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 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 +0000 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éry AOL,Yahoo: pkriens > >>34160 Beaulieu, France ICQ 255570717 > >>Skype pkriens Fax +1 8153772599 > >> > >> > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
