Created attachment 417173 [details] screenshot Description of problem: Embedded WAR as Root "/" Webapplication shown as not available for JBoss EAP 5.0.0 Version-Release number of selected component (if applicable): 3.0.0.B05 How reproducible: Make an EAR with Embedded WAR wich has set the context-root to "/" in application.xml: <context-root>/</context-root> and deploy it on JBoss EAP 5.0.0 Actual results: The "Embedded Web Application Context (Service)" is shown as down Expected results: The "Embedded Web Application Context (Service)" is shown with availibility up Additional info: We have several webapplications as Embedded WARs on our JBoss instances. All others have a "deeper" context-root and are shown as available, but not the one which we have as root-application
Jochen, are you able to provide a stripped down example of the bogus embedded war? I was trying locally with a EAP 5.0.1 instance and am not seeing the issue and want to be sure I am looking at the right thing. Thanks Heiko
I also just tried with EAP 5.0.0 and the current release-3.0.0 branch (from yesterday) and my embedded war shows availability just fine. Jochen: please provide us with a stripped down version of your ear file so we can try to reproduce it. Heiko
Jochen, if you have steps to reproduce, please re-open this bz-entry. Heiko
Hello Heiko, sorry for not responding earlier, I had a holiday..... This morning I installed 3.0.0 final and I still have the problem with our root-web-application while all other web-apps are shown as available. I'll try to provide you with a small example app, which has the same behaviour. Our "real"-app will not run in your environment (too many LDAP and database prerequisites...). Thanks, Jochen
Created attachment 430644 [details] Very Basic Root Web Application The EAR contains an embedded WAR. I deleted all EJBs and the (Struts-) web-Application logic from our original Application. It only contains one html and one JSP file. The descriptos are quite similar to the originals, I only commented out the things not needed. I checkes on an EAP 5.0.0 JBoss on Win-32 and on 64-bit Linux. The embedded-WAR itself is shown as available, but the "/home/jb/jboss-eap-5.0/jboss-as/server/production/log" and "//localhost" nodes beneath are shon as unavaiable (see also the new screenshot.
Created attachment 430645 [details] New Screenshot with "stripped" Root Webapp and RHQ 3.0.0 final This is a new screenshot which shows the issue with Version 3.0.0 final of RHQ. P.S.: See also that not all of our XQ-Datasources are recognized as available, although they are all coonfigued the same way and point to the same database (just different schemas). This problem is also there in all servers I try to monitor...(win and linux)....
Jochen, thanks for the ear file - now things start getting interesting (see screenshot). what JVM are you using? And I am also suddenly seeing an XA datasource being unavailable - could you perhaps open a new BZ ? heiko
Created attachment 430681 [details] Screenshot of my local view
Hi Heiko, hm, I don't like your screenshot very much, since it doesn't show the same result as mine;-) Here's some additional informnation. I'm using: RHQ Server on: - Windows XP 32-bit, with Sun JDK 1.6u17 Monitored JBoss EAP 5.0.0 Servers (and their RHQ Agents): - OpenSUSE 11.2 64-bit, Sun JDK 1.6u18 - Windows XP 32-bit, with Sun JDK 1.6u17 We use the "production" configuration of JBossAS and changed the settings in jboss-service.xml and EAR-Deployer to CallByValue and isolated classloading (I think this is the most significant difference to your setup). We have deployed 18 EAR files most of which have Web-Application and/or Webservice WAR files embedded. Yes, I can open a new Bug for the Datasource problem. But will will do that somewhen next week. I have some other priorities ( ;-( ) and I am not sure if always the same datasources are show as not available or if some of them are randomly shown as unavailable. You'll hear from me next week. Thanks, Jochen
Hi Jochen, By using the production configuration instead of 'default', I am now also seeing the embedded war (and actually the whole ear) as down. Switching from production back to default makes the vhost show as up again. Debug logging in the *production* instance shows this stack trace for the .ear file. The EAP5 instance is shown as up the whole time and other children of it also show as UP (like other embedded wars in a SAR). 2010-07-11 15:59:24,414 DEBUG [ResourceContainer.invoker.daemon-6] (org.rhq.plugins.jbossas5.EmbeddedManagedDeploymentComponent)- Could not get deployment state, cause: java.lang.reflect.UndeclaredThrowableException at $Proxy89.load(Unknown Source) at org.rhq.plugins.jbossas5.AbstractManagedDeploymentComponent.getManagedDeployment(AbstractManagedDeploymentComponent.java:188) at org.rhq.plugins.jbossas5.AbstractManagedDeploymentComponent.getAvailability(AbstractManagedDeploymentComponent.java:109) at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57) ... 12 more Caused by: java.lang.RuntimeException: java.lang.InterruptedException at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:823) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:167) at org.jboss.remoting.Client.invoke(Client.java:1917) at org.jboss.remoting.Client.invoke(Client.java:768) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aop.generatedproxies.AOPProxy$1.load(AOPProxy$1.java) ... 16 more Caused by: java.lang.InterruptedException at EDU.oswego.cs.dl.util.concurrent.Semaphore.attempt(Semaphore.java:120) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:1124) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:816) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:167) at org.jboss.remoting.Client.invoke(Client.java:1917) at org.jboss.remoting.Client.invoke(Client.java:768) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aop.generatedproxies.AOPProxy$1.load(AOPProxy$1.java) at sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57) at $Proxy89.load(Unknown Source) at org.rhq.plugins.jbossas5.AbstractManagedDeploymentComponent.getManagedDeployment(AbstractManagedDeploymentComponent.java:188) at org.rhq.plugins.jbossas5.AbstractManagedDeploymentComponent.getAvailability(AbstractManagedDeploymentComponent.java:109) at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
This is an issue in the underlying EAP instances See https://jira.jboss.org/browse/JBPAPP-4651
----- Forwarded Message ----- From: "Fernando Nasser" <fnasser> To: "Charles Crouch" <ccrouch>, "Mike Millson" <mmillson>, "Fernando Nasser" <fnasser> Sent: Friday, July 16, 2010 1:06:39 PM GMT -06:00 US/Canada Central Subject: Re: patch for EAP5.1 Charles Crouch wrote: > Hi Fernando > How do we go about getting a patch applied for EAP5.1? > https://jira.jboss.org/browse/JBPAPP-4651 > Mike can apply the patch the Remy provided to the JBPAPP_5_1 branch. Regards, Fernando
Moving to ON_QA this just needs to be tested with an EAP5.1 instance that has JBPAPP-4651 fixed
Currently no EAP 5.x builds exist with this fix. Will revisit closer to GA.
Installed JON 2.4 GA on Postgres 8.4 and start EAP5.1 (production configuration) The "Embedded Web Application Context (Service)" is shown with availability up. If I deploy 'portal-1.2.0.ear' the attached in comment-5 then it shows availability down. There isn't any exception/error message in server log.
Created attachment 437563 [details] screenshot
https://jira.jboss.org/browse/JBPAPP-4651 should be fixed in EAP5.1.1 so this issue should be resolved when retesting against that
Created attachment 526112 [details] verification-screenshot Result of verification
Verified with EAP 5.1.2 ER1 + JON build 11140:81e26be20d, see screenshot.
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.