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]
