February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3998) failing org.jboss.test.classloader.test.ScopingUnitTestCase

by Dimitris Andreadis (JIRA)

failing org.jboss.test.classloader.test.ScopingUnitTestCase ----------------------------------------------------------- Key: JBAS-3998 URL: http://jira.jboss.com/jira/browse/JBAS-3998 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ClassLoading, Test Suite Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-4.2.0.CR1 Test fails due to the commons-loggings upgrade. We need a patched commons-logging to solve this (see JBAS-3128). -- 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
4
0 / 0

[JBoss JIRA] Commented: (JBPM-569) improve EL expression examples in the user guide

by Arjan van Bentem (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-569?page=comments#action_12353713 ] Arjan van Bentem commented on JBPM-569: --------------------------------------- In my previous comment, "2.3.Beta2" should read "3.2.Beta2". > improve EL expression examples in the user guide > ------------------------------------------------ > > Key: JBPM-569 > URL: http://jira.jboss.com/jira/browse/JBPM-569 > Project: JBoss jBPM > Issue Type: Task > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Fix For: jBPM jPDL 3.2 > > -- 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] Commented: (JBPM-569) improve EL expression examples in the user guide

by Arjan van Bentem (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-569?page=comments#action_12353712 ] Arjan van Bentem commented on JBPM-569: --------------------------------------- This might include changing 'deprecated' into 'no longer supported' in lines 1690 and 1691 of jpdl.xml: http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl/userguide/en/modules/jpd... 1690 <entry>{content} For backwards compatibility, the condition can also be entered with the 'expression' 1691 attribute, but that attribute is deprecated since 3.2</entry> [ In 2.3.Beta2 'deprecated' seems to imply it is ignored without any warning. When using "Deploy Process Archive" in the Eclipse GPD 3.0.13.1 (as included in the 2.3.Beta2 Suite) then the condition is simply not persisted in JBPM_TRANSITION. This could be a problem of the GPD, but as I assume the GPD simply deploys processdefinition.xml without interpreting it, the attribute is probably ignored somewhere in the jPDL sources. ] It might also include noting that context variables may be accessed using either, for example, #{ quantity > 2 } or #{ contextInstance.variables['quantity'] > 2 } or #{ contextInstance.variables.quantity > 2 } That is: if I understand correctly...! Arjan. > improve EL expression examples in the user guide > ------------------------------------------------ > > Key: JBPM-569 > URL: http://jira.jboss.com/jira/browse/JBPM-569 > Project: JBoss jBPM > Issue Type: Task > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Fix For: jBPM jPDL 3.2 > > -- 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: (JBMESSAGING-862) org.jboss.test.messaging.jms.clustering.FailoverTest.testFailureRightBeforeACK() fails

by Ovidiu Feodorov (JIRA)

org.jboss.test.messaging.jms.clustering.FailoverTest.testFailureRightBeforeACK() fails -------------------------------------------------------------------------------------- Key: JBMESSAGING-862 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-862 Project: JBoss Messaging Issue Type: Bug Reporter: Ovidiu Feodorov Assigned To: Clebert Suconic Priority: Blocker Fix For: 1.2.0.CR1 testFailureRightBeforeACK Failure N/A junit.framework.AssertionFailedError at org.jboss.test.messaging.jms.clustering.FailoverTest.failureOnInvocation(FailoverTest.java:1907) at org.jboss.test.messaging.jms.clustering.FailoverTest.testFailureRightBeforeACK(FailoverTest.java:1674) -- 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
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-852) Unacked message state is not cleaned up after failure in ack

by Tim Fox (JIRA)

Unacked message state is not cleaned up after failure in ack ------------------------------------------------------------ Key: JBMESSAGING-852 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-852 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.CR1, 1.0.1.SP5 If an exception is thrown from a call to acknowledge, then the unacked message data is not cleared out, this cause the next call to postDeliver to give the exception: -- 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
4
0 / 0

[JBoss JIRA] Commented: (JBAS-1824) JACC: <role-name>*</role-name> in web.xml should allow configurable authorization bypass

by Anil Saldhana (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1824?page=comments#action_12353708 ] Anil Saldhana commented on JBAS-1824: ------------------------------------- This is ready for 4.2.0.CR1. I have to get the test case working. > JACC: <role-name>*</role-name> in web.xml should allow configurable authorization bypass > ---------------------------------------------------------------------------------------- > > Key: JBAS-1824 > URL: http://jira.jboss.com/jira/browse/JBAS-1824 > Project: JBoss Application Server > Issue Type: Feature Request > Components: Security > Affects Versions: JBossAS-4.0.2 Final > Environment: - > Reporter: Roland R?z > Assigned To: Anil Saldhana > Fix For: JBossAS-4.2.1.CR1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > In some cases I wish to do authentication without authorisation. For example everybody has access to my web-resource, but I want to know who she/he is. > Therefore the accessing user must login. > So my web.xml contains the following snippet: > ... > <security-constraint> > <web-resource-collection> > <web-resource-name>Protected Helloworld example</web-resource-name> > <description/> > <url-pattern>/servlet/HelloWorldExample</url-pattern> > <http-method>POST</http-method> > <http-method>GET</http-method> > </web-resource-collection> > <auth-constraint> > <role-name>*</role-name> > </auth-constraint> > </security-constraint> > <login-config> > <auth-method>BASIC</auth-method> > <realm-name>public</realm-name> > </login-config> > ... > The web app runs with this configuration in Tomcat 5.5.8 standalone but not in Jboss. > To run it in Jboss I have to add the following element: > <security-role> > <role-name>aRole</role-name> > </security-role> > The JACC spec (section 3.1.3.1, paragraph 3)states : > " ?. When an auth-constraint names the reserved role-name, "*", all of the patterns in the containing security-constraint must be combined with all of the roles defined in the web application." > JBoss implemented this by combining all of the patterns with all roles defined in the web.xml and assumes that each role has to be defined in the web.xml. > But the web applications roles are probably defined in other files than the web.xml. In our case we use JACC with an external authentication provider. And each time, the roles changes, I also would have to modify the web.xml. > It is desirable if the auth-contraint with the role-name "*" acceppts "all" roles and not only those that are defined in the web.xml. > Or is this a JACC spec issue? > Regards, > Andrea -- 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-139) StackOverflowError when traversing certain directories

by Scott M Stark (JIRA)

StackOverflowError when traversing certain directories ------------------------------------------------------ Key: JBMICROCONT-139 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-139 Project: JBoss MicroContainer Issue Type: Bug Components: VFS Reporter: Scott M Stark Fix For: JBossMC_2_0_0_CR1 The current 2.0.0.snapshot version of the vfs fails under win32 for jrockit 1.5.0_06 with a StackOverflowError when the quartz-ra.rar is deployed: 16:05:27,344 ERROR [AbstractKernelController] Error installing to Start: name=jb oss.jca:name='quartz-ra.rar',service=RARDeployment state=Create mode=Manual requ iredState=Installed java.lang.StackOverflowError at java.lang.String.substring(II)Ljava.lang.String;(Unknown Source) at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:220) at org.jboss.net.protocol.file.Handler.parseURL(Handler.java:47) at java.net.URL.<init>(URL.java:596) at java.net.URL.<init>(URL.java:465) at java.net.URL.<init>(URL.java:413) at sun.net.www.protocol.jar.Handler.parseAbsoluteSpec(Handler.java:89) at sun.net.www.protocol.jar.Handler.parseURL(Handler.java:64) at java.net.URL.<init>(URL.java:596) at java.net.URL.<init>(URL.java:465) at java.net.URL.<init>(URL.java:413) at org.jboss.virtual.plugins.context.jar.AbstractJarHandler.getURL(Abstr actJarHandler.java:308) at org.jboss.virtual.plugins.context.jar.AbstractJarHandler.createVirtua lFileHandler(AbstractJarHandler.java:370) at org.jboss.virtual.plugins.context.jar.AbstractJarHandler.initJarFile( AbstractJarHandler.java:186) at org.jboss.virtual.plugins.context.jar.JarHandler.<init>(JarHandler.ja va:81) at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua lFileHandler(FileSystemContext.java:179) at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa ndler.java:171) at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua lFileHandler(FileSystemContext.java:239) at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua lFileHandler(FileSystemContext.java:186) at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa ndler.java:171) at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua lFileHandler(FileSystemContext.java:239) at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua lFileHandler(FileSystemContext.java:186) at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa ndler.java:171) at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua lFileHandler(FileSystemContext.java:239) at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua lFileHandler(FileSystemContext.java:186) at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa ndler.java:171) at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua lFileHandler(FileSystemContext.java:239) at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua lFileHandler(FileSystemContext.java:186) at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa ndler.java:171) at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua lFileHandler(FileSystemContext.java:239) at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtua lFileHandler(FileSystemContext.java:186) at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHa ndler.java:171) 16:05:27,344 INFO [RARDeployment] Required license terms exist, view vfsfile:/C :/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta2/server/default/deploy/ quartz-ra.rar/META-INF/ra.xml 16:05:31,719 ERROR [AbstractKernelController] Error installing to Start: name=jb oss.jca:name='quartz-ra.rar#quartz-ra.rar',service=RARDeployment state=Create mo de=Manual requiredState=Installed java.lang.StackOverflowError 16:05:31,734 INFO [TomcatDeployment] deploy, ctxPath=/, warUrl=vfsfile:/C:/svn/ JBossHead/jboss-head/build/output/jboss-5.0.0.Beta2/server/default/deploy/ROOT.w ar/ This is due to the following bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192331 The problem is that a file returned via File.listFiles() is such that the File.exists() check fails, and there is recursion to try to resolve the file as a link against the parent. The link checking could be improved, or the resulting listFiles() validated before used. -- 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
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-716) Add a flag to disable replication event notification

by Ben Wang (JIRA)

Add a flag to disable replication event notification ---------------------------------------------------- Key: EJBTHREE-716 URL: http://jira.jboss.com/jira/browse/EJBTHREE-716 Project: EJB 3.0 Issue Type: Sub-task Components: Clustering Reporter: Ben Wang This came up from an email thread: (1) By default, passivation events get called during replication cycle (2) There is a config setting to disable this (3) We should introduce JBoss-specific replication-only and passivation-only events that actually let you directly write/read the bytestream (4) I will work to get two sets of events into the next EJB spec, ie. introduce @PreReplicate / @PostReplicate or something like that We should now tie the replication to passivation events (there is no concrete spec but everyone else is doing it). But we should also have a flag to disable it if needs to. -- 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
3
0 / 0

[JBoss JIRA] Commented: (EJBTHREE-420) redeploy of TreeCached entities fails

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-420?page=comments#action_12353698 ] Brian Stansberry commented on EJBTHREE-420: ------------------------------------------- I believe the work on EJBTHREE-795 should have fixed this. There's tests that include redeployment. I'll double check and if it looks OK I'll resolve this. Erica -- does the problem go away with EJB3 RC9 Patch 1? That includes the EJBTHREE-795 fixes. > redeploy of TreeCached entities fails > ------------------------------------- > > Key: EJBTHREE-420 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-420 > Project: EJB 3.0 > Issue Type: Bug > Affects Versions: EJB 3.0 RC3 > Reporter: Bill Burke > Assigned To: Brian Stansberry > Fix For: EJB 3.0 RC10 - FD > > > 2006-01-20 15:14:19,843 INFO [STDOUT] org.hibernate.PropertyAccessException: exception getting property value with CGLIB (set hibernate.cglib.use_reflection_optimizer=false for more info) getter of com.airit.fidsdb.entity.ArrPrevPortPK.? > at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:79) > at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:307) > at org.hibernate.type.ComponentType.isEqual(ComponentType.java:111) > at org.hibernate.cache.CacheKey.equals(CacheKey.java:51) > at org.jboss.cache.Fqn.equals(Fqn.java:134) > at java.util.HashMap.eq(HashMap.java:277) > at java.util.HashMap.containsKey(HashMap.java:346) > at org.jboss.cache.eviction.LRUAlgorithm.add(LRUAlgorithm.java:126) > at org.jboss.cache.eviction.LRUAlgorithm.processAddedNodes(LRUAlgorithm.java:99) > at org.jboss.cache.eviction.LRUAlgorithm.processQueues(LRUAlgorithm.java:77) > at org.jboss.cache.eviction.LRUAlgorithm.process(LRUAlgorithm.java:52) > at org.jboss.cache.eviction.EvictionTimerTask.run(EvictionTimerTask.java:37) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > Caused by: java.lang.ClassCastException: com.airit.fidsdb.entity.ArrPrevPortPK > at com.airit.fidsdb.entity.ArrPrevPortPK$$BulkBeanByCGLIB$$8b6b36b9.getPropertyValues(<generated>) > at net.sf.cglib.beans.BulkBean.getPropertyValues(BulkBean.java:48) > at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:76) > ... 13 more -- 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] Assigned: (EJBTHREE-420) redeploy of TreeCached entities fails

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-420?page=all ] Brian Stansberry reassigned EJBTHREE-420: ----------------------------------------- Assignee: Brian Stansberry (was: Bill Burke) > redeploy of TreeCached entities fails > ------------------------------------- > > Key: EJBTHREE-420 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-420 > Project: EJB 3.0 > Issue Type: Bug > Affects Versions: EJB 3.0 RC3 > Reporter: Bill Burke > Assigned To: Brian Stansberry > Fix For: EJB 3.0 RC10 - FD > > > 2006-01-20 15:14:19,843 INFO [STDOUT] org.hibernate.PropertyAccessException: exception getting property value with CGLIB (set hibernate.cglib.use_reflection_optimizer=false for more info) getter of com.airit.fidsdb.entity.ArrPrevPortPK.? > at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:79) > at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:307) > at org.hibernate.type.ComponentType.isEqual(ComponentType.java:111) > at org.hibernate.cache.CacheKey.equals(CacheKey.java:51) > at org.jboss.cache.Fqn.equals(Fqn.java:134) > at java.util.HashMap.eq(HashMap.java:277) > at java.util.HashMap.containsKey(HashMap.java:346) > at org.jboss.cache.eviction.LRUAlgorithm.add(LRUAlgorithm.java:126) > at org.jboss.cache.eviction.LRUAlgorithm.processAddedNodes(LRUAlgorithm.java:99) > at org.jboss.cache.eviction.LRUAlgorithm.processQueues(LRUAlgorithm.java:77) > at org.jboss.cache.eviction.LRUAlgorithm.process(LRUAlgorithm.java:52) > at org.jboss.cache.eviction.EvictionTimerTask.run(EvictionTimerTask.java:37) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > Caused by: java.lang.ClassCastException: com.airit.fidsdb.entity.ArrPrevPortPK > at com.airit.fidsdb.entity.ArrPrevPortPK$$BulkBeanByCGLIB$$8b6b36b9.getPropertyValues(<generated>) > at net.sf.cglib.beans.BulkBean.getPropertyValues(BulkBean.java:48) > at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:76) > ... 13 more -- 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

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