| I remembered the way to add a (fragment) bundle to the kernel for the deployer integration tests is to provide a config file e.g. [3] and then specify this using the @ConfigLocation as in DeployerLogMessageTests [4]:
@ConfigLocation("META-INF/no.heap.dump.test.config.properties")
public class DeployerLogMessageTests extends AbstractParTests {
Of course this approach is probably only a temporary measure since the EAR file support does not belong in the kernel and will most likely not be contributed to Virgo. However, it's a reasonably straightforward way of enabling us to collaborate.
On 7 Dec 2010, at 06:39, Glyn Normington wrote: Actually the approach below would not work in the case of a fragment because the fragment needs to attach to the deployer bundle during kernel initialisation.
Lin: are you planning to write a fragment of the deployer bundle to start with? If so, we'll have to find a way to attach it to the deployer during initialisation of the kernel in the test environment.
On 7 Dec 2010, at 03:21, Glyn Normington wrote: Ok. You could start to develop a testcase EarDeploymentTests by copying/changing ParDeploymentTests [1]. You could write your EAR deployer extension as a fragment of the deployer bundle and add it to a test repository configured in [2]. This would enable you to make progress without any changes to the kernel.
One way to collaborate would be for you to make these changes in your own fork of the kernel repository on github, probably on your own branch for ease of communication.
Then we committers could work on refactoring the kernel so that the deployer extension can become a regular (non-fragment) bundle which would be deployed at the start of the testcase. To synchronise your fork, you would pull our changes, merge them into your branch, and push the branch to github.
Does that sound reasonable?
Dmitry and other "soon to be committers": does that approach sound best to you or can you suggest something smoother?
On 4 Dec 2010, at 08:46, Linfengqi wrote: Hi Glyn,
Yes, I'm very interested in these integration tests. And I'm still work on implementing the EAR deployer for Virgo.
Best Regards,
Lin Fengqi
On Fri, Dec 3, 2010 at 5:55 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 (Glyn Normington)
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Dec 2010 09:55:24 +0000
From: Glyn Normington <gnormington@xxxxxxxxxx>
To: Virgo Project <virgo-dev@xxxxxxxxxxx>
Subject: Re: [virgo-dev] Jboss Migrating to Virgo
Message-ID: <4D219580-EE92-44AF-87F5-151574E06AB5@xxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
Hi Lin
We discussed adding artifact types during the recent Virgo F2F. Dmitry has a proposal for refactoring the deployer to help in this.
One or more integration tests would really help to tie down the requirements, but I'm not sure who has the time+skills to write these. If that's something you may be interested in looking at, please say so! The tests would probably build some very simple EARs from source (using our build system) and then test the content appearing after deployment. These tests would of course fail without the necessary deployer extension. They could be made to pass by extending the deployer using a fragment (something that Dmitry has successfully managed in the past) and then the task before us would be to refactor the deployer so a non-fragment bundle could achieve the same effect using only public deployer/kernel APIs.
Regards,
Glyn
On 23 Nov 2010, at 10:33, Linfengqi wrote:
> Hi Dmitry,
>
> Thanks for your information!
>
> If we want to implement custom deployer, does this mean we only need to implement org.eclipse.virgo.repository.
> AftifactBridge and org.eclipse.virgo.kernel.
> install.artifact.InstallArtifact interfaces, and configure the classes in Virgo by spring context, is this enough? If not, what else we have to do? Thanks a lot!
>
>
> Best Regards,
> Lin Fengqi
>
>
> On Tue, Nov 23, 2010 at 5:04 AM, <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: Mon, 22 Nov 2010 16:04:54 -0500
> From: Dmitry Sklyut <dmitry@xxxxxxxxxxx>
> To: Virgo Project <virgo-dev@xxxxxxxxxxx>
> Subject: Re: [virgo-dev] Jboss Migrating to Virgo
> Message-ID:
> <AANLkTinhKQoksuWhVKKOYSODcWGpADCPQy2MJGMQvM=q@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="iso-8859-1"
>
> A little more research and it looks to me like StandardPlanInstallArtifact
> should be exposed also.
> There are some code in places (for example ImportExpandingTransformer,
> AtomicInstallArtifactLifecycleListener
> and StandardBundleInstallArtifact) that try to cast or instanceof check for
> PlanInstallArtifacts as it is the only component that can have scope and
> atomic behavior.
>
> Can the "standard" InstallArtifacts be promoted to a public package? There
> will be a lot of extra code to write otherwise.
>
> Regards,
> Dmitry
>
> On Mon, Nov 22, 2010 at 2:58 PM, Dmitry Sklyut <dmitry@xxxxxxxxxxx> wrote:
>
> > A little further research and some more items might need to be escalated in
> > visibility in addition to
> > org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact
> > or at least get interfaces and be published as services.
> >
> > 1. org.eclipse.virgo.kernel.install.artifact.internal.ArtifactStateMonitor;
> > Is called by AbstractInstallArtifact during lifecycle change events (i.e.
> > installing/installed/resolved/etc) and
> > notifies InstallArtifactLifecycleListener on state change. I think this
> > class is fairly safe to be moved up into public package.
> >
> > 2.
> > org.eclipse.virgo.kernel.install.artifact.internal.InstallArtifactRefreshHandler;
> > Is called on refresh and delegates to a bean generated by bundle private
> > Plumber.getRefreshSubpipeline bean. I think at least interface can be moved
> > up to a public package and service is published. Not sure if there is a way
> > to get a reference to a "refresh sub-pipeline" pipeline otherwise as Plumber
> > in in internal package.
> >
> > I am also wonder on the best way to get a reference to a specific
> > InstallArtifactTreeFactory. Maybe each of the core types can get a
> > subinterface or service properties? Third party deployers might want to get
> > a reference to a BundleInstallArtifactTreeFactory or
> > ConfigInstallArtifactTreeFactory.
> >
> > As for AbstractIntallArtifact - attached is a fairly crude patch. I just
> > picked up the AbstractInstallArtifact specific methods and moved them to a
> > publicly visible interface.
> > I am not advocating taking this patch as it is now (although tests pass),
> > just want to start a discussion on the way forward.
> >
> > Regards,
> > Dmitry
> >
> > On Sat, Nov 20, 2010 at 1:34 PM, Glyn Normington <gnormington@xxxxxxxxxx>wrote:
> >
> >> Hi Lin
> >>
> >> repository/ext and repository/usr contain bundles, not "plain" JARs.
> >>
> >> Glyn
> >> On Nov 20, 2010, at 1:33 PM, Linfengqi wrote:
> >>
> >> Hi Glyn,
> >>
> >> As you said, the Virgo doesn't convert the jars into bundles. I'm
> >> wondering how the Virgo processes the jars in "repository/ext" and
> >> "repository/usr" directory? And what's the mechanism of other bundles
> >> reference the jars in "repository/ext" and "repository/usr" directory?
> >>
> >> Best Regards
> >> Lin Fengqi
> >>
> >>
> >>
> >> On Fri, Nov 19, 2010 at 6:57 PM, <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: Security in Virgo (Glyn Normington)
> >> 2. Re: Jboss Migrating to Virgo (Glyn Normington)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Fri, 19 Nov 2010 01:53:23 -0800
> >> From: Glyn Normington <gnormington@xxxxxxxxxx<mailto:
> >> gnormington@xxxxxxxxxx>>
> >> To: Virgo Project <virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
> >> Subject: Re: [virgo-dev] Security in Virgo
> >> Message-ID: <8F8997EC-60A3-40E4-AF83-FBB6AA05902F@xxxxxxxxxx<mailto:
> >> 8F8997EC-60A3-40E4-AF83-FBB6AA05902F@xxxxxxxxxx>>
> >> Content-Type: text/plain; charset="us-ascii"
> >>
> >> Spring Security and OSGi security should work ok, but that's not an area
> >> we have tested so there may be bugs.
> >>
> >> Also we haven't tested Virgo with the Java security manager switched on,
> >> so there may be problems there. However, this is an area that the community
> >> is interested in working on for the next release, so things may improve
> >> there.
> >>
> >> Regards,
> >> Glyn
> >>
> >> On 19 Nov 2010, at 04:09, Saadat Dowlati wrote:
> >>
> >> > Hello,
> >> > Can someone elaborate on the supported security features of virgo?
> >> Is Spring Security fully supported in Virgo? How about OSGi's?
> >> > --
> >> > Thanks,
> >> > sd
> >> > <ATT00001..txt>
> >>
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Fri, 19 Nov 2010 02:57:23 -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: <462A1652-FA89-4D81-92A4-D04E327820CF@xxxxxxxxxx<mailto:
> >> 462A1652-FA89-4D81-92A4-D04E327820CF@xxxxxxxxxx>>
> >> Content-Type: text/plain; charset="us-ascii"
> >>
> >> 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><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 (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><mailto:gnormington@xxxxxxxxxx<mailto:
> >> gnormington@xxxxxxxxxx>>>
> >> 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: <E41AF26E-0F8B-4470-98FD-F5916B3D452C@xxxxxxxxxx<mailto:
> >> E41AF26E-0F8B-4470-98FD-F5916B3D452C@xxxxxxxxxx><mailto:
> >> 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>><mailto:
> >> 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>><mailto:
> >> 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>><mailto: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
> >> >><mailto: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>><mailto:
> >> 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>><mailto:
> >> 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>
> >> >><mailto:v0rzU8pOFwEPSMUV%2B%2BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx<v0rzU8pOFwEPSMUV%252B%252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx>
> >> <mailto:v0rzU8pOFwEPSMUV%252B%252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx<v0rzU8pOFwEPSMUV%25252B%25252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx>
> >> ><mailto:v0rzU8pOFwEPSMUV%252B%252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx<v0rzU8pOFwEPSMUV%25252B%25252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx>
> >> <mailto:v0rzU8pOFwEPSMUV%25252B%25252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx<v0rzU8pOFwEPSMUV%2525252B%2525252BuqZ2U_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>><mailto: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>><mailto:
> >> 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>><mailto:
> >> 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>><mailto:
> >> 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>><mailto:
> >> 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>><mailto:
> >> 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>><mailto:
> >> 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>><mailto:
> >> 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>><mailto:
> >> 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>><mailto:
> >> 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
> >> ><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:
> >> <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>
> >> ><mailto:
> >> AANLkTink6rHKS3hn9cWVjxV%2BfKc9D%2BnTy3_L%2ByO2__Ty@xxxxxxxxxxxxxx<AANLkTink6rHKS3hn9cWVjxV%252BfKc9D%252BnTy3_L%252ByO2__Ty@xxxxxxxxxxxxxx>
> >> <mailto:
> >> AANLkTink6rHKS3hn9cWVjxV%252BfKc9D%252BnTy3_L%252ByO2__Ty@xxxxxxxxxxxxxx<AANLkTink6rHKS3hn9cWVjxV%25252BfKc9D%25252BnTy3_L%25252ByO2__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><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
> >> >
> >> -------------- 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><mailto:gnormington@xxxxxxxxxx<mailto:
> >> gnormington@xxxxxxxxxx>>>
> >> 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: <515A4531-FD37-4730-81C1-9D277DAA2AA8@xxxxxxxxxx<mailto:
> >> 515A4531-FD37-4730-81C1-9D277DAA2AA8@xxxxxxxxxx><mailto:
> >> 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>><mailto: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>><mailto:
> >> 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><mailto:
> >> 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<mailto:virgo-dev@xxxxxxxxxxx>
> >> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >>
> >>
> >> End of virgo-dev Digest, Vol 9, Issue 32
> >> ****************************************
> >>
> >> <ATT00001..txt>
> >>
> >> _______________________________________________
> >> 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/20101122/663e125d/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 45
> ****************************************
>
> <ATT00001..txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/virgo-dev/attachments/20101203/0f28c554/attachment.htm>
------------------------------
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev
End of virgo-dev Digest, Vol 10, Issue 3
****************************************
_______________________________________________
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
|
