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" <[EMAIL PROTECTED]> Date: Thu, September 15, 2005 5:58 am To: "Dean Hiller" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] -------------------------------------------------------------------------- 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 >
Dean Hiller wrote:Is there any way to get something like methods added to JAXBContext.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. 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. |
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
