[adrian.brock]

"alesj" wrote:

The fix is for you to learn xsd, XSD 1.0.1 :-)

Looks like not that I'll only learn, I'll have to make a whole degree out of it.
I though JBossXB Builder was here to relieve the xsd pain, but it's turning to be the other way around ... :-)

No. The port to JBossXBBuilder has just caught the fact that you didn't do
the original work correctly ;-)

It's like what I found when I really tested the javabean constructor stuff
from the container project (see other thread with the jira issue :-)

i.e. we create an mc-commons.xsd and you xsd:redefine that into your namespace.
You can then use all the mc xsd types in your namespace and the user
doesn't have to write all those xmlns directives. ;-)

And how does this affect jaxb usage?

I don't understand the question. Did you even read the thread I had with
Kabir? You're a fast reader if you did, it was a long thread.

Here's a different summary.

The idea is to make the value type and group (and other xsd artificats from the
mc) part of your schema/namespace.

1) It will make your life simpler since you can just reuse the already defined parsing

e.g. this will automagically create a value element/type in your
namespace with the MC's value group defined in your namespace

@XmlElement(name="value")
public void setValue(ValueMetaData value)

and it will be maintained going forwards as it evolves.

The same goes for the schema definition via mc-commons.xsd

2) It will make the user's life simpler since they don't have to type xmlns
all over the place (or think about which namespace it belongs in)

<policy xmlns="urn:jboss:policy:1.0">
 <binding name="somename">
 <!-- no need for namespace for known/native value type -->
 <value class="java.lang.Integer">42</value>
 </binding>
</policy>

[alesj]

I don't understand the question. Did you even read the thread I had with
Kabir? You're a fast reader if you did, it was a long thread.

I did, post by post when they came up.
But like you said, it's a long thread, which took quite some time to 'grow', so probably some details got blurred. :-)

The idea is to make the value type and group (and other xsd artificats from the mc) part of your schema/namespace.

I get the idea.
It was this automagic that I didn't see/understand:

e.g. this will automagically create a value element/type in your
namespace with the MC's value group defined in your namespace

@XmlElement(name="value")
public void setValue(ValueMetaData value)

So the only work to be done is to split those common elements into mc-commons.xsd?

But will that jaxb automagic work currently ootb?
Since I believe I tried something similar already and got exception on the types that need special adapter, e.g. AutowireType --> AutowireTypeValueAdapter.
Not being able to handle them, saying there is no existing adapter for that particular type.

[alesj]

"alesj" wrote:
And how does this affect jaxb usage?

Similar question :-)

What would this xsd:refine map to in jaxb annotations? My understanding was that using jaxb it generates a schema from the annotations?

- http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134223#4134223

[kabirkhan]

"alesj" wrote:

Since I believe I tried something similar already and got exception on the types that need special adapter, e.g. AutowireType --> AutowireTypeValueAdapter.
Not being able to handle them, saying there is no existing adapter for that particular type.

I think you can solve that by adding a package-info.java to your package similar to org.jboss.kernel.plugins.deployment.package-info.java

[alesj]

I think you can solve that by adding a package-info.java to your package similar to org.jboss.kernel.plugins.deployment.package-info.java

Sure, but I don't want to have duplicates.
It shouldn't work that way.

[adrian.brock]

"alesj" wrote:

I think you can solve that by adding a package-info.java to your package similar to org.jboss.kernel.plugins.deployment.package-info.java

Sure, but I don't want to have duplicates.
It shouldn't work that way.

We should really be able to specify the adapter on the class being adapted
rather than having to repeat it on every top level package.

e.g.

@JBossXMLAdapter(ConstrollerStateXMLAdapter.class)
public class ControllerState {}

Raise it as a feature request in JBossXB

[alesj]

Raise it as a feature request in JBossXB

Pushing this one to Alexey:
- http://jira.jboss.com/jira/browse/JBXB-125

[aloubyansky]

Finally, fixed. I used @JBossXmlAdaptedType for this (it had already had type as a target). Here is an example from the testsuite

@XmlType()
@JBossXmlAdaptedType(valueAdapter=CardinalityValueAdapter.class)
public class Cardinality extends JBossObject implements Serializable