geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <>
Subject Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Date Tue, 03 Jul 2007 19:04:57 GMT

Please see my comments inline.


----- Original Message ----- 
From: "Manu George" <>
To: <>
Cc: <>
Sent: Tuesday, July 03, 2007 7:53 AM
Subject: Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)

> Hi ,
>                From Paul's mail I guess a Geronimo plugin would be
> the way forward. I am going to list down a few more questions on the
> scenarios that Sebastien has explained. The scenarios are given first
> and then my understanding, approach and issues. I would be just
> listing two of the scenarios and trying to implement them initially.
> (a) I develop SCA components, assemble them in a composite, package them
>     in an SCA contribution. I don't really know what a WAR or an EAR is, 
> I'm
>     just using the SCA programming model and packaging model. I deploy my
>     SCA contribution to Geronimo and run it there.
> This will require a tuscany specific deployer that is installed as
> part of the plugin. Ususally deployers have access to a server
> specific deployment plan at some fixed path say
> (META-INF/geronimo-tuscany.xml). If this file is found then the
> deployer will know that the module that was supplied to it is a
> tuscany module. In case I am deploying a tuscany contribution using
> the sca packaging model then there will be a .composite file somewhere
> in the module and the deployer will have to search in the module for
> scdl files.  For now the tuscany  contributions will always be
> packaged as jars.

I'm not a geronimo expert. My understanding is that the Tuscany deployer 
needs a way to recognize the archive is a SCA contribution. It could
be an external deployment plan such as genronimo-tuscany.xml. If the 
deployment plan is not present, then a SCA "deployment descriptor" will be
checked. The SCA assembly spec doesn't define a mandatory deployment 
descriptor. We might be able to use "META-INF/sca-contributions.xml" as
a starting point.

> This will mean that if the deployer finds this file then it will
> handle the module as a tuscany module and if not found relinquish
> control to other deployers.

The SCA contribution itself can be an EAR. I assume an archive can be 
processed by multiple deployers.

> Now we come to the question of the Domain. This has been a vexing
> question for me. I think that going for a single SCADomain for the
> entire server would be a good place to start.
> All the applications will have an application composite and that
> composite will be deployed on the server wide SCADomain. What the
> server wide SCADomain should provide is the ability to add and remove
> composites at runtime. If I am not mistaken this will be supported by
> the EmbeddedSCADomain. Can someone in the know comment on this.

We can start with a local SCA domain for the Geronimo server. 
EmbeddedSCADomain is the right class and it can be extended to support the 
Geronimo host.

> The other logical approach would be to go for different partial
> SCADomain instances per contribution. These different instances will
> still have information about the other instances and will do the
> wiring across the instances that constitute a complete SCADomain.
>     From what I could find, this type of an SCADomain is not
> supported currently. There is work on an SCADomain spanning multiple
> runtimes. This would be a simpler case of an SCADomain spanning
> multiple classloaders or (configurations in Geronimo).

SCADomain can span multiple runtimes. Simon Laws from Tuscany is driving the 
support of distributed SCADomain. I'm a bit confused by the statement
"different partial SCADomain instances per contribution". Can you clarify?

> The reason for not going with the second approach is that it is not
> available in tuscany as of today. Please correct me if I am wrong.
> (b) This was point (c) in Sebastien's mail.
>       I want to use a Web app in my SCA assembly and call SCA components
>       from it. I should be able to declare an SCA component representing 
> my
>       Web app, wire that component to other SCA components in the 
> assembly,
>       and then magically the wired references will be available as proxies 
> for
>       use in my JSPs, allowing me to call an SCA component using a simple
>       jsp:useBean tag.
>     In addition to this the J2EE integration whitepaper at the OSOA
> site mentions abt being able to annotate Web
> artifacts(servlets,filters etc) with the SCA Annotations and get
> services injected into servlets/filters etc for usage. The wiring will
> be done by the SCA runtime. The whitepaper is here
> The things to be done for achieving this functionality are,
> 1) Create a new implementation type in Tuscany namely implementation.web.
> 2) Declare in a .composite file in the war that the war is an
> implementation.web type
> 3) The implementation.web tuscany extension will have functionality
> to introspect the web module classes for SCA specific annotations and
> build up information. Since there is a single SCADomain instance per
> server and all the services that we are going to reference are already
> deployed there, the implementation.web extension will take care of
> wiring and creating service proxies. These proxies will be bound to
> jndi.

I didn't do much investigation in this space but it seems that it's in line 
with the white paper.

> The injection into geronimo managed objects cannot be done by tuscany
> runtime. I am not 100% sure but I think that if I can populate the
> injectionMap in the Holder object in the TomcatWebAppContext GBean for
> that war with the right information then the injection will be taken
> care of by Geronimo. Can someone confirm this?
> This will take care of the integration in these two cases. As of now
> we are assuming all the services to of scope stateless. All the stuff
> in the second case will be done in a deployment watcher after a war
> has been deployed.
> This is the approach that myself and Vamsi are planning to use. If
> there is any problem with this approach that you can see or a better
> way to do things or something in the mail is not clear, please fell
> free to point it out.
> Regards
> Manu
> On 6/29/07, Paul McMahan <> wrote:
>> On Jun 29, 2007, at 3:11 AM, Manu George wrote:
>> >> >
>> >> > Some of the questions we have are:
>> >> > 1.  Should we use this plugin approach and host the plugin
>> >> separatley
>> >> > or intergrate Tuscany to be bundled as part of the Geronimo
>> >> > distribution?
>> >>
>> >> The plugin approach looks OK to me, but maybe somebody from the
>> >> Geronimo
>> >> project could give a more educated opinion?
>> >>
>> >
>> > I believe we can start with a plugin approach but if we run into some
>> > problems with implementation as a plugin then probably we can think of
>> > full fledged integration.
>> > Can someone from the Geronimo community with expertise here, please
>> > give their opinions on this.
>> Implementing as a plugin should not affect the technical design of
>> this component.   I don't know of anything you can do in a component
>> integrated into Geronimo at assembly time that you cannot do in a
>> plugin integrated after installation.   A plugin is really just a
>> component that has been preconfigured for rapid deployment and
>> dependency downloading.   It's a packaging decision.
>> IMO new components created for Geronimo that are not required by the
>> JEE specification should be implemented as plugins.  This is a rule
>> of thumb, and in some cases there may be justification for an
>> exception.  Like for example if we believed that almost every
>> Geronimo user will need SOA then we should discuss "full fledged
>> integration".  Another type of exception would be if we think that
>> the component would provide useful services to Geronimo's native
>> components.
>> Best wishes,
>> Paul

View raw message