January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBAS-1313) RepositorySelector should be integrated into JBoss Server

by Cserveny Tamas (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1313?page=comments#action_12351337 ] Cserveny Tamas commented on JBAS-1313: -------------------------------------- Hi, I've implemented this change request. A notification is installed into all subdeployers (the listeners are dynamically added/removed from/to the SubDeployers using the notifications from the MainDeployer). It seeks META-INF/log4j.xml / .prop in the classpath (using localCl), and configure the logger for the given deployment. It uses ClassLoaders to track deployments. It needs no code changes in any of the existing JBoss code. (Tested on 4.0.3, with EARs, WARs and spring deployer) One problem though, in an EAR deployment all subdeployments receives the classloader thus, one cannot create seperate logger for sub deployments. (eg. one for the whole EAR and a seperate for the WAR inside) Or a logger in a subdeployment would be used for the whole application. That's why this service is limited for 'root' deployments only at the moment. What's next? Cheers, Tamas > RepositorySelector should be integrated into JBoss Server > --------------------------------------------------------- > > Key: JBAS-1313 > URL: http://jira.jboss.com/jira/browse/JBAS-1313 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMX > Reporter: Stan Silvert > Assigned To: Stan Silvert > Priority: Minor > Fix For: JBossAS-4.2.0.CR1 > > > Often, an application will want to have its own log4j configuration and have all log messages generated go to an application-specific log file. Solutions to this problem are documented on this wiki page: http://www.jboss.org/wiki/Wiki.jsp?page=Logging > The log4j RepositorySelector provides a clean solution to this problem without any special classloader settings. However, at the present time, a developer must create his own version of a RepositorySelector and make sure his application initializes it properly. > This can be difficult to accomplish because the RepositorySelector feature is not well known and takes time to understand. It can also be difficult to make sure that the RepositorySelector is initialized before the application makes ANY call to Logger.getLogger(). > We can instead, provide a RepositorySelector implementation as part of the JBoss Application server. If a deployer finds a log4j.xml file in the /META-INF direcotry (or /WEB-INF for WARs) it would add an entry into the RepositorySelector for that application. Then, logging from that application would use the custom log4j configuration. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2895) Extend SecureIdentityLoginModule to externalize the secret

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2895?page=all ] Scott M Stark closed JBAS-2895. ------------------------------- Resolution: Done A new org.jboss.resource.security.PBEIdentityLoginModule has been added extends the SecureIdentityLoginModule to provide control over the masking password and cipher. wiki info: !! Configured Identity with Password Based Encryption An extension to configured identity that uses a credential that is encrypted using a PBE cipher. Example login-module.xml entries are: {{{ <application-policy name = "testPBEIdentityLoginModule"> <authentication> <login-module code = "org.jboss.resource.security.PBEIdentityLoginModule" flag = "required"> <module-option name = "principal">sa</module-option> <module-option name = "userName">sa</module-option>  <module-option name = "password">3fp7R/7TMjyTTxhmePdJVk</module-option> <module-option name = "ignoreMissigingMCF">true</module-option> <module-option name = "pbealgo">PBEWithMD5AndDES</module-option> <module-option name = "pbepass">testPBEIdentityLoginModule</module-option> <module-option name = "salt">abcdefgh</module-option> <module-option name = "iterationCount">19</module-option> <module-option name = "managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option> </login-module> </authentication> </application-policy> <application-policy name = "testPBEIdentityLoginModuleTmpFilePassword"> <authentication> <login-module code = "org.jboss.resource.security.PBEIdentityLoginModule" flag = "required"> <module-option name = "principal">sa</module-option> <module-option name = "userName">sa</module-option>  <module-option name = "password">2zff525DS/OgTuWuJtHYHa</module-option> <module-option name = "ignoreMissigingMCF">true</module-option> <module-option name = "pbealgo">PBEWithMD5AndDES</module-option> <module-option name = "pbepass">{CLASS}org.jboss.security.plugins.TmpFilePassword:${java.io.tmpdir}/tmp.password,5000</module-option> <module-option name = "salt">abcdefgh</module-option> <module-option name = "iterationCount">19</module-option> <module-option name = "managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option> </login-module> </authentication> </application-policy> }}} This uses password based encryption (PBE) with algorithm parameters dervived from pbealgo, pbepass, salt, iterationCount options: * pbealgo - the PBE algorithm to use. Defaults to PBEwithMD5andDES. * pbepass - the PBE password to use. Can use the JaasSecurityDomain {CLASS} and {EXT} syntax to obtain the password from outside of the configuration. Defaults to "jaas is the way". * salt - the PBE salt as a string. Defaults to {1, 7, 2, 9, 3, 11, 4, 13}. * iterationCount - the PBE iterationCount. Defaults to 37. > Extend SecureIdentityLoginModule to externalize the secret > ---------------------------------------------------------- > > Key: JBAS-2895 > URL: http://jira.jboss.com/jira/browse/JBAS-2895 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JCA service, Security > Affects Versions: JBossAS-4.0.3 SP1, JBossAS-3.2.8 Final > Reporter: Scott M Stark > Assigned To: Scott M Stark > Fix For: JBossAS-4.2.0.CR1 > > > The SecureIdentityLoginModule is a simple security by obscurity approach to hiding the jca password. Having the secret used by the PBE externalized with an ability to hash it reversibly would make this more flexible. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-179) Turn over updated course to training org

by Brian Stansberry (JIRA)

Turn over updated course to training org ---------------------------------------- Key: JBCLUSTER-179 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-179 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-178) Update certification exam questions for AS

by Brian Stansberry (JIRA)

Update certification exam questions for AS ------------------------------------------ Key: JBCLUSTER-178 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-178 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-404) Provide API to allow multiple callers to safely call activateRegion() .

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-404?page=all ] Brian Stansberry updated JBCACHE-404: ------------------------------------- Fix Version/s: 2.0.0.BETA2 (was: 2.0.0.BETA1) > Provide API to allow multiple callers to safely call activateRegion() . > ----------------------------------------------------------------------- > > Key: JBCACHE-404 > URL: http://jira.jboss.com/jira/browse/JBCACHE-404 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4SP1, 1.2.4 > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Minor > Fix For: 2.0.0.BETA2 > > > If a caller calls activateRegion() and the region is already active, they will get a RegionNotEmptyException. Need to add an API to make it easy for use cases where multiple callers may want to activate the same region. > Use case for this is ClusteredSSO. Multiple ClusteredSSO valves can be running in the same server; all share the /SSO region. The TreeCache is shared with session replication, so the activateRegion API needs to be used. Currently it catches the RegionNotEmptyException, but I don't like this in the ClusteredSSO code. > Possibilities: > 1) Add an isRegionActive() method, callers can check first. But this can lead to race conditions. > 2) Overload the activateRegion method with a version that won't throw the RegionNotEmptyException. > Don't want to get rid of the RegionNotEmptyException, as in many uses cases (e.g. session repl) the region should not have data; if it does that's an error condition the application should know about. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-676) TimerTasks run by TimerUtil should have a chance to clean up if TimerUtil.destroy() is called.

by Ron Sigal (JIRA)

TimerTasks run by TimerUtil should have a chance to clean up if TimerUtil.destroy() is called. ---------------------------------------------------------------------------------------------- Key: JBREM-676 URL: http://jira.jboss.com/jira/browse/JBREM-676 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Alpha6 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Alpha6 org.jboss.remoting.ConnectionValidator is being changed so that it creates a client invoker one time in start() and destroys it in stop(), instead of recreating it for each ping. But it runs in org.jboss.remoting.util.TimerUtil's Timer, and if TimerUtil.destroy() were called, ConnectionValidator.stop() would never get called. Comment from Tom Elrod: "... the Client that created the ConnectionValidator would be out in the cold if someone were to destroy() the TimerUtil since the ConnectionValidator would still be there, just doing nothing (and Client would be unaware that ConnectionValidator is no longer checking for the server to be down). ...Hopefully no one would do that in code." -- 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, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-767) HTTP tests lock testsuite run

by Ovidiu Feodorov (JIRA)

HTTP tests lock testsuite run ----------------------------- Key: JBMESSAGING-767 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-767 Project: JBoss Messaging Issue Type: Sub-task Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Blocker Fix For: 1.2.0.Beta2 Why didn't the timeout kick in? [junit] @Thread-13 07:55:57,062 ERROR [CallbackPoller] Error getting callbacks from server. [junit] org.jboss.remoting.CannotConnectException: Can not connect http client invoker. [junit] at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:234) [junit] at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:95) [junit] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:118) [junit] at org.jboss.remoting.Client.invoke(Client.java:635) [junit] at org.jboss.remoting.Client.invoke(Client.java:627) [junit] at org.jboss.remoting.Client.getCallbacks(Client.java:1297) [junit] at org.jboss.remoting.callback.CallbackPoller.run(CallbackPoller.java:190) [junit] at java.util.TimerThread.mainLoop(Timer.java:432) [junit] at java.util.TimerThread.run(Timer.java:382) [junit] Caused by: java.net.ConnectException: Connection refused: connect [junit] at java.net.PlainSocketImpl.socketConnect(Native Method) [junit] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) [junit] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) [junit] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) [junit] at java.net.Socket.connect(Socket.java:461) [junit] at java.net.Socket.connect(Socket.java:411) [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:139) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:402) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:618) [junit] at sun.net.www.http.HttpClient.<init>(HttpClient.java:306) [junit] at sun.net.www.http.HttpClient.<init>(HttpClient.java:267) [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:339) [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:320) [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:315) [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:521) [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:498) [junit] at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:569) [junit] at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:193) [junit] ... 8 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-164) Tag the clustering course in CVS

by Brian Stansberry (JIRA)

Tag the clustering course in CVS -------------------------------- Key: JBCLUSTER-164 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-164 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-158) Clustering training course improvements

by Brian Stansberry (JIRA)

Clustering training course improvements --------------------------------------- Key: JBCLUSTER-158 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-158 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q1Y7 Container task for RH439 course improvements -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-161) Use AS 4.0.5 for the AS labs

by Brian Stansberry (JIRA)

Use AS 4.0.5 for the AS labs ---------------------------- Key: JBCLUSTER-161 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-161 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q1Y7 -- 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, 3 months

1
1
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 January 2007