[JBoss Seam] - Class type issue
by lcoetzee
Hi,
I have quite an interesting issue (which at this point has me stumped).
I have a class Service that has a one-to-many to Topic (which is a base clase). Topic is extended into three other (CMSTopic, DFTopic and MMTopic).
Service
| @Entity
| @Name("service")
| @Table(name = "service")
| public class Service implements Serializable {
| private Map<Integer,Topic> topics = new HashMap<Integer,Topic>();
|
| @OneToMany(mappedBy = "service")
| @MapKey(name="id")
| public Map<Integer,Topic> getTopics() {
| return topics;
| }
| }
Topic
@Entity
| @Name("topic")
| @Table(name = "topic")
| @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
| @DiscriminatorColumn(name = "topic_type", discriminatorType = DiscriminatorType.STRING)
|
| public class Topic implements Serializable {
| private Service service;
| @ManyToOne(fetch=FetchType.LAZY)
| public Service getService() {
| return service;
| }
| }
|
|
and the extended classes e.g. CMSTopic
| @Entity
| @Name("cmsTopic")
| @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
| @DiscriminatorColumn(discriminatorType = DiscriminatorType.STRING)
| @DiscriminatorValue("CMS")
| public class CMSTopic extends Topic {
| }
When I do a service.getTopics().values() the correct subclasses of Topic is returned. But for some reason the instance type is weird.. I get the following when doing an getClass() on each element in the returned map:
class csir.structure.par.DFTopic
class csir.structure.par.CMSTopic
class csir.structure.par.Topic_$$_javassist_227
class csir.structure.par.CMSTopic
Does anybody have an idea of why only one of these would be Topic_$$_javassist_227 while the others are the correct type ?
Thanks
Louis
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060403#4060403
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060403
18Â years, 9Â months
[JBoss Messaging] - Re: PingTimerTask broken pipe
by bob_walker99
Hi - I' checked my code and did find some instances in my sending client that wasn't closing connections properly in the event of exceptions, which I've fixed, but I've had the same problem overnight again.
I've isolated my sending and receiving jobs - this morning I've successfully sent around 10,000 messages to a single queue with no apparent resource hit to either my client or the JBM server, so I have to conclude that the problem is in the receiver.
I have an ExceptionListener in place that notifies the thread that starts the listener when an exception occurs, this disposes all the JMS environment objects and re-initialises them, correctly as far as I can see.
However, all this is kind of academic, because I'm not actually getting exceptions in my listener code - the threads and open file handles are just mounting and mounting, but until the server runs out of resources, it does actually work. I'm at a bit of a loss as to where to look next...?
If it helps, these are fairly large text messages, often up to 1Mb, so I've set the queue's FullSize param to 100, and the PageSize and DownCacheSize to 20 apiece - are these reasonable values?
Any advice gratefully received.
Best regards,
Bob
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060400#4060400
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060400
18Â years, 9Â months
[JBossWS] - Failed to setup client ENC ... Cannot bind webservice to cli
by sverker
We have a project that deploys to the AS as an ear. Suddenly the deployment begun to fail because it says that the webservice clients are already bound.
We have two webservice clients that are deployed as jar files in the ear. They are referenced by application.xml like this:
| <module>
| <java>IdentificationApi-europe-3.0-1.jar</java>
| </module>
| <module>
| <java>SmsApi-europe-5.1-1.jar</java>
| </module>
|
Until now this have worked fine. The webservice clients were deployed and could be looked up from jndi. They are not directly called by the ejb's but through a third package.
Now we've started to get exceptions during the deploy, the webservice clients are first bound but directly after we get an Exception that client ENC could not be bound because of NameAlreadyBoundException. According to the debug output in server.log this happens when it tries to deploy our ejb jar. I've searched that jar and the only reference I can find is that MANIFEST.MF specifies one of the webservice clients in it's classpath (don't know why though, as there is no reference to it in pom.xml)
This is the relevant log output:
13:11:34,154 INFO [ClientDeployer] Client ENC bound under: IdentificationApi30Europe-client
| 13:11:34,444 INFO [ClientDeployer] Client ENC bound under: SmsApi51Europe-client
| 13:11:34,584 WARN [NestedThrowable] Duplicate throwable nesting of same base type: class org.jboss.deployment.DeploymentException is assignable from: class org.jboss.deployment.DeploymentException
| 13:11:34,594 ERROR [MainDeployer] Could not start deployment: file:/C:/java/jboss-4.0.5.GA/server/default/tmp/deploy/tmp34838t2-tvportal-0.1.ear-contents/t2-tvportal-core-0.1.jar
| org.jboss.deployment.DeploymentException: Failed to setup client ENC; - nested throwable: (org.jboss.deployment.DeploymentException: Cannot bind webservice to client environment; - nested throwable: (javax.naming.NameAlreadyBoundException))
|
| at org.jboss.deployment.ClientDeployer.start(ClientDeployer.java:171)
| at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
| at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
| at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
| sorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
| er.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
| or.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
| BeanOperationInterceptor.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 $Proxy8.deploy(Unknown Source)
| at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
| tScanner.java:421)
| at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
| canner.java:610)
| at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
| doScan(AbstractDeploymentScanner.java:263)
| at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
| loop(AbstractDeploymentScanner.java:274)
| at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
| run(AbstractDeploymentScanner.java:225)
| Caused by: org.jboss.deployment.DeploymentException: Cannot bind webservice to c
| lient environment; - nested throwable: (javax.naming.NameAlreadyBoundException)
| at org.jboss.ws.integration.jboss.WebServiceClientDeployer.setupServiceR
| efEnvironment(WebServiceClientDeployer.java:94)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
| java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
| sorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
| er.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 $Proxy62.setupServiceRefEnvironment(Unknown Source)
| at org.jboss.webservice.WebServiceClientHandler.setupServiceRefEnvironme
| nt(WebServiceClientHandler.java:94)
| at org.jboss.deployment.ClientDeployer.setupEnvironment(ClientDeployer.j
| ava:272)
| at org.jboss.deployment.ClientDeployer.start(ClientDeployer.java:167)
| ... 22 more
| Caused by: javax.naming.NameAlreadyBoundException
| at org.jnp.server.NamingServer.bind(NamingServer.java:144)
| at org.jnp.server.NamingServer.bind(NamingServer.java:109)
| at org.jnp.server.NamingServer.bind(NamingServer.java:109)
| at org.jnp.server.NamingServer.bind(NamingServer.java:109)
| at org.jnp.interfaces.NamingContext.bind(NamingContext.java:566)
| at org.jnp.interfaces.NamingContext.bind(NamingContext.java:531)
| at org.jboss.util.naming.Util.bind(Util.java:102)
| at org.jboss.util.naming.Util.bind(Util.java:89)
| at org.jboss.ws.integration.jboss.WebServiceClientDeployer.setupServiceR
| efEnvironment(WebServiceClientDeployer.java:87)
| ... 36 more
|
If I remove the webservice clients from application.xml then the ejb jar is not deployed. The application is generated with AndroMDA so the problem could have occured because of some update there but on the other hand I've verified all deployment descriptiors and it looks correct. Another strange thing is that if I deploy the application as an unpackaged ear, i.e. as a directory then it works eventhough it's the same content.
The problem first occured when we deployed on a freshly installed 4.2.0. We then went back to our lab server with 4.0.5, the same problem. Even when taking the same ear that deploys successfully on the production server (also 4.0.5) cause the same problem.
What to look for? What could be the cause of this problem?
What is the correct way to deploy the webservice clients in our ear? I couldn't find documentation regarding that so I tried this variant and it has worked until now.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060390#4060390
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060390
18Â years, 9Â months