[JBoss JIRA] Created: (JBTM-200) jbossts-common.jar includes commons-logging Log4JLogger
by Scott M Stark (JIRA)
jbossts-common.jar includes commons-logging Log4JLogger
-------------------------------------------------------
Key: JBTM-200
URL: http://jira.jboss.com/jira/browse/JBTM-200
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Scott M Stark
Assigned To: Mark Little
Fix For: 4.2.3
The jbossts-common.jar jar includes an implementation of the commons-logging Log interface:
[starksm@succubus lib]$ jar -tf jbossts-common.jar | grep Log4
org/apache/commons/logging/impl/Log4JLogger.class
This cannot be included in jars bundled in jbossas as it conflicts with the commons logging classes we bundle with the server. Either this needs to be extracted to a jar that is not included, or simply an external dependency that requires a valid commons logging jar.
--
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] Resolved: (JBAS-3268) FormAuthenticator has copy/paste error
by Remy Maucherat (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3268?page=all ]
Remy Maucherat resolved JBAS-3268.
----------------------------------
Resolution: Done
I had forgotten about this issue. I have applied the fix for now. I don't think it will fix any real world issue, however (the check is supposed to return true).
> FormAuthenticator has copy/paste error
> --------------------------------------
>
> Key: JBAS-3268
> URL: http://jira.jboss.com/jira/browse/JBAS-3268
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service
> Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.4.GA
> Reporter: Anil Saldhana
> Assigned To: Anil Saldhana
> Priority: Minor
> Fix For: JBossAS-4.2.0.CR1
>
>
> The matchRequest method of the FormAuthenticator is trying to match a URI with itself as indicated at the end of the method:
> ==================================================
> // Does the request URI match?
> String requestURI = request.getRequestURI();
> if (requestURI == null)
> return (false);
> return (requestURI.equals(request.getRequestURI()));
> ==================================================
> It should be:
> ========================================================
> // Does the request URI match?
> String requestURI = request.getRequestURI();
> if (requestURI == null)
> return (false);
> return (requestURI.equals(sreq.getRequestURI()));
> =======================================================
> This affects both org.jboss.web.tomcat.security.FormAuthenticator and
> http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/catalina/src/sha...
--
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] Assigned: (JBAS-3268) FormAuthenticator has copy/paste error
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3268?page=all ]
Dimitris Andreadis reassigned JBAS-3268:
----------------------------------------
Assignee: Anil Saldhana (was: Remy Maucherat)
Anil, are you back? Do you want to take this?
> FormAuthenticator has copy/paste error
> --------------------------------------
>
> Key: JBAS-3268
> URL: http://jira.jboss.com/jira/browse/JBAS-3268
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service
> Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.4.GA
> Reporter: Anil Saldhana
> Assigned To: Anil Saldhana
> Priority: Minor
> Fix For: JBossAS-4.2.0.CR1
>
>
> The matchRequest method of the FormAuthenticator is trying to match a URI with itself as indicated at the end of the method:
> ==================================================
> // Does the request URI match?
> String requestURI = request.getRequestURI();
> if (requestURI == null)
> return (false);
> return (requestURI.equals(request.getRequestURI()));
> ==================================================
> It should be:
> ========================================================
> // Does the request URI match?
> String requestURI = request.getRequestURI();
> if (requestURI == null)
> return (false);
> return (requestURI.equals(sreq.getRequestURI()));
> =======================================================
> This affects both org.jboss.web.tomcat.security.FormAuthenticator and
> http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/catalina/src/sha...
--
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: (JBAS-1608) Configuration (RW) attribute on JMX-Console breaks for jboss:service=Mail MBean
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1608?page=comments#action_12352832 ]
Dimitris Andreadis commented on JBAS-1608:
------------------------------------------
Again, Amit do you want to do this? If not, unassign from yourself and unset the fix version.
> Configuration (RW) attribute on JMX-Console breaks for jboss:service=Mail MBean
> -------------------------------------------------------------------------------
>
> Key: JBAS-1608
> URL: http://jira.jboss.com/jira/browse/JBAS-1608
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Management services
> Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.0 Final, JBossAS-3.2.6 Final, JBossAS-3.2.5 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1
> Environment: Nothing specific
> Reporter: Amit Bhayani
> Assigned To: Amit Bhayani
> Priority: Minor
> Fix For: JBossAS-4.2.0.CR1
>
>
> The Configuration (RW) attribute of jboss:service=Mail MBean breaks (doesn't display the whole property but while setting it works fine) when encounters " (double inverted comma).
> For example set the following in Configuration (RW) attribute <configuration><property name="mail.from" value="xyz(a)nosuchhost.nosuchdomain.com"/></configuration> and apply changes. Now on Configuration textbox you can see <configuration><property name= only.
--
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] Updated: (JBAS-1182) Thread creation during deactivate_object
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1182?page=all ]
Dimitris Andreadis updated JBAS-1182:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
No progress.
> Thread creation during deactivate_object
> ----------------------------------------
>
> Key: JBAS-1182
> URL: http://jira.jboss.com/jira/browse/JBAS-1182
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: IIOP service
> Reporter: SourceForge User
> Assigned To: Francisco Reverbel
> Fix For: JBossAS-4.2.1.CR1
>
>
> SourceForge Submitter: kevinconner .
> This is a duplicate of bug 527 in the JacORB database.
> It is being submitted here so that a patch may be
> applied to the JBoss patched version of JacORB.
> http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=527
> The deactiviation of an object causes Thread creation
> in AOM.remove. Would it
> be possible to use a thread pool instead of creating
> new threads?
> A possible solution could be to have the
> RequestController provide a
> notification mechanism (instead of a thread waiting on
> object completion) and
> have the notification request work from the thread pool.
> The attached patch uses a threadpool to prevent the
> thread creation but I don't
> believe it is the best solution.
> Index: AOM.java
> ===================================================================
> RCS file:
> /cvsroot/jacorb/JacORB/src/org/jacorb/poa/AOM.java,v
> retrieving revision 1.29
> diff -u -r1.29 AOM.java
> --- AOM.java 6 May 2004 12:40:00 -0000 1.29
> +++ AOM.java 21 Oct 2004 14:38:11 -0000
> @@ -27,6 +27,9 @@
> import org.jacorb.poa.util.ByteArrayKey;
> import org.jacorb.poa.util.POAUtil;
> import org.jacorb.poa.util.StringPair;
> +import org.jacorb.util.threadpool.Consumer;
> +import org.jacorb.util.threadpool.ConsumerFactory;
> +import org.jacorb.util.threadpool.ThreadPool;
>
> import
> org.omg.PortableServer.POAPackage.ObjectAlreadyActive;
> import org.omg.PortableServer.POAPackage.ObjectNotActive;
> @@ -69,6 +72,23 @@
> /** a lock to protect two consecutive operations
> on the list, used
> in remove() */
> private Object deactivationListLock =
> new Object();
> +
> + private Consumer deactivationConsumer = new
> Consumer() {
> + public void doWork(final Object job) {
> + try {
> + ((Runnable)job).run() ;
> + } catch (final Throwable th) {
> + logger.info("Unhandled exception
> during deactivation", th);
> + }
> + }
> + } ;
> + private ConsumerFactory
> deactivationConsumerFactory = new ConsumerFactory() {
> + public Consumer create() {
> + return deactivationConsumer ;
> + }
> + } ;
> +
> + private ThreadPool deactivationPool = new
> ThreadPool(deactivationConsumerFactory) ;
>
> private AOM()
> {
> @@ -348,8 +368,7 @@
> final POA poa_ = poa;
> final boolean cleanupInProgress_ =
> cleanupInProgress;
>
> - Thread thread = new Thread("AOM_RemovalThread")
> - {
> + final Runnable job = new Runnable() {
> public void run()
> {
> _remove(
> @@ -361,8 +380,8 @@
> );
> }
> };
> -
> - thread.start();
> +
> + deactivationPool.putJob(job) ;
> }
--
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] Updated: (JBAS-1180) bi-pass JacORB interceptors for purely local invocations
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1180?page=all ]
Dimitris Andreadis updated JBAS-1180:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
No progress.
> bi-pass JacORB interceptors for purely local invocations
> --------------------------------------------------------
>
> Key: JBAS-1180
> URL: http://jira.jboss.com/jira/browse/JBAS-1180
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: IIOP service
> Affects Versions: JBossAS-3.2.6 Final
> Reporter: SourceForge User
> Assigned To: Francisco Reverbel
> Fix For: JBossAS-4.2.1.CR1
>
>
> SourceForge Submitter: marklittle .
> I registered the following issue
> (http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?
> id=526) with JacORB bugzilla a couple of weeks ago, but
> no response so far. I think it's sufficiently important to
> register here too in case you are able to do something
> for JBoss.
> In the current implementation of JacORB (2.2), if I
> register an interceptor with the ORB, then
> it appears that all invocations to all objects go through
> that interceptor,
> even if they are co-located with the invoker. I
> understand that rational given
> the PI specification and the original intention behind
> that work: to make
> local invocations and remote invocations similar.
> However, most ORBs provide a way of doing a local, no-
> interceptor
> optimization. The JDK 1.4 ORB is one example (though
> that takes the other
> extreme and won't invoke interceptors on any local
> object).
> Orbix 2000, for example, supports multiple ORBs and
> POAs within the same VM,
> and interceptors are registered on a per-ORB basis, not
> a per VM basis as
> appears to be the case with JacORB. You can also turn
> on local optimizations
> for the individual ORBs.
> The reason for asking for this optimization is
> performance. With a very simple
> test, where the interceptor does nothing, we see a 66%
> degredation in
> performance for local calls. For example, with no
> interceptors we can get > 3000 invocations, whereas
> with a "null" interceptor this is around 1000.
--
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] Resolved: (JBAS-2823) Upgrade commons-logging to v1.1
by Scott M Stark (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2823?page=all ]
Scott M Stark resolved JBAS-2823.
---------------------------------
Resolution: Done
A 1.1.0.jboss release of commons-logging has been added to the repository and tagged with JBoss_Apache_Common_Logging_1_1_0 in the
:ext:starksm@cvs.forge.jboss.com:/cvsroot/jboss apache/commons-logging cvs module. The repository includes the source as commons-logging-src.zip.
An additional org.jboss.test.classloader.test.ScopingUnitTestCase.testWarCommonsLoggingWithCLJarLog4jOverrides test has been added so that the log4j factory is validated both without and with the commons-logging.jar in the war WEB-INF/lib.
This has been tested with the commons logging package filter removed from the jboss-web.deployer, so the filter has been dropped as well.
> Upgrade commons-logging to v1.1
> -------------------------------
>
> Key: JBAS-2823
> URL: http://jira.jboss.com/jira/browse/JBAS-2823
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1
> Environment: Windows XP Professional, JDK 1.5.0
> Reporter: Martin Lui
> Assigned To: Scott M Stark
> Fix For: JBossAS-4.2.0.CR1
>
>
> The Apache commons-logging package has release version 1.1.0.
> Please upgrade this library to take advantage of items listed in the release notes:
> http://jakarta.apache.org/commons/logging/RELEASE-NOTES.txt
> It would be helpful if this upgrade can be done to upgrade the server libraries since individual EAR files cannot overwrite this particular library.
> Also, looking through the notes and searching for information on the 1.0.4 patch, it appears that the WeakHashTables memory-leak fix is included in 1.1.0. (Bug 31286: http://issues.apache.org/bugzilla/show_bug.cgi?id=31286)
> Depending on how JBoss uses this package, upgrading should be as simple as replacing the current package (though I admit I had not try doing so yet).
--
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: (JBAS-4080) failing org.jboss.test.security.test.CustomPrincipalPropagationUnitTestCase
by Dimitris Andreadis (JIRA)
failing org.jboss.test.security.test.CustomPrincipalPropagationUnitTestCase
---------------------------------------------------------------------------
Key: JBAS-4080
URL: http://jira.jboss.com/jira/browse/JBAS-4080
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Test Suite
Environment: Java Version 1.5.0_10
Java Vendor Sun Microsystems Inc.
Java VM Name Java HotSpot(TM) Client VM
Java VM Version 1.5.0_10-b03
Java VM Info mixed mode
OS Name Linux
OS Version 2.6.9-42.0.2.EL
OS Arch i386
Reporter: Dimitris Andreadis
Assigned To: Stan Silvert
Fix For: JBossAS-4.2.0.CR1
testCustomPrincipalTransmissionInVM Failure Get OK(401)
junit.framework.AssertionFailedError: Get OK(401)
at org.jboss.test.security.test.CustomPrincipalPropagationUnitTestCase.testCustomPrincipalTransmissionInVM(CustomPrincipalPropagationUnitTestCase.java:105)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
Both jrockit and sun VMs
--
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