Re: [virgo-dev] Jboss Migrating to Virgo

[Dmitry Sklyut <dmitry@xxxxxxxxxxx>]

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<mailto:v0rzU8pOFwEPSMUV%2B%2BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx><mailto:v0rzU8pOFwEPSMUV%2B%2BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx<mailto:v0rzU8pOFwEPSMUV%252B%252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx>><mailto:v0rzU8pOFwEPSMUV%2B%2BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx<mailto:v0rzU8pOFwEPSMUV%252B%252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx><mailto:v0rzU8pOFwEPSMUV%252B%252BuqZ2U_KG6uOefsGfgDu@xxxxxxxxxxxxxx<mailto: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>><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<mailto:AANLkTink6rHKS3hn9cWVjxV%2BfKc9D%2BnTy3_L%2ByO2__Ty@xxxxxxxxxxxxxx><mailto:AANLkTink6rHKS3hn9cWVjxV%2BfKc9D%2BnTy3_L%2ByO2__Ty@xxxxxxxxxxxxxx<mailto: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><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

Attachment: 0001-Push-up-AbstractInstallArtifact-specific-operations-.patch
Description: Binary data