[JBoss Seam] - Re: Basic Seam questions
by lightbulb432
Thanks for the clarification. Here are a couple more questions I have in addition to my previous posting:
1)
Let me clarify if I have a correct understanding of annotations and lifecycle based on the past several posts. Perhaps somebody could clarify, correct or add additional info to what I describe below:
Stateful Session Bean:
A conversation begins when an action is called by a JSF view on a method marked @Begin. The conversation ends upon timeout or when a method marked @End is called.
In either case of an ended conversation, Seam calls the @Destroy method, in which the developer puts ????? code. Because that same method is required to be marked @Remove by Seam, the bean is to be discarded. Before the bean is actually discarded, though, the @PreDestroy method is called.
Stateless Session Bean:
A conversation begins when an action is called by a JSF view on a method marked @Begin. The conversation ends upon timeout or when a method marked @End is called.
In either case of an ended conversation, Seam calls the @Destroy method, in which the developer puts ????? code. Because SLSBs can't have @Remove methods, this is where I get confused for SLSBs.
2)
When we say "Seam calls the @Destroy method", what exactly is "Seam" in that context? Is it through that SeamInterceptor or some kind of SeamPhaseListener thing that we put into the Seam configuration files? How does Seam actually sit on top of JSF to do what it does? (I tried to do the debug from FacesServlet onwards, but seam-gen didn't bring include any source code in the final build so I'm tracking them down for all the JARs one-by-one. Is including the source code a worthwhile suggestion for seam-gen?)
3)
Must @Begin and @End methods be defined on the same bean class (e.g. RegisterBean), or can a @Begin method in one bean start a conversation that is ended by an @End method in another bean (e.g. MaintainRegistrationBean)? I tried it out but can't tell for sure if it's supposed to work that way or not...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994342#3994342
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994342
19 years, 4 months
[Clustering/JBoss] - Re: Clustering local interfaces.
by bstansberry＠jboss.com
I'll preface this all by saying you're going to have to try it out; I'm pretty sure most of our unit tests involve EJBs with remote interfaces.
Clustering an EJB does the following for you:
1) On the client side:
Client gets a smart proxy that automatically tracks cluster topology, load balances calls around the cluster, and can fail over to another server if it detects certain kinds of failures during a call.
(Note the client can be inside the appserver with the beans; 'client' is any code that access the beans and makes calls on them.)
2) On the server side:
For beans with state, keeps state in sync between servers. For SFSBs that means replicating state. For entities, that means invalidating local caches if an entity is changed on another server. (For EJB3 entities it currently means replicating state; this may move to an invalidation model or to a choice.)
OK, with all that spelled out, now to answer your question...
The client-side benefits don't apply if you have no remote interface, since without it a client can only interact with a bean in the same jvm.
The server side benefits do apply. For example, if the 'client' is a servlet contacting an SFSB, if you store an EJBHandle in the session and replicate the session, if the user fails over to another server, the EJBHandle can be used to retrieve the SFSB.
SLSBs have no state, so there is no benefit to marking an SLSB with no remote interface as clustered.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994339#3994339
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994339
19 years, 4 months
[JBoss Seam] - Re: Basic Seam questions
by ccanning
@Destroy - Designates a destroy method that is called when a context ends and the component is being disposed. (Seam annotation)
@Remove - Applied to a business method of a stateful session bean class. Indicates that the stateful session bean is to be removed by the container after completion of the method. (EJB annotation)
If your SFSB lives beyond the seam context and you require cleanup, then this may be different from the EJB remove method which after a successful call indicates to the container that the bean can effectively be removed from the system. It is also recommended that resource cleanup, be done in the @PreDestroy method which is called before the @Remove method is called.
Hope this provides a little more clarity.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994332#3994332
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994332
19 years, 4 months
[JBoss Messaging] - sp2 upgrade failure
by nbreau
We just upgraded our jboss server to 1.0.1sp2 and are getting the following error when our application is trying to connect to jboss:
If anyone could let me know what jar i need to add to my application that would be great. We're already including jboss-messaging-client.jar but the class still isnt found.
ERROR [main] - Failed to config client side AOP
org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for locator - InvokerLocator [socket://192.168.2.181:4457/?clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.server.remoting.JMSWireFormat&serializationtype=jboss&socket.check_connection=false&unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat]
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:323)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:125)
at org.jboss.remoting.Client.invoke(Client.java:589)
at org.jboss.remoting.Client.invoke(Client.java:581)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.invoke(ClientConnectionFactoryDelegate.java:199)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$getClientAOPConfig_8697532701842707646.invokeNext(ClientConnectionFactoryDelegate$getClientAOPConfig_8697532701842707646.java)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.getClientAOPConfig(ClientConnectionFactoryDelegate.java)
at org.jboss.jms.client.JBossConnectionFactory.ensureAOPConfigLoaded(JBossConnectionFactory.java:233)
at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:196)
at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
at com.company.xyz.exploration.services.mq.AsyncLinkDiscoveryMQConsumer.connect(AsyncLinkDiscoveryMQConsumer.java:89)
at com.company.xyz.exploration.services.mq.AsyncLinkDiscoveryMQConsumer.start(AsyncLinkDiscoveryMQConsumer.java:62)
at com.company.xyz.exploration.Explore.main(Explore.java:21)
Caused by: java.lang.ClassNotFoundException: org.jboss.jms.client.remoting.ClientSocketWrapper
at org.jboss.remoting.loading.ClassByteClassLoader.findClass(ClassByteClassLoader.java:372)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.remoting.transport.socket.SocketClientInvoker.createClientSocket(SocketClientInvoker.java:145)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:699)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:319)
... 13 more
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994331#3994331
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994331
19 years, 4 months