December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-1485) JMS ResourceAdapter makes unnecessary temporary delete requests

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1485?page=all ] Dimitris Andreadis updated JBAS-1485: ------------------------------------- Fix Version/s: JBossAS-5.0.1.CR1 (was: JBossAS-4.2.0.CR1) Assignee: Weston Price If Weston wants to look at it. > JMS ResourceAdapter makes unnecessary temporary delete requests > --------------------------------------------------------------- > > Key: JBAS-1485 > URL: http://jira.jboss.com/jira/browse/JBAS-1485 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1 > Reporter: Adrian Brock > Assigned To: Weston Price > Priority: Optional > Fix For: JBossAS-5.0.1.CR1 > > > The JMS ResourceAdaptor keeps track of temporaries created on a connection > (org.jboss.resource.adapter.jms.JMSSessionFactoryImpl) > and deletes them. > This is because we cannot expect the real JMS implementation to do this > because the connection is pooled and not closed. > However, if the user is deleting the temporaries themselves > (good practice in terms of resource usage), > the JMS ResourceAdapter does not know about this > and tries to repeat the delete at connection.close(); > Solution: > Add some wrapping processing for the temporary queues and topics > so we can trap temporary.delete(). That way we will know we don't > need to do it on close() > IMPORTANT: Invocations like send() or JMSMessage.setJMSReplyTo will > also need to trap these destinations to do the necessary wrapping/unwrapping. > It is also possible to retrieve a temporary destination with Session.createQueue/Topic. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2391) Need to review PropertyManager

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2391?page=all ] Dimitris Andreadis updated JBAS-2391: ------------------------------------- Fix Version/s: JBossAS-5.0.1.CR1 (was: JBossAS-4.2.0.CR1) (was: JBossAS-5.0.0.Beta2) reschedule > Need to review PropertyManager > ------------------------------ > > Key: JBAS-2391 > URL: http://jira.jboss.com/jira/browse/JBAS-2391 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.3 Final > Reporter: Adrian Brock > Priority: Optional > Fix For: JBossAS-5.0.1.CR1 > > > The PropertyManager installs itself as the system properties inorder to allow listeners to be registered > on property changes. > This should at least be configurable. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1711) HTMLAdaptorServlet updateAttributes bug?

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1711?page=all ] Dimitris Andreadis updated JBAS-1711: ------------------------------------- Fix Version/s: (was: JBossAS-4.2.0.CR1) > HTMLAdaptorServlet updateAttributes bug? > ---------------------------------------- > > Key: JBAS-1711 > URL: http://jira.jboss.com/jira/browse/JBAS-1711 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Management services > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 > Reporter: SourceForge User > Priority: Minor > > SourceForge Submitter: raja05 . > UpdateAttributes method in HtmlAdaptorServlet has a > section of code something like > while( paramNames.hasMoreElements() ) > { > String param = (String) paramNames.nextElement(); > if( param.equals("name") || > param.equals("action") ) > continue; > String value = request.getParameter(param); > log.trace("name="+param+", value='"+value+"'"); > // Ignore null values, these are empty > write-only fields > if( value == null || value.length() == 0 ) > continue; > attributes.put(param, value); > } > The check for value == null || value.length() == 0 is > kind of wrong for my case. > Im trying to use a XMBean that would store the values > from the JMX-Console to a filestore that i have created > using Properties.load(not the > ObjectStreamPersistenceManager but something along the > line that uses the Property.save to store the data in a > name=value fashion). > The problem im getting is that if i want to clear out > any of the attributes that have been set already, the > above code comes to the check of value.length() == 0 > and since its blank, just moves to the next request > param. I would like to remove this check from there so > that even though i blank out my value, i need that to > get persisted. > Please let me know if you need a detailed explanation > or if the above is not clear > I just need the value.length() == 0 check removed but > not sure if thats going to cause an issue somewhere else. > Thanks a bunch > Raja -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3193) Use getCanonicalFile() to provide absolute paths without prepend characters (\..\..\..\)

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3193?page=all ] Dimitris Andreadis updated JBAS-3193: ------------------------------------- Fix Version/s: (was: JBossAS-4.2.0.CR1) Assignee: Galder Zamarreno > Use getCanonicalFile() to provide absolute paths without prepend characters (\..\..\..\) > ---------------------------------------------------------------------------------------- > > Key: JBAS-3193 > URL: http://jira.jboss.com/jira/browse/JBAS-3193 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.4.CR2 > Environment: Windows > Reporter: Galder Zamarreno > Assigned To: Galder Zamarreno > Priority: Minor > > Due to a bug in the JVM, paths created by expressions like this File f = new File(parentDir, fileName) > contain prepend characters (\..\..\..\..\ ) and can result on paths bigger than 255 characters (Windows limit). > The JVM bug has been fixed but won't be available until Java 6 (Mustang): > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4403166 > The feature request consists of changing File f = new File(parentDir, fileName) to > f = new File(parentDir, fileName).getCanonicalFile();. This would guarantee that relative paths > are constructed into absolute ones without prepend characters. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2831) Allow run-as indentity propagation across servers with configurable trust

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2831?page=all ] Dimitris Andreadis updated JBAS-2831: ------------------------------------- Component/s: Security Fix Version/s: JBossAS-5.0.1.CR1 (was: JBossAS-4.2.0.CR1) Assignee: Anil Saldhana Add component, assign to Anil, reschedule. > Allow run-as indentity propagation across servers with configurable trust > ------------------------------------------------------------------------- > > Key: JBAS-2831 > URL: http://jira.jboss.com/jira/browse/JBAS-2831 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: JBossAS-4.0.4RC1 > Reporter: Scott M Stark > Assigned To: Anil Saldhana > Fix For: JBossAS-5.0.1.CR1 > > > Look to provide propagation of the run-as identity across server calls with control over how the target server trusts this call is correct. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2909) Testcase infra structure for MemoryLeaks

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ] Dimitris Andreadis updated JBAS-2909: ------------------------------------- Component/s: Test Suite Fix Version/s: (was: JBossAS-4.2.0.CR1) Assignee: Clebert Suconic Added component, assigned to Clebert. > Testcase infra structure for MemoryLeaks > ---------------------------------------- > > Key: JBAS-2909 > URL: http://jira.jboss.com/jira/browse/JBAS-2909 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Clebert Suconic > Assigned To: Clebert Suconic > Fix For: JBossAS-5.0.1.CR1 > > > We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). > Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. > Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) > To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). > This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: > jvmtiInterface.forceReleaseOfGC(); > Class[] classes = jvmtiInterface.getLoadedClasses(); -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-3316) outdated log4j.jar causes UndeclaredThrowableException

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3316?page=all ] Dimitris Andreadis closed JBAS-3316. ------------------------------------ Resolution: Done Assignee: Dimitris Andreadis (was: Scott M Stark) Attempting an upgrade to log4j 1.2.14 through the linked task. > outdated log4j.jar causes UndeclaredThrowableException > ------------------------------------------------------ > > Key: JBAS-3316 > URL: http://jira.jboss.com/jira/browse/JBAS-3316 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Affects Versions: JBossAS-4.0.4.GA > Environment: java version 1.5.0_06 macosx > Reporter: afm > Assigned To: Dimitris Andreadis > Fix For: JBossAS-4.2.0.CR1 > > > The log(String callerFQCN, Priority level, Object message, Throwable t) method of org.apache.log4j.Logger > in the log4j.jar distributed with JBoss throws a NullPointerException if called with t = null. This then > causes an InvocationTargetException on line 288 of org/apache/commons/logging/impl/Log4jProxy.java, > leading to an UndeclaredThrowableException on line 296. The problem is that very often the method is > called with t = null, e.g. on line 235, in the debug method. This then causes some servlets not to work > (Google finds a few instances of this). > The cause is a rather outdated log4j.jar. Replacing log4j.jar by a more recent version seems to > fix this problem -- 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

17 years, 9 months

1
0
0 / 0

(no subject)

by cee3

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3948) JndiLoginInitialContextFactory cannot be used in a server environment

by Scott M Stark (JIRA)

JndiLoginInitialContextFactory cannot be used in a server environment --------------------------------------------------------------------- Key: JBAS-3948 URL: http://jira.jboss.com/jira/browse/JBAS-3948 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA Reporter: Scott M Stark Assigned To: Scott M Stark The org.jboss.security.jndi.JndiLoginInitialContextFactory cannot be used in a server environment as it is not using the SecurityAssociation api in a way that preserves incoming security context. -- 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

17 years, 9 months

1
0
0 / 0

Save on meD$ with us!

by Phillip Arrington

17 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2006