[JBoss JIRA] Updated: (JBAS-2086) Transform some Managed Objects in SMO
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2086?page=all ]
Dimitris Andreadis updated JBAS-2086:
-------------------------------------
Fix Version/s: (was: JBossAS-4.2.0.CR1)
> Transform some Managed Objects in SMO
> -------------------------------------
>
> Key: JBAS-2086
> URL: http://jira.jboss.com/jira/browse/JBAS-2086
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Management services
> Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.3RC1
> Environment: jmx, twiddle
> Reporter: Fabiano C. de Oliveira
> Priority: Minor
> Attachments: management.patch
>
>
> Make managed objects that inherits from J2EEDeployedObject a SMO. The exception is WebModule and ServiceModule for a while.
> To prevent copy&paste pattern and duplicate code the StateManagement code was moved to ManagedObject class. Instead initialize states using ServiceMBean ServiceContext was used(Adrian advice). This form MBeans tha not implement ServiceMBean not launch a exception. Tested using jmx-console and trace logs only.
> Some managed object still are not a SMO, but it is not difficult to change this.
> Suggestions always appreciated.
--
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
[JBoss JIRA] Updated: (JBAS-2968) Allow UseJBossWebLoader to be configured per war
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2968?page=all ]
Dimitris Andreadis updated JBAS-2968:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
Assignee: Remy Maucherat
Move to a next release
> Allow UseJBossWebLoader to be configured per war
> ------------------------------------------------
>
> Key: JBAS-2968
> URL: http://jira.jboss.com/jira/browse/JBAS-2968
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service, Deployment services
> Affects Versions: JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1, JBossAS-3.2.8 Final, JBossAS-3.2.8.SP1
> Reporter: Jim Moran
> Assigned To: Remy Maucherat
> Priority: Minor
> Fix For: JBossAS-4.2.1.CR1
>
>
> Allow for wars to individually be configured to use either the Tomcat classloader or the JBoss deployment UCL.
> Provide individual wars with the semantic currently provided on a global level via UseJbossWebLoader attribute of jboss.web:service=WebServer MBean configured in deploy/jbossweb-tomcat55.sar/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
17 years, 9 months
[JBoss JIRA] Updated: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=all ]
Dimitris Andreadis updated JBAS-1283:
-------------------------------------
Fix Version/s: (was: JBossAS-4.2.0.CR1)
> Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
> ---------------------------------------------------------------------------------
>
> Key: JBAS-1283
> URL: http://jira.jboss.com/jira/browse/JBAS-1283
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service
> Affects Versions: JBossAS-3.2.6 Final
> Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04
> Reporter: Jeremy Brown
> Assigned To: Scott M Stark
> Priority: Minor
> Attachments: test.war
>
>
> See my initial forum post at "http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3861452#3861452".
> The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's "jboss-web.xml"--as per the wiki page at "http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration"--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace.
> I'll attach a .war file exhibiting this behavior to this bug report.
> Here's the specific exception for this .war file:
> java.lang.ClassCastException
> at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93)
> at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91)
> at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70)
> at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188)
> at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240)
> at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439)
> at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66)
> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158)
> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
> at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
> at java.lang.Thread.run(Thread.java:534)
> Interestingly enough, I can copy my app-specific "dom4j-full.jar" over the JBoss-provided "dom4j.jar" in "/lib", and everything works great.
--
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
[JBoss JIRA] Updated: (JBAS-2477) Exception in web-console j2ee domain after undeploy of application
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2477?page=all ]
Dimitris Andreadis updated JBAS-2477:
-------------------------------------
Fix Version/s: (was: JBossAS-4.2.0.CR1)
> Exception in web-console j2ee domain after undeploy of application
> ------------------------------------------------------------------
>
> Key: JBAS-2477
> URL: http://jira.jboss.com/jira/browse/JBAS-2477
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Console
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Both Linux and Windows
> Reporter: Lennart Petersson
> Assigned To: Darran Lofthouse
> Priority: Minor
>
> Had listed all apps in web-console j2ee domains. Then undeployed one app. Then list again in web-console ---> exception below.
> 10:31:54,896 INFO [TomcatDeployer] undeploy, ctxPath=/crimeportal, warUrl=.../tmp/deploy/tmp65013crimeportal.war/
> 10:31:54,914 INFO [EJBDeployer] Undeploying: file:/home/lenp/sources/jboss-4.0.3SP1/build/output/jboss-4.0.3SP1/server/lenp/deploy/CrimePortal.ear/CrimePortalBeans.jar
> 10:31:55,162 INFO [ProxyFactory] Unbind EJB Home 'SicilianLaundry' from jndi 'SicilianLaundry'
> 10:31:55,172 INFO [EjbModule] Undeployed SicilianLaundry
> 10:31:55,173 INFO [ProxyFactory] Unbind EJB Home 'ShanghaiLaundry' from jndi 'ShanghaiLaundry'
> 10:31:55,173 INFO [EjbModule] Undeployed ShanghaiLaundry
> 10:31:55,190 INFO [EARDeployer] Undeploying J2EE application, destroy step: file:/home/lenp/sources/jboss-4.0.3SP1/build/output/jboss-4.0.3SP1/server/lenp/deploy/CrimePortal.ear/
> 10:32:01,401 INFO [STDOUT] javax.management.InstanceNotFoundException: jboss.management.local:J2EEApplication=CrimePortal.ear,J2EEServer=Local,j2eeType=EJBModule,name=CrimePortalBeans.jar is not registered.
> 10:32:01,406 INFO [STDOUT] at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:508)
> 10:32:01,406 INFO [STDOUT] at org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:651)
> 10:32:01,410 INFO [STDOUT] at org.jboss.console.plugins.JSR77Lister.createDeployedObjects(JSR77Lister.java:167)
> 10:32:01,410 INFO [STDOUT] at org.jboss.console.plugins.JSR77Lister.createServer(JSR77Lister.java:194)
> 10:32:01,410 INFO [STDOUT] at org.jboss.console.plugins.JSR77Lister.createServers(JSR77Lister.java:218)
> 10:32:01,410 INFO [STDOUT] at org.jboss.console.plugins.JSR77Lister.createDomain(JSR77Lister.java:233)
> 10:32:01,410 INFO [STDOUT] at org.jboss.console.plugins.JSR77Lister.createDomains(JSR77Lister.java:256)
> 10:32:01,410 INFO [STDOUT] at org.jboss.console.plugins.JSR77Lister.getTreeForResource(JSR77Lister.java:282)
> 10:32:01,410 INFO [STDOUT] at org.jboss.console.plugins.helpers.AbstractPluginWrapper.getSubTreeForResource(AbstractPluginWrapper.java:201)
> 10:32:01,410 INFO [STDOUT] at org.jboss.console.manager.PluginManager.getTreesForResource(PluginManager.java:392)
> 10:32:01,410 INFO [STDOUT] at org.jboss.console.manager.PluginManager.getTreeForProfile(PluginManager.java:192)
> 10:32:01,410 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:32:01,410 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:32:01,410 INFO [STDOUT] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:32:01,411 INFO [STDOUT] at java.lang.reflect.Method.invoke(Method.java:324)
> 10:32:01,411 INFO [STDOUT] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> 10:32:01,411 INFO [STDOUT] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> 10:32:01,411 INFO [STDOUT] at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> 10:32:01,411 INFO [STDOUT] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> 10:32:01,411 INFO [STDOUT] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> 10:32:01,411 INFO [STDOUT] at org.jboss.console.remote.InvokerServlet.processRequest(InvokerServlet.java:90)
> 10:32:01,411 INFO [STDOUT] at org.jboss.console.remote.InvokerServlet.doPost(InvokerServlet.java:133)
> 10:32:01,411 INFO [STDOUT] at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 10:32:01,411 INFO [STDOUT] at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 10:32:01,411 INFO [STDOUT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 10:32:01,411 INFO [STDOUT] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 10:32:01,411 INFO [STDOUT] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 10:32:01,412 INFO [STDOUT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 10:32:01,412 INFO [STDOUT] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 10:32:01,412 INFO [STDOUT] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 10:32:01,412 INFO [STDOUT] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 10:32:01,412 INFO [STDOUT] at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 10:32:01,412 INFO [STDOUT] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
> 10:32:01,412 INFO [STDOUT] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 10:32:01,412 INFO [STDOUT] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 10:32:01,412 INFO [STDOUT] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 10:32:01,412 INFO [STDOUT] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 10:32:01,412 INFO [STDOUT] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 10:32:01,412 INFO [STDOUT] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> 10:32:01,430 INFO [STDOUT] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
> 10:32:01,430 INFO [STDOUT] at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 10:32:01,430 INFO [STDOUT] at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 10:32:01,430 INFO [STDOUT] at java.lang.Thread.run(Thread.java:534)
> 1
--
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
[JBoss JIRA] Updated: (JBAS-1082) jdbc.WrapperDataSource.getConnection is slow
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1082?page=all ]
Dimitris Andreadis updated JBAS-1082:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
Move minor issues to a next release.
> jdbc.WrapperDataSource.getConnection is slow
> --------------------------------------------
>
> Key: JBAS-1082
> URL: http://jira.jboss.com/jira/browse/JBAS-1082
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JCA service
> Affects Versions: JBossAS-3.2.6 Final
> Reporter: Elias Ross
> Assigned To: Clebert Suconic
> Priority: Minor
> Fix For: JBossAS-4.2.1.CR1
>
>
> SourceForge Submitter: genman .
> I've been profiling JMS code. When a JMS message is
> added to the server, the persistence manager locates an
> appropriate DataSource.
> Out of the time spent in
> org.jboss.mq.Connection.sendToServer, about 28% of the
> time is getting the database connection through
> jdbc.WrapperDataSource.getConnection to do its work.
> This is after the pool has been initialized, etc. (40%
> is actual persistence, though most of it is the message
> serialization.)
> I suspect a lot of the work is calculating a hashCode
> on the javax.security.auth.Subject. SubjectCriKey and
> SubjectKey should have this value cached. Ideally,
> when one is accessing the local DB, none of this auth
> stuff should have to take place. Looking at the source
> for Subject.java, the hash code is not kept.
> BaseConnectionManager2.allocateConnection %CPU=27.949
> %Time=27.963 calls=411
> Allocations I've seen:
> JBossManagedConnectionPool$SubjectActions
> is created 3284 times (for 411 getConnection calls)
> java.util.Properties (1642 times)
> (Disclaimer: This was done through JBoss profiler,
> which may or may not create real numbers. It does
> look, though, that CX is pretty slow for some operations.)
--
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
[JBoss JIRA] Updated: (JBAS-2301) Startup fails if plus sign in JBoss home path
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2301?page=all ]
Dimitris Andreadis updated JBAS-2301:
-------------------------------------
Fix Version/s: JBossAS-4.2.1.CR1
(was: JBossAS-4.2.0.CR1)
Move minor issues to a next release.
> Startup fails if plus sign in JBoss home path
> ---------------------------------------------
>
> Key: JBAS-2301
> URL: http://jira.jboss.com/jira/browse/JBAS-2301
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: System service
> Affects Versions: JBossAS-4.0.3RC2
> Environment: Linux
> Reporter: Ortwin Glück
> Priority: Minor
> Fix For: JBossAS-4.2.1.CR1
>
>
> If the JBoss home directory contains a plus sign (+) startup fails with a ClassNotFoundException. In my setup the real path contained the plus sign but I used a symlink without a plus and it still crashed. I guess this is due to missing/wrong URL encoding when you configure the URLClassLoader in the startup classes.
--
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