You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wink.apache.org by Michael Rheinheimer <ro...@us.ibm.com> on 2009/07/09 00:12:23 UTC
default JAXB context resolver?
Team,
We had previously discussed implementing a default JAXB context resolver to
better hand JAXB contexts. As far as I can tell, there are no default
"system" context resolvers loaded in WINK; only the context resolvers
defined by an application are available. For JAXB, however, it might make
sense to provide a default.
As a proof of concept, I put a context resolver in wink-common at
org.apache.wink.common.contexts.resolver.JAXBContextResolver
And added the following to
wink-common/src/main/resources/META-INF/core/wink-providers
# Context Resolvers
org.apache.wink.common.contexts.resolver.JAXBContextResolver
I poked around in the debugger a bit just to see how everything got loaded
up. It looked to me like the context resolvers were loaded in the correct
order. My sample also picked up the right provider with this context
resolver in place as well.
I'd like to hear opinions on this... or if you wish, I can work on building
up a sample to demonstrate value. I figured I'd pose the idea here on the
mailing list instead of a Jira to get a sense of what we want or need.
I think the value-add is that JAXB has a very standardized way of
processing data, and it's clear when we should be working with JAXB
objects, so an app should not necessarily be responsible for including
their own JAXB context resolver.
Any thoughts, concerns, objections?
Thanks..
mike
Re: default JAXB context resolver?
Posted by Michael Rheinheimer <ro...@us.ibm.com>.
I opened a Jira so we have a place to share ideas and patches:
https://issues.apache.org/jira/browse/WINK-68
mike
From: Nicholas L Gallardo/Austin/IBM@IBMUS
To: wink-dev@incubator.apache.org
Date: 07/08/2009 10:46 PM
Subject: Re: default JAXB context resolver?
> Looking at the Wink code today, the MessageBodyReader/Writer
> for JAXB stuff actually attempts to find the JAXBContext itself
> internally.
Yep, looks like AbstractJAXBProvider just holds on to a static map of those
contexts based on the Class. I'm assuming that Class is the entity
parameter or return type on the method signature.
It might actually be as simple as storing the static map of JAXBContexts in
the new resolver and just going from there. That map uses a Class<?> for
its key. This is good because it avoids the conflicts created by
JAXBContexts that support the same config, but were created on different
threads/from different Classloaders.
-Nick
Nicholas Gallardo
WebSphere - REST & WebServices Development
nlgallar@us.ibm.com
Phone: 512-286-6258
Building: 903 / 5G-016
Inactive hide details for Bryant Luk <br...@gmail.com>Bryant Luk
<br...@gmail.com>
Bryant Luk
<bryant.luk@gm
ail.com>
To
07/08/2009
10:18 PM wink-dev@incubator.apa
che.org
Please respond to cc
wink-dev@incubator.apache.org
Subject
Re: default JAXB
context resolver?
I did a quick peek again at this code.
One difference between the two implementations is that the IBM
implementation put the JAXBContextResolver on the list of
ContextResolver<JAXBContext> so it would show back up in the
Providers.getContextResolver() (at the tail end using user context
resolvers before built-in ones). Looking at the Wink code today, the
MessageBodyReader/Writer for JAXB stuff actually attempts to find the
JAXBContext itself internally.
The spec is kind of vague on this, but I don't see any obvious harm in
having a ContextResolver<JAXBContext> available as a standard
built-in, and I think application developers would like to know what
JAXBContext we would be using in the Reader/Writer. This isn't
exactly something I would lightly change later since even the
slightest change in behavior IMO could cause some random bug to pop
up, so making it "public" by putting it on the ContextResolver list
shouldn't be too bad. I'm probably missing something tho.
btw, I think Doug Larson may have had something to say about the
MessageBodyReader/Writer<JAXB...> code too. Dunno if he's back yet.
Thoughts?
On Wed, Jul 8, 2009 at 6:52 PM, Nicholas L Gallardo<nl...@us.ibm.com>
wrote:
> Mike,
>
> You're saying make a system level ContextResolver available so that we
can
> re-use instances and so users don't have to create one. I think that's
good.
> Take a look at this::
>
>
https://svn.apache.org/repos/asf/incubator/wink/contrib/ibm-jaxrs/src/com/ibm/ws/jaxrs/resolver/JAXBContextResolver.java
>
> Dustin created a system level JAXBContextResolver hid all of the caching
of
> the JAXBContext instances. The resolver is injected into the JAXB related
> Providers (as is already done in the current code) and they are able to
> share JAXBContext instances. I think Michael Elman (btw, can we just call
> you "Mike" and Michael E. "Michael"?) made a comment earlier about liking
> the JAXBContext caching mechanism. This is a good way to pull that over.
>
> -Nick
>
>
> Nicholas Gallardo
> WebSphere - REST & WebServices Development
> nlgallar@us.ibm.com
> Phone: 512-286-6258
> Building: 903 / 5G-016
> Michael Rheinheimer/Austin/IBM@IBMUS
>
>
> Michael Rheinheimer/Austin/IBM@IBMUS
>
> 07/08/2009 05:12 PM
>
> Please respond to
> wink-dev@incubator.apache.org
>
> To
> wink-dev@incubator.apache.org
> cc
>
> Subject
> default JAXB context resolver?
>
>
> Team,
>
> We had previously discussed implementing a default JAXB context resolver
to
> better hand JAXB contexts. As far as I can tell, there are no default
> "system" context resolvers loaded in WINK; only the context resolvers
> defined by an application are available. For JAXB, however, it might
make
> sense to provide a default.
>
> As a proof of concept, I put a context resolver in wink-common at
>
> org.apache.wink.common.contexts.resolver.JAXBContextResolver
>
> And added the following to
> wink-common/src/main/resources/META-INF/core/wink-providers
>
> # Context Resolvers
> org.apache.wink.common.contexts.resolver.JAXBContextResolver
>
> I poked around in the debugger a bit just to see how everything got
loaded
> up. It looked to me like the context resolvers were loaded in the
correct
> order. My sample also picked up the right provider with this context
> resolver in place as well.
>
> I'd like to hear opinions on this... or if you wish, I can work on
building
> up a sample to demonstrate value. I figured I'd pose the idea here on
the
> mailing list instead of a Jira to get a sense of what we want or need.
>
> I think the value-add is that JAXB has a very standardized way of
> processing data, and it's clear when we should be working with JAXB
> objects, so an app should not necessarily be responsible for including
> their own JAXB context resolver.
>
> Any thoughts, concerns, objections?
>
> Thanks..
> mike
>
--
- Bryant Luk
Re: default JAXB context resolver?
Posted by Nicholas L Gallardo <nl...@us.ibm.com>.
> Looking at the Wink code today, the MessageBodyReader/Writer
> for JAXB stuff actually attempts to find the JAXBContext itself
> internally.
Yep, looks like AbstractJAXBProvider just holds on to a static map of those
contexts based on the Class. I'm assuming that Class is the entity
parameter or return type on the method signature.
It might actually be as simple as storing the static map of JAXBContexts in
the new resolver and just going from there. That map uses a Class<?> for
its key. This is good because it avoids the conflicts created by
JAXBContexts that support the same config, but were created on different
threads/from different Classloaders.
-Nick
Nicholas Gallardo
WebSphere - REST & WebServices Development
nlgallar@us.ibm.com
Phone: 512-286-6258
Building: 903 / 5G-016
Bryant Luk
<bryant.luk@gmail
.com> To
wink-dev@incubator.apache.org
07/08/2009 10:18 cc
PM
Subject
Re: default JAXB context resolver?
Please respond to
wink-dev@incubato
r.apache.org
I did a quick peek again at this code.
One difference between the two implementations is that the IBM
implementation put the JAXBContextResolver on the list of
ContextResolver<JAXBContext> so it would show back up in the
Providers.getContextResolver() (at the tail end using user context
resolvers before built-in ones). Looking at the Wink code today, the
MessageBodyReader/Writer for JAXB stuff actually attempts to find the
JAXBContext itself internally.
The spec is kind of vague on this, but I don't see any obvious harm in
having a ContextResolver<JAXBContext> available as a standard
built-in, and I think application developers would like to know what
JAXBContext we would be using in the Reader/Writer. This isn't
exactly something I would lightly change later since even the
slightest change in behavior IMO could cause some random bug to pop
up, so making it "public" by putting it on the ContextResolver list
shouldn't be too bad. I'm probably missing something tho.
btw, I think Doug Larson may have had something to say about the
MessageBodyReader/Writer<JAXB...> code too. Dunno if he's back yet.
Thoughts?
On Wed, Jul 8, 2009 at 6:52 PM, Nicholas L Gallardo<nl...@us.ibm.com>
wrote:
> Mike,
>
> You're saying make a system level ContextResolver available so that we
can
> re-use instances and so users don't have to create one. I think that's
good.
> Take a look at this::
>
>
https://svn.apache.org/repos/asf/incubator/wink/contrib/ibm-jaxrs/src/com/ibm/ws/jaxrs/resolver/JAXBContextResolver.java
>
> Dustin created a system level JAXBContextResolver hid all of the caching
of
> the JAXBContext instances. The resolver is injected into the JAXB related
> Providers (as is already done in the current code) and they are able to
> share JAXBContext instances. I think Michael Elman (btw, can we just call
> you "Mike" and Michael E. "Michael"?) made a comment earlier about liking
> the JAXBContext caching mechanism. This is a good way to pull that over.
>
> -Nick
>
>
> Nicholas Gallardo
> WebSphere - REST & WebServices Development
> nlgallar@us.ibm.com
> Phone: 512-286-6258
> Building: 903 / 5G-016
> Michael Rheinheimer/Austin/IBM@IBMUS
>
>
> Michael Rheinheimer/Austin/IBM@IBMUS
>
> 07/08/2009 05:12 PM
>
> Please respond to
> wink-dev@incubator.apache.org
>
> To
> wink-dev@incubator.apache.org
> cc
>
> Subject
> default JAXB context resolver?
>
>
> Team,
>
> We had previously discussed implementing a default JAXB context resolver
to
> better hand JAXB contexts. As far as I can tell, there are no default
> "system" context resolvers loaded in WINK; only the context resolvers
> defined by an application are available. For JAXB, however, it might
make
> sense to provide a default.
>
> As a proof of concept, I put a context resolver in wink-common at
>
> org.apache.wink.common.contexts.resolver.JAXBContextResolver
>
> And added the following to
> wink-common/src/main/resources/META-INF/core/wink-providers
>
> # Context Resolvers
> org.apache.wink.common.contexts.resolver.JAXBContextResolver
>
> I poked around in the debugger a bit just to see how everything got
loaded
> up. It looked to me like the context resolvers were loaded in the
correct
> order. My sample also picked up the right provider with this context
> resolver in place as well.
>
> I'd like to hear opinions on this... or if you wish, I can work on
building
> up a sample to demonstrate value. I figured I'd pose the idea here on
the
> mailing list instead of a Jira to get a sense of what we want or need.
>
> I think the value-add is that JAXB has a very standardized way of
> processing data, and it's clear when we should be working with JAXB
> objects, so an app should not necessarily be responsible for including
> their own JAXB context resolver.
>
> Any thoughts, concerns, objections?
>
> Thanks..
> mike
>
--
- Bryant Luk
Re: default JAXB context resolver?
Posted by Bryant Luk <br...@gmail.com>.
I did a quick peek again at this code.
One difference between the two implementations is that the IBM
implementation put the JAXBContextResolver on the list of
ContextResolver<JAXBContext> so it would show back up in the
Providers.getContextResolver() (at the tail end using user context
resolvers before built-in ones). Looking at the Wink code today, the
MessageBodyReader/Writer for JAXB stuff actually attempts to find the
JAXBContext itself internally.
The spec is kind of vague on this, but I don't see any obvious harm in
having a ContextResolver<JAXBContext> available as a standard
built-in, and I think application developers would like to know what
JAXBContext we would be using in the Reader/Writer. This isn't
exactly something I would lightly change later since even the
slightest change in behavior IMO could cause some random bug to pop
up, so making it "public" by putting it on the ContextResolver list
shouldn't be too bad. I'm probably missing something tho.
btw, I think Doug Larson may have had something to say about the
MessageBodyReader/Writer<JAXB...> code too. Dunno if he's back yet.
Thoughts?
On Wed, Jul 8, 2009 at 6:52 PM, Nicholas L Gallardo<nl...@us.ibm.com> wrote:
> Mike,
>
> You're saying make a system level ContextResolver available so that we can
> re-use instances and so users don't have to create one. I think that's good.
> Take a look at this::
>
> https://svn.apache.org/repos/asf/incubator/wink/contrib/ibm-jaxrs/src/com/ibm/ws/jaxrs/resolver/JAXBContextResolver.java
>
> Dustin created a system level JAXBContextResolver hid all of the caching of
> the JAXBContext instances. The resolver is injected into the JAXB related
> Providers (as is already done in the current code) and they are able to
> share JAXBContext instances. I think Michael Elman (btw, can we just call
> you "Mike" and Michael E. "Michael"?) made a comment earlier about liking
> the JAXBContext caching mechanism. This is a good way to pull that over.
>
> -Nick
>
>
> Nicholas Gallardo
> WebSphere - REST & WebServices Development
> nlgallar@us.ibm.com
> Phone: 512-286-6258
> Building: 903 / 5G-016
> Michael Rheinheimer/Austin/IBM@IBMUS
>
>
> Michael Rheinheimer/Austin/IBM@IBMUS
>
> 07/08/2009 05:12 PM
>
> Please respond to
> wink-dev@incubator.apache.org
>
> To
> wink-dev@incubator.apache.org
> cc
>
> Subject
> default JAXB context resolver?
>
>
> Team,
>
> We had previously discussed implementing a default JAXB context resolver to
> better hand JAXB contexts. As far as I can tell, there are no default
> "system" context resolvers loaded in WINK; only the context resolvers
> defined by an application are available. For JAXB, however, it might make
> sense to provide a default.
>
> As a proof of concept, I put a context resolver in wink-common at
>
> org.apache.wink.common.contexts.resolver.JAXBContextResolver
>
> And added the following to
> wink-common/src/main/resources/META-INF/core/wink-providers
>
> # Context Resolvers
> org.apache.wink.common.contexts.resolver.JAXBContextResolver
>
> I poked around in the debugger a bit just to see how everything got loaded
> up. It looked to me like the context resolvers were loaded in the correct
> order. My sample also picked up the right provider with this context
> resolver in place as well.
>
> I'd like to hear opinions on this... or if you wish, I can work on building
> up a sample to demonstrate value. I figured I'd pose the idea here on the
> mailing list instead of a Jira to get a sense of what we want or need.
>
> I think the value-add is that JAXB has a very standardized way of
> processing data, and it's clear when we should be working with JAXB
> objects, so an app should not necessarily be responsible for including
> their own JAXB context resolver.
>
> Any thoughts, concerns, objections?
>
> Thanks..
> mike
>
--
- Bryant Luk
Re: default JAXB context resolver?
Posted by Nicholas L Gallardo <nl...@us.ibm.com>.
Mike,
You're saying make a system level ContextResolver available so that we can
re-use instances and so users don't have to create one. I think that's
good. Take a look at this::
https://svn.apache.org/repos/asf/incubator/wink/contrib/ibm-jaxrs/src/com/ibm/ws/jaxrs/resolver/JAXBContextResolver.java
Dustin created a system level JAXBContextResolver hid all of the caching of
the JAXBContext instances. The resolver is injected into the JAXB related
Providers (as is already done in the current code) and they are able to
share JAXBContext instances. I think Michael Elman (btw, can we just call
you "Mike" and Michael E. "Michael"?) made a comment earlier about liking
the JAXBContext caching mechanism. This is a good way to pull that over.
-Nick
Nicholas Gallardo
WebSphere - REST & WebServices Development
nlgallar@us.ibm.com
Phone: 512-286-6258
Building: 903 / 5G-016
Michael
Rheinheimer/Austi
n/IBM@IBMUS To
wink-dev@incubator.apache.org
07/08/2009 05:12 cc
PM
Subject
default JAXB context resolver?
Please respond to
wink-dev@incubato
r.apache.org
Team,
We had previously discussed implementing a default JAXB context resolver to
better hand JAXB contexts. As far as I can tell, there are no default
"system" context resolvers loaded in WINK; only the context resolvers
defined by an application are available. For JAXB, however, it might make
sense to provide a default.
As a proof of concept, I put a context resolver in wink-common at
org.apache.wink.common.contexts.resolver.JAXBContextResolver
And added the following to
wink-common/src/main/resources/META-INF/core/wink-providers
# Context Resolvers
org.apache.wink.common.contexts.resolver.JAXBContextResolver
I poked around in the debugger a bit just to see how everything got loaded
up. It looked to me like the context resolvers were loaded in the correct
order. My sample also picked up the right provider with this context
resolver in place as well.
I'd like to hear opinions on this... or if you wish, I can work on building
up a sample to demonstrate value. I figured I'd pose the idea here on the
mailing list instead of a Jira to get a sense of what we want or need.
I think the value-add is that JAXB has a very standardized way of
processing data, and it's clear when we should be working with JAXB
objects, so an app should not necessarily be responsible for including
their own JAXB context resolver.
Any thoughts, concerns, objections?
Thanks..
mike