Skip to main content

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

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>> 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 (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>>
To: Virgo Project <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>>
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>> 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>>
>> To: Virgo Project <virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
>> Subject: Re: [virgo-dev] Jboss Migrating to Virgo
>> Message-ID:
>>        <AANLkTi=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>
>> >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>
>> > > https://dev.eclipse.org/mailman/listinfo/virgo-dev
>> >
>> > _______________________________________________
>> > 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/20101115/e03152e8/attachment.htm
>> >
>>
>> ------------------------------
>>
>>
>> _______________________________________________
>> 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 12
>> ****************************************
>>
>
>
> _______________________________________________
> 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/20101116/d74a9355/attachment.htm>

------------------------------

_______________________________________________
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 15
****************************************

<ATT00001..txt>



Back to the top