jaxb spec may accept jaxme feature

[de...@xsoftware.biz]

See below email from sun guy.  If the solution I have in my head works for
them, they may accept the new feature I have been adding to jaxme.  That
would be pretty cool.  Do you think you will accept that code I submitted?
 If so, I will probably start working on the wildcard/any feature in about
a month after I tie some other stuff up and have more of my platform using
JaxME in it.

thanks,
dean



---------------------------- Original Message ----------------------------
Subject: Re: feature request
From:    "Joe Fialli" <Jo...@Sun.COM>
Date:    Thu, September 15, 2005 5:58 am
To:      "Dean Hiller" <de...@xsoftware.biz>
Cc:      jsr-31-comments@jcp.org
--------------------------------------------------------------------------

Dean Hiller wrote:

> Is there any way to get something like methods added to JAXBContext.
>
> Specifically, I would love to see
>
> int JAXBContext.registerPackages(String package, ClassLoader cl); void
JAXBContext.unregisterPackages(int id);

Rationale on why these methods do not exist extracted from JAXB 2.0 
Specification, Section  4.2 JAXBContext.

/Design Note - JAXBContext class is designed to be immutable and thus 
thread-safe. Given the amount of dynamic processing that potentially 
could take place when creating a new instance of JAXBContxt, it is 
recommended that a JAXBContext instance be shared across threads and 
reused as much as possible to improve application performance.
/
//

>
> This allows the dynamic ability to add and remove packages that can be 
marshalled/unmarshalled at runtime without double parsing.  ie. I get 
some xml from a client and I don't know which marshaller to use  because
I have to have a JAXBContext for each new package that
> dynamically comes in(they do not all come in at once as services can  be
deployed after other services).  I have modified JaxME to test this  out
and it works great.  With JaxME, I can now register new packages 
without creating a new JAXBContext.

I agree with your use case.  Have you been able to address the following 
issue that prevented
us from adding mutators to JAXBContext..

By not having any mutators on JAXBContext, none of the accesses to 
JAXBContext need to be
slowed down by synchronize blocks.  It would impact  JAXB
unmarshal/marshal performance
if each access to the XML/Java binding needed to go through a
synchronize block due to the
potential of someone adding /removing a package mid marshal/unmarshal.

I guess that it could be explicitly javadoc'ed that no package can be 
added or removed
while marshalling or unmarshalling is occuring for a JAXBContext.  But 
without explicitly
synchronizing access to the logical XML Schema component/Java component 
mapping maintained
by JAXBContext, it is an error-prone concept that we were trying to 
design away by
the current JAXBContext design.

-Joe Fialli, Sun Microsystems

> I can also do this with castor but that is not JAXB compliant.
> thanks for any info,
> dean
>

Re: jaxb spec may accept jaxme feature

[Jochen Wiedmann <jo...@gmail.com>]

dean@xsoftware.biz wrote:

> See below email from sun guy.  If the solution I have in my head works for
> them, they may accept the new feature I have been adding to jaxme.  That
> would be pretty cool.  Do you think you will accept that code I submitted?
>  If so, I will probably start working on the wildcard/any feature in about
> a month after I tie some other stuff up and have more of my platform using
> JaxME in it.

Quoting 
http://mail-archives.apache.org/mod_mbox/ws-jaxme-dev/200509.mbox/%3ce75283b105091422413e4fb3a7@mail.gmail.com%3e

 > I am basically quite ready to add the feature. I have certain
 > requirements though:

 > - First of all, to save me work, please be so kind to provide a
 >   context diff (diff -ubR), becase that will allow me to detect
 >   much better what you have actually changed.
 > - Second, in your own interest: If you want this feature to stick
 >   in the code, please provide a unit test as well, that verifies
 >   whether it works. Otherwise, there will be no references in the
 >   source code, and the danger is high, that someone (aka me) will
 >   remove it in the future without prior notice.


---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org