[JBoss Seam] - Two EAR files in one JVM
by wiberto
I have two seam applications that are deployed in the same JBoss server. Those two EAR files share a common EJB module. One app is an end user app while the other is an admin style app. I'm having issues running both EAR files at the same time.
This used to worked fine as I have tested both apps at the same time before. I don't remember the combination of server/seam/etc. when this work, so I'm trying to go back and see if I have a version of the code when it worked. It looks to be a problem with the classloader because the error I get is a class cast exception casting the object to itself.
One thing that makes me think that is that the app that always work is the one that has been either loaded last (when you start the server) or hot deployed last after the server has been started. So it looks like it's grabbing the lastest class and trying to cast it to the one in the other module.
Has anyone seen this before? I updated to CR1 just to make sure, but the same thing.
The only strange thing that I notice in the logs besides the ClassCastException is this:
| 22:59:50,488 WARN [Ejb3Configuration] Persistence provider caller does not implements the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.
|
I don't know where it comes from, but I'll try to find out.
Any help is appreciated.
Thanks,
Jose
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085832#4085832
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085832
18 years, 10 months
[JBoss Messaging] - Re: I need help about Messaging!
by catania
Hi !
I edited my MDB, and it's Ok. My jbossmq-myqueues-service.xml is look like:
<mbean code="org.jboss.mq.server.jmx.Queue"
| name="jboss.mq.destination:service=Queue,name=myQueue">
| <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
| </mbean>
And I put it inside /deploy --> all things are Ok. but when I write a client that send some TextMessage :
InitialContext jndiContext = getInitialContext( );
| try {
| ConnectionFactory factory = (ConnectionFactory)jndiContext.lookup("ConnectionFactory");
| Queue queueTmp= (Queue)jndiContext.lookup("queue/producerQueue");
| Connection connect = factory.createConnection( );
| Session session = connect.createSession(false,Session.AUTO_ACKNOWLEDGE);
| MessageProducer sender = session.createProducer(queueTmp);
| for(int i=0; i<10; i++){
| TextMessage t = session.createTextMessage();
| t.setText(new Timestamp(System.currentTimeMillis())+" JmsClientProducer Message "+i);
| sender.send(t);
| Thread.sleep(1000);
| }
| connect.close();
| } catch (NamingException e) {
| ......
| }
And my jndi.properties is look like:
anonymous wrote : java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
| java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
| java.naming.provider.url=localhost:1099
When I run client, I received some errors:
javax.naming.CommunicationException [Root exception is java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
| java.lang.ClassNotFoundException: org.jboss.mq.referenceable.ObjectRefAddr (no security manager: RMI class loader disabled)]
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:722)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
| at javax.naming.InitialContext.lookup(Unknown Source)
| at thai.jms.client.JmsClient.main(JmsClient.java:33)
| Caused by: java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
| java.lang.ClassNotFoundException: org.jboss.mq.referenceable.ObjectRefAddr (no security manager: RMI class loader disabled)
| at sun.rmi.server.UnicastRef.invoke(Unknown Source)
| at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
| ... 3 more ---> and error at line:
ConnectionFactory factory = (ConnectionFactory)jndiContext.lookup("ConnectionFactory");
But inside my MDB, I were declared:
@Resource(mappedName="ConnectionFactory")
| private ConnectionFactory connectionFactory;
I understand your suggestions.And althought, I posted my article not correct but I recognized your helps and can you continue guide some my remain problems ?
Thanks.
Catania.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085827#4085827
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085827
18 years, 10 months
[JBoss jBPM] - Stack overflow on recursive patten.
by jemodurn
I am trying to understand 9.10 section of the user guide.
* Token.signal(Transition)
* --> Node.leave(ExecutionContext,Transition)
* --> Transition.take(ExecutionContext)
* --> Node.enter(ExecutionContext)
* --> Node.execute(ExecutionContext)
If my process contains a loop like this:
<process-definition name="emailLoop" >
| <start-state name="start">
| <transition to="CheckEmail" />
| </start-state>
|
| <node name="CheckEmail">
| <action class="CheckEmailAction" />
| <transition to="SendEmail" />
| </node>
|
| <node name="SendEmail">
| <action class="SendEmailAction" />
| <transition to="CheckEmail" />
| <transition to="finish" />
| </node>
|
| <end-state name="finish"/>
| </process-definition>
By the time I loop a gazillion times, will the repeated call to ExecutionContext.leaveNode() cause stack overflow?? I can see a deep recursive execution tree.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085820#4085820
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085820
18 years, 10 months
[Remoting] - Remoting release 2.2.2.SP1
by ron.sigal＠jboss.com
We have recently released version 2.2.2.SP1 of Remoting. It is largely characterized by bug fixes to 2.2.0.GA, with some minor feature additions. It should be possible to replace jboss-remoting.jar from any of the 2.2.x versions with jboss-remoting.jar from 2.2.2.SP1.
It is available in the jboss repository in two places:
http://repository.jboss.com/jboss/remoting/2.2.2.SP1-brew/
contains a copy of jboss-remoting.jar built with jdk 1.5, and
http://repository.jboss.com/jboss/remoting/2.2.2.SP1/
contains a copy of jboss-remoting.jar built with jdk 1.4.
Here are the release notes for the releases that followed 2.2.0.GA:
==========================================================================================================
Release Notes - JBoss Remoting - Version 2.2.2.SP1
** Bug
* [JBREM-653] - allow user to set content-type for http responses
* [JBREM-750] - Logger in HTTPClientInvoker should be static.
** Release
* [JBREM-803] - Release 2.2.2.SP1
** Task
* [JBREM-805] - Verify Remoting 2.2.2.SP1 is compatible with earlier versions
==========================================================================================================
Release Notes - JBoss Remoting - Version 2.2.2.GA
** Bug
* [JBREM-731] - Address of secondary server socket should be acquired each time a control connection is created.
* [JBREM-743] - For polling callback handler, org.jboss.remoting.Client.addListener() should create only one CallbackPoller per InvokerCallbackHandler
* [JBREM-747] - org.jboss.remoting.transport.Connector should unregister server invoker from MBeanServer
* [JBREM-754] - Reset timeout on each use of HttpURLConnection
* [JBREM-761] - NPE in BisocketServerInvoker$ControlConnectionThread
* [JBREM-766] - Guard against "spurious wakeup" from Thread.sleep()
* [JBREM-771] - MicroSocketClientInvoker can experience socket leaks
* [JBREM-774] - BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should close control socket
* [JBREM-775] - MicroSocketClientInvoker.initPool() should omit pool from log message
* [JBREM-778] - BisocketServerInvoker.start() creates a new static Timer each time
* [JBREM-779] - BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
* [JBREM-784] - Use separate maps for control sockets and ordinary sockets in BisocketClientInvoker
* [JBREM-785] - BisocketClientInvoker.transport() inadvertently uses listenerId member variable
* [JBREM-787] - Move network i/o in BisocketClientInvoker constructor to handleConnect()
* [JBREM-788] - Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()
* [JBREM-790] - NPE in BisocketClientInvoker$PingTimerTask
* [JBREM-793] - Lease should synchronize access to client map
* [JBREM-794] - LeasePinger.addClient() should not create a new LeaseTimerTask if none currently exists
* The following is the public version of support patch JBREM-791, under which the fix was applied. -RS
* [JBREM-806] - In HTTPClientInvoker remove newlines and carriage returns from Base64 encoded user names and passwords
** Feature Request
* [JBREM-749] - BisocketServerInvoker: Make configurable the address and port of secondary server socket
* [JBREM-755] - Make ConnectorValidator parameters configurable
* [JBREM-756] - CallbackPoller should shut down if too many errors occur.
* [JBREM-757] - Implement quick Client.removeListener() for polled callbacks.
* [JBREM-765] - Add a separate timeout parameter for callback clients
** Patch
* [JBREM-781] - Socket transport needs to provide to the client local address of a TCP/IP connection, as seen from the server
** Release
* [JBREM-789] - Release 2.2.2.GA
** Task
* [JBREM-641] - re-implement the callback polling for http transport to reduce latency
* [JBREM-767] - Avoid deadlock in callback BisocketClientInvoker when timeout == 0
* [JBREM-782] - Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()
* [JBREM-783] - Remove network i/o from synch blocks that establish and terminate LeasePingers
* [JBREM-796] - Verify Remoting 2.2.2 is compatible with earlier versions
==========================================================================================================
Release Notes - JBoss Remoting - Version 2.2.1.GA
** Bug
* [JBREM-751] - Eliminate unnecessary "Unable to process control connection:" message from BisocketServerInvoker
** Release
* [JBREM-763] - Release 2.2.1.GA
==========================================================================================================
Release Notes - JBoss Remoting - Version 2.2.0.SP4
** Bug
* [JBREM-748] - BisocketClientInvoker should guard agains scheduling on an expired Timer
** Release
* [JBREM-744] - Release 2.2.0.SP4
** Task
* [JBREM-714] - Make sure 2.2.0 and 2.0.0 are compatible binary releases
* [JBREM-734] - BisocketClientInvoker constructor should get parameters from InvokerLocator as well as configuration map.
==========================================================================================================
Release Notes - JBoss Remoting - Version 2.2.0.SP3
** Task
* [JBREM-741] - Eliminate unnecessary log.warn() in BisocketServerInvoker
Release Notes - JBoss Remoting - Version 2.2.0.SP2
** Bug
* [JBREM-739] - Fix java serialization leak. [Note. This issue has been moved to 2.4.0.Beta1
pending the addition of unit tests, but the bug has been fixed.]
Release Notes - JBoss Remoting - Version 2.2.0.SP1
** Bug
* [JBREM-732] - When server terminates and has clients, when the server comes back up clients that survived, can't connect. Connection refused when trying to connect the control socket.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085818#4085818
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085818
18 years, 10 months