[alesj]

It accepts the new property but it doesn't seem to notice the jboss-remoting.xml file which is in the same place as the jboss-beans.xml that contains the above.

Sure. As expected. ;-)
When this bean is installed, we're passed PARSE stage.
Which is where this new deployer will kick in, for the next deployments.

Try deploying jboss-remoting.xml separately, after you've deployed this jboss-beans.xml.

btw: you could write this xml config with the new stuff :-)

 <jbossxb-parser xmlns="urn:jboss:deployers:2.0"
 name="RemotingMetaDataParser"
 metadata="org.jboss.cx.remoting.metadata.RemotingMetaData"
 name="jboss-remoting.xml"
 register-with-jbossxb="true"
 />

just add this before

 <bean name="SchemaResolverConfig" class="org.jboss.xb.binding.sunday.unmarshalling.SchemaResolverConfig">
 <property name="bindingClasses">
 <map keyClass="java.lang.String" valueClass="java.lang.String">
 <entry>
 <key>urn:jboss:deployers:2.0</key>
 <value>org.jboss.deployers.vfs.plugins.xb.SchemaResolverDeployerMetaData</value>
 </entry>
 </map>
 </property>
 </bean>

[dmlloyd]

I did the "jbossxb-parser" element after the "bean" element in the same "deployment" element and I'm getting a validation error. Does it have to be in a separate "deployment" element?

[alesj]

Does it have to be in a separate "deployment" element?

Sure.
Use logic. :-)
We first need to parse the file, and only after that we register the schema that recognizes jbossxb-parser element, which is what we want to parse.
Chicken and the egg. ;-)

[dmlloyd]

Well, when you explain it *that* way... :-) Not knowing how the parsers work internally, I didn't know if it did some fancy streaming-dynamic-recombobulation or something.

[adrian.brock]

Well, when you explain it *that* way... :-) Not knowing how the parsers work internally, I didn't know if it did some fancy streaming-dynamic-recombobulation or something.

There's a feature request in JBossXB so you can do it in the same file.
Vote for it:
http://jira.jboss.com/jira/browse/JBXB-135

[dmlloyd]

OK, so I've got another dumb question but I can't find the answer in the docs, and I don't understand what I'm seeing in the source code. I'm getting a ClassCastException here:

Caused by: java.lang.ClassCastException: org.jboss.cx.remoting.metadata.RemotingMetaData
at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:147)
at org.jboss.cx.remoting.jrpp.EmbeddedBootstrap.deploy(EmbeddedBootstrap.java:21)

Looks like it wants the result of the parsing to be a KernelDeployment instance. But I'm sure I've seen metadata objects in other projects that don't implement this interface - and besides, I thought that if I implemented BeanMetaDataFactory on my metadata beans that it would use this data somehow to produce KernelDeployments for me?

So... what basic point am I missing now? :-)

[alesj]

I think you're misusing BasicXMLDeployer.
This one expects KernelDeployment. As the exception and code clearly say. :-)
So your URL must point to MC beans xml file.

OK, I'm guessing here.
You have a file that is your custom xml.
e.g.

<remoting>
 <endpoint name="someendpoint"/>
</remoting>

And you want to get RemotingMD out.
Then all you need to is to change that line

 KernelDeployment deployment = (KernelDeployment) unmarshaller.unmarshal(url.toString(), resolver);

to

 RemotingMD deployment = (RemotingMD) unmarshaller.unmarshal(url.toString(), resolver);

Since the unmarshaller already knows about your schema (if it is previously registered).
And the CCE proves that, by knowing the RemotingMD class.

[dmlloyd]

"alesj" wrote:
I think you're misusing BasicXMLDeployer.

Well I certainly won't argue that.

"alesj" wrote:
This one expects KernelDeployment. As the exception and code clearly say. :-)
So your URL must point to MC beans xml file.

Right - my -beans.xml looks like this (not using the new stuff quite yet):

<deployment xmlns="urn:jboss:bean-deployer:2.0">
 <bean name="RemotingMetaDataParser" class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer">
 <constructor>
 <parameter>org.jboss.cx.remoting.metadata.RemotingMetaData</parameter>
 </constructor>
 <property name="name">jboss-remoting.xml</property>
 <property name="registerWithJBossXB">true</property>
 </bean>
</deployment>

...based on previous examples given here and elsewhere.

"alesj" wrote:
OK, I'm guessing here. You have a file that is your custom xml. And you want to get RemotingMD out.

Not quite. I don't really care about getting my RemotingMetaData out. I just want the container to pull the BeanMetaData from it (it implements BeanMetaDataFactory) and use it to create the actual deployment. Adrian stated that you don't need to write a deployer if you use the JAXB annotations, and this is exactly what I'm trying to do.

"alesj" wrote:
Then all you need to is to change that line

 KernelDeployment deployment = (KernelDeployment) unmarshaller.unmarshal(url.toString(), resolver);

to

 RemotingMD deployment = (RemotingMD) unmarshaller.unmarshal(url.toString(), resolver);

So I do need my own deployer after all?

[alesj]

OK, now I'm confused. :-)
What is the file that causes that CCE?

[dmlloyd]

Glad I'm not the only one.

Here's the remoting-deployer-beans.xml: http://pastebin.stonekeep.com/1825
Here's RemotingMetaData.java: http://pastebin.stonekeep.com/1826
The jboss-remoting.xml that it fails to deploy is:

<remoting xmlns="urn:jboss:remoting:3.0"/>

The exception is:

Exception in thread "main" java.lang.RuntimeException: Deployment failed
 at org.jboss.cx.remoting.jrpp.EmbeddedBootstrap.deploy(EmbeddedBootstrap.java:23)
 at org.jboss.cx.remoting.jrpp.Test2.main(Test2.java:12)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: java.lang.ClassCastException: org.jboss.cx.remoting.metadata.RemotingMetaData
 at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:147)
 at org.jboss.cx.remoting.jrpp.EmbeddedBootstrap.deploy(EmbeddedBootstrap.java:21)
 ... 6 more

[alesj]

The jboss-remoting.xml that it fails to deploy is:

<remoting xmlns="urn:jboss:remoting:3.0"/>

OK, like I said:

"alesj" wrote:

You have a file that is your custom xml.

The thing is very simple. :-)
You should not be delegating parsing of this file to BasicXMLDeployer.
Since, like also already said, this one only 'speaks' MC beans.
You should somehow delegate parsing to the new RemotingMetaDataParser deployer/parser you've installed before.

Look at my simple bootstrap that I've done for my OSGi demo:
- http://anonsvn.jboss.org/repos/jbossas/projects/demos/osgi/

You can register new deployers there.
And the file will be delegated to all deployers, but only picked up by your new RemotingMetaDataParser.

[dmlloyd]

Ooooh, I see - it's not the deployment that's the problem, it's my test bootstrap. Heh. OK, I'll have a look.