February 2007 - jboss-jira - Jboss List Archives

[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

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-3939) Upgrade jbossxb to v1.0.0.CR7

by Dimitris Andreadis (JIRA)

Upgrade jbossxb to v1.0.0.CR7 ----------------------------- Key: JBAS-3939 URL: http://jira.jboss.com/jira/browse/JBAS-3939 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: XML services Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-4.2.0.CR1 -- 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

3
15
0 / 0

[JBoss JIRA] Created: (JBTM-202) end of suspended resources not called via JCA

by Mark Little (JIRA)

end of suspended resources not called via JCA --------------------------------------------- Key: JBTM-202 URL: http://jira.jboss.com/jira/browse/JBTM-202 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.2 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.2.3 -- 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

1
1
0 / 0

[JBoss JIRA] Commented: (JBPM-621) Decision 'otherwise' choice does not appear to work.

by Arjan van Bentem (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-621?page=comments#action_12353623 ] Arjan van Bentem commented on JBPM-621: --------------------------------------- The 3.2.x documentation has been changed (version 1.2 of http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl/userguide/en/modules/jpd...) So, I guess the new official otherwise flow is now: "The first transition represents the otherwise branch", which would imply this bug is resolved? > Decision 'otherwise' choice does not appear to work. > ---------------------------------------------------- > > Key: JBPM-621 > URL: http://jira.jboss.com/jira/browse/JBPM-621 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.1 > Reporter: youngm > Assigned To: Tom Baeyens > > The following decision appears to always result in the "to_print" transition choosen. The decision node doesn't appear to ever check transisions who don't have conditions. So it assumes there is only one transition so it chooses the 'default' or first transition. > <decision name="data_needed"> > <transition name="to_print" to="print_application"> > <condition expression="#{true == false}"/> > </transition> > <transition name="to_get_approval" to="get_approval"/> > </decision> -- 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

1
0
0 / 0

[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

3
2
0 / 0

[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

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-926) PojoCache local concurrent test produced lock timeout exception

by Ben Wang (JIRA)

PojoCache local concurrent test produced lock timeout exception --------------------------------------------------------------- Key: JBCACHE-926 URL: http://jira.jboss.com/jira/browse/JBCACHE-926 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0.BETA1 This is reproducible in LocalConcurrentTest that has multiple threads doing POJO attach simultaneously. End result is it can produce lock timeout exception during loop. -- 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

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-972) Microcontainer deps introduced too early

by Manik Surtani (JIRA)

Microcontainer deps introduced too early ---------------------------------------- Key: JBCACHE-972 URL: http://jira.jboss.com/jira/browse/JBCACHE-972 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Reporter: Manik Surtani Assigned To: Ben Wang Fix For: 2.0.0.BETA2 Ben, JBoss Serialization attempts to un-serialize some MC classes when running certain pojo cache tests. If these deps are intentional, then please make sure the relevant jars are available. Affects org.jboss.cache.pojo.collection.CachedListImplTest org.jboss.cache.pojo.collection.CachedMapImplTest -- 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

2
1
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-144) JAXPDeployer needs to support a dom attachment to allow management overrides.

by Scott M Stark (JIRA)

JAXPDeployer needs to support a dom attachment to allow management overrides. ----------------------------------------------------------------------------- Key: JBMICROCONT-144 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-144 Project: JBoss MicroContainer Issue Type: Feature Request Components: Deployment Affects Versions: JBossMC_2_0_0 Beta Reporter: Scott M Stark Fix For: JBossMC_2_0_0_CR1 The JAXPDeployer should support a notion of a dom document attachment view that can be overriden to introduce an edited view of the xml document. This allows management tools to update the document without having to overwrite the original xml document. -- 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

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2007