[JBoss Messaging] - java.lang.ClassCastException: org.jboss.messaging.core.plugi
by jgilbert
I'm trying to configure a Topic in a cluster. I have configured ports-01 and ports-02. If either server is started first then it successfully starts. And I can publish messages to my topic on the first server.
However, the 2nd server fails with the following exception.
Am I doing something wrong or is this a bug?
|
| 13:48:02,658 ERROR [ExceptionUtil] Topic[null, name=net.taylor.TestTopic] startService
| java.lang.ClassCastException: org.jboss.messaging.core.plugin.postoffice.cluster.RemoteQueueStub
| at org.jboss.jms.server.destination.TopicService.startService(TopicService.java:74)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
| at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
| at $Proxy0.start(Unknown Source)
| at org.jboss.system.ServiceController.start(ServiceController.java:417)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy4.start(Unknown Source)
| at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy115.start(Unknown Source)
| at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
| at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
| at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy9.deploy(Unknown Source)
| at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
| at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
| at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
| at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
| at $Proxy0.start(Unknown Source)
| at org.jboss.system.ServiceController.start(ServiceController.java:417)
| at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy4.start(Unknown Source)
| at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
| at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy5.deploy(Unknown Source)
| at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
| at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
| at org.jboss.Main.boot(Main.java:200)
| at org.jboss.Main$1.run(Main.java:464)
| at java.lang.Thread.run(Unknown Source)
|
Here is the configuration for my topic:
| <mbean code="org.jboss.jms.server.destination.TopicService"
| name="jboss.messaging.destination:service=Topic,name=net.taylor.TestTopic"
| xmbean-dd="xmdesc/Topic-xmbean.xml">
| <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
| <attribute name="Clustered">true</attribute>
| </mbean>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977639#3977639
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977639
19 years, 7 months
[JBoss Seam] - Re: Eclipse Getting Started Guide
by james.williams＠jboss.com
"japplicoon" wrote : I now started the n-th trial (I'm quite quick now ;-) with jboss-seam.jar in server/default/lib. "sample" did not work because parse errors with processflow config files, but I got the "blank" app deployed successfully.
| The start page came up, ok. But I had to again add the Module-dependency on jboss-seam.jar (the one you suggested to remove) to get the Seam Component (MySfsb in the example) be resolved properly.
|
| But I still don't understand why the publishing process does not pick up jboss-seam jar (and jbpm-xxx.jar) into the ear file while it is present in nearly every directory ...
|
| Since I don't like to be tied to eclipse to build my project anyway, I wonder whether I could feed the "publish" process with a custom buid.xml I may use outside eclipse as well? Unfortunately, seam-gen only packages a build.xml for the "non-wtp"-Structure. Perhaps someone has already done something like that?
|
| Greets.
| sonja
|
What version of eclipse are you using? Is it 3.2 with callisto and the exact plugins mentioned in the guide, or is it something else?
I have not tested seam-gen with JBossIDE 2.0-Beta1 or any other combination of eclipse+plugins yet, so I suspect this is an eclipse wtp quirk. Let me know what you're using and I'll do some digging.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977637#3977637
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977637
19 years, 7 months
[Security & JAAS/JBoss] - JAAS/LDAP Roles configuration pulls superset instead of filt
by sarahm
I am having a strange error with what should be a simple configuration. I am able to authenticate off LDAP, but the role list received is not the one I expect.
I have the following config (with my actual domain, etc):
login-config.xml
| <application-policy name="testLDAP">
| <authentication>
| <login-module code="org.jboss.security.auth.spi.LdapLoginModule"
| flag="required">
| <module-option name="java.naming.factory.initial">
| com.sun.jndi.ldap.LdapCtxFactory
| </module-option>
| <module-option name="java.naming.provider.url">
| ldap://ldap.mydomain.com/
| </module-option>
| <module-option name="java.naming.security.authentication">
| simple
| </module-option>
| <module-option name="principalDNPrefix">uid=</module-option>
| <module-option name="principalDNSuffix">
| ,ou=People,dc=mydomain,dc=com
| </module-option>
| <module-option name="rolesCtxDN">
| ou=Groups,dc=mydomain,dc=com
| </module-option>
| <module-option name="uidAttributeID">memberUid</module-option>
| <module-option name="matchOnUserDN">false</module-option>
| <module-option name="roleAttributeID">cn</module-option>
| <module-option name="roleAttributeIsDN">false</module-option>
| <module-option name="searchScope">ONELEVEL_SCOPE</module-option>
| </login-module>
| </authentication>
| </application-policy>
Example LDAP User:
dn: uid=sarahm,ou=People,dc=mydomain,dc=com
| objectClass: posixAccount
| objectClass: shadowAccount
| objectClass: inetOrgPerson
| objectClass: sambaSamAccount
| uid: sarahm
| uidNumber: 1040
| gidNumber: 6000
Example LDAP Group:
dn: cn=it,ou=Groups,dc=mydomain,dc=com
| cn: it
| displayName: it
| sambaGroupType: 2
| objectClass: top
| objectClass: posixGroup
| objectClass: sambaGroupMapping
| gidNumber: 6008
| memberUid: sarahm
| memberUid: user1
| memberUid: user2
With this configuration, I expect only the groups for the current user to be used as roles. However, in both JSP (request.isUserInGroup) and the auth-constraint roles in web.xml all of my checks for roles will resolve to true if I have a corresponding group, even if the user is not in the group. For instance, request.isUserInGroup("accounting") is true for any user as the accounting group exists in LDAP.
It seems for some reason roles are not being filtered properly by user.
Any suggestions would be appreciated.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977631#3977631
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977631
19 years, 7 months
[JBossCache] - Re: Hibernate/Cache conceptual mismatch
by steve.ebersole＠jboss.com
Yes, but as already well discussed and documented, putFailFast is and has always been a hack job ;)
---
As I said, I have not yet had time to really think through all the various use cases for SYNCH vs ASYNCH of these putFromExternalRead() calls.
In general, yes, all database writes result in a cache write (there are some cases that will result in a cache invalidation...). Furthermore, this will result in the region being write locked by TreeCache for the remainder of the transaction *on the same node* (TreeCache does *not* provide a distributed lock manager).
In my mind the general process here would be:
1) get an intention lock (or even re-use write lock here, if it is truly that 'symbolic') when you did the get() if no node/data existed
2) get db state
3) put state into cache, releasing the intention lock
In which case we'd need a way to specify our "do a get and acquire such an intention lock if no such node/data is found" requirement. Flash-to-bang I do not feel comfortable with having them be seperate operations, i.e.:
Object state = cache.get(fqn);
if ( state == null ) {
cache.intentionLock(fqn);
state = ...;
}
Instead, maybe something like:
Object state = cache.getWithIntention(fqn);
if ( state == null ) {
state = readFromExternal();
cache.putFromExternalRead(fqn,state); // releases lock
}
...
?
Additionally, I'd throw in that really you and I are simply proposing different "ignore it" solutions to an exception condition. Perhaps we need to call a spade a spade and actually throw an exception in this case. There is not a time I can think of where I do a read from the cache, see no data, read from the database, go to put that db data into the cache and find data now in the cache where the overall outcome is anything desireable. Maybe a simple replication of the cache fill event from another node is ok? But, in general, simply "not replacing" the data just delays the inevitable. On the other hand, the "locking" approach makes this consitent at least. The one corner case I see right now is what do to with a replication event where the node has such an intention lock.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977625#3977625
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977625
19 years, 7 months