[JBoss JIRA] Updated: (JBAS-3093) Undeploying WAR from vitual host does not work correctly.
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3093?page=all ]
Dimitris Andreadis updated JBAS-3093:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
Moving issue to a next release
> Undeploying WAR from vitual host does not work correctly.
> ---------------------------------------------------------
>
> Key: JBAS-3093
> URL: http://jira.jboss.com/jira/browse/JBAS-3093
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Deployment services
> 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
> Assigned To: Remy Maucherat
> Fix For: JBossAS-4.2.1.CR1
>
>
> 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: 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-2131) Better support for BMT SFSB "mistakes"
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2131?page=all ]
Dimitris Andreadis updated JBAS-2131:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
Moving issue to a next release
> Better support for BMT SFSB "mistakes"
> --------------------------------------
>
> Key: JBAS-2131
> URL: http://jira.jboss.com/jira/browse/JBAS-2131
> Project: JBoss Application Server
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: EJB2
> Affects Versions: JBossAS-4.0.3RC2
> Reporter: Adrian Brock
> Assigned To: Weston Price
> Fix For: JBossAS-4.2.1.CR1
>
>
> Further to JBAS-2128 we should also implement some sort of listener on the transaction timeout.
> Given the stupid BMT SFSB semantics (this part of the spec is one my favourite anti-patterns :-)
> where a client can hog server resources.
> sfsb.doBegin();
> doLongRunningProcess();
> sfsb.doCommit();
> And even crash during the doLongRunningProcess().
> We should allow the server to reclaim the resources from a transaction timeout more quickly.
> Another option would be to allow a configuration that does a rollback() at transaction timeout.
> But this would require some serious testing to make sure all JBoss code is checking transaction status correctly.
> It would also confuse any non-j2ee compliant framework that registers transaction synchronizations
> and then assumes their "thread local" is still valid from the timeout thread or they aren't threadsafe.
> No names mentioned to protect the guilty :-)
--
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-3378) Application Policy (Authentication + Authorization Info) Extendable
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3378?page=all ]
Dimitris Andreadis updated JBAS-3378:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
(was: JBossAS-5.0.1.CR1)
Moving issue to a next release
> Application Policy (Authentication + Authorization Info) Extendable
> -------------------------------------------------------------------
>
> Key: JBAS-3378
> URL: http://jira.jboss.com/jira/browse/JBAS-3378
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: JBossAS-4.0.4.GA
> Reporter: Anil Saldhana
> Assigned To: Anil Saldhana
> Fix For: JBossAS-4.2.1.CR1
>
>
> <policy>
> <application-policy name="xyz" extends "abc">
> <authentication>
> ...
> </authentication>
> </application-policy>
> </policy>
> A configuration that can derive from a different application policy for authentication (and or authorization) information is useful to reduce redundant definition of login modules in various security domain definitions.
--
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-2766) tomcat libraries not available to remoting when using http transport
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2766?page=all ]
Dimitris Andreadis updated JBAS-2766:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
(was: JBossAS-5.0.1.CR1)
Moving issue to a next release
> tomcat libraries not available to remoting when using http transport
> --------------------------------------------------------------------
>
> Key: JBAS-2766
> URL: http://jira.jboss.com/jira/browse/JBAS-2766
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Remoting
> Affects Versions: JBossAS-4.0.4.CR2
> Reporter: Tom Elrod
> Assigned To: Tom Elrod
> Priority: Critical
> Fix For: JBossAS-4.2.1.CR1
>
> Attachments: jboss-service.xml, remoting-service.xml, standardjboss.xml
>
>
> As of JBoss Remoting 1.4.0 final (which is now included for JBossAS 4.0.4 and JBossAS 5), the http transport implementation uses Tomcat connectors. Therefore, the following jars need to be available to remoting when running within JBossAS:
> tomcat-apr.jar
> tomcat-coyote.jar
> tomcat-http.jar
> tomcat-util.jar
> These are included in the jbossweb-tomcat55.sar directory, but are not on the classpath when the UnifiedInvoker is used (which uses remoting). So if use the http transport within remoting when using UnifiedInvoker, get errors since the needed classes are not found.
> BTW, does not matter if 'UseJBossWebLoader' is true or false within jbossweb-tomcat55.jar/META-INF/jboss-service.xml.
--
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-2923) Making JCA security more pluggable
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2923?page=all ]
Dimitris Andreadis updated JBAS-2923:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
Moving issue to a next release
> Making JCA security more pluggable
> ----------------------------------
>
> Key: JBAS-2923
> URL: http://jira.jboss.com/jira/browse/JBAS-2923
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JCA service
> Reporter: Adrian Brock
> Assigned To: Weston Price
> Fix For: JBossAS-4.2.1.CR1
>
>
> We need a mechanism to make JCA security more pluggable.
> This is to cater for use cases where some extra context needs to be used.
> The connection manager only understands a subject.
> The connection factory (e.g. DataSource) only understands the CRI (method parameters).
> The pooling uses both without needing to understand what they are in detail.
> This change would provide a "wrapper" connection manager that can do things
> more associated to context, e.g. it could be connection factory specific,
> i.e. it understands the CRI and can do things that the connection factory doesn't do
> or it can do things based on information.
> An example of other information would allowing a per deployment
> security domain such that you have different pre-configured user/password per ejb.
> With something like the following in META-INF/jboss-[web].xml
> <jboss>
> <enterprise-beans>
> <session>
> <ejb-name>Whatever</ejb-name>
> ...
> <resource-ref>
> <res-ref-name>jdbc/DataSource</res-ref-name>
> <jndi-name>java:/MySQLDS</jndi-name>
> <security-domain>FooBar</security-domain>
> </resource-ref>
> </session>
> </enterprise-beans>
> </jboss>
--
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-1434) JMS Message Inflow
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1434?page=all ]
Dimitris Andreadis updated JBAS-1434:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
Moving issue to a next release
> JMS Message Inflow
> ------------------
>
> Key: JBAS-1434
> URL: http://jira.jboss.com/jira/browse/JBAS-1434
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JCA service
> Affects Versions: JBossAS-4.0.2 Final
> Reporter: Adrian Brock
> Assigned To: Weston Price
> Fix For: JBossAS-4.2.1.CR1
>
>
> Forums Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48672
> The JMS message inflow in the JMS resource adapter needs properly testing.
> There are basic tests, but the following are missing:
> 1) Complete tests of edge cases for each configuration parameter in the activation spec
> 2) Failure tests to confirm the implementation handles error gracefully
> 3) Stress tests to make sure there the implementation is stable
> 4) Performance tests to optimize the implementation
> Additionally, we need to confirm that it is possible to use this implementation for EJB2.0
> style deployments and hence as the default configuration.
> This should be possible provided the user has not created their own
> container configuration that uses the old JMSContainerInvoker explicitly.
--
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-2676) ClassLoader getResources() omits directory but finds files in the directory - this affects Facelets *.taglib.xml auto-loading
by Howard Lewis Ship (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2676?page=comments#action_12353656 ]
Howard Lewis Ship commented on JBAS-2676:
-----------------------------------------
I'm having the same issue as Facelets, for Tapestry 5.
https://issues.apache.org/jira/browse/TAPESTRY-1287
Just want the JBoss and/or Tomcat class loaders to do the same as Sun's ... return directories. I'm going to see if I can do a workaround based on ServletContext to access classes inside WEB-INF/classes.
> ClassLoader getResources() omits directory but finds files in the directory - this affects Facelets *.taglib.xml auto-loading
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBAS-2676
> URL: http://jira.jboss.com/jira/browse/JBAS-2676
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Windows XP, JDK 1.5.0_04
> Reporter: David Richmond
> Assigned To: Remy Maucherat
>
> Using JSF and Facelets.
> Have a JAR file in my WebApps WEB-INF/lib, JAR file contains META-INF/faces-config.xml and META-INF/isalib.taglib.xml
> Using the Thread.currentThread().getContextClassLoader() classloader:
> .getResources("META-INF/faces-config.xml") finds the file in the JAR
> .getResources("META-INF/") does not find the directory in the JAR
> This is quite important, since Facelets scans the classpath for "META-INF/" dircetories and searches for *.taglib.xml files therein - this allows Facelets to auto-load the files it finds.
> One work around is to copy the taglib.xml file into my web-app and point the facelets.LIBRARIES context parameter at the file. Another workaround is to put the taglib.xml file into the Web-App's META-INF directory (since WAR files are on the classpath - is this an error?). However, the taglib.xml definitions belong to the JAR and can change when the JAR source code changes - so loading from the JAR is prefered.
--
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
