geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manu George" <manu.t.geo...@gmail.com>
Subject Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Date Tue, 03 Jul 2007 14:53:07 GMT
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.

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.

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.

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).

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
http://www.osoa.org/pages/viewpage.action?pageId=3980.

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.

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 <paulmcmahan@gmail.com> 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
>
>
>

Mime
View raw message