Menu
▾
▴
jboss-dev-forums
|
From: <ale...@jb...> - 2005-04-28 12:25:55
|
I would like to see what you are doing. Could you post/send me the code? What kind of warnings? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875753#3875753 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875753 |
|
From: <ale...@jb...> - 2005-04-28 12:43:55
|
I just tried commenting out schema location in testGenericBeanFactory.xml | <!-- | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="urn:jboss:xml-deployer xml-deployer_1_0.xsd" | xmlns="urn:jboss:xml-deployer"> | --> | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xmlns="urn:jboss:xml-deployer"> | It worked fine. Warnings like this | WARN [AttributesHandler] Attribute is not bound: element owner {urn:jboss:xml-deployer}deployment, attribute {http://www.w3.org/2001/XMLSchema-instance}schemaLocation | can be ignored. In fact, there is a property that doesn't include schema instance attributes into Attributes object. Setting it will remove these warnings. I don't understand why NULL is returned. Passing SchemaBinding with handlers should do the job. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875758#3875758 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875758 |
|
From: <ale...@jb...> - 2005-04-28 12:55:22
|
"ad...@jb..." wrote : 2) Even though I've told it the schema with the schema binding (including the real local
| location) this has no affect on the entity resolver:
|
| | 4625 WARN [EntityResolver] Entity is not registered, publicId=null systemId=file:/home/ejort/jboss-head/workspace/kernel/src/resources/xml-test/org/jboss/test/kern
| | el/xml/test/pojo-deployer_1_0.xsd
| |
This is logged by the
| package org.jboss.util.xml;
| public class JBossEntityResolver implements EntityResolver
| {
| private static final Logger log = Logger.getLogger(EntityResolver.class);
|
From getLocalEntityName method. Since this schema is not registered there yet.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875760#3875760
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875760
|
|
From: <ad...@jb...> - 2005-04-28 14:54:41
|
"ale...@jb..." wrote : I would like to see what you are doing. Could you post/send me the code? What kind of warnings? I'll try to reproduce the problem in the testsuite. I was definitley getting a null object back without the schema. The issues with the warnings is not so much that they are appear (though it is undue noise), more that when the schema has a real url (http://jboss.com/etc) it will be doing network requests that might not work behind a firewall. I'll start a new thread on schema usage (what Scott and I discussed before) when I've looked a bit deeper into your current implementation - so I have a more informed opinion :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875791#3875791 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875791 |
|
From: <ad...@jb...> - 2005-04-28 17:54:30
|
I've modified the SimpleCollection test to reproduce the Null problem. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875822#3875822 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875822 |
|
From: <ale...@jb...> - 2005-04-29 12:41:03
|
That's because of this change | <?xml version="1.0" encoding="UTF-8"?> | -<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | +<deployment> | + <!--xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="urn:jboss:xml-deployer xml-deployer_1_0.xsd" | - xmlns="urn:jboss:xml-deployer"> | + xmlns="urn:jboss:xml-deployer"--> | <bean name="SimpleBean1" | class="org.jboss.test.xml.pojoserver.SimpleBeanImpl"> | <property name="aList"> Now the qualified name of the deployment element is QName("deployment"), not QName("urn:jboss:xml-deployer", "deployment") which is used in the schema binding. So, it is just not recognized. BTW, currently, in the XSD all attributes belong to the default/empty namespace, not the urn:jboss:xml-deployer. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875904#3875904 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875904 |
|
From: <ad...@jb...> - 2005-04-29 14:04:39
|
My question was why does it return null rather than throwing an exception?
I know the reason is the namespace is missing/mismatched,
but a user won't :-)
JBossXB has a better chance at giving a reasonable error message than anything
I could do:
| Unmarshaller unmarshaller = UnmarshallerFactory.newInstance().newUnmarshaller();
| KernelDeployment deployment = (KernelDeployment) unmarshaller.unmarshal(url.toString(), schemaBinding);
| if (deployment == null)
| throw new DeploymentException("Unable to parse " + url + " it is not well formed.");
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875923#3875923
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875923
|
|
From: <ale...@jb...> - 2005-04-30 16:31:35
|
Yes, maybe. I was thinking about this: throwing an exception when met an element/attribute that is not bound or just ignoring. Perhaps, there should be a property for this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876029#3876029 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876029 |
|
From: <ad...@jb...> - 2005-05-10 19:05:00
|
It looks like the new parsing is going to cope with everything I throw at it for the pojo parsing. Well done Alex. The outstanding issues are: 1) Using schema annotations to define the parsing 2) The ANY parsing 3) Making the map definition less verbose. Up-to-date progress here: http://jira.jboss.com/jira/browse/JBMICROCONT-32 P.S. I still need to do a lot more testing to complete the parser, but I don't see anything to do that is going to require a pattern that I haven't already successfully used. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877237#3877237 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877237 |
|
From: <ad...@jb...> - 2005-05-10 19:07:38
|
I'd appreciate any insight on the Map/Entry parsing: http://jira.jboss.com/jira/browse/JBMICROCONT-36 Is it possible for the parser to understand this or is this just something that isn't guaranteed to work with xml? | <map> | <key/><value/> | <key/><value/> | <key/><value/> | </map> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877238#3877238 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877238 |
|
From: <ad...@jb...> - 2005-05-10 19:43:59
|
Actually, it looks like I spoke too soon. e.g. What is a good format for defining a map that has non-trivial objects in the key as well as the value. | <map> | <entry> | <key><set><value>1</set></key> | <value>collection><value>2</value></collection></value> | </entry> | </map> | Perhaps this is such a stupid use case we shouldn't support it, and just incorporate the key into the entry i.e. only support trivial keys: | <map> | <entry key="1" class="java.lang.Integer"> | <collection><value>2</value></collection> | </entry> | </map> | I think this would also solves the parsing problem, mentioned above. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877241#3877241 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877241 |
|
From: <sco...@jb...> - 2005-05-10 20:21:24
|
I think incorporating the key into the entry as an attribute is too limiting. In terms of the difference between: | <map> | <entry> | <key><set><value>1</set></key> | <value>collection><value>2</value></collection></value> | </entry> | </map> | and: | <map> | <key><set><value>1</set></key> | <value>collection><value>2</value></collection></value> | </map> | I don't think its an issue of the parser not handling it, but rather having to introduce an uneccessary compilication in the handling of the parser stack state to effectively combine the key and value elements into a composite context at the object factory layer. Alexey could better speak to whether this is an actual complication in the current object factory though. However, since the entry element really does not translate to a single object as far as the java.util.Map api is concerned, the pair does have to be dealt with, and I don't see that its much easier to keep track of this by adding an entry element since the pair container can just as easily be created at the start of the key element as a containing entry element. I browsed through the jaxb2.0 spec again, and they don't support map type of collections. Only arrays and list type of collections are supported so this is a construct that won't be supported other than by proprietary bindings. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877250#3877250 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877250 |
|
From: <ad...@jb...> - 2005-05-10 20:38:01
|
The issue is the verbosity, not just the parsing.
Perhaps I could support both types of map descriptions?
With the short form probably being used the most often?
| <entry key="AKEY">AVALUE</entry>
|
Essentially, all I'm doing is creating a temporary "entry"
| entry.key = new StringValueMetaData("AKEY");
| entry.value = new StringValueMetaData("AVALUE");
|
which is then used at the end of element to do
| mapMetadata.put(entry.key, entry.value)
|
I'm not sure how this would tranlate to schema annotations?
I'll wait to see what Alex says, before doing any more on this.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877253#3877253
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877253
|
|
From: <sco...@jb...> - 2005-05-10 20:48:26
|
For that usecase I would argue that there should be a properties mapping: | <properties> | <entry key="key1">value1</entry> | <entry key="key2">value2</entry> | </properties> | because this is a universal construct that I could define a reusable xsd fragment for the content model and annotation for the binding. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877257#3877257 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877257 |
|
From: <ale...@jb...> - 2005-05-11 08:29:11
|
"ad...@jb..." wrote : It looks like the new parsing is going to cope with everything I throw at it | for the pojo parsing. Well done Alex. Glad to hear it works for you :) I am still not satisfied with the API though. And, frankly, am still also experimenting with other prototypes of the same style trying to come up with a more elegant programming model. Sorry, got hooked and just can't stop now :) "ad...@jb..." wrote : The outstanding issues are: | 1) Using schema annotations to define the parsing | 2) The ANY parsing | 3) Making the map definition less verbose. 1) I think, annotations will be the next step (will need to patch xerces.2.6 for this, 2.7 is going to be released about June 24). 2) I'll probably write some kind of spec for this before coding so we can discuss it in details. 3) is being discussed in this thread. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877300#3877300 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877300 |
|
From: <ale...@jb...> - 2005-05-11 09:41:47
|
"ad...@jb..." wrote : Is it possible for the parser to understand this or is this just something that | isn't guaranteed to work with xml? | | | <map> | | <key/><value/> | | <key/><value/> | | <key/><value/> | | </map> | | So, there are several issues with maps: 1) representation of entries in XML 2) unmarshalling entries (representation of entries in Java) 3) configuration, e.g. with xsd annotations, etc 1) Representation in XML Probably, the most natural one is to have an element that wraps key/value pair, e.g. that represents the entry. This is what you currently do. I don't see a problem with having "complex" keys and values. A key element is unmarshalled (be it of a complex or a simple type) and used as the key, the same for the value element. Another representation is actually your question. I don't have tests for this but it's possible as long as you can rely on the order of the elements in the sequence, i.e. after the key element we always have the corresponding value element. In XSD, when you define the type of the map, you have to use sequence compositor (other kinds of compositors are 'choice' and 'all'). If the compositor is 'all', the order of the elements in XML content is not guaranteed (SAX parser of course will still report elements in the order they appear in the XML content). This is important if we want to make sure that if an XML content is valid we can guarantee the unmarshalling result. How to unmarshal this? Create an entry object when the key element starts, complete and add the entry to the map when the value element is parsed. I was thinking about adding a convenient API for unmarshalling a sequence of elements (w/o a wrapper element) into one object but didn't want to complicate the API too early. I think, it'll be added in the future. 2) Unmarshalling of and Java representation of entries In the approach we use currently, we create objects ahead, i.e. when an element starts we create an object and then add data to it when we parse the content of the element. The disadvantage of this approach is that sometimes we have to create temporary container objects, like a map entry object (as you do) which we actually don't need or a container for constructor arguments for classes that don't have default no-arg constructors. In general, there is no way you can avoid an 'entry' object in this approach. A bit of theory... another approach would be to expose the stack of objects (which is present anyway) to unmarshalling handlers. And instead of requering an element handler to return an object from startElement (or whatever it's called), let the handler to push an object (or maybe even several objects into the stack). Attribute values, text content and child elements would also be pushed into the stack. In the endElement, the element handler would pop objects from the stack and do whatever is needed, i.e. pop key and value from the stack and add them to the map, pop ctor arguments and create an instance, etc. I had one prototype of this approach but the API was a bit complex and error-prone. Though, maybe it was just a bad try. 3) configuration, xsd annotation or something else I am also actually not sure atm how it would translate into xsd annotations. But I believe it's possible :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877311#3877311 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877311 |
|
From: <sco...@jb...> - 2005-05-11 14:59:31
|
I don't see a problem with needing to create holder objects. The main advantage is that they give you a type explicit representation of the stack as opposed to having to know the types and order of the stack. An example I have that has a clean ObjectModelFactory view is the org.jboss.security.auth.login.LoginConfigObjectModelFactory. Here the javax.security.auth.login.AppConfigurationEntry that is represented in the xml config cannot be constructed incrementally as a java bean because it has no setters. All data must be passed in via the ctor. There is an example of such a document with the associated xsds in jboss-head/testsuite/src/resources/xml/mbeanserver: | [starksm@banshee9100 jboss-4.0]$ ls -l jboss-head/testsuite/src/resources/xml/mbeanserver/ | total 10 | drwxrwxrwx+ 2 starksm None 0 May 3 18:12 CVS/ | -rwxrwxrwx 1 starksm None 1879 May 3 18:14 login-config2.xsd* | -rwxrwxrwx 1 starksm None 1599 May 3 18:14 mbean-service_1_0.xsd* | -rwxrwxrwx 1 starksm None 3370 May 3 18:14 testObjFactory.xml* | -rwxrwxrwx 1 starksm None 1040 May 3 18:14 user-roles.xsd* | I think the general extension to jaxb that we need is the notion of a holder object that is a java bean which can be constructed via standard jaxb rules or customizations + a mapping of that holder into the actual object. The mapping could be specified via simple transform/factory interface. The authentication type in the login-config2.xsd could be customized using something like: | <xs:complexType name="authentication"> | <xs:annotation> | <xs:appinfo> | <jbossxb:factory | name="org.jboss.security.auth.login.LoginConfigFactory" | holderClass="org.jboss.security.auth.login.AppConfigurationEntryHolder" | /> | </xs:appinfo> | </xs:annotation> | ... | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877347#3877347 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877347 |
|
From: <ad...@jb...> - 2005-05-11 19:46:06
|
I've figured out what the problem is with the expression of the Map and Key/Value.
The issue is with the polymorphism, my attempts to reduce the
verbosity of the xml and the parsing API.
Essentially, the problem is that to get the polymorphism to work,
I have to introduce a type binding, in this case
key -> valueType
value -> valueType
where valueType can be collection/array/list/ANY/etc.
But this then requires an extra object to be constructed to model the polymorphic behaviour:
| // value binding
| TypeBinding valueType = schemaBinding.getType(valueTypeQName);
|
| configureValueBindings(valueType); // <------ subelements
|
| valueType.setHandler(new DefaultElementHandler()
| {
| public Object startElement(Object parent, QName name, TypeBinding type)
| {
| return new AbstractValueMetaData(new StringValueMetaData());
| }
| etc.
|
Then later I have to unwrap the extra AbstractValueMetaData
| AbstractMapMetaData map = (AbstractMapMetaData) parent;
| MapEntry entry = (MapEntry) child;
| AbstractValueMetaData entryKey = (AbstractValueMetaData) entry.key;
| if (entryKey == null)
| throw new IllegalArgumentException("No key in map entry");
| AbstractValueMetaData entryValue = (AbstractValueMetaData) entry.value;
| if (entryValue == null)
| throw new IllegalArgumentException("No value in map entry");
| map.put(entryKey.getValue(), entryValue.getValue());
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877380#3877380
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877380
|
|
From: <ad...@jb...> - 2005-05-11 19:49:37
|
So the problem is two fold: 1) The need to specify a concrete type in startElement 2) My desire to have a less verbose API in the common case | <entry><key class="java.lang.Integer>1</key><value>x</value></entry> | instead of | <entry><key><value class="java.lang.Integer">1</value></key><value>x</value></entry> | The later is closer to the underlying object model, but obviously more tedious. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877381#3877381 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877381 |
|
From: <ad...@jb...> - 2005-05-11 19:58:52
|
In case it isn't clear from the above posts. The Map stuff is working now, but I'd appreciate it if you know a better way to handle what I'm trying to do. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877383#3877383 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877383 |
|
From: <ale...@jb...> - 2005-05-12 12:42:33
|
"sco...@jb..." wrote : I don't see a problem with needing to create holder objects. The main advantage is that they give you a type explicit representation of the stack as opposed to having to know the types and order of the stack. Ok, thanks for feedback. "sco...@jb..." wrote : I think the general extension to jaxb that we need is the notion of a holder object that is a java bean which can be constructed via standard jaxb rules or customizations + a mapping of that holder into the actual object. The mapping could be specified via simple transform/factory interface. I actually have this general holder. There are some tests for classes that don't have no-arg ctors. I find out that at runtime and collect children. When element is parsed I am trying to find a constructor that would take all the children (the order is the order of the elements in the XML content). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877457#3877457 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877457 |
|
From: <ale...@jb...> - 2005-05-12 13:09:23
|
"ad...@jb..." wrote : Essentially, the problem is that to get the polymorphism to work,
| I have to introduce a type binding, in this case
| key -> valueType
| value -> valueType
| where valueType can be collection/array/list/ANY/etc.
|
| But this then requires an extra object to be constructed to model the polymorphic behaviour:
|
|
| | // value binding
| | TypeBinding valueType = schemaBinding.getType(valueTypeQName);
| |
| | configureValueBindings(valueType); // <------ subelements
| |
| | valueType.setHandler(new DefaultElementHandler()
| | {
| | public Object startElement(Object parent, QName name, TypeBinding type)
| | {
| | return new AbstractValueMetaData(new StringValueMetaData());
| | }
| | etc.
| |
|
| Then later I have to unwrap the extra AbstractValueMetaData
|
| | AbstractMapMetaData map = (AbstractMapMetaData) parent;
| | MapEntry entry = (MapEntry) child;
| | AbstractValueMetaData entryKey = (AbstractValueMetaData) entry.key;
| | if (entryKey == null)
| | throw new IllegalArgumentException("No key in map entry");
| | AbstractValueMetaData entryValue = (AbstractValueMetaData) entry.value;
| | if (entryValue == null)
| | throw new IllegalArgumentException("No value in map entry");
| | map.put(entryKey.getValue(), entryValue.getValue());
| |
You want to get rid of constructing an instance of AbstractValueMetaData, right?
I think, you could just use the DefaultElementHandler as is, w/o overwritting the startElement. Which will just propagate the MapEntry further and you will be able to add the actual key and value to it.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877461#3877461
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877461
|
|
From: <ad...@jb...> - 2005-05-12 21:26:23
|
Yes, but the problem is also with processing the attributes.
<key class="java.lang.Integer">7</key>
will eventually lead to
map.put(new StringValueMetaData("java.lang.Integer", "7"), ...)
whereas
<key><collection/></key>
leads to
map.put(new CollectionValueMetaData(), ...)
The new AbstractValueMetaData(new StringValueMetaData()))
serves two purposes
1) The AbstractValueMetaData is really just a holder for the polymorphic object
2) I have somewhere to store the attributes if they are present, although
they only apply if there is a direct xsd:string element.
The problem I think is the ordering, which means I have to put something
in place to meet all possible later outcomes:
key -> AbstractValueMetaData
attributes -> StringValueMetaData
valueGroup -> It is only here that I know what is really going on
This also repeats for the "value" part of the map element.
Maybe I should be looking at richer holder object that does things a bit
more lazily?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877542#3877542
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877542
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X