[JBoss JIRA] Created: (JBAS-4117) CTS Challenge for getCookies tests
by Stan Silvert (JIRA)
CTS Challenge for getCookies tests
----------------------------------
Key: JBAS-4117
URL: http://jira.jboss.com/jira/browse/JBAS-4117
Project: JBoss Application Server
Issue Type: CTS Challenge
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-4.2.0.CR1
Reporter: Stan Silvert
Assigned To: Shelly McGowan
Priority: Critical
In the J2EE 1.4 TCK running against JBoss AS 4.2, we have two "getCookie" tests failing:
com/sun/ts/tests/servlet/api/javax_servlet_http/httpservletrequest/URLClient.java#getCookiesTest
com/sun/ts/tests/servlet/api/javax_servlet_http/httpservletrequestwrapper/URLClient.java#getCookiesTest
They are both failing because the TCK client is sending two copies of the same cookie on each request. The spec says that the cookies returned by the servlet container should reflect what was sent by the client. However, the TCK test servlet reports the duplicate cookie as an error.
I confirmed that this is an error in the TCK two different ways. First, I enabled the RequestDumperValve. You do this by adding this to server.xml:
<Valve className="org.apache.catalina.valves.RequestDumperValve" />
The RequestDumperValve dumps the raw data for each HttpRequest sent to Tomcat. When you do this for the getCookiesTest you get:
15:36:16,125 INFO [[localhost]] REQUEST URI =/servlet_jsh_HSReqWrapper_web/TestServlet
15:36:16,125 INFO [[localhost]] authType=null
15:36:16,125 INFO [[localhost]] characterEncoding=null
15:36:16,125 INFO [[localhost]] contentLength=-1
15:36:16,125 INFO [[localhost]] contentType=null
15:36:16,125 INFO [[localhost]] contextPath=/servlet_jsh_HSReqWrapper_web
15:36:16,125 INFO [[localhost]] cookie=cookie=value
15:36:16,125 INFO [[localhost]] cookie=cookie=value
15:36:16,125 INFO [[localhost]] header=cookie=cookie=value
15:36:16,125 INFO [[localhost]] header=cookie=cookie=value
15:36:16,125 INFO [[localhost]] header=user-agent=Jakarta Commons-HttpClient/3.0
15:36:16,125 INFO [[localhost]] header=host=localhost:8080
15:36:16,135 INFO [[localhost]] locale=en_US
15:36:16,145 INFO [[localhost]] method=GET
15:36:16,145 INFO [[localhost]] parameter=testname=getCookiesTest
15:36:16,145 INFO [[localhost]] pathInfo=null
15:36:16,145 INFO [[localhost]] protocol=HTTP/1.1
15:36:16,145 INFO [[localhost]] queryString=testname=getCookiesTest
15:36:16,145 INFO [[localhost]] remoteAddr=127.0.0.1
15:36:16,145 INFO [[localhost]] remoteHost=127.0.0.1
15:36:16,145 INFO [[localhost]] remoteUser=null
15:36:16,145 INFO [[localhost]] requestedSessionId=null
15:36:16,145 INFO [[localhost]] scheme=http
15:36:16,145 INFO [[localhost]] serverName=localhost
15:36:16,145 INFO [[localhost]] serverPort=8080
15:36:16,145 INFO [[localhost]] servletPath=/TestServlet
15:36:16,145 INFO [[localhost]] isSecure=false
As you can clearly see, the cookie was sent twice.
The second way I verified this was to manually deploy the test EAR and hit it with a manual request containing only one copy of the cookie. I'll attach the test ear in case anyone else wants to try this. To manually run the test, I use the Firefox plugin "Live HTTP Headers" to set a single cookie "cookie=value". Then, I submit this URL:
http://localhost:8080//servlet_jsh_httpservletrequest_web/TestServlet?tes...
The result I get in the browser is "Test PASSED".
--
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, 2 months
[JBoss JIRA] Created: (JBCACHE-858) Investigate POJOCACHE failures
by Manik Surtani (JIRA)
Investigate POJOCACHE failures
------------------------------
Key: JBCACHE-858
URL: http://jira.jboss.com/jira/browse/JBCACHE-858
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PojoCache
Affects Versions: 2.0.0.ALPHA1
Reporter: Manik Surtani
Assigned To: Ben Wang
Fix For: 2.0.0.ALPHA2
Ben,
This pertains to the following tests:
org.jboss.cache.pojo.collection.ReplicatedSyncMapTest
org.jboss.cache.pojo.collection.ReplicatedSyncSetTest
org.jboss.cache.pojo.region.LocalConcurrentTest
These have been marked as "known issues" as of 2.0.0.Alpha1 so you won't see them in CC builds until you un-mark them as "known issues" in build.xml.
--
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, 2 months
[JBoss JIRA] Created: (JBCACHE-981) PojoCache to add additional internal mapping to promote concurrent access
by Ben Wang (JIRA)
PojoCache to add additional internal mapping to promote concurrent access
-------------------------------------------------------------------------
Key: JBCACHE-981
URL: http://jira.jboss.com/jira/browse/JBCACHE-981
Project: JBoss Cache
Issue Type: Task
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: 2.0.0.BETA2
Currently we use flat mapping for the internal fqn. But this creates problem for concurrent access as every pojo will contend for the root access, e.g., "__JBossInternal__/xxx". End result is there will be lock upgrade exception and needs to be re-tried. The proposed solution is to use additional layer of mapping, e.g.,
Internal fqn is now structured as:
* a) If no region -- /__JBossInternal__/realId/__ID__/xxxx
* b) If there is region -- /region/__JBossInternal__/xxx
--
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, 2 months
[JBoss JIRA] Commented: (JBPM-653) make the process parent classloader configurable
by Matej Knopp (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-653?page=comments#action_12353613 ]
Matej Knopp commented on JBPM-653:
----------------------------------
I'm building a custom workflow solution with jBPM. The solution consists of a custom web client built with Wicket web framework and a possibility to deploy wicket components alongside the workflow. The components are then part of user tasklist.
I had to modify the ProcessClassLoader and ClassLoaderUtil, because by default jbpm creates new instance of class loader for every delegate object requested. So I cache the classloaders for specific process defition + version. I also modified the classloader. I understand this is not how jbpm classloading is supposed to work, however, it would be great if in future it would be possible to achieve such effect without having to modify jbpm code.
So i'd really appreciate if it was possible to set custom classloader. But that would also need means to affect how ClassLoaderUtil works, so that it is possible to cache class loaders and not to create one every time a delegate class is requested.
> make the process parent classloader configurable
> ------------------------------------------------
>
> Key: JBPM-653
> URL: http://jira.jboss.com/jira/browse/JBPM-653
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Core Engine
> Reporter: Tom Baeyens
> Assigned To: Tom Baeyens
> Fix For: jBPM jPDL 3.2
>
>
> now, always the jBPM classloader is taken as a parent for the process classloaders. this should be made configurable. at least one other possibility should be to configure the context classloader.
--
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, 2 months