[JBoss JIRA] Created: (JBAS-3442) Use absolute path (or URL) to load keystores
by Khiem Tang (JIRA)
Use absolute path (or URL) to load keystores
--------------------------------------------
Key: JBAS-3442
URL: http://jira.jboss.com/jira/browse/JBAS-3442
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Environment: all platforms
Reporter: Khiem Tang
Keystores and trust stores referenced in jboss-wsse-server.xml are relative to deployment. We need to be able to reference keystores that are not part of the EAR file, e.g. using absolute file paths or URL. The reason is that for security reasons, developers don't have access to production keystores. This means in order for us to run in production, the EAR file will need to be unpacked and re-packed to include a different keystore. It's an error prone process that we want to avoid.
I also created a support ticket for this. It is 10530.
Thanks,
\KT
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months
[JBoss JIRA] Created: (JBMESSAGING-434) Client receive the server side exception
by Tomohisa Igarashi (JIRA)
Client receive the server side exception
----------------------------------------
Key: JBMESSAGING-434
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-434
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Facade
Affects Versions: 1.0.1.CR3
Reporter: Tomohisa Igarashi
Assigned To: Ovidiu Feodorov
Priority: Minor
Sender call MessageProducer.send() and Session.commit() When database is down, sender receive server side exception.
When I used PostgreSQL, sender received PSQLException.
Because of sender doesn't have JDBC Driver, ClassNotFoundException was thrown at client side.
That is not so serious, but not so good, I think.
Server side exception should be processed at server side, and JMSException should be thrown at client side.
stack trace is here:
[ * * * Sender * * * ]
java.lang.ClassNotFoundException: org.postgresql.util.PSQLException
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.serial.io.JBossObjectInputStream.resolveClass(JBossObjectInputStream.java:141)
at org.jboss.serial.io.JBossObjectInputStream$1.resolveClass(JBossObjectInputStream.java:127)
at org.jboss.serial.classmetamodel.ClassMetamodelFactory.resolveClassByName(ClassMetamodelFactory.java:267)
at org.jboss.serial.classmetamodel.ClassMetamodelFactory.getClassMetaData(ClassMetamodelFactory.java:346)
at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:72)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:380)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:634)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:634)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:634)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:634)
at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:333)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
at org.jboss.jms.server.remoting.JMSWireFormat.read(JMSWireFormat.java:458)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:454)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:328)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:116)
at org.jboss.remoting.Client.invoke(Client.java:610)
at org.jboss.remoting.Client.invoke(Client.java:602)
at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeNext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeNext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeNext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeNext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.java)
at org.jboss.jms.tx.ResourceManager.commitLocal(ResourceManager.java:152)
at org.jboss.jms.client.container.TransactionAspect.handleCommit(TransactionAspect.java:97)
at org.jboss.aop.advice.org.jboss.jms.client.container.TransactionAspect7.invoke(TransactionAspect7.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.commit(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossSession.commit(JBossSession.java:165)
at TestSender.perform(TestSender.java:44)
at TestSender.main(TestSender.java:12)
[ * * * JBoss Messaging * * * ]
2006-07-14 22:10:33,382 ERROR [org.jboss.jms.server.endpoint.ServerConnectionEndpoint] Exception occured
java.sql.BatchUpdateException: Batch entry 0 INSERT INTO JMS_MESSAGE_REFERENCE (CHANNELID, MESSAGEID, TRANSACTIONID, STATE, ORD, DELIVERYCOUNT, RELIABLE, LOADED) VALUES (4, 16640, NULL, C, 2, 0, Y, Y) was aborted. Call getNextException to see the cause.
at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2497)
at org.postgresql.core.v3.QueryExecutorImpl$1.handleError(QueryExecutorImpl.java:399)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1298)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:347)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2559)
at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:517)
at org.jboss.messaging.core.plugin.JDBCPersistenceManager.handleBeforeCommit1PC(JDBCPersistenceManager.java:2702)
at org.jboss.messaging.core.plugin.JDBCPersistenceManager$TransactionCallback.beforeCommit(JDBCPersistenceManager.java:4383)
at org.jboss.messaging.core.tx.Transaction.commit(Transaction.java:171)
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:390)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:99)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:842)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:691)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:443)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:530)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:253)
2006-07-14 22:11:12,629 WARN [org.jboss.jms.server.connectionmanager.SimpleConnectionManager] A problem has been detected with the connection to remote client 5c4o2a-eht8at-epmkjvuk-1-epmkjwhd-3 It is possible the client has exited without closing its connection(s) or there is a network problem. All connection resources corresponding to that client process will now be removed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months
[JBoss JIRA] Closed: (EJBTHREE-570) DLQ fails when JMSMessage has properties with null values.
by William DeCoste (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-570?page=all ]
William DeCoste closed EJBTHREE-570.
------------------------------------
Resolution: Done
> DLQ fails when JMSMessage has properties with null values.
> ----------------------------------------------------------
>
> Key: EJBTHREE-570
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-570
> Project: EJB 3.0
> Issue Type: Bug
> Reporter: Jury Sysoyev
> Assigned To: William DeCoste
> Priority: Trivial
> Fix For: EJB 3.0 RC9 - FD
>
>
> If an EJB3 MDB not correctly processed some JMSMessage, jboss server try to put message in DLQ queue. If this message has properties with null values, an error appears and fails in infinite loop.
> It because you use java.util.Hashtable to save jms properties temporary. This class not supports null values. You may use java.util.HashMap to fix this problem. Or you may replace nulls by empty (??) values.
> Server log for jboss4.0.4rc1 (one iteration from infinite loop)
> 2006-05-12 17:46:48,552 WARN [org.jboss.ejb3.mdb.DLQHandler] Message resent too many times; sending it to DLQ; message id=ID:3-11473485279351
> 2006-05-12 17:46:48,552 ERROR [org.jboss.jms.asf.StdServerSession] session failed to run; setting rollback only
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:396)
> at org.jboss.ejb3.mdb.DLQHandler.makeWritable(DLQHandler.java:357)
> at org.jboss.ejb3.mdb.DLQHandler.sendMessage(DLQHandler.java:269)
> at org.jboss.ejb3.mdb.DLQHandler.handleRedeliveredMessage(DLQHandler.java:228)
> at org.jboss.ejb3.mdb.MDB$MessageListenerImpl.onMessage(MDB.java:1171)
> at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:266)
> at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:902)
> at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170)
> at org.jboss.mq.SpySession.run(SpySession.java:323)
> at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:194)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months
[JBoss JIRA] Commented: (EJBTHREE-627) authentication exception for stopping Service beans with SecurotyDomain
by Matt Jennings (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-627?page=comments#action_12340177 ]
Matt Jennings commented on EJBTHREE-627:
----------------------------------------
On redeploy of a @Service mbean, there is an unexpected exception:
javax.ejb.EJBAccessException: Authentication failure
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.handleGeneralSecurityException(Ejb3AuthenticationInterceptor.java:68)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:71)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:199)
at org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:167)
at org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:168)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
at $Proxy0.stop(Unknown Source)
at org.jboss.system.ServiceController.stop(ServiceController.java:508)
at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
...
This exception occurs on every redeployment since I started to use a SecurityDomain on some other EJB3 beans.
I get this error whether or not on the @Service bean I declare @SecurityDomain, @PermitAll on methods, no security annotation at all, etc.
> authentication exception for stopping Service beans with SecurotyDomain
> -----------------------------------------------------------------------
>
> Key: EJBTHREE-627
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-627
> Project: EJB 3.0
> Issue Type: Bug
> Affects Versions: EJB 3.0 RC7 - FD
> Reporter: William DeCoste
> Assigned To: William DeCoste
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months
[JBoss JIRA] Updated: (JBREM-480) Insure reliable tests in socket invoker for unusable socket connections.
by Tom Elrod (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-480?page=all ]
Tom Elrod updated JBREM-480:
-----------------------------
Fix Version/s: 2.2.0.Beta1 (Bluto)
(was: 2.0.0.CR1 (Boon))
> Insure reliable tests in socket invoker for unusable socket connections.
> ------------------------------------------------------------------------
>
> Key: JBREM-480
> URL: http://jira.jboss.com/jira/browse/JBREM-480
> Project: JBoss Remoting
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 2.0.0.CR1 (Boon)
> Reporter: Ron Sigal
> Assigned To: Tom Elrod
> Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The socket invoker needs to test for unusable socket connections, on both the client and server side. There are currently two tests in place, only one of which is correct. On the client side, if the shouldCheckConnection flag is set, then MicroSocketClientInvoker.getPooledConnection() and SocketClientInvoker.getPooledConnection() will call ClientSocketWrapper.checkConnection(), which will call ObjectInputStream.readByte(), which throws an EOFException at end of file, i.e., when the remote endpoint closes. If the shouldCheckConnection flag is not set, then SocketClientInvoker.getPooledConnection() will call Socket.isConnected() on its socket, and MicroSocketClientInvoker.getPooledConnection() makes no test. In any case, Socket.isConnected() does not appear to be useful, since it seems that a Socket, once connected, never returns to a disconnected state (at least in linux and jdk 1.4). On the server side, ServerThread.acknowledge() will call ServerSocketWrapper.checkConnection(), which behaves like ClientSocketWrapper.checkConnection(), if the shouldCheckConnection flag is set.
> The problem on the client side is that if the performVersioning flag is set, a version byte will be read by calling InputStream.read(), which returns -1 at end of file instead of throwing EOFException. If an InputStream at end of file is not tested for end of file, -1 will be read and treated as an incorrect version. resulting in an Exception. There needs to be an explicit test for -1.
> On the server side, a version of -1 is set to 1, and the end of file condition is caught later. It would be simpler to test explicitly for -1.
> In any case, we need to verify that there are reliable tests in place for unusable connections. It is difficult to see how to write a unit test that creates an error condition on a socket, but there should be unit tests for client side and server side end of file conditions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 11 months