[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Jboss Migrating to Virgo

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.


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:



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
> â Âââ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