[Microcontainer] - Re: SchemaResolverDeployer is parsing but not deploying
by david.lloyd@jboss.com
So do I need anything beyond this:
| <?xml version="1.0" encoding="UTF-8"?>
|
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
| <bean name="JBossIODeployer" class="org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryDeployer">
| <constructor>
| <parameter>org.jboss.cx.io.metadata.DeploymentMetaData</parameter>
| </constructor>
| </bean>
|
| <bean name="JBossIOParser" class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer">
| <constructor>
| <parameter>org.jboss.cx.io.metadata.DeploymentMetaData</parameter>
| </constructor>
| <property name="name">jboss-iobeans.xml</property>
| <property name="registerWithJBossXB">true</property>
| </bean>
| </deployment>
|
to make this work? I'm getting a ClassCastException on deployment:
| [org.jboss.deployers.plugins.deployers.DeployersImpl] (HDScanner) Deploying vfsfile:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-iobeans.xml
| [org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer] (HDScanner) Parsing file: FileHandler(a)277720476[path=jboss-iobeans.xml context=file:/home/david/src/java/jboss-5.0.0.CR1-r73551/server
| /default/deploy/ real=file:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-iobeans.xml] for deploymentType: class org.jboss.cx.io.metadata.DeploymentMetaData
| [...]
| [org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer] (HDScanner) Parsed file: FileHandler(a)277720476[path=jboss-iobeans.xml context=file:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/ real=file:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-iobeans.xml] to: org.jboss.cx.io.metadata.DeploymentMetaData@73fcd8fb
| [org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer] (HDScanner) Error during deploy: vfsfile:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-iobeans.xml
| org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-iobeans.xml
| [...]
| Caused by: java.lang.ClassCastException
| at java.lang.Class.cast(Class.java:2990)
| at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:230)
|
Sorry in advance if these brilliant forums mangle the logs. I'm not really sure what type it is expecting but it looks to me like it's parsing the XML but not passing the resultant custom metadata to the BeanMetaDataFactoryDeployer. (My DeploymentMetaData class does implement BeanMetaDataFactory).
What did I forget?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153123#4153123
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153123
17 years, 11 months
Delivery Notification <efin_messages_01@raiffeisen.ru>
by Postmaster@lists.jboss.org
This is a delivery status notification, automatically generated by MTA mgate.raiffeisen.ru on Sat, 24 May 2008 04:24:07 +0400
Regarding recipient(s) : efin_messages_01(a)raiffeisen.ru
Delivery status : Failed. Message could not be delivered to domain <raiffeisen.ru> .Failed while initiating the protocol. <[('efin_messages_01(a)raiffeisen.ru', 550, 'efin_messages_01@raiffeisen.ru... No such user')]>
MTA Response :550
The original message headers are included as attachment.
17 years, 11 months
[JBoss Messaging] - Re: PLEASE DO NOT POST JBOSS MQ QUESTIONS HERE
by clebert.suconic@jboss.com
anonymous wrote : an someone provide a one-liner pointing out the *differences*:
In a single but big:
"JBoss MQ (JBMQ)is our legacy implementation of JMS. It exists because there are still production systems using it, and JBoss is obligated to provide support for its users/customers, while JBoss Messaging (JBM) is our new implementation, where we are doing the new features, development and enhancements. JBM is under constant renovation and active development. If you look at our dev forums you will see a lot of activity going on."
Some more information:
JBMQ can *probably* still accept new features or enhancements if users contribute good code without breaking compatibility, but JBoss MQ by it's by definition now is maintenance state only.
JBMQ is the default JMS provider on JBAS 4.0.5 and 4.2.0.
We support replacing JBMQ by JBM as we state on the documentation.
JBM is also the default JMS provider at EAP 4.3, and it is already default on JBoss 5.
I hope this answers your questions.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153109#4153109
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153109
17 years, 11 months
[Installation, Configuration & DEPLOYMENT] - JBoss 4.2.1: Classloader hang at findBoostrapClass
by tingzhou
Recently we run into a serious problem with our JBoss 4.2.1 server. About an hour (sometimes shorter) after the server is started, many threads (hundreds of them) start frequent lockup, all waiting to acquire a "synchronized" lock on AppClassLoader. And the thread that holds the lock has the following stack trace:
java.lang.ClassLoader.findBootstrapClass(Native Method)
java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:891)
java.lang.ClassLoader.loadClass(ClassLoader.java:301)
java.lang.ClassLoader.loadClass(ClassLoader.java:299)
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
java.lang.ClassLoader.loadClass(ClassLoader.java:251)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1273)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
-- snip --
I did a little timing exercise. This simple findBootstrapClass() call, which usually takes a few milliseconds at most, would take 20 seconds to multi-minutes to complete. During this time, since AppClassLoader.loadClass() is synchronized, the entire application simply stops and the requests quickly stack up and crash the application as a result.
I'm not saying this is a JBoss or JVM bug (though could be), since this only happens after we recently deploys our new application code. Some change in our code triggered this behavior but we don't know what it is, and this behavior only shows up in one of our JBoss servers.
Any experience on this kind of lockup? This problem has jeopardized our release schedule and any help will be greatly appreciated.
Ting Zhou
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153108#4153108
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153108
17 years, 11 months