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