As far as I know CXF uses a slighty changed jaxb impl to adapt it to OSGi.
Christian
Am 25.04.2012 09:55, schrieb Jean-Baptiste Onofré:
Hi Hervé,
Karaf itself doesn't provide a DOSGi implementation. However, you can
install Karaf Cellar in your Karaf instance: Cellar provides a DOSGi
impleme
Hi Hervé,
Karaf itself doesn't provide a DOSGi implementation. However, you can
install Karaf Cellar in your Karaf instance: Cellar provides a DOSGi
implementation (powered by Hazelcast).
Another possible DOSGi implementation in Karaf is to use CXF DOSGi.
Regards
JB
On 04/25/2012 09:53 AM,
Hi, thanks for the tip.
I just think that Karaf provides DOSGi implementation [not in my old
version]. I guess this implementation has the right implementation of
serialization.
Regards
Hervé
On Tue, Apr 24, 2012 at 10:45 PM, Christian Schneider <
ch...@die-schneider.net> wrote:
> As you can n
As you can not change the jdk code I think such a workaround is acceptable.
Btw. It is a good practice to save the old ThreadContextClassLoader and
restore it after the call.
Christian
Am 24.04.2012 22:08, schrieb Hervé BARRAULT:
Hi, i did a really ugly quick fix using ThreadContextClassLoader
Hi, i did a really ugly quick fix using ThreadContextClassLoader and it is
working (using resolveClass for ObjectInputStream).
I say ugly because it is still based on class name [not OSGI compliant] but
it validates the ThreadContextClassLoader "Workaround".
Thanks
Regards
hervé
On Tue, Apr 24,
Hi thanks for the explanation about the Class.forname usage (It is clear
when you don't forget that you can manipulate at the same classes in
different versions).
I think, it could be a good idea that the OSGi container provides a
serialization/deserialization service or tool which covers the cons
Hi Hervé,
does not look like ObjectInputStream is really doing this cleanly. It
just uses Class.forname which is not good in the OSGi case.
You can try to set the ContextClassloader like this before calling the
deserialization code:
Thread.currentThread().setContextClassLoader(YourSerializedCl
On Tue, 24 Apr 2012 15:53:32 +0200, Hervé BARRAULT wrote:
Not really a Karaf problem, but whatever..
> I have a case where i can't see how to cleanly list the imported packages
> without using DynamicImport-Package.
It is always possible. It's software.
> I have a bundle B which defines a "cont
Hi,
thanks for the answer.
The deserialization code is like this :
final byte[] byteData = Base64.decodeBase64(dataStr);
ByteArrayInputStream bout = null;
ObjectInputStream oos = null;
try {
bout = new ByteArrayInputStream(byteData);
oos = new ObjectInputStream(bout);
toReturn = oos.
That is the typical case like in jpa where you have a generic service
that needs to create objects from a packages it can not know at compile
time.
The typical solution for this is to give B the classloader of C. So
currently you might have a deserialize method like:
Object object = unmarshal
Hi,
I have a case where i can't see how to cleanly list the imported packages
without using DynamicImport-Package.
Example :
I have a bundle A where there is the whole dto.
I have a bundle B which defines a "container" library (basically a
container can support any Serializable and provides
ser
11 matches
Mail list logo
