| Re: [virgo-dev] Jboss Migrating to Virgo |
Hi Dmitry,
Thanks for your reply.
For your first question, we don't want to add headers in EAR package similar to PAR. We prefer to deploy plain EAR files. The EAR files don't know any OSGI headers. But we implement each of jar file in "core", "system", "platform" and "infrastructure" directory as a standalone OSGI bundle.
The "config" folder contains log4j.xml and other configuration files. We only want to add config directory to the classpath, so any code can reference it.
The OSGI-INF folder contains some self-defined property files to support the Nuxeo OSGI module. The property file defines the start level for each bundle. But we will remove this folder when the projects migrate to Virgo, and use the internal start level in Virgo.
And now, it's a little difficult to implement a custom deployer for Virgo. So we don't know how to start it. Could you give us some guide or procedure? Thank you very much!
Best Regards
Lin Fengqi
Message: 1
Date: Mon, 15 Nov 2010 11:42:13 -0500
From: Dmitry Sklyut <dmitry@xxxxxxxxxxx>
To: Virgo Project <virgo-dev@xxxxxxxxxxx>
Subject: Re: [virgo-dev] Jboss Migrating to Virgo
Message-ID:
<AANLkTi=cmbcD3bztMcjiOBZ0JhRLiPrsUB7zKg1xgtc1@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"-------------- next part --------------
Hi Lin,
Can you provide a bit more information about expectations of EAR deployer
with your specific packaging?
Do you expect ear to contain headers similar to PAR? I was thinking that it
would be a good addition to allow deployment of plain ear files, similar to
how war files are deployed without having to know of any OSGi headers.
Some questions that I have relate to* *contents of *config * subdirectory as
well as *core, infrastructure, etc.*
*
*
I am assuming that config will contain properties and xml descriptors.
log4j.xml file aside - you can use logback.xml at the root of the bundle
with log4j bridge (already deployed) to deal with logging configuration. Do
you expect any property file found in the ear to be deployed as a
ConfigurationAdmin artifact, or just add config directory to the classpath
of the ear so any code can reference it (probably through TCCL only)?
Will contents of core, system, platform be jars or ready made bundles?
Deployer can be made smart enough to add plain jars to the Bundle-ClassPath
of a the Synthetic context bundle. This can be done with Ear manifest
Class-Path: header parsing or looking at the deployment descriptors (I think
jee 5 added that capability in application.xml).
What kind of information are you storing in OSGI-INF?
This is a very interesting addition to Virgo. I think there is a need for a
detailed discussion on how far to take it. I think there must be some
limits on the supported level of jee spec configuration file supported and
very explicit contraints on what is actually "deployable". Maybe limit
deployed units to:
1. Any jar at the top level of the ear must be:
1.1 Valid bundle
1.2 Valid JAR - in this case it will included to the Bundle-ClassPath of the
Synthetic context bundle
2. Can't have any nested pars/ear/plans
Not sure how to deal with "configuration" yet. That is - should it be
deployed as ConfigurationAdmin. Maybe again if it is at the top level of
ear - it will be treated as configuration admin properties.
Regards,
Dmitry
On Fri, Nov 12, 2010 at 9:16 AM, Glyn Normington <gnormington@xxxxxxxxxx>wrote:
> Sorry about all the opengrok URLs which you wont be able to follow. What I
> meant was:
>
>
> org.eclipse.virgo.kernel.deployer/src/main/java/org/eclipse/virgo/kernel/install/artifact/internal/ParPlanInstallArtifact.java
>
> Regards,
> Glyn
>
> On 12 Nov 2010, at 14:13, Glyn Normington wrote:
>
> > Hi Lin
> >
> > This sounds like a fascinating project. Others have expressed interest in
> supporting EARs on top of Virgo in the past. Essentially, I see this as a
> variant of a PAR file. The kernel was designed with the ability to add
> custom artifact types in mind, but no-one outside the kernel has achieved
> this yet AFAIK. There are some enhancement bugs that you should take a look
> at:
> >
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=320721
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=315867
> >
> > Then I would start to look in the kernel at:
> >
> > org.eclipse.virgo.kernel.deployer<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer
> >/src<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer/src
> >/main<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer/src/main
> >/java<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer/src/main/java
> >/org<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer/src/main/java/org
> >/eclipse<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer/src/main/java/org/eclipse
> >/virgo<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer/src/main/java/org/eclipse/virgo
> >/kernel<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer/src/main/java/org/eclipse/virgo/kernel
> >/install<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer/src/main/java/org/eclipse/virgo/kernel/install
> >/artifact<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer/src/main/java/org/eclipse/virgo/kernel/install/artifact
> >/internal<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer/src/main/java/org/eclipse/virgo/kernel/install/artifact/internal
> >/ParPlanInstallArtifact.java<
> http://sou-opengrok.eng.vmware.com:8080/xref/virgo/org.eclipse.virgo.kernel/org.eclipse.virgo.kernel.deployer/src/main/java/org/eclipse/virgo/kernel/install/artifact/internal/ParPlanInstallArtifact.java
> >
> >
> > and associated types. Please then continue the discussion on this thread
> and raise bugs as appropriate as you see the need to change the kernel
> (probably to expose more types for your EAR support to use). Ultimately, you
> should develop one or more bundles that provides a kernel extension to
> support an EAR artifact type. This can then be configured into the Virgo web
> server so it is available before any applications get deployed and so you'll
> then be able to deploy EARs using any of the standard techniques.
> >
> > One other wrinkle is that you'll probably need to add EARs to the set of
> artifact types that the Virgo repository component can regcognize. I can
> give you some pointers on this when you are ready. You'll then be able to
> store EAR files in a Virgo repository and deploy them as part of a plan.
> >
> > Given the apparent size of your project, I would hope you may be able to
> develop some Virgo internals skills and submit patches for the bugs you
> raise so that we can get this implemented approximately at your pace rather
> than being held back waiting for committers to implement changes on your
> behalf, but let's see how we go and we'll do our best to help you.
> >
> > Regards,
> > Glyn
> > PS. I hope it's ok to address you as "Lin".
> >
> > On 12 Nov 2010, at 06:25, Linfengqi wrote:
> >
> > Hi virgo-dev,
> >
> > We have investigated the Virgo project, and the Virgo is a powerful
> server to support the OSGI and SOA architecture. So we planned to migrate
> from Jboss to Virgo, currently we use EAR deployment, but we didn't use EJB
> in EAR package, we use the Spring Dynamic Modules and Nuxeo OSGI module to
> implement distributed services, and other third part library.
> >
> > For now I saw the Virgo doesn't support the directory structure of EAR
> package, in order to migrating to Virgo, We have to modify EAR package or
> implement new EAR deployment in Virgo. We compared these two approaches, and
> we prefer to the second one which implements the EAR deployment in Virgo,
> because we have hundreds of projects, it's a big risk and huge workload to
> modify the whole EAR packages.
> >
> > And I want to know if we decide to implement a new EAR deployment, what
> should we to do? Is there any interface or procedure to do this? I read the
> User guide and Programmer Guide, but there are a few content talks about
> this. Do you have any ideas or suggestions for us, thanks a lot!
> >
> > The directory structure of EAR package which we used is bellowing:
> >
> > ??config -----------------> contains some
> configuration file, like log4j.xml
> > ? ??autoconf
> > ??core -----------------> contains the core
> module for application
> > ??infrastructure -----------------> contains the core module
> for framework
> > ??lib -----------------> contains the third
> part library
> > ??META-INF -----------------> the meta data for package
> > ??OSGI-INF -----------------> the meta data for OSGI
> > ? ??templates
> > ??platform -----------------> contains the core module
> for framework
> > ??plugins -----------------> contains the core module
> for application
> > ??trade.war -----------------> the web part for
> application
> > ? ??META-INF
> > ? ??WEB-INF
> > ??system -----------------> contains the core module
> for framework
> >
> >
> > Best Regards!
> > Lin Fengqi
> > <ATT00001..txt>
> >
> > _______________________________________________
> > virgo-dev mailing list
> > virgo-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/virgo-dev
>
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/virgo-dev/attachments/20101115/e03152e8/attachment.htm>
------------------------------End of virgo-dev Digest, Vol 9, Issue 12
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev
****************************************
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev