[JBoss JIRA] Created: (JBPM-958) Can't display the non-ISO8859-1 characters!
by David Chan (JIRA)
Can't display the non-ISO8859-1 characters!
-------------------------------------------
Key: JBPM-958
URL: http://jira.jboss.com/jira/browse/JBPM-958
Project: JBoss jBPM
Issue Type: Bug
Components: Web Interface
Affects Versions: jBPM jPDL 3.2
Environment: Windows XP Professional English
JDK 1.5
Eclipse 3.2.2
JPDL Suite 3.2 GA
Reporter: David Chan
Assigned To: Tom Baeyens
When I run the console application, log in as the user bert, then start the sample process websale, it display a form.
So I input some Chinese characters as task variable, see the attachment(JPG). After click the save button, what the input has been saved into database and page was rendered again, but the character displayed is not same as I just inputed.
Please see the second attachment(JPG), I really don't know how the strange character came out.
I also checked the page encoding, which is all UTF-8.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBAS-3468) JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
by Francis Labaere (JIRA)
JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
-----------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-3468
URL: http://jira.jboss.com/jira/browse/JBAS-3468
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMS service
Affects Versions: JBossAS-4.0.2 Final
Environment: Windows XP
Reporter: Francis Labaere
Assigned To: Adrian Brock
Priority: Minor
Fix For: JBossAS-4.0.5.GA
When creating a JMS connection using HTTPConnectionFactory for a user without preconfigured ClientID, mq.Connection starts the ping thread before the ClientID of the Connection is set (explicitely using setClientID or implicitely). The ping thread starts pinging the server with ConnectionToken/@ClientID equal to null.
The ClientMonitorInterceptor adds this ConnectionToken to its clients HashMap. When the ClientID of the Connection is set (e.g. to XXX) later, the next call to the server will add the updated ConnectionToken to the ClientMonitorInterceptor's clients HashMap with the same SessionID as the previous one. When the ClientMonitorInterceptor checks timedout clients, it will close the session for the first ConnectionToken. Subsequent calls to the server will generate exceptions: User session is not valid.
On the JBoss server, the ClientMonitorInterceptor closes the client with ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Checking for timedout clients.
2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Disconnecting client due to inactivity timeout: ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientIL] close()
2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] getInstance()
2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] put(HTTPILRequest asynchClose(), String 105)
2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.il.http.HTTPClientILStorageQueue] ClientIL #105 has existing storage queue, adding request to it.
Later (e.g. after sending a JMS message) the SecurityInterceptor checks the connection with the same sessionID ,but different ClientID: ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
2006-08-04 13:17:57,294 TRACE [org.jboss.mq.security.ServerSecurityInterceptor] Checking receive authorize on ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] EXCEPTION : receive:
javax.jms.JMSSecurityException: User session is not valid
at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] RETURN : receive
2006-08-04 13:17:57,294 DEBUG [org.jboss.mq.il.http.servlet.HTTPServerILServlet] Threw an exception of type 'javax.jms.JMSSecurityException' with a message of 'User session is not valid.' This exception is being propogated to the client as a HTTPILResponse.
2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] doPost() defers to processRequest, see the parameters in its trace.
2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] processRequest(HttpServletRequest org.apache.catalina.connector.RequestFacade@2bac2b, HttpServletResponse org.apache.catalina.connector.ResponseFacade@1343c2a)
On the Client side: following stacktrace is visible
13:17:57 [MessageListenerThread - MyTopic] WARN org.jboss.mq.SpyMessageConsumer - Message consumer closing due to error in listening thread.
javax.jms.JMSSecurityException: User session is not valid
at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
mq.Connection should start the ping thread after the ClientID is known.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBMICROCONT-155) java.io.IOException: No context factory for vfsfile
by Scott M Stark (JIRA)
java.io.IOException: No context factory for vfsfile
---------------------------------------------------
Key: JBMICROCONT-155
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-155
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Affects Versions: JBossMC_2_0_0 Beta3
Reporter: Scott M Stark
Assigned To: Scott M Stark
Fix For: JBossMC_2_0_0_CR1
The following org.jboss.test.virtual.test.FileVFSUnitTestCase:
/**
* Test that one can go from a file uri to VirtualFile and obtain the
* same VirtualFile using VirtualFile vfsfile uri
* @throws Exception
*/
public void testVFSFileURIFactory()
throws Exception
{
URL rootURL = getClass().getProtectionDomain().getCodeSource().getLocation();
VFS rootVFS0 = VFS.getVFS(rootURL.toURI());
VirtualFile root0 = rootVFS0.getRoot();
VFS rootVFS1 = VFS.getVFS(root0.toURI());
VirtualFile root1 = rootVFS1.getRoot();
assertEquals(root0, root1);
}
fails with:
java.io.IOException: No context factory for vfsfile:/home/svn/JBossMC/vfs/target/test-classes/
at org.jboss.virtual.VFS.getVFS(VFS.java:83)
at org.jboss.test.virtual.test.FileVFSUnitTestCase.testVFSFileURIFactory(FileVFSUnitTestCase.java:104)
The VFSContextFactory uri mappings need to be updated to include the vfs* forms of the known handlers.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBREM-675) Problems with Servlet invoker
by Tom Elrod (JIRA)
Problems with Servlet invoker
-----------------------------
Key: JBREM-675
URL: http://jira.jboss.com/jira/browse/JBREM-675
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 1.4.6.GA, 2.0.0.GA (Boon)
Reporter: Tom Elrod
Assigned To: Tom Elrod
Fix For: 2.2.0.Beta1 (Bluto)
Attachments: ServletServerInvoker.java
Several problems with servlet invoker:
1) There can't be two servlet invokers (it's necessary, for example, if you want to use them for JBoss Messagning and for EJBs - they require separate connectors) because ObjectName is hard-coded in ServletServerInvoker.java
2) Null returns from invokers are sent to client as empty 204 responses and custom marshallers have no change to process return value. This breaks JBoss Messaging which expects that EVERY message contains at least two bytes (version tag and format tag).
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBMESSAGING-835) Simple test suite configuration
by Tim Fox (JIRA)
Simple test suite configuration
-------------------------------
Key: JBMESSAGING-835
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-835
Project: JBoss Messaging
Issue Type: Task
Affects Versions: 1.2.0.Beta2
Reporter: Tim Fox
Assigned To: Ovidiu Feodorov
Fix For: 1.2.0.GA
The test suite configuration needs to be simplified.
Currently, the same settings can be specified in enrvironment variables, properties file, build.xml, system properties, and in container.xml, with a complex precedence hierarchy determining which setting overrides another setting.
Also some settings are specified redundantly - e.g. test database is inferred from the jdbc connection url but is already specified in the container.xml.
We should have one place and one place only where configuration settings are specified.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JGRP-465) Deadlock in FC if RPC response blocks
by Brian Stansberry (JIRA)
Deadlock in FC if RPC response blocks
-------------------------------------
Key: JGRP-465
URL: http://jira.jboss.com/jira/browse/JGRP-465
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1 SP1
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.4.1 SP2
In 2.4.1.SP1 (and probably earlier) FC can deadlock if all up/down threads are set to false at and above FC and an incoming RPC loops back down the channel with its response.
Following stack trace shows a deadlock situation (note the line numbers in FC are off from the cvs code; this occured with a patched FC version, but the patch is not relevant to this error):
"IncomingPacketHandler (channel=Tomcat-Cluster)" daemon prio=1 tid=0xc8a68b60 nid=0x1ece in Object.wait() [0xc94d1000..0xc94d1f30]
at java.lang.Object.wait(Native Method)
at EDU.oswego.cs.dl.util.concurrent.CondVar.timedwait(CondVar.java:222)
- locked <0xd187e398> (a EDU.oswego.cs.dl.util.concurrent.CondVar)
at org.jgroups.protocols.FC.handleDownMessage(FC.java:394)
at org.jgroups.protocols.FC.down(FC.java:336)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
at org.jgroups.protocols.FC.receiveDownEvent(FC.java:330)
at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
at org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:294)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
at org.jgroups.JChannel.down(JChannel.java:1231)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:790)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:767)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:693)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:377)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:393)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:197)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FC.up(FC.java:377)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:768)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:788)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:260)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:476)
- locked <0xd1eec6d8> (a org.jgroups.protocols.UNICAST$Entry)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:206)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:569)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:170)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FD.up(FD.java:300)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:162)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.Discovery.up(Discovery.java:225)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:908)
at org.jgroups.protocols.TP.handleIncomingPacket(TP.java:850)
at org.jgroups.protocols.TP.access$400(TP.java:45)
at org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1296)
at java.lang.Thread.run(Thread.java:595)
The thread carried an RPC up to RpcDispatcher and is waiting in FC.handleDownMessage() for credits to become available to send the RPC response. Those credits will never arrive, as the thread that is blocking is the one that would need to deliver the credits.
This is less of an issue in 2.5. This is because 2.5. uses the concurrent stack and credit replenishments are sent as OOB messages on a separate thread. (Would still be an issue in 2.5 if the concurrent stack were disabled via configuration.)
Hacky solution is to somehow flag the up thread and in handleDownMessage() check for the flag before blocking the thread. If the flag is set, don't block the thread -- just let it through, i.e. let it exceed max_credits.
In cases like recent JBC releases where the vast majority of RPC responses are lightweight "null" responses, this is pretty safe. Need to add a config flag to disable the workaround though for use in applications where RPC responses frequently return large amounts of data.
--
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
18 years, 9 months