Re: Eclipse RCP apps and Tuscany

[Simon Nash]

Simon Laws wrote:

Hi Rajini




But the code that I have run into problems with are in


org.apache.tuscany.sca.node.util.SCAContributionUtil.findContributionFromResource
(ClassLoader
classLoader, String compositeString)

which only works with file:// or jar:// URLs (it is very similar to the
code
used by the old DefaultSCADomain).




I've always been skeptical about this method. It was included as a
convenience to allow the location of a contribution to be determined from
some well know file, for example, the composite file that is being tested.
Handy for testing but it seems back to front to me. As a user you either
have a contribution or you don't. Seems a strange thing to ask a runtime to
find a contribution based on what is known to be inside it.




This method is invoked from

 1. SCADomainImpl to find the folder/jar containing domain.composite
 2. SCADomainProxyImpl to find the folder/jar containing node.composite
 3. SCANodeFactory.createNodeWithComposite(String composite)
 4. SCANodeLauncher.main()

1) and 2) in particular need to be fixed properly since they are internal
to





Tuscany and it doesn't seem appropriate to expect applications to
override resource loading for the Tuscany runtime when Tuscany is
installed
into OSGi.




For 1 and 2 I'm sure we can find a better solution that using this method,
for example, some alternatives
  Have the runtime implementations that Ant is thinking about specify a well
know location for these system contributions
  Have the assemblies for these contributions generated programatically
rather than read from the file system


Case 3 is a convenience method for use by samples and itests.  The
composite file may either be part of the current module and picked up
from the target/classes directory, or it may be part of some other
module that's listed in the pom.xml dependencies of the current module,
and picked up from a jar file in a local or remote maven repo.  The
findContributionFromResource() method allows these two cases to be
treated the same by the sample writer.

If we change the samples and tests so that they identify contributions
rather than composite files, I think we would also need to change the
build process to package contributions in a uniform way (probably as
jar files), so that case 3 could use a replacement convenience API
that refers explicitly to contributions rather than to composite files.

  Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Eclipse RCP apps and Tuscany

[Jean-Sebastien Delfino]

Rajini Sivaram wrote:
[snip]
 I dont know the code well enough to understand how

these contributions are used/loaded/resolved etc. But yes, it will be good
to stop manipulating URLs to locate contributions.



+1, if I understand correctly, the scenario discussed here is like this:

Bob, application developer, writes Java code to bootstrap Tuscany and 
load some SCA contributions into it, before starting his composites.


With the current API, Bob's code needs to do something like:
TuscanySomething.addContribution()

Bob can't seriously hardcode the location of the contribution:

- C:\Bob's Dir\aContribution.jar is only going to work on Bob's machine.

- At development time the location is also different, something like 
C:\Bob's IDE workspace\aProject\bin.


- When Bob builds with Maven the location is probably different again 
C:\Bob's build Dir\target\classes.


Bob didn't want to have to write 3 different classes for these 3 cases, 
so he put his SCA contribution on his classpath and wrote (almost) 
portable code to locate it (by looking for a known resource on the 
classpath and getting the location of the contribution from the 
resource's URL).


This is a hack around an inconvenient Tuscany bootstrap API which 
requires the app developer to give the location of his contributions.


How about trying to attack the real problems IMO:

- Bob shouldn't have to specify a location in the first place, he should 
be able to identify his contributions by contribution logical URI.


- or even better, Bob should not have to write any code to bootstrap the 
runtime and list contributions in the first place.


- and Bob shouldn't have to put his SCA contributions on his VM's 
classpath either (see the Store tutorial for an example, where the store 
contribution references the assets contribution without a classpath 
dependency on it).


Thoughts?
--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Eclipse RCP apps and Tuscany

[ant elder]

On Jan 11, 2008 2:16 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

> Hi Rajini
>
>
> > But the code that I have run into problems with are in
> >
> >
> >
> org.apache.tuscany.sca.node.util.SCAContributionUtil.findContributionFromResource
> > (ClassLoader
> > classLoader, String compositeString)
> >
> > which only works with file:// or jar:// URLs (it is very similar to the
> > code
> > used by the old DefaultSCADomain).
>
>
> I've always been skeptical about this method. It was included as a
> convenience to allow the location of a contribution to be determined from
> some well know file, for example, the composite file that is being tested.
> Handy for testing but it seems back to front to me. As a user you either
> have a contribution or you don't. Seems a strange thing to ask a runtime
> to
> find a contribution based on what is known to be inside it.
>

+1 to that.

   ...ant

Re: Eclipse RCP apps and Tuscany

[Rajini Sivaram]

Simon,


On 1/11/08, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> Hi Rajini
>
>
> > But the code that I have run into problems with are in
> >
> >
> >
> org.apache.tuscany.sca.node.util.SCAContributionUtil.findContributionFromResource
> > (ClassLoader
> > classLoader, String compositeString)
> >
> > which only works with file:// or jar:// URLs (it is very similar to the
> > code
> > used by the old DefaultSCADomain).
>
>
> I've always been skeptical about this method. It was included as a
> convenience to allow the location of a contribution to be determined from
> some well know file, for example, the composite file that is being tested.
> Handy for testing but it seems back to front to me. As a user you either
> have a contribution or you don't. Seems a strange thing to ask a runtime
> to
> find a contribution based on what is known to be inside it.


Yes, it will be good if the code can be changed, but since many of the
samples and tests find their contributions based on the composites/sca-
contribution.xml, I am not sure if it is feasible to get rid of it
altogether after it has been around for so long.

>
> > This method is invoked from
> >
> >   1. SCADomainImpl to find the folder/jar containing domain.composite
> >   2. SCADomainProxyImpl to find the folder/jar containing node.composite
> >   3. SCANodeFactory.createNodeWithComposite(String composite)
> >   4. SCANodeLauncher.main()
> >
> > 1) and 2) in particular need to be fixed properly since they are
> internal
> > to
>
>
> > Tuscany and it doesn't seem appropriate to expect applications to
> > override resource loading for the Tuscany runtime when Tuscany is
> > installed
> > into OSGi.
>
>
> For 1 and 2 I'm sure we can find a better solution that using this method,
> for example, some alternatives
> Have the runtime implementations that Ant is thinking about specify a well
> know location for these system contributions
> Have the assemblies for these contributions generated programatically
> rather than read from the file system


When Tuscany is running under OSGi, we will require these contributions to
be installed into OSGi. I dont know the code well enough to understand how
these contributions are used/loaded/resolved etc. But yes, it will be good
to stop manipulating URLs to locate contributions.

.
> Simon
>

Thank you...

Regards,

Rajini

Re: Eclipse RCP apps and Tuscany

[Simon Laws]

Hi Rajini


> But the code that I have run into problems with are in
>
>
> org.apache.tuscany.sca.node.util.SCAContributionUtil.findContributionFromResource
> (ClassLoader
> classLoader, String compositeString)
>
> which only works with file:// or jar:// URLs (it is very similar to the
> code
> used by the old DefaultSCADomain).


I've always been skeptical about this method. It was included as a
convenience to allow the location of a contribution to be determined from
some well know file, for example, the composite file that is being tested.
Handy for testing but it seems back to front to me. As a user you either
have a contribution or you don't. Seems a strange thing to ask a runtime to
find a contribution based on what is known to be inside it.


>
> This method is invoked from
>
>   1. SCADomainImpl to find the folder/jar containing domain.composite
>   2. SCADomainProxyImpl to find the folder/jar containing node.composite
>   3. SCANodeFactory.createNodeWithComposite(String composite)
>   4. SCANodeLauncher.main()
>
> 1) and 2) in particular need to be fixed properly since they are internal
> to


> Tuscany and it doesn't seem appropriate to expect applications to
> override resource loading for the Tuscany runtime when Tuscany is
> installed
> into OSGi.


For 1 and 2 I'm sure we can find a better solution that using this method,
for example, some alternatives
  Have the runtime implementations that Ant is thinking about specify a well
know location for these system contributions
  Have the assemblies for these contributions generated programatically
rather than read from the file system

  .
Simon

Re: Eclipse RCP apps and Tuscany

[Rajini Sivaram]

Simon,

There is code used by the new domain/node APIs as well which manipulate URLs
returned by classloader.getResource() to open a directory or jar file
corresponding to a contribution. There are still some outstanding issues
with classloading in the new domain code, so I haven't been able to fully
test it under OSGi. But the code that I have run into problems with are in

org.apache.tuscany.sca.node.util.SCAContributionUtil.findContributionFromResource(ClassLoader
classLoader, String compositeString)

which only works with file:// or jar:// URLs (it is very similar to the code
used by the old DefaultSCADomain).

This method is invoked from

   1. SCADomainImpl to find the folder/jar containing domain.composite
   2. SCADomainProxyImpl to find the folder/jar containing node.composite
   3. SCANodeFactory.createNodeWithComposite(String composite)
   4. SCANodeLauncher.main()

1) and 2) in particular need to be fixed properly since they are internal to
Tuscany and it doesn't seem appropriate to expect applications to
override resource loading for the Tuscany runtime when Tuscany is installed
into OSGi.


Thank you...

Regards,

Rajini

On 1/11/08, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> The SCADomain.newInstance() method and the DefaultSCADomain class in
> host-embedded have been replaced by the domain and node APIs in
> domain-api and node-api.  However, most samples have not yet been
> converted to the new APIs.  For examples of samples that use the
> new APIs, see callback-ws-client, callback-ws-service and
> calculator-distributed.
>
> Do the same issues apply to the new APIs, or only when the old
> DefaultSCADomain class is used?
>
>   Simon
>
> Rajini Sivaram wrote:
>
> > SCADomain.newInstance(compositeName), which is used in many of the
> Tuscany
> > samples to create a DefaultSCADomain works only if
> > contextClassLoader.getResource(compositeName) returns a file:// or
> jar://
> > URL. This is broken when Tuscany is run under OSGi, since Apache Felix
> > returns a bundle:// URL and Equinox returns a bundleresource:// URL for
> the
> > composite. At the moment, existing samples can be run under an OSGi
> based
> > Tuscany only by using a custom classloader as the thread context
> > classloader, which returns file:// or jar:// URLs from its getResource
> > method, like Jason described(
> > http://marc.info/?l=tuscany-user&m=119559170431301&w=2).
> >
> > DefaultSCADomain determines the location of the SCA contribution
> relative to
> > the composite or sca-contribution.xml. This file is first loaded using
> > applicationClassLoader.getResource(), and root of the contribution
> folder or
> > jar file  is determined from the resource URL. Since bundle:// URLs dont
> > correspond to a folder or jar file, they are not correctly processed by
> > Tuscany. To fix this in Tuscany, we need a BundleContributionProcessor
> > similar to JarContributionProcessor (at the moment, artifacts from
> bundle
> > contributions are read using the JarContributionProcessor). The bundle
> > contribution processor should either 1) read the stream using the bundle
> URL
> > and use OSGi bundle API to read its artifacts or 2) find the actual file
> > location corresponding to the bundle and read it using the
> > JarContributionProcessor. Unfortunately, both of these require OSGi
> specific
> > code in the contribution processing logic.
> >
> > addContribution() methods for SCANode and SCADomain work with file://
> URLs
> > which specify bundle contributions, and these are resolved correctly
> using
> > OSGi. But at the moment, they cannot process bundle:// URLs. A proper
> fix
> > for DefaultSCADomain will also enable bundle:// or bundleresource://
> URLs to
> > be used in addContribution().
> >
> > Since this is a problem only when Tuscany is run under OSGi, and any fix
> > would require adding OSGi specific code into the contribution processing
> > code in Tuscany, I am not sure if this needs fixing in Tuscany, or the
> > workaround of overriding the context classloader is sufficient.
> >
> > Thoughts?
> >
> >
> >
> >
> > On 11/23/07, Peter Kriens <[EMAIL PROTECTED]> wrote:
> >
> >>I think it sounds very much like Felix Meschberger's conclusion.
> >>Converting URLs to strings and then back to URLs, which is not
> >>necessary and not guaranteed to work.
> >>
> >>Anyway, I'd like to know why someone needs to escape to Equinox hooks
> >>when it should work on standard OSGi level ...
> >>
> >>Kind regards,
> >>
> >>Peter Kriens
> >>
> >>RS> Hi,
> >>
> >>RS> Tuscany supports OSGi bundle contributions which are currently
> loaded
> >>using
> >>RS> the Apache Felix OSGi runtime by default. These contributions can
> >>contain
> >>RS> composite files and other meta-data which are  loaded using OSGi and
> >>RS> passed around as URLs. Tests for OSGi contributions are run under
> >>Felix with
> >>RS> urlhandlers set, so we dont have any trouble with bundle:// URLs
> >>returned by
> >>RS> resources located using Felix (Tuscany calls

Re: Eclipse RCP apps and Tuscany

[Simon Nash]

The SCADomain.newInstance() method and the DefaultSCADomain class in
host-embedded have been replaced by the domain and node APIs in
domain-api and node-api.  However, most samples have not yet been
converted to the new APIs.  For examples of samples that use the
new APIs, see callback-ws-client, callback-ws-service and
calculator-distributed.

Do the same issues apply to the new APIs, or only when the old
DefaultSCADomain class is used?

  Simon

Rajini Sivaram wrote:


SCADomain.newInstance(compositeName), which is used in many of the Tuscany
samples to create a DefaultSCADomain works only if
contextClassLoader.getResource(compositeName) returns a file:// or jar://
URL. This is broken when Tuscany is run under OSGi, since Apache Felix
returns a bundle:// URL and Equinox returns a bundleresource:// URL for the
composite. At the moment, existing samples can be run under an OSGi based
Tuscany only by using a custom classloader as the thread context
classloader, which returns file:// or jar:// URLs from its getResource
method, like Jason described(
http://marc.info/?l=tuscany-user&m=119559170431301&w=2).

DefaultSCADomain determines the location of the SCA contribution relative to
the composite or sca-contribution.xml. This file is first loaded using
applicationClassLoader.getResource(), and root of the contribution folder or
jar file  is determined from the resource URL. Since bundle:// URLs dont
correspond to a folder or jar file, they are not correctly processed by
Tuscany. To fix this in Tuscany, we need a BundleContributionProcessor
similar to JarContributionProcessor (at the moment, artifacts from bundle
contributions are read using the JarContributionProcessor). The bundle
contribution processor should either 1) read the stream using the bundle URL
and use OSGi bundle API to read its artifacts or 2) find the actual file
location corresponding to the bundle and read it using the
JarContributionProcessor. Unfortunately, both of these require OSGi specific
code in the contribution processing logic.

addContribution() methods for SCANode and SCADomain work with file:// URLs
which specify bundle contributions, and these are resolved correctly using
OSGi. But at the moment, they cannot process bundle:// URLs. A proper fix
for DefaultSCADomain will also enable bundle:// or bundleresource:// URLs to
be used in addContribution().

Since this is a problem only when Tuscany is run under OSGi, and any fix
would require adding OSGi specific code into the contribution processing
code in Tuscany, I am not sure if this needs fixing in Tuscany, or the
workaround of overriding the context classloader is sufficient.

Thoughts?




On 11/23/07, Peter Kriens <[EMAIL PROTECTED]> wrote:


I think it sounds very much like Felix Meschberger's conclusion.
Converting URLs to strings and then back to URLs, which is not
necessary and not guaranteed to work.

Anyway, I'd like to know why someone needs to escape to Equinox hooks
when it should work on standard OSGi level ...

Kind regards,

   Peter Kriens

RS> Hi,

RS> Tuscany supports OSGi bundle contributions which are currently loaded
using
RS> the Apache Felix OSGi runtime by default. These contributions can
contain
RS> composite files and other meta-data which are  loaded using OSGi and
RS> passed around as URLs. Tests for OSGi contributions are run under
Felix with
RS> urlhandlers set, so we dont have any trouble with bundle:// URLs
returned by
RS> resources located using Felix (Tuscany calls openConnection and
openStream
RS> on these urls).

RS> Are the Eclipse RCP apps run without an URL stream handler to handle
RS> bundleresource:// URLs?


RS> Thank you...

RS> Regards,

RS> Rajini

RS> On 11/23/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:


Hi all,

I don't think it is a bug in eclipse (just from the likeliness point of
view). What I do not know is, what Tuscany does with the URLs returned.
If they would just open a stream on the URL, there would be no issue at
all, because the URls are backed by handlers supporting opening the
streams.

If on the other they convert the URls to Strings and later want to
create URLs from the strings again, they are hosed. But I assume, this
is then a bug/issue in Tuscany rather than in Eclipse. In fact, they
might run into the same troubles with Felix or just about any
framework...

Regards
Felix

Am Freitag, den 23.11.2007, 08:55 + schrieb Rob Walker:


Peter

On a  very quick read thru this - tbh - it sounds like a bug/feature


of


their OSGi implementation.

I'm 99% sure we use classloader getResource() calls under Felix, and


the


felix classloaders correctly resolve them to bundle URL references


which


can then be used in a normal way. Pretty sure you need the URL


handler


feature enabled, since I think as Jason points out the URL returned


has


a custom protocol type that the specific framework implementation


needs


to handle.

A possible alternative may be for them to use getResourceAsStream()


if


viable

Re: Re[2]: Eclipse RCP apps and Tuscany

[Rajini Sivaram]

SCADomain.newInstance(compositeName), which is used in many of the Tuscany
samples to create a DefaultSCADomain works only if
contextClassLoader.getResource(compositeName) returns a file:// or jar://
URL. This is broken when Tuscany is run under OSGi, since Apache Felix
returns a bundle:// URL and Equinox returns a bundleresource:// URL for the
composite. At the moment, existing samples can be run under an OSGi based
Tuscany only by using a custom classloader as the thread context
classloader, which returns file:// or jar:// URLs from its getResource
method, like Jason described(
http://marc.info/?l=tuscany-user&m=119559170431301&w=2).

DefaultSCADomain determines the location of the SCA contribution relative to
the composite or sca-contribution.xml. This file is first loaded using
applicationClassLoader.getResource(), and root of the contribution folder or
jar file  is determined from the resource URL. Since bundle:// URLs dont
correspond to a folder or jar file, they are not correctly processed by
Tuscany. To fix this in Tuscany, we need a BundleContributionProcessor
similar to JarContributionProcessor (at the moment, artifacts from bundle
contributions are read using the JarContributionProcessor). The bundle
contribution processor should either 1) read the stream using the bundle URL
and use OSGi bundle API to read its artifacts or 2) find the actual file
location corresponding to the bundle and read it using the
JarContributionProcessor. Unfortunately, both of these require OSGi specific
code in the contribution processing logic.

addContribution() methods for SCANode and SCADomain work with file:// URLs
which specify bundle contributions, and these are resolved correctly using
OSGi. But at the moment, they cannot process bundle:// URLs. A proper fix
for DefaultSCADomain will also enable bundle:// or bundleresource:// URLs to
be used in addContribution().

Since this is a problem only when Tuscany is run under OSGi, and any fix
would require adding OSGi specific code into the contribution processing
code in Tuscany, I am not sure if this needs fixing in Tuscany, or the
workaround of overriding the context classloader is sufficient.

Thoughts?




On 11/23/07, Peter Kriens <[EMAIL PROTECTED]> wrote:
>
> I think it sounds very much like Felix Meschberger's conclusion.
> Converting URLs to strings and then back to URLs, which is not
> necessary and not guaranteed to work.
>
> Anyway, I'd like to know why someone needs to escape to Equinox hooks
> when it should work on standard OSGi level ...
>
> Kind regards,
>
> Peter Kriens
>
> RS> Hi,
>
> RS> Tuscany supports OSGi bundle contributions which are currently loaded
> using
> RS> the Apache Felix OSGi runtime by default. These contributions can
> contain
> RS> composite files and other meta-data which are  loaded using OSGi and
> RS> passed around as URLs. Tests for OSGi contributions are run under
> Felix with
> RS> urlhandlers set, so we dont have any trouble with bundle:// URLs
> returned by
> RS> resources located using Felix (Tuscany calls openConnection and
> openStream
> RS> on these urls).
>
> RS> Are the Eclipse RCP apps run without an URL stream handler to handle
> RS> bundleresource:// URLs?
>
>
> RS> Thank you...
>
> RS> Regards,
>
> RS> Rajini
>
> RS> On 11/23/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> >>
> >> Hi all,
> >>
> >> I don't think it is a bug in eclipse (just from the likeliness point of
> >> view). What I do not know is, what Tuscany does with the URLs returned.
> >> If they would just open a stream on the URL, there would be no issue at
> >> all, because the URls are backed by handlers supporting opening the
> >> streams.
> >>
> >> If on the other they convert the URls to Strings and later want to
> >> create URLs from the strings again, they are hosed. But I assume, this
> >> is then a bug/issue in Tuscany rather than in Eclipse. In fact, they
> >> might run into the same troubles with Felix or just about any
> >> framework...
> >>
> >> Regards
> >> Felix
> >>
> >> Am Freitag, den 23.11.2007, 08:55 + schrieb Rob Walker:
> >> > Peter
> >> >
> >> > On a  very quick read thru this - tbh - it sounds like a bug/feature
> of
> >> > their OSGi implementation.
> >> >
> >> > I'm 99% sure we use classloader getResource() calls under Felix, and
> the
> >> > felix classloaders correctly resolve them to bundle URL references
> which
> >> > can then be used in a normal way. Pretty sure you need the URL
> handler
> >> > feature enabled, since I think as Jason points out the URL returned
> has
> >> > a custom protocol type that the specific framework implementation
> needs
> >> > to handle.
> >> >
> >> > A possible alternative may be for them to use getResourceAsStream()
> if
> >> > viable - since this will resolve the URL and open it for them.
> >> >
> >> > Regards
> >> >
> >> > -- Rob
> >> >
> >> > Peter Kriens wrote:
> >> > > I noticed this mail:
> >> > >
> >> > >
> >>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-user

Re[2]: Eclipse RCP apps and Tuscany

[Peter Kriens]

I think it sounds very much like Felix Meschberger's conclusion.
Converting URLs to strings and then back to URLs, which is not
necessary and not guaranteed to work.

Anyway, I'd like to know why someone needs to escape to Equinox hooks
when it should work on standard OSGi level ...

Kind regards,

 Peter Kriens
 
RS> Hi,

RS> Tuscany supports OSGi bundle contributions which are currently loaded using
RS> the Apache Felix OSGi runtime by default. These contributions can contain
RS> composite files and other meta-data which are  loaded using OSGi and
RS> passed around as URLs. Tests for OSGi contributions are run under Felix with
RS> urlhandlers set, so we dont have any trouble with bundle:// URLs returned by
RS> resources located using Felix (Tuscany calls openConnection and openStream
RS> on these urls).

RS> Are the Eclipse RCP apps run without an URL stream handler to handle
RS> bundleresource:// URLs?


RS> Thank you...

RS> Regards,

RS> Rajini

RS> On 11/23/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
>>
>> Hi all,
>>
>> I don't think it is a bug in eclipse (just from the likeliness point of
>> view). What I do not know is, what Tuscany does with the URLs returned.
>> If they would just open a stream on the URL, there would be no issue at
>> all, because the URls are backed by handlers supporting opening the
>> streams.
>>
>> If on the other they convert the URls to Strings and later want to
>> create URLs from the strings again, they are hosed. But I assume, this
>> is then a bug/issue in Tuscany rather than in Eclipse. In fact, they
>> might run into the same troubles with Felix or just about any
>> framework...
>>
>> Regards
>> Felix
>>
>> Am Freitag, den 23.11.2007, 08:55 + schrieb Rob Walker:
>> > Peter
>> >
>> > On a  very quick read thru this - tbh - it sounds like a bug/feature of
>> > their OSGi implementation.
>> >
>> > I'm 99% sure we use classloader getResource() calls under Felix, and the
>> > felix classloaders correctly resolve them to bundle URL references which
>> > can then be used in a normal way. Pretty sure you need the URL handler
>> > feature enabled, since I think as Jason points out the URL returned has
>> > a custom protocol type that the specific framework implementation needs
>> > to handle.
>> >
>> > A possible alternative may be for them to use getResourceAsStream() if
>> > viable - since this will resolve the URL and open it for them.
>> >
>> > Regards
>> >
>> > -- Rob
>> >
>> > Peter Kriens wrote:
>> > > I noticed this mail:
>> > >
>> > >
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200711.mbox/[EMAIL 
>> PROTECTED]
>> > >
>> > > This is from the Tuscany project and seem to struggle with resource
>> > > handling in OSGi. Anybody knows Jason Clark and can discuss this with
>> > > him? As far as I can see, it can all be done with the bundle methods
>> > > or by creating new URLs.
>> > >
>> > > Kind regards,
>> > >
>> > >Peter Kriens
>> > >
>> > >
>> >
>>
>>


-- 
Peter Kriens  Tel +33467542167
9C, Avenue St. DrézéryAOL,Yahoo: pkriens
34160 Beaulieu, FranceICQ 255570717
Skype pkriens Fax +1 8153772599


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Eclipse RCP apps and Tuscany

[Rajini Sivaram]

Hi,

Tuscany supports OSGi bundle contributions which are currently loaded using
the Apache Felix OSGi runtime by default. These contributions can contain
composite files and other meta-data which are  loaded using OSGi and
passed around as URLs. Tests for OSGi contributions are run under Felix with
urlhandlers set, so we dont have any trouble with bundle:// URLs returned by
resources located using Felix (Tuscany calls openConnection and openStream
on these urls).

Are the Eclipse RCP apps run without an URL stream handler to handle
bundleresource:// URLs?


Thank you...

Regards,

Rajini

On 11/23/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I don't think it is a bug in eclipse (just from the likeliness point of
> view). What I do not know is, what Tuscany does with the URLs returned.
> If they would just open a stream on the URL, there would be no issue at
> all, because the URls are backed by handlers supporting opening the
> streams.
>
> If on the other they convert the URls to Strings and later want to
> create URLs from the strings again, they are hosed. But I assume, this
> is then a bug/issue in Tuscany rather than in Eclipse. In fact, they
> might run into the same troubles with Felix or just about any
> framework...
>
> Regards
> Felix
>
> Am Freitag, den 23.11.2007, 08:55 + schrieb Rob Walker:
> > Peter
> >
> > On a  very quick read thru this - tbh - it sounds like a bug/feature of
> > their OSGi implementation.
> >
> > I'm 99% sure we use classloader getResource() calls under Felix, and the
> > felix classloaders correctly resolve them to bundle URL references which
> > can then be used in a normal way. Pretty sure you need the URL handler
> > feature enabled, since I think as Jason points out the URL returned has
> > a custom protocol type that the specific framework implementation needs
> > to handle.
> >
> > A possible alternative may be for them to use getResourceAsStream() if
> > viable - since this will resolve the URL and open it for them.
> >
> > Regards
> >
> > -- Rob
> >
> > Peter Kriens wrote:
> > > I noticed this mail:
> > >
> > >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200711.mbox/[EMAIL 
> PROTECTED]
> > >
> > > This is from the Tuscany project and seem to struggle with resource
> > > handling in OSGi. Anybody knows Jason Clark and can discuss this with
> > > him? As far as I can see, it can all be done with the bundle methods
> > > or by creating new URLs.
> > >
> > > Kind regards,
> > >
> > >Peter Kriens
> > >
> > >
> >
>
>

RE: Eclipse RCP apps and Tuscany

[Jason Clark]

Here's a big long winded explanation on how we got Tuscany to work with
Eclipse for now while other solutions are looked at. 

This is all based on the 1.01 branch in the repository. Also, we have no
idea if this is the right or wrong way to do things. But, it's working for
us right now so...

Any feedback would be appreciated. 

Tuscany resource loading in Eclipse RCP

Problem:

Tuscany loads composite configuration files using the class loader
getResource() method, 
but in the eclipse RCP environment, a special class loader is used that
locates the resources
by the bundle (plugin) they are located in. The URL returned by
getResource() is in the form:
"bundleresource://plugin##/resourceName" instead of an absolute file path
starting with "file://".
Since this special type is not handled, Tuscany can not locate any
resources.

Solution:

Eclipse provides a means to add a ClassLoadingHook, which is an interface
that provides methods
that can be implemented to create and use a custom class loader for a
particular bundle (plugin).
The ClassLoaderHook is added to the system by implementing and adding a
HookConfigurator implementation.

A plugin must be created that depends on the org.eclipse.osgi plugin.
Note that all of the classes needed to setup the custom class loader are
marked with restricted access
by eclipse, but may still be implemented and used.

HookConfigurators are loaded by OSGI prior to the bundle loading.

A HookConfigurator (org.eclipse.osgi.baseadaptor.HookConfigurator) has an
addHooks() method which passes in a HookRegistry object. The
addClassLoadingHook() method is used to pass in the new ClassLoadingHook
(org.eclipse.osgi.baseadaptor.hooks.ClassLoadingHook) created.

Within the ClassLoadingHook implementation, the main method of interest is
createClassLoader() which should be used to create a custom class loader
that will properly return the file URLs from getResource() (mentioned
below). All other methods can return null or false accordingly.

A custom class loader could be returned for all plugin bundles, or for
particular bundles based on the use case desired. For adding it to only the
plugin bundles containing Tuscany configuration files, the BaseData object
can be used to determine the bundle name using data.getSymbolicName().

To create the custom class loader, extending the default used by the eclipse
RCP seemed the best approach to not lose any other components of the class
loader. That class is DefaultClassLoader
(org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) and the only
method that needs to be overridden is getResource(String). The constructor
method must take the same arguments as DefaultClassLoader, and those are the
parameters passed into createClassLoader() in the ClassLoadingHook.

To properly check that the resource being returned was listed with the
custom "bundleresource" prefix, the following code can be used:

public URL getResource(String name) {
URL resource = super.getResource(name);
if (resource == null) {
return null;
}
try {
URLConnection connection = resource.openConnection();
if (connection instanceof BundleURLConnection) {
BundleURLConnection bundleConn = (BundleURLConnection)
connection;
//Gets the absolute File path URL
return bundleConn.getFileURL();
}
}
catch (IOException e) {
// Ignore Exception.
}

return resource;
}

Configuration file:
The final addition to the plugin in the inclusion of a
hookconfigurators.properties" at the base level of the plugin which includes
the following line: hook.configurators=FullClassName

FullClassName is the class name of the HookConfigurator implementation in
the plugin.


Exporting and Use The plugin must now be exported and include the
manifest.mf file, the classes, and the hookconfigurators.properties file.
The plugin must be exported as a JAR (not a folder) and the version number
must be appended on the end (which should happen automatically) in the form
pluginId_version.jar The exported plugin must be placed in the target
platform in the same folder as the org.eclipse.osgi plugin to work properly.

At runtime, for the plugin to be recognized as an extension, one of the
following options must be performed:

1) Config.ini
Add this line to the config.ini of the application:
osgi.framework.extensions=plugin_id_name

2) Runtime VM argument
Add the following line to the VM arguments
-Dosgi.framework.extensions=plugin_id_name

For more details regarding Eclipse Adapter Hooks, see:
http://wiki.eclipse.org/Adaptor_Hooks

-Jason
 

> -Original Message-
> From: Jason Clark [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 20, 2007 9:11 AM
> To: tuscany-user@ws.apache.org
> Subject: RE: Eclipse RCP apps and Tuscany
> 
> We found a work-around, but it involves using some classes from the
> Eclipse
> internal package, which i

RE: Eclipse RCP apps and Tuscany

[Jason Clark]

We found a work-around, but it involves using some classes from the Eclipse
internal package, which is frowned upon by them. It's more of a fix for
eclipse than making the app OSGi friendly though. I'll get more details and
post them soon.

-Jason
 
> -Original Message-
> From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 20, 2007 6:38 AM
> To: tuscany-user@ws.apache.org
> Subject: Re: Eclipse RCP apps and Tuscany
> 
> Jason Clark wrote:
> > We tried launching Tuscany in an RCP application but ran into a lot of
> > class loading problems. In particular, for finding resources using
> > Thread.currentThread().getContextClassLoader and
> > ClassLoader.getResource, i.e. getting the classLoader from the thread or
> > class. Has anyone run into this problem before?
> >
> >
> >
> > -Jason Clark
> >
> 
> Rajini is currently working on making the Tuscany runtime OSGi-friendly
> and has run into similar problems.
> 
> What you describe is a good and increasingly common use case for
> Tuscany, I think we should have a sample plus an integration test using
> Tuscany from RCP.
> 
> Are you interested in contributing a test case? Then we can fix the
> runtime to make it work, and once the test case is in the build we can
> make sure that it continues to work over time :)
> 
> --
> Jean-Sebastien
> 
> -
> 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]

Re: Eclipse RCP apps and Tuscany

[Jean-Sebastien Delfino]

Jason Clark wrote:
We tried launching Tuscany in an RCP application but ran into a lot of 
class loading problems. In particular, for finding resources using 
Thread.currentThread().getContextClassLoader and 
ClassLoader.getResource, i.e. getting the classLoader from the thread or 
class. Has anyone run into this problem before?


 


-Jason Clark



Rajini is currently working on making the Tuscany runtime OSGi-friendly 
and has run into similar problems.


What you describe is a good and increasingly common use case for 
Tuscany, I think we should have a sample plus an integration test using 
Tuscany from RCP.


Are you interested in contributing a test case? Then we can fix the 
runtime to make it work, and once the test case is in the build we can 
make sure that it continues to work over time :)


--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Eclipse RCP apps and Tuscany

[Luciano Resende]

Could you please clarify if you are using Tuscany trunk, or a given
release, as there has been some recent class loader related changes in
trunk.

On Nov 16, 2007 12:48 PM, Jason Clark <[EMAIL PROTECTED]> wrote:
>
>
>
>
> We tried launching Tuscany in an RCP application but ran into a lot of class
> loading problems. In particular, for finding resources using
> Thread.currentThread().getContextClassLoader and ClassLoader.getResource,
> i.e. getting the classLoader from the thread or class. Has anyone run into
> this problem before?
>
>
>
> -Jason Clark
>
>
>
> 21st Century Systems, Inc.
>
> 3375 Koapaka Street, Suite I540
>
> Honolulu, HI 96819
>
> Work: 808-954-6043
>
> [EMAIL PROTECTED]
>
> www.21csi.com
>
>
>
>
> This e-mail and any files transmitted with it are intended solely for the
> use of the individual or entity to whom they are addressed.  If you have
> received this e-mail in error please notify the sender immediately and
> delete this e-mail from you system.  This message may contain company
> proprietary, sensitive information and is intended only for the individual
> named.  Its contents may be covered under the Trade Secret Act of various
> jurisdictions.  If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. If you are not the intended
> recipient you are notified that disclosing, copying, distributing or taking
> any action in reliance on the contents of this information is strictly
> prohibited.
>
>
>
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Eclipse RCP apps and Tuscany

[Jason Clark]

We tried launching Tuscany in an RCP application but ran into a lot of class
loading problems. In particular, for finding resources using
Thread.currentThread().getContextClassLoader and ClassLoader.getResource,
i.e. getting the classLoader from the thread or class. Has anyone run into
this problem before?

 

-Jason Clark

 

21st Century Systems, Inc.

3375 Koapaka Street, Suite I540

Honolulu, HI 96819

Work: 808-954-6043

[EMAIL PROTECTED]

www.21csi.com



This e-mail and any files transmitted with it are intended solely for the
use of the individual or entity to whom they are addressed.  If you have
received this e-mail in error please notify the sender immediately and
delete this e-mail from you system.  This message may contain company
proprietary, sensitive information and is intended only for the individual
named.  Its contents may be covered under the Trade Secret Act of various
jurisdictions.  If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. If you are not the intended
recipient you are notified that disclosing, copying, distributing or taking
any action in reliance on the contents of this information is strictly
prohibited.