On 5/27/08, Sebastian Voigt [EMAIL PROTECTED] wrote:
In our application we use Jaxb for reading and storing of configurations.
This application is distributed and uses Tuscany for the remote
communication.
The first problem that we have is that we load a configuration file with
jaxb and then we send this java object (the configuration) over a Tuscany
remote API.
For this workflow there exits two problems for us at the moment:
1) The more common problem at first. In our application the configuration
is created
with our jaxb-classes and sometimes (not always) Tuscany finds another jaxb
-classes (classes within jaxb).
The problem is in this case that the serialization isn't working. Tuscany
compares the classes (e.g. elements/
annotations classes) and it can't find them because they were loaded by a
different classloaders.
In some cases it uses in both the same jaxb-implementation, then the
serialization works fine. One main problem
is that the current Tuscany bundles only have short manifest -files. The
imports and so on don't have version restrictions included.
I have added some comments to
https://issues.apache.org/jira/browse/TUSCANY-2343. I wasn't sure if this
note and the JIRA correspond to the same problem. Are you using the
installer bundle in itest/osgi-tuscany which installs separate bundles for
3rd party libs and Tuscany modules, or the older 5-bundle version?
Tuscany uses jaxb-impl version 2.1.6. If your application is able to use the
same version, I would expect you to be able to use the installer bundle as
is. If not, you may have to exclude this dependency in the installer to
ensure that Tuscany uses the version of jaxb that your application is using.
I am not sure adding versions to Tuscany imports will actually help if the
versions used by the application and Tuscany are actually different, but you
are trying to share classes across these.
2) The second problem (we fixed it temporary) that the Tuscany jaxb binding
plugin creates instance of jaxb
context that applies only to one bundle that is related to the root object
class. But we use xml extensions and
have the mapping classes (for the xml tags) in different java-bundles (in
the same package). Therefore it is unable
to marshal the configuration.
I dont know enough about jaxb to comment, but from the jaxb databinding code
I can see the Jaxb context being created with a single class. Am I right in
assuming that the bundle containing the root object class does not have
visibility of the other classes in the other bundles? I wasn't sure since
you said 'in the same package' which seems to suggest that these bundles use
Require-Bundle to handle split-packages. Could you raise a JIRA for this
issue? Would it be possible to provide a test case (or some more detail on
the classes and bundles)? We could possibly use thread context classloader
to provide access to other bundles, but it doesn't look like the right thing
to do - it would help to understand the scenario better.
We would provide further information if needed,
Thanks in advance
Sebastian Voigt
--
Thank you...
Regards,
Rajini
