[JBoss JIRA] Created: (JBWEB-147) RewriteValve MBean configuration attribute - getter and setter not compatible
by Kevin Mudrick (JIRA)
RewriteValve MBean configuration attribute - getter and setter not compatible
-----------------------------------------------------------------------------
Key: JBWEB-147
URL: https://jira.jboss.org/jira/browse/JBWEB-147
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossWeb-2.1.4.GA
Reporter: Kevin Mudrick
Assignee: Remy Maucherat
If one hits the "Apply Changes" in the jboss.web / RewriteValve JMX MBean in the JBoss JMX console, with the existing value (from what the console renders), without making any changes whatsoever, you lose your existing rewrite rules.
Looking at the code, it seems as though the implementation of the setter and getter methods for the configuration property not quite on the same page. The getter loops over your rules and conditions, calling toString on each - but the toString implementations for org.jboss.web.rewrite.RewriteCond and org.jboss.web.rewrite.RewriteRule ignore things like the flags. There are FIXMEs that mention this. The setter expects a properly formatted, newline-delimited complete set of properties as a String.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBAS-5299) Jboss 4.2.2 ignores attributes to tag files when pages are pre-compiled
by Stephen Cresswell (JIRA)
Jboss 4.2.2 ignores attributes to tag files when pages are pre-compiled
-----------------------------------------------------------------------
Key: JBAS-5299
URL: http://jira.jboss.com/jira/browse/JBAS-5299
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-4.2.2.GA
Environment: Ubuntu 7.10, java 6.03, JBoss 4.2.2.GA
Reporter: Stephen Cresswell
Assigned To: Remy Maucherat
The following will not work on JBoss 4.2.2.GA when JSPs are precompiled.
<!-- standardHead tag file-->
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
<%@ attribute name="code" required="true" %>
<head>
<title><spring:message code="site.title"/> - <spring:message code="${code}"/></title>
</head>
<!-- JSP using standard head tag file -->
<%@ taglib prefix="tags" tagdir="/WEB-INF/tags/" %>
<html>
<tags:standardHead code="contactUs.title" />
<body>
<div class="pod">
<h2><spring:message code="contactUs.label"/></h2>
<spring:message code="contactUs.address"/>
</div>
</body>
</html>
Even though the standardHead tag is passed a valid message key 'contactUs.title', when precompiled this value is translated to the empty string, causing the following error.
javax.servlet.ServletException: javax.servlet.jsp.JspTagException: No message found under code '' for locale 'en_GB'.
The page works fine if not precompiled.
It also works fine when deployed to tomcat 5.5.26 precompiled or otherwise.
The same war that fails on JBoss 4.2.2.GA works if deployed to 4.2.1.GA
I have created a demonstration app if required.
--
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
15 years, 9 months
[JBoss JIRA] Created: (JBAS-4813) EAR with WAR classloading isolation & commons-httpclient
by C￩dric Chantepie (JIRA)
EAR with WAR classloading isolation & commons-httpclient
--------------------------------------------------------
Key: JBAS-4813
URL: http://jira.jboss.com/jira/browse/JBAS-4813
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading, Web (Tomcat) service
Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.3 SP1
Environment: Linux 2.6.11-1.1369_FC4smp (Fedora Core 4) 2005 i686 i686 i386 GNU/Linux
jrockit-R26.4.0-jdk1.5.0_06
Reporter: C￩dric Chantepie
Assigned To: Scott M Stark
Priority: Blocker
We have an EAR including 4 modules :
- an ejb .jar,
- persistence .har
- 2 webapps.
3 modules -- the ejb .jar and the 2 webapps, depends on commons-httpclient 3.1, different from jboss version which 2.x, so I've first maid the EAR isolated by adding the jboss-app.xml with instruction given in JBoss wiki about EAR classloading.
== META-INF/jboss-app.xml ==
<!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 1.4//EN"
"http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd">
<jboss-app>
<loader-repository>my.package:loader=My.ear
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
<jmx-name>my.package:module=My.ear</jmx-name>
<module>
<har>MyPersistence.har</har>
</module>
</jboss-app>
Then I've added Class-Path attribute in ejb .jar manifest.
== ejb.jar | META-INF/MANIFEST.MF ==
Manifest-Version: 1.0
Class-Path: lib/commons-httpclient-3.1.jar lib/commons-codec-1.2.jar l
ib/lucene-core-2.0.0.jar lib/commons-lang-2.3.jar lib/j2cdk.jar lib/l
ucene-analyzers-2.0.0.jar
(Line breaks there are as in MANIFEST.MF when I extract it from the jar.)
I've also manifest files in WAR for the 2 webapps, but I'm not sure jboss/jbossweb(tomcat) take care of it.
== webapp1.war | META-INF/MANIFEST.MF ==
Manifest-Version: 1.0
Class-Path: lib/a-web-lib.jar lib/commons-beanutils-1.7.0.jar li
b/commons-beanutils-core-1.7.0.jar lib/commons-digester-1.6.jar lib/c
ommons-fileupload-1.0.jar lib/j2cdk-taglib.jar lib/j2cdk.jar lib/jgen
.jar lib/jstl.jar lib/standard.jar lib/struts-1.2.9.jar lib/taglibs-m
ailer.jar lib/commons-httpclient-3.1.jar
== webapp2.war | META-INF/MANIFEST.MF ==
Manifest-Version: 1.0
Class-Path: lib/a-web-lib.jar lib/commons-beanutils-1.7.0.jar li
b/commons-beanutils-core-1.7.0.jar lib/commons-digester-1.6.jar lib/j
2cdk-taglib.jar lib/j2cdk.jar lib/jgen.jar lib/jstl.jar lib/standard.
jar lib/struts-1.2.9.jar lib/taglibs-mailer.jar lib/htmlparser-1.0-SN
APSHOT.jar lib/commons-httpclient-3.1.jar
And I've also jboss-web.xml files in these two WAR, even if there are included when deployed inside EAR (which is the top deployment in this case), with the same load repository specified "my.package:loader=My.ear".
== webapp1.war | WEB-INF/MANIFEST.MF ==
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jboss-web
PUBLIC "-//JBoss//DTD Web Application 2.3V2//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd">
<jboss-web>
<context-root>/BO</context-root>
<virtual-host>www.my-vhost.com</virtual-host>
<class-loading java2ClassLoadingCompliance="false">
<loader-repository>my.package:loader=My.ear
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
== webapp2.war | WEB-INF/MANIFEST.MF ==
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jboss-web
PUBLIC "-//JBoss//DTD Web Application 2.3V2//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd">
<jboss-web>
<context-root>/</context-root>
<virtual-host>www.my-vhost.com</virtual-host>
<class-loading java2ClassLoadingCompliance="false">
<loader-repository>my.package:loader=My.ear
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
Ok, that the situation. All work well on several developpement servers (tested on 3 linux hosts and 1 os x), it can be deployed without any error on prodution server (which environement is indicated in this issue), but I get an exception when I test it.
The exceptions occurs when I call a JSP, not precompiled and so compiled on-the-fly by jbossweb (as on developpement servers where it works fine). Then I get a NoSuchMethodException about getParams() on org.apache.commons.httpclient.HttpConnectionManager. In fact this method doesn't exist in commons-httpclient 2.x included in JBoss, that why I include it as lib in EAR, and isolate this one.
If I replace the commons-httpclient in jboss/server/default/lib by mine it works fine.
I've tested on 3 other server with the same JBoss, same JVM and same EAR, it works on the others. I'm sure JBoss/JVM/EAR are absolutely the same as on the production server because in fact I've make a tar file of all this on the server before transfering it on the 3 others.
2 of these test server have the same linux version (kernel), excepted SMP support.
Here is where I'm. In fact now I really don't know what could cause this difference, and prevent EAR from working on production jboss server. Could it be related to the SMP (2 cpu) ? Does in this case jbossweb compile with a different classloader for the second cpu ? Maybe silly but I haven't real idea.
So please if you can give some useful information.
--
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
15 years, 9 months
[JBoss JIRA] Resolved: (JBAS-3093) Undeploying WAR from vitual host does not work correctly.
by Remy Maucherat (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-3093?page=com.atlassian.jira.plug... ]
Remy Maucherat resolved JBAS-3093.
----------------------------------
Fix Version/s: JBossAS-5.0.0.GA
Resolution: Done
As I understand it, not using the Tomcat classloader will help with this issue (as is the default in new AS versions). Create a new issue if you encounter this with new AS versions.
> Undeploying WAR from vitual host does not work correctly.
> ---------------------------------------------------------
>
> Key: JBAS-3093
> URL: https://jira.jboss.org/jira/browse/JBAS-3093
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Deployers
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Microsoft Windows XP Service Pack 2
> JDK 1.5.0_05
> Running with Java SecurityManager turned on.
> Reporter: Paul Sideleau
> Assignee: Remy Maucherat
> Fix For: JBossAS-5.0.0.GA
>
>
> I have a class that implements a javax.servlet.ServletContextListener. The contextDestroyed method is correctly called and executes without errors when I delete my WAR file from the deploy directly. However, if I use virtual hosts and add a virtual-host element to my jboss-web.xml file, the contextDestroyed method is not called when I delete my WAR file. The contextDestroyed method is only called when I redeploy the WAR. This also sometimes causes the following exception:
> 3:00:40,816 WARN [WebappClassLoader] Failed to open JAR
> java.util.zip.ZipException: The system cannot find the path specified
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:203)
> at java.util.jar.JarFile.<init>(JarFile.java:132)
> at java.util.jar.JarFile.<init>(JarFile.java:97)
> at org.apache.catalina.loader.WebappClassLoader.openJARs(WebappClassLoader.java:1544)
> at org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1763)
> at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1570)
> at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:850)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1299)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at com.jboss.bugtest.servlet.TestServletContextListener.contextDestroyed(TestServletContextListener.java:27)
> at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3710)
> at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4283)
> at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1131)
> at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4358)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
> at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:150)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeployInternal(TomcatDeployer.java:157)
> at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeploy(TomcatDeployer.java:88)
> at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:357)
> at org.jboss.web.WebModule.startModule(WebModule.java:68)
> at org.jboss.web.WebModule.startService(WebModule.java:46)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:274)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:230)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:943)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:428)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy31.start(Unknown Source)
> at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:400)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy32.start(Unknown Source)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
> at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy9.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:319)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:507)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:192)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:203)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:182)
> 13:00:41,191 DEBUG [WebappClassLoader] -->RuntimeException Rethrown
> java.lang.NullPointerException
> at org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1766)
> at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1570)
> at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:850)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1299)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at com.jboss.bugtest.servlet.TestServletContextListener.contextDestroyed(TestServletContextListener.java:27)
> at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3710)
> at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4283)
> at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1131)
> at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4358)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
> at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:150)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeployInternal(TomcatDeployer.java:157)
> at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeploy(TomcatDeployer.java:88)
> at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:357)
> at org.jboss.web.WebModule.startModule(WebModule.java:68)
> at org.jboss.web.WebModule.startService(WebModule.java:46)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:274)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:230)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:943)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:428)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy31.start(Unknown Source)
> at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:400)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy32.start(Unknown Source)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
> at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy9.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:319)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:507)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:192)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:203)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:182)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBAS-4249) isUserInRole returns always false when jacc is enabled and the principal roles are empty
by Roland Räz (JIRA)
isUserInRole returns always false when jacc is enabled and the principal roles are empty
----------------------------------------------------------------------------------------
Key: JBAS-4249
URL: http://jira.jboss.com/jira/browse/JBAS-4249
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-4.0.5.GA
Reporter: Roland Räz
Assigned To: Remy Maucherat
We are using our won jacc policy and login modules that don't add (cache) the roles in the principal. In this situation, the org.jboss.web.tomcat.security.JaccAuthorizationRealm hasRole method always returns false. The reason behind that is that the method hasRole setups a Principal array that does not contain the principal itself (only the roles are contained) when getPrincipalRoles return a not null Set. The getPrincipalRoles retuns for the above described setup not null.
The following code fixes the issue:
public boolean hasRole(Principal principal, String name)
{
...
Principal[] principals = {principal};
Set roles = getPrincipalRoles(principal);
if( roles != null )
{
principals = new Principal[roles.size() + 1];
principals[0]= principal;
Iterator it = roles.iterator();
for (int i=1;it.hasNext();i++) {
principals[i] =(Principal) it.next();
}
}
...
In my opinion it would be even cleaner to use only the Principal and do not using the principal roles as own identity when querying a jacc provider. JBoss could then still extract in it's own jacc provider the principal roles from the principal. In the current design there is a clash between the role and principal names. The better solution is used in the EJB 2.x code (org.jboss.ejb.enterpriseContext.isCallerInRoleCheckForJacc();
It looks like this for servlets:
...
Principal[] principals = {principal};
...
--
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
15 years, 9 months
[JBoss JIRA] Created: (JBWEB-151) Jboss saaj implementation does not work with jax-rpc clients inside server
by William Newman (JIRA)
Jboss saaj implementation does not work with jax-rpc clients inside server
--------------------------------------------------------------------------
Key: JBWEB-151
URL: https://jira.jboss.org/jira/browse/JBWEB-151
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Linux RedHat4
Jboss 4.2.3
Not sure what version on JBossWeb, but it is the version packaged with JBoss 4.2.3 AS
Reporter: William Newman
Assignee: Remy Maucherat
Priority: Critical
When using/calling a JAX-RPC client stub inside the AS I get the following exception:
jboss ClassCastException: org.apache.xerces.dom.ElementNSImpl
I was able to temporarily fix this by adding in a system property to use a different implementation of MessageFactory (sun's implementation
javax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
However when this does not work when trying to also use jax-ws web services on the same server as jboss implementation code throws a class cast exception because it cannot cast one of its classes to com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl.
Is there a fixed version of the jboss saaj implementation that I can put into 4.2.3 such that I do not need to use sun's MessageFactory implementation to use jax-rpc generated client stubs within the appserver?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (EJBTHREE-1982) Fix hang(s) in ejbthree1116 test
by Carlo de Wolf (JIRA)
Fix hang(s) in ejbthree1116 test
--------------------------------
Key: EJBTHREE-1982
URL: https://jira.jboss.org/jira/browse/EJBTHREE-1982
Project: EJB 3.0
Issue Type: Task
Components: testsuite
Reporter: Carlo de Wolf
[junit] "main" prio=10 tid=0x0000000048b0f800 nid=0x6a6c in Object.wait() [0x00000000403f0000]
[junit] java.lang.Thread.State: WAITING (on object monitor)
[junit] at java.lang.Object.wait(Native Method)
[junit] - waiting on <0x00002aaab3700bf8> (a java.lang.Thread)
[junit] at java.lang.Thread.join(Thread.java:1143)
[junit] - locked <0x00002aaab3700bf8> (a java.lang.Thread)
[junit] at java.lang.Thread.join(Thread.java:1196)
[junit] at org.jboss.ejb3.test.ejbthree1116.unit.ContainerShutdownTestCase.testConcurrentRemove(ContainerShutdownTestCase.java:203)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months