Hi Raymond,
Comments Inline
On 7/4/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Manu George" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <tuscany-dev@ws.apache.org>
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.
See Jaceks Mail in this mail chain
>
> 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.
I think the module can be processed only by a single builder that
implements the ConfigurationBuilder interface. We cannot chain
ConfigurationBuilder instances.
We can have references to ModuleBuilders in our builder but i think
that is not the approach to follow.
So in case of a plugin approach i think we will need to write a
deployment watcher i.e a gbean that implements the
org.apache.geronimo.kernel.config.DeploymentWatcher interface. The
interface has two methods
void deployed(Artifact id);
void undeployed(Artifact id);
So whenever any module is deployed this will get called after
deployment. And u can access and modify the configuration. This
approach too has some disadvantages
The biggest one is since serialized gbeans cannot be edited we will
need to recreate the configuration. We can use also use some methods
in EditableConfigurationManager but again its functionality is limited
and also adds the info to config.xml
> 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?
I will be responding to Simon on this. Please see that mail.
> 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.
>
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 <[EMAIL PROTECTED]> 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
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
