[Design of JBoss Web Services] - JBWS-1079 - Incorrect WSDL to Java mapping for anonymous str
by darran.lofthouse@jboss.com
I need some clarification on what is going to be the correct solution for this task.
It looks like the current naming convention was chosen because that is the way it is generated by wscompile, we even have a test in the testsuite to make sure that the generated class does have the same name as the class generated by wscompile.
As I mentioned in the Jira task the jax-rpc specification says that the name should be the name of the nearest enclosing element, complexType or simpleType, I haven't seen anything that says it should be created by concatenating a series of names together.
There would however be a problem with just taking the name of the enclosing element. If two different elements with the same name (because they are in their own complex types contain an anonymous simple type then there will be a name collision.
The jax-rpc specification does contain a section that describes the expected collisions and this doesn't appear to be one of them.
To try and get an idea of how this has evolved in the later specs I have tried generating the code using the JaxB 2.0 RI from Sun, the RI generates the type as a static inner class within the class representing the enclosing type. This does mean that the anonymous type is named after the element that contains it and it also gets round the naming collisions but it feels as if this is ahead of what is intended by the JAX-RPC spec.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978411#3978411
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978411
19 years, 5 months
[Design of JBossCache] - Re: API Issues integrating 2.0.0.DR1 in HEAD
by bstansberry@jboss.com
I've started working on #2 above. This work ties into what I think should be done for MC usage of the cache.
1) We already have configuration via DOM Elements and Properties of complex types like CacheLoaderManager. We need to add the ability to configure via MC construction of POJOs that represent all the configuration elements. The MC doesn't need to use Element/Properties to build up these POJOs.
2) Configuration becomes a composite object, with a contained CacheLoaderConfig, (new) BuddyReplicationConfig and (revised) EvictionConfig.
3) When the old Element/Properties style of configuration is used, all parsing of DOM elements/reading of Properties to populate the config objects should be done within the config objects themselves. E.g. pass an Element to the constructor of CacheLoaderConfig and let it parse it. CacheLoaderManager constructor gets passed the CacheLoaderConfig, not an Element. BuddyManager gets passed a BuddyReplicationConfig, not an Element.
4) The various config objects like CacheLoaderConfig are now exposed to user code via a getter in Configuration. This means their setter methods are also exposed, so if those methods are invoked after the cache is started we need to check if that's allowed. This is already done in Configuration; need to apply the same technique in the other config objects.
I've got a good start on this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978370#3978370
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978370
19 years, 5 months