You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2007/05/16 04:14:50 UTC
Integrating SCADomain with sca-contribution.xml, was: Re: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat log 14 May 2007
I have modified the SCADomain to utilize sca-contribution.xml to find the
root of the contribution and the deployable composites when these are not
explicitly passed to the SCADomain. This helps simplify our webApp story and
promote a consistent way to identify deployable composites.
Below, you can find a summary of the usage scenarios of the SCADomain and
how it would use sca-contribution.xml or sca-contribution-generated.xml
newInstance() or newInstance("http://localhost", null) -> assumes an
sca-contribution.xml, finds the contribution root from it, uses the
deployables specified in it.
newInstance("http://localhost", ".") -> assumes an sca-contribution.xml,
uses the given location, uses the deployables in contrib.xml
newInstance("http://localhost", ".", "MyComposite.composite") -> does not
require sca-contribution.xml, finds the contribution from the given
composite and adds the given composite to the domain.
I have also modified the implementation-composite sample to use
sca-contribution.xml to define the deployable composite.
During this exercise, I found that the SCADomain spi is confusing, and would
like to propose the following signatures to be available :
public static SCADomain newInstance(String domainURI)
public static SCADomain newInstance(String domainURI, String
contributionLocation, String... composites)
and remove the current
public static SCADomain newInstance(String composite)
This should help avoid further confusion
Thoughts ?
On 5/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
>
> Raymond Feng wrote:
> > Hi,
> >
> > I have now refactored the RuntimeWire.Source and RuntimeWire.Target
> > into a new interface EndpointReference uner r538339. The Message
> > interface now has the following methods:
> >
> > public interface Message {
> > ...
> > EndpointReference<RuntimeComponentReference> getFrom();
> > void setFrom(EndpointReference<RuntimeComponentReference> from);
> > EndpointReference<RuntimeComponentService> getTo();
> > void setTo(EndpointReference<RuntimeComponentService> to);
> > }
> >
> > The EndpointReference can be later on used to implement the
> > CallableReference/ServiceReference and it can be serialized as URI to
> > represent an endpoint.
> >
> > Please let me know your opinions.
> >
> > Thanks,
> > Raymond
> >
>
> Do we absolutely need these generics? What if we wanted to send a
> message back to a client, we probably wouldn't have a component service
> to send the message to, right?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: How to make Tuscany SDO available in Websphere or other server?
Posted by Fuhwei Lwo <fu...@bricemedia.com>.
Hi Raymond,
I believe you are right that the only way to consume Tuscany SDO in WebSphere 6.x is to package Tuscany SDO 2.1/EMF 2.2.x in the EAR and set the application classloading policy to PARENT_LAST to override the ones in the WebSphere runtime.
Fuhwei Lwo
Raymond Feng <en...@gmail.com> wrote: Hi,
This seems to be class isolation issue in WebSphere. Are you using Websphere
6.0.x or 6.1? As far as I know, the 6.1 comes with OSGi support which can
help isolate different versions of EMF classes.
How did you make the SDO/EMF jars available to WebSphere, per server or per
application? Would it possible that you package the SDO/EMF jars in your EAR
and set the application classloading policy to PARENT_LAST?
For those who working on SDO, can you comment?
Thanks,
Raymond
----- Original Message -----
From: "Huang Kai"
To:
Cc: "jiaoly"
Sent: Sunday, May 20, 2007 11:08 PM
Subject: How to make Tuscany SDO available in Websphere or other server?
> We wanna use tuscany sdo in application that runs on websphere 6.
> Unfortunatelly we found it conflicts with websphere's own sdo api jar(
> actually an emf sdo jar :
> org.eclipse.emf.commonj.sdo_2.1.0.v200609210005.jar).
> Since websphere's own jar has higher privillege when loading classes,
> tuscany's sdo spec api jar won't take effect. What made it worse is that
> those sdo api in emf is out of date, eg. calling Type.isAbstract() throws
> NoSuchMethodError. And, it uses old-fashion "Class.forName(
> "commonj.sdo.impl.HelperProviderImpl").newInstance()" to find sdo impl
> instead of reading "META-INF/services/commonj.sdo.impl.HelperProvider",
> which make it impossible to use tuscany's sdo impl.
> Did anyone encounter similiar problem?
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: How to make Tuscany SDO available in Websphere or other server?
Posted by Raymond Feng <en...@gmail.com>.
Hi,
This seems to be class isolation issue in WebSphere. Are you using Websphere
6.0.x or 6.1? As far as I know, the 6.1 comes with OSGi support which can
help isolate different versions of EMF classes.
How did you make the SDO/EMF jars available to WebSphere, per server or per
application? Would it possible that you package the SDO/EMF jars in your EAR
and set the application classloading policy to PARENT_LAST?
For those who working on SDO, can you comment?
Thanks,
Raymond
----- Original Message -----
From: "Huang Kai" <pr...@gmail.com>
To: <tu...@ws.apache.org>
Cc: "jiaoly" <ji...@primeton.com>
Sent: Sunday, May 20, 2007 11:08 PM
Subject: How to make Tuscany SDO available in Websphere or other server?
> We wanna use tuscany sdo in application that runs on websphere 6.
> Unfortunatelly we found it conflicts with websphere's own sdo api jar(
> actually an emf sdo jar :
> org.eclipse.emf.commonj.sdo_2.1.0.v200609210005.jar).
> Since websphere's own jar has higher privillege when loading classes,
> tuscany's sdo spec api jar won't take effect. What made it worse is that
> those sdo api in emf is out of date, eg. calling Type.isAbstract() throws
> NoSuchMethodError. And, it uses old-fashion "Class.forName(
> "commonj.sdo.impl.HelperProviderImpl").newInstance()" to find sdo impl
> instead of reading "META-INF/services/commonj.sdo.impl.HelperProvider",
> which make it impossible to use tuscany's sdo impl.
> Did anyone encounter similiar problem?
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
How to make Tuscany SDO available in Websphere or other server?
Posted by Huang Kai <pr...@gmail.com>.
We wanna use tuscany sdo in application that runs on websphere 6. Unfortunatelly we found it conflicts with websphere's own sdo api jar( actually an emf sdo jar : org.eclipse.emf.commonj.sdo_2.1.0.v200609210005.jar).
Since websphere's own jar has higher privillege when loading classes, tuscany's sdo spec api jar won't take effect. What made it worse is that those sdo api in emf is out of date, eg. calling Type.isAbstract() throws NoSuchMethodError. And, it uses old-fashion "Class.forName( "commonj.sdo.impl.HelperProviderImpl").newInstance()" to find sdo impl instead of reading "META-INF/services/commonj.sdo.impl.HelperProvider", which make it impossible to use tuscany's sdo impl.
Did anyone encounter similiar problem?
Re: Integrating SCADomain with sca-contribution.xml, was: Re: More
TODOs for the 0.90 release, was: Tuscany weekly IRC chat log 14 May 2007
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Comments inline.
>
> Luciano Resende wrote:
>> I have modified the SCADomain to utilize sca-contribution.xml to find
>> the
>> root of the contribution and the deployable composites when these are
>> not
>> explicitly passed to the SCADomain. This helps simplify our webApp
>> story and
>> promote a consistent way to identify deployable composites.
>>
>> Below, you can find a summary of the usage scenarios of the SCADomain
>> and
>> how it would use sca-contribution.xml or sca-contribution-generated.xml
>>
>> newInstance() or newInstance("http://localhost", null) -> assumes an
>> sca-contribution.xml, finds the contribution root from it, uses the
>> deployables specified in it.
>>
>> newInstance("http://localhost", ".") -> assumes an sca-contribution.xml,
>> uses the given location, uses the deployables in contrib.xml
>
> ... and determines the actual location of the contribution root using
> sca-contribution.xml (same algorithm as in the next case where we
> determine the actual location of the contribution using the given path
> to a composite, here we use META-INF/sca-contribution.xml instead).
>
>>
>> newInstance("http://localhost", ".", "MyComposite.composite") -> does
>> not
>> require sca-contribution.xml, finds the contribution from the given
>> composite and adds the given composite to the domain.
>>
>> I have also modified the implementation-composite sample to use
>> sca-contribution.xml to define the deployable composite.
>>
>> During this exercise, I found that the SCADomain spi is confusing,
>> and would
>> like to propose the following signatures to be available :
>>
>> public static SCADomain newInstance(String domainURI)
>> public static SCADomain newInstance(String domainURI, String
>> contributionLocation, String... composites)
>>
>> and remove the current
>>
>> public static SCADomain newInstance(String composite)
>>
>> This should help avoid further confusion
>
> +1, SCADomain.newInstance(domainURI) replaces
> SCADomain.newInstance(composite)
>
>>
>> Thoughts ?
>>
Further thoughts:
I looked at the samples and how they're using
SCADomain.newInstance("MyComposite.composite") and I think that it will
unnecessarily complicate them to change them to call
SCADomain.newInstance("http://localhost:8080, "/",
"MyComposite.composite"). In most cases the domain URI is
http://localhost:8080 and the contribution is located at the root of the
classpath. What varies and is really useful is the path to the composite
to activate. So I now suggest to keep the current
SCADomain.newInstance(composite).
I also suggest to change the contribution location from "." to "/". It
resolves to the same location but I think "/" more clearly indicates
that your SCA contribution is at the root of the classpath.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Integrating SCADomain with sca-contribution.xml, was: Re: More
TODOs for the 0.90 release, was: Tuscany weekly IRC chat log 14 May 2007
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments inline.
Luciano Resende wrote:
> I have modified the SCADomain to utilize sca-contribution.xml to find the
> root of the contribution and the deployable composites when these are not
> explicitly passed to the SCADomain. This helps simplify our webApp
> story and
> promote a consistent way to identify deployable composites.
>
> Below, you can find a summary of the usage scenarios of the SCADomain and
> how it would use sca-contribution.xml or sca-contribution-generated.xml
>
> newInstance() or newInstance("http://localhost", null) -> assumes an
> sca-contribution.xml, finds the contribution root from it, uses the
> deployables specified in it.
>
> newInstance("http://localhost", ".") -> assumes an sca-contribution.xml,
> uses the given location, uses the deployables in contrib.xml
... and determines the actual location of the contribution root using
sca-contribution.xml (same algorithm as in the next case where we
determine the actual location of the contribution using the given path
to a composite, here we use META-INF/sca-contribution.xml instead).
>
> newInstance("http://localhost", ".", "MyComposite.composite") -> does not
> require sca-contribution.xml, finds the contribution from the given
> composite and adds the given composite to the domain.
>
> I have also modified the implementation-composite sample to use
> sca-contribution.xml to define the deployable composite.
>
> During this exercise, I found that the SCADomain spi is confusing, and
> would
> like to propose the following signatures to be available :
>
> public static SCADomain newInstance(String domainURI)
> public static SCADomain newInstance(String domainURI, String
> contributionLocation, String... composites)
>
> and remove the current
>
> public static SCADomain newInstance(String composite)
>
> This should help avoid further confusion
+1, SCADomain.newInstance(domainURI) replaces
SCADomain.newInstance(composite)
>
> Thoughts ?
>
>
> On 5/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> [snip]
>>
>> Raymond Feng wrote:
>> > Hi,
>> >
>> > I have now refactored the RuntimeWire.Source and RuntimeWire.Target
>> > into a new interface EndpointReference uner r538339. The Message
>> > interface now has the following methods:
>> >
>> > public interface Message {
>> > ...
>> > EndpointReference<RuntimeComponentReference> getFrom();
>> > void setFrom(EndpointReference<RuntimeComponentReference> from);
>> > EndpointReference<RuntimeComponentService> getTo();
>> > void setTo(EndpointReference<RuntimeComponentService> to);
>> > }
>> >
>> > The EndpointReference can be later on used to implement the
>> > CallableReference/ServiceReference and it can be serialized as URI to
>> > represent an endpoint.
>> >
>> > Please let me know your opinions.
>> >
>> > Thanks,
>> > Raymond
>> >
>>
>> Do we absolutely need these generics? What if we wanted to send a
>> message back to a client, we probably wouldn't have a component service
>> to send the message to, right?
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org