[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [virgo-dev] Jboss Migrating to Virgo
|
Hi Dmitry,
Yes, you said is exactly what we want to
implement. Our EAR package doesn't contain any connectors (jca), ejb and ejb
client. We only want to expose non-osgi artifacts to war/bundle classpath. And
we don't want OSGI features for these third part artifacts.
Best Regards
Lin Fengqi
On Fri, Nov 19, 2010 at 10:25 PM,
<virgo-dev-request@xxxxxxxxxxx> wrote:
Send virgo-dev mailing list submissions to
virgo-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/virgo-dev
or, via email, send a message with subject or body 'help' to
virgo-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
virgo-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of virgo-dev digest..."
Today's Topics:
1. Re: Jboss Migrating to Virgo (Dmitry Sklyut)
----------------------------------------------------------------------
Message: 1
Date: Fri, 19 Nov 2010 09:25:37 -0500
From: Dmitry Sklyut <dmitry@xxxxxxxxxxx>
To: Virgo Project <virgo-dev@xxxxxxxxxxx>
Subject: Re: [virgo-dev] Jboss Migrating to Virgo
Message-ID:
<AANLkTimUW70QY9Cszuhu2NA9W6vY5NenD1kf23WB+o_F@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
Looking at Lin's example, there will be a bunch of bundles in number of
sub-directories plus potentially some 3rd party non-osgi bundle artifacts in
"lib" directory as well as configuration in "config" directory. But if it
is a fully "legacy" ear deployment - Virgo can really only support type=war
and jar (bundelized or not bundelized). No connectors (jca), ejb, ejb
client. Non supported types can be dealt with easily. The remaining
question is how to expose non-osgi artifacts to war/bundle classpath.
But that stated me thinking about this post of Paul Fremantle's response to
Mule on osgi complexity:
http://pzf.fremantle.org/2010/11/using-osgi-as-core-of-middleware.html.
<quote>
Drop a JAR in and *we *take care of the OSGi bundling for you.
</quote>
Something to consider as an extension maybe? There isn't really a full
proof way to do it (that I know of :)) unless Bundlor becomes mighty smarter
than it is now.
On Fri, Nov 19, 2010 at 8:31 AM, Glyn Normington <gnormington@xxxxxxxxxx>wrote:
> That could work but it could bloat the footprint of the deployed EAR a lot.
> There could be restrictions too if classes from these JARs needed to be
> shared between the bundles.
>
> But now you've got me wondering. How many bundles will there typically be
> in a "legacy" EAR? Presumably zero.
>
> Regards,
> Glyn
>
> On 19 Nov 2010, at 12:32, Dmitry Sklyut wrote:
>
> > Would it make sense to add those libs to all bundles in archive? That
> would solve TCCL issue me thinks
> >
> > ?
> >
> > Sent from my iPhone
> >
> > On Nov 19, 2010, at 7:02, Glyn Normington <gnormington@xxxxxxxxxx>
> wrote:
> >
> >> I don't *think* the class loader of the synthetic context bundle is set
> as the TCCL at all points where it might be needed. Currentlym it is set on
> the way out of PARs when invoking 3rd party bundles outside the PAR.
> >>
> >> Then there's the issue of how a TCCL will be invoked. You don't get this
> for free in OSGi.
> >>
> >> I'm not saying it couldn't work, just that there may be issues to
> overcome.
> >>
> >> Regards,
> >> Glyn
> >>
> >> On 19 Nov 2010, at 11:44, Dmitry Sklyut wrote:
> >>
> >>> Wouldn't scope drive TCCL usage implicitly? So if deployer adds "lib"
> jars to the Bundle-ClassPath of the synthetic context bundle wouldn't that
> be enough?
> >>>
> >>> I am very close to pushing rough draft of ear deployer to git hub. Will
> follow up with links to the code
> >>>
> >>> Regards
> >>> Dmitry
> >>>
> >>> On Nov 19, 2010, at 5:57, Glyn Normington <gnormington@xxxxxxxxxx>
> wrote:
> >>>
> >>>> Virgo does not convert JARs into bundles. That's something which is
> usually done offline using a tool like bundlor. I guess you could run
> bundlor programmatically when processing an EAR.
> >>>>
> >>>> Using a thread context class loader seems more problematic. For
> instance, how would you know that thread context class loading would be used
> each time a class needs to be loaded from one of the JARs? Bundle class
> loaders do not use thread context class loaders, so thread context class
> loading needs to be programmed in the code that needs to do the loading.
> >>>>
> >>>> Regards,
> >>>> Glyn
> >>>>
> >>>> On 19 Nov 2010, at 09:38, Linfengqi wrote:
> >>>>
> >>>> Hi Glyn,
> >>>>
> >>>> I have a question for implement a custom deployers now. If there is a
> "lib" directory in EAR package, and there are some third part jar files in
> lib directory, my question is : how to load these jars into Virgo? Does the
> Virgo will convert each jar file in the "lib" directory to a standalone
> bundle, or just add the path of jar into thread context classloader? Thanks
> a lot!
> >>>>
> >>>> Best Regards,
> >>>> Lin Fengqi
> >>>>
> >>>> On Thu, Nov 18, 2010 at 5:21 AM, <virgo-dev-request@xxxxxxxxxxx
> <mailto:virgo-dev-request@xxxxxxxxxxx>> wrote:
> >>>> Send virgo-dev mailing list submissions to
> >>>> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>
> >>>>
> >>>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >>>> or, via email, send a message with subject or body 'help' to
> >>>> virgo-dev-request@xxxxxxxxxxx<mailto:virgo-dev-request@xxxxxxxxxxx
> >
> >>>>
> >>>> You can reach the person managing the list at
> >>>> virgo-dev-owner@xxxxxxxxxxx<mailto:virgo-dev-owner@xxxxxxxxxxx>
> >>>>
> >>>> When replying, please edit your Subject line so it is more specific
> >>>> than "Re: Contents of virgo-dev digest..."
> >>>>
> >>>>
> >>>> Today's Topics:
> >>>>
> >>>> 1. Re: Jboss Migrating to Virgo (Glyn Normington)
> >>>> 2. Re: Jboss Migrating to Virgo (Dmitry Sklyut)
> >>>> 3. Re: Jboss Migrating to Virgo (Glyn Normington)
> >>>>
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>
> >>>> Message: 1
> >>>> Date: Wed, 17 Nov 2010 10:17:25 -0800
> >>>> From: Glyn Normington <gnormington@xxxxxxxxxx<mailto:
> gnormington@xxxxxxxxxx>>
> >>>> To: Virgo Project <virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx
> >>
> >>>> Subject: Re: [virgo-dev] Jboss Migrating to Virgo
> >>>> Message-ID: <E41AF26E-0F8B-4470-98FD-F5916B3D452C@xxxxxxxxxx<mailto:
> E41AF26E-0F8B-4470-98FD-F5916B3D452C@xxxxxxxxxx>>
> >>>> Content-Type: text/plain; charset="us-ascii"
> >>>>
> >>>> Hi Lin/Dmitry
> >>>>
> >>>> Please note that it is definitely an objective of Virgo to enable the
> deployer to be extended by non-kernel bundles and in particular to allow
> non-kernel bundles to add artifact types. The only thing preventing this
> from happening is resourcing/priorities. If you can provide patches, this
> may speed up the solution. For bug 320721, I still favour ensuring the
> deployer can handle instances of InstallArtifact that do not extend
> AbstractInstallArtifact as a clean first step.
> >>>>
> >>>> Regards,
> >>>> Glyn
> >>>>
> >>>> On 17 Nov 2010, at 05:58, Linfengqi wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Nov 16, 2010 at 11:13 PM, <virgo-dev-request@xxxxxxxxxxx
> <mailto:virgo-dev-request@xxxxxxxxxxx><mailto:
> virgo-dev-request@xxxxxxxxxxx<mailto:virgo-dev-request@xxxxxxxxxxx>>>
> wrote:
> >>>> Send virgo-dev mailing list submissions to
> >>>> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx><mailto:
> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
> >>>>
> >>>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >>>> or, via email, send a message with subject or body 'help' to
> >>>> virgo-dev-request@xxxxxxxxxxx<mailto:virgo-dev-request@xxxxxxxxxxx
> ><mailto:virgo-dev-request@xxxxxxxxxxx<mailto:
> virgo-dev-request@xxxxxxxxxxx>>
> >>>>
> >>>> You can reach the person managing the list at
> >>>> virgo-dev-owner@xxxxxxxxxxx<mailto:virgo-dev-owner@xxxxxxxxxxx
> ><mailto:virgo-dev-owner@xxxxxxxxxxx<mailto:virgo-dev-owner@xxxxxxxxxxx>>
> >>>>
> >>>> When replying, please edit your Subject line so it is more specific
> >>>> than "Re: Contents of virgo-dev digest..."
> >>>>
> >>>>
> >>>> Today's Topics:
> >>>>
> >>>> 1. Re: Jboss Migrating to Virgo (Lin Fengqi)
> >>>>
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>
> >>>> Message: 1
> >>>>
> >>>> Hi Dmitry,
> >>>>
> >>>> 1. Do you still have requirement on start up order of osgi artifacts?
> That is core > system > platform > infrastructure > plugins > trade.war?
> >>>>
> >>>> Yes, we have start-level property file to define this requirement, and
> it's processed by Nuxeo OSGI framework now. But we want to move the
> start-level to the Virgo in the future.
> >>>>
> >>>> 2. Config folder might only be reliably accessed by using thread
> context classloader. Is that acceptable?
> >>>>
> >>>> Yes, it's acceptable. But how to add the resources into thread context
> classloader at the runtime of Virgo? Does the Virgo will switch the thread
> context classloader to the specific one at the runtime?
> >>>>
> >>>> I have read the document about Pipeline and Scoping, and study these
> two interfaces. Thanks for your information!
> >>>>
> >>>> For working on a prototype, I'm glad to participate and collaborate
> with you!
> >>>>
> >>>> Best Regards
> >>>> Lin Fengqi
> >>>>
> >>>>
> >>>>
> >>>> Date: Tue, 16 Nov 2010 10:13:54 -0500
> >>>> From: Dmitry Sklyut <dmitry@xxxxxxxxxxx<mailto:dmitry@xxxxxxxxxxx
> ><mailto:dmitry@xxxxxxxxxxx<mailto:dmitry@xxxxxxxxxxx>>>
> >>>> To: Virgo Project <virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx
> ><mailto:virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>>
> >>>> Subject: Re: [virgo-dev] Jboss Migrating to Virgo
> >>>> Message-ID:
> >>>> <AANLkTi=v0rzU8pOFwEPSMUV++uqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx<v0rzU8pOFwEPSMUV%2B%2BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx>
> <mailto:v0rzU8pOFwEPSMUV%2B%2BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx<v0rzU8pOFwEPSMUV%252B%252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx>
> ><mailto:v0rzU8pOFwEPSMUV%2B%2BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx<v0rzU8pOFwEPSMUV%252B%252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx>
> <mailto:v0rzU8pOFwEPSMUV%252B%252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx<v0rzU8pOFwEPSMUV%25252B%25252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx>
> >>>
> >>>> Content-Type: text/plain; charset="iso-8859-1"
> >>>>
> >>>> Hi Lin,
> >>>>
> >>>> Thanks for the info. Few more questions:
> >>>>
> >>>> 1. Do you still have requirement on start up order of osgi artifacts?
> That
> >>>> is core > system > platform > infrastructure > plugins > trade.war?
> >>>> 2. Config folder might only be reliably accessed by using thread
> context
> >>>> classloader. Is that acceptable?
> >>>>
> >>>>
> >>>> As for the implementation: I started working on a custom deployer a
> while
> >>>> back but never finished. I have some notes left over and need to go
> back
> >>>> and remember the process once again.
> >>>>
> >>>> If you want to take some time and get familiar with the process, you
> can
> >>>> start with looking at this (to understand deployment pipeline)
> >>>> http://wiki.eclipse.org/Virgo/Concepts#Pipeline.
> >>>> There are few other concepts that are explained there, i.e.
> Transformers and
> >>>> Scoping (http://wiki.eclipse.org/Virgo/Concepts#Scoping).
> >>>>
> >>>> There are few other things you have to be aware of:
> >>>>
> >>>> 1. org.eclipse.virgo.repository.AftifactBridge
> >>>> 2.org.eclipse.virgo.kernel.install.artifact.InstallArtifact
> >>>>
> >>>> #1 is used to read deployed artifact and generate descriptors for
> pipeline
> >>>> to consume. #2 encapsulate lifecycle logic for a specific type of an
> >>>> installed artifact.
> >>>>
> >>>> I have been trying to find the time to write up something concreate on
> >>>> custom deployed artifacts for months now, but work and life gets in
> the way
> >>>> :)
> >>>>
> >>>> If you are interested in participating on working on a prototype, I
> can
> >>>> throw together an initial implementation on github and we can
> collaborate on
> >>>> implementation.
> >>>> There are a lot of edge cases that might be specific to your
> deployment
> >>>> structure that would be missed without your input. For example start
> order
> >>>> of artifacts.
> >>>>
> >>>> Regards,
> >>>> Dmitry
> >>>>
> >>>>
> >>>> On Tue, Nov 16, 2010 at 1:42 AM, Linfengqi <linfengqi@xxxxxxxxx
> <mailto:linfengqi@xxxxxxxxx><mailto:linfengqi@xxxxxxxxx<mailto:
> linfengqi@xxxxxxxxx>>> wrote:
> >>>>
> >>>>>
> >>>>>>
> >>>>> 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<mailto:dmitry@xxxxxxxxxxx
> ><mailto:dmitry@xxxxxxxxxxx<mailto:dmitry@xxxxxxxxxxx>>>
> >>>>>> To: Virgo Project <virgo-dev@xxxxxxxxxxx<mailto:
> virgo-dev@xxxxxxxxxxx><mailto:virgo-dev@xxxxxxxxxxx<mailto:
> virgo-dev@xxxxxxxxxxx>>>
> >>>>>> Subject: Re: [virgo-dev] Jboss Migrating to Virgo
> >>>>>> Message-ID:
> >>>>>> <AANLkTi=cmbcD3bztMcjiOBZ0JhRLiPrsUB7zKg1xgtc1@xxxxxxxxxxxxxx
> <mailto:cmbcD3bztMcjiOBZ0JhRLiPrsUB7zKg1xgtc1@xxxxxxxxxxxxxx><mailto:
> cmbcD3bztMcjiOBZ0JhRLiPrsUB7zKg1xgtc1@xxxxxxxxxxxxxx<mailto:
> cmbcD3bztMcjiOBZ0JhRLiPrsUB7zKg1xgtc1@xxxxxxxxxxxxxx>>>
> >>>>>> Content-Type: text/plain; charset="utf-8"
> >>>>>>
> >>>>>>
> >>>>>> 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<mailto:gnormington@xxxxxxxxxx><mailto:
> gnormington@xxxxxxxxxx<mailto: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<mailto:virgo-dev@xxxxxxxxxxx><mailto:
> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
> >>>>>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> virgo-dev mailing list
> >>>>>>> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx><mailto:
> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
> >>>>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >>>>>>>
> >>>>>> -------------- next part --------------
> >>>>>> An HTML attachment was scrubbed...
> >>>>>> URL: <
> >>>>>>
> https://dev.eclipse.org/mailman/private/virgo-dev/attachments/20101115/e03152e8/attachment.htm
> >>>>>>>
> >>>>>>
> >>>>>> ------------------------------
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> virgo-dev mailing list
> >>>>>> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx><mailto:
> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
> >>>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >>>>>>
> >>>>>>
> >>>>>> End of virgo-dev Digest, Vol 9, Issue 12
> >>>>>> ****************************************
> >>>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> virgo-dev mailing list
> >>>>> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx><mailto:
> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
> >>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >>>>>
> >>>>>
> >>>> -------------- next part --------------
> >>>> An HTML attachment was scrubbed...
> >>>> URL: <
> https://dev.eclipse.org/mailman/private/virgo-dev/attachments/20101116/d74a9355/attachment.htm
> >
> >>>>
> >>>> ------------------------------
> >>>>
> >>>> _______________________________________________
> >>>> virgo-dev mailing list
> >>>> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx><mailto:
> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
> >>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >>>>
> >>>>
> >>>> End of virgo-dev Digest, Vol 9, Issue 15
> >>>> ****************************************
> >>>>
> >>>> <ATT00001..txt>
> >>>>
> >>>>
> >>>>
> >>>> ------------------------------
> >>>>
> >>>> Message: 2
> >>>> Date: Wed, 17 Nov 2010 14:42:49 -0500
> >>>> From: Dmitry Sklyut <dmitry@xxxxxxxxxxx<mailto:dmitry@xxxxxxxxxxx>>
> >>>> To: Virgo Project <virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx
> >>
> >>>> Subject: Re: [virgo-dev] Jboss Migrating to Virgo
> >>>> Message-ID:
> >>>> <AANLkTink6rHKS3hn9cWVjxV+fKc9D+nTy3_L+yO2__Ty@xxxxxxxxxxxxxx<AANLkTink6rHKS3hn9cWVjxV%2BfKc9D%2BnTy3_L%2ByO2__Ty@xxxxxxxxxxxxxx>
> <mailto:AANLkTink6rHKS3hn9cWVjxV%2BfKc9D%2BnTy3_L%2ByO2__Ty@xxxxxxxxxxxxxx<AANLkTink6rHKS3hn9cWVjxV%252BfKc9D%252BnTy3_L%252ByO2__Ty@xxxxxxxxxxxxxx>
> >>
> >>>> Content-Type: text/plain; charset="iso-8859-1"
> >>>>
> >>>> Glyn,
> >>>>
> >>>> After looking at ArtifactIdentityDeterminer both Standard and
> Delegating, it
> >>>> looks like the job can be done with just ArtifactBridge without
> >>>> custom ArtifactIdentityDeterminer for ear.
> >>>> As long as bridge is published it will be queried first for
> >>>> AftifactDescriptor. The only benefit that custom
> ArtifactIdentityDeterminer
> >>>> can provide is examining the file extension.
> >>>>
> >>>> WDYT?
> >>>>
> >>>> Regards,
> >>>> Dmitry
> >>>>
> >>>> On Tue, Nov 16, 2010 at 10:59 AM, Glyn Normington <
> gnormington@xxxxxxxxxx<mailto:gnormington@xxxxxxxxxx>>wrote:
> >>>>
> >>>>> On 16 Nov 2010, at 15:13, Dmitry Sklyut wrote:
> >>>>>
> >>>>> There are few other things you have to be aware of:
> >>>>>
> >>>>> 1. org.eclipse.virgo.repository.AftifactBridge
> >>>>> 2.org.eclipse.virgo.kernel.install.artifact.InstallArtifact
> >>>>>
> >>>>> #1 is used to read deployed artifact and generate descriptors for
> pipeline
> >>>>> to consume. #2 encapsulate lifecycle logic for a specific type of an
> >>>>> installed artifact.
> >>>>>
> >>>>> One correction.
> >>>>>
> >>>>> Actually #1 is used by the Virgo repository to determine the (type,
> name,
> >>>>> version) identity of an artifact found while scanning the repository.
> Lin
> >>>>> will need to implement this to make the repository recognize EARs.
> >>>>>
> >>>>> org.eclipse.virgo.kernel.install.artifact.ArtifactIdentityDeterminer
> is the
> >>>>> interface for determining the identity of an artifact which is being
> >>>>> deployed. Lin will need to implement this so EARs can be deployed,
> e.g. by
> >>>>> dropping in the pickup directory.
> >>>>>
> >>>>>
> >>>>> I have been trying to find the time to write up something concreate
> on
> >>>>> custom deployed artifacts for months now, but work and life gets in
> the way
> >>>>> :)
> >>>>>
> >>>>> I know the feeling.
> >>>>>
> >>>>>
> >>>>> If you are interested in participating on working on a prototype, I
> can
> >>>>> throw together an initial implementation on github and we can
> collaborate on
> >>>>> implementation.
> >>>>> There are a lot of edge cases that might be specific to your
> deployment
> >>>>> structure that would be missed without your input. For example start
> order
> >>>>> of artifacts.
> >>>>>
> >>>>> This is a great suggestion and would allow us to identify and answer
> the
> >>>>> remaining questions about adding an artifact type.
> >>>>>
> >>>>> Regards,
> >>>>> Glyn
> >>>>> _______________________________________________
> >>>>> virgo-dev mailing list
> >>>>> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>
> >>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >>>>>
> >>>> -------------- next part --------------
> >>>> An HTML attachment was scrubbed...
> >>>> URL: <
> https://dev.eclipse.org/mailman/private/virgo-dev/attachments/20101117/0b625c96/attachment.htm
> >
> >>>>
> >>>> ------------------------------
> >>>>
> >>>> Message: 3
> >>>> Date: Wed, 17 Nov 2010 13:21:22 -0800
> >>>> From: Glyn Normington <gnormington@xxxxxxxxxx<mailto:
> gnormington@xxxxxxxxxx>>
> >>>> To: Virgo Project <virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx
> >>
> >>>> Subject: Re: [virgo-dev] Jboss Migrating to Virgo
> >>>> Message-ID: <515A4531-FD37-4730-81C1-9D277DAA2AA8@xxxxxxxxxx<mailto:
> 515A4531-FD37-4730-81C1-9D277DAA2AA8@xxxxxxxxxx>>
> >>>> Content-Type: text/plain; charset="us-ascii"
> >>>>
> >>>> Hi Dmitry
> >>>>
> >>>> I haven't been into that area of the code for a long time, so what you
> say sounds plausible. Thanks!
> >>>>
> >>>> Regards,
> >>>> Glyn
> >>>>
> >>>> On 17 Nov 2010, at 19:42, Dmitry Sklyut wrote:
> >>>>
> >>>> Glyn,
> >>>>
> >>>> After looking at ArtifactIdentityDeterminer both Standard and
> Delegating, it looks like the job can be done with just ArtifactBridge
> without custom ArtifactIdentityDeterminer for ear.
> >>>> As long as bridge is published it will be queried first for
> AftifactDescriptor. The only benefit that custom ArtifactIdentityDeterminer
> can provide is examining the file extension.
> >>>>
> >>>> WDYT?
> >>>>
> >>>> Regards,
> >>>> Dmitry
> >>>>
> >>>> On Tue, Nov 16, 2010 at 10:59 AM, Glyn Normington <
> gnormington@xxxxxxxxxx<mailto:gnormington@xxxxxxxxxx><mailto:
> gnormington@xxxxxxxxxx<mailto:gnormington@xxxxxxxxxx>>> wrote:
> >>>> On 16 Nov 2010, at 15:13, Dmitry Sklyut wrote:
> >>>>
> >>>> There are few other things you have to be aware of:
> >>>>
> >>>> 1. org.eclipse.virgo.repository.AftifactBridge
> >>>> 2.org.eclipse.virgo.kernel.install.artifact.InstallArtifact
> >>>>
> >>>> #1 is used to read deployed artifact and generate descriptors for
> pipeline to consume. #2 encapsulate lifecycle logic for a specific type of
> an installed artifact.
> >>>>
> >>>> One correction.
> >>>>
> >>>> Actually #1 is used by the Virgo repository to determine the (type,
> name, version) identity of an artifact found while scanning the repository.
> Lin will need to implement this to make the repository recognize EARs.
> >>>>
> >>>> org.eclipse.virgo.kernel.install.artifact.ArtifactIdentityDeterminer
> is the interface for determining the identity of an artifact which is being
> deployed. Lin will need to implement this so EARs can be deployed, e.g. by
> dropping in the pickup directory.
> >>>>
> >>>>
> >>>> I have been trying to find the time to write up something concreate on
> custom deployed artifacts for months now, but work and life gets in the way
> :)
> >>>>
> >>>> I know the feeling.
> >>>>
> >>>>
> >>>> If you are interested in participating on working on a prototype, I
> can throw together an initial implementation on github and we can
> collaborate on implementation.
> >>>> There are a lot of edge cases that might be specific to your
> deployment structure that would be missed without your input. For example
> start order of artifacts.
> >>>>
> >>>> This is a great suggestion and would allow us to identify and answer
> the remaining questions about adding an artifact type.
> >>>>
> >>>> Regards,
> >>>> Glyn
> >>>> _______________________________________________
> >>>> virgo-dev mailing list
> >>>> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx><mailto:
> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
> >>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >>>>
> >>>> <ATT00001..txt>
> >>>>
> >>>>
> >>>>
> >>>> ------------------------------
> >>>>
> >>>> _______________________________________________
> >>>> virgo-dev mailing list
> >>>> virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>
> >>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >>>>
> >>>>
> >>>> End of virgo-dev Digest, Vol 9, Issue 20
> >>>> ****************************************
> >>>>
> >>>> <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
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/virgo-dev/attachments/20101119/611b3fd4/attachment.htm>
------------------------------
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev
End of virgo-dev Digest, Vol 9, Issue 38
****************************************