Re: Support for SCA Java package imports/exports, was: svn commit: r559257

[Jean-Sebastien Delfino <js...@gmail.com>]

Raymond Feng wrote:
> Hi,
>
> Please see my comments inline.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "ant elder" <an...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Tuesday, July 31, 2007 3:29 AM
> Subject: Re: Support for SCA Java package imports/exports, was: svn 
> commit: r559257
>
>
>> On 7/30/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>>
>>> [snip]
>>> Luciano Resende wrote:
>>> >    - Another issue I noticed is regarding resolving classReferences.
>>> > Because loading a given class would never fails (no class loader
>>> > isolation) there is never going to be delegation to the proper
>>> > modelResolver from a contribution that is exporting the package. Any
>>> > ideas here ? Or should we revisit this when we enhance classLoader
>>> > support?
>>> >
>>> >
>>> Right, SCA Java imports will only be effective in environments using a
>>> different classloader per SCA contribution, which we have not
>>> encountered yet. I'd suggest to revisit this when we encounter such an
>>> environment. For now adding support for Java import/export only helps
>>> validate the import/export extensibility mechanism.
>>
>>
>> How about we create such an environment? We seemed to be getting lots 
>> of new
>> function added these days - for things like starting and stopping,
>> incremental updates, this import/export stuff, etc - but nothing that
>> actually properly uses the function, and then issues like the above
>> mentioned class loader problem meaning its actually not at all easy 
>> to use
>> the function when you do try to. I don't think thats so good for the 
>> project
>> as it makes it hard to understand why things a getting so 
>> complicated, so
>> wouldn't it be better to have something 'real' that exercises that 
>> code? How
>> about we create an environment that properly demonstrates using multiple
>> contributions and all the code and function we're adding around that?
>>
>
> I think we need to have a good balance here. Writing a new Tuscany 
> server is exciting. For those who already run their applications on 
> existing host environment such as Tomcat and Geronimo, maybe it's more 
> desirable to have Tuscany to be well integrated/embedded. I agree with 
> you that we need to have something real that exercises the new 
> features. IMHO, Tuscany/Geronimo integration will be a good testbed.
>

Our J2SE bootstrap does not provide the ability to exercise the following:

- contribution <import.java> pointing to contributions loaded by 
different classloaders
I'm hoping that the folks working on OSGI will help with that, as 
suggested in the SCA spec and discussed on tuscany-dev in [1]

- components running in a single JVM in different classloaders
+1 to Raymond's comment, the Geronimo/Tuscany integration will be a good 
real environment to exercise that.

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19342.html

--
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org