Bug 596680 - Embedded WAR as Root "/" Webapplication shown as not available
Summary: Embedded WAR as Root "/" Webapplication shown as not available
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Monitoring
Version: 3.0.0
Hardware: x86_64
OS: Linux
urgent
medium
Target Milestone: ---
: ---
Assignee: Jan Martiska
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: jon-sprint11-bugs jon30-bugs jon3-sprint1 715334
TreeView+ depends on / blocked
 
Reported: 2010-05-27 10:00 UTC by Jochen Riedlinger
Modified: 2013-09-02 07:27 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-02 07:27:27 UTC
Embargoed:


Attachments (Terms of Use)
screenshot (3.98 KB, image/gif)
2010-05-27 10:00 UTC, Jochen Riedlinger
no flags Details
Very Basic Root Web Application (52.62 KB, application/octet-stream)
2010-07-09 11:37 UTC, Jochen Riedlinger
no flags Details
New Screenshot with "stripped" Root Webapp and RHQ 3.0.0 final (18.98 KB, image/gif)
2010-07-09 11:44 UTC, Jochen Riedlinger
no flags Details
Screenshot of my local view (12.05 KB, image/png)
2010-07-09 13:35 UTC, Heiko W. Rupp
no flags Details
screenshot (155.27 KB, image/png)
2010-08-09 10:08 UTC, Rajan Timaniya
no flags Details
verification-screenshot (57.18 KB, image/png)
2011-10-03 19:16 UTC, Jan Martiska
no flags Details

Description Jochen Riedlinger 2010-05-27 10:00:39 UTC
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

Comment 1 Heiko W. Rupp 2010-06-17 10:14:41 UTC
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

Comment 2 Heiko W. Rupp 2010-06-17 12:20:18 UTC
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

Comment 3 Heiko W. Rupp 2010-07-07 14:22:14 UTC
Jochen,
if you have steps to reproduce, please re-open this bz-entry.

  Heiko

Comment 4 Jochen Riedlinger 2010-07-09 09:53:16 UTC
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

Comment 5 Jochen Riedlinger 2010-07-09 11:37:38 UTC
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.

Comment 6 Jochen Riedlinger 2010-07-09 11:44:29 UTC
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)....

Comment 7 Heiko W. Rupp 2010-07-09 13:34:53 UTC
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

Comment 8 Heiko W. Rupp 2010-07-09 13:35:43 UTC
Created attachment 430681 [details]
Screenshot of my local view

Comment 9 Jochen Riedlinger 2010-07-09 14:24:50 UTC
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

Comment 10 Heiko W. Rupp 2010-07-11 18:09:47 UTC
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)

Comment 11 Heiko W. Rupp 2010-07-14 15:36:32 UTC
This is an issue in the underlying EAP instances
See https://jira.jboss.org/browse/JBPAPP-4651

Comment 12 Charles Crouch 2010-07-16 18:11:10 UTC
----- 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

Comment 13 Charles Crouch 2010-07-16 18:12:03 UTC
Moving to ON_QA this just needs to be tested with an EAP5.1 instance that has JBPAPP-4651 fixed

Comment 14 Corey Welton 2010-07-19 23:56:18 UTC
Currently no EAP 5.x builds exist with this fix.  Will revisit closer to GA.

Comment 15 Rajan Timaniya 2010-08-09 10:06:48 UTC
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.

Comment 16 Rajan Timaniya 2010-08-09 10:08:05 UTC
Created attachment 437563 [details]
screenshot

Comment 17 Charles Crouch 2011-09-27 13:04:57 UTC
https://jira.jboss.org/browse/JBPAPP-4651 should be fixed in EAP5.1.1 so this 
issue should be resolved when retesting against that

Comment 18 Jan Martiska 2011-10-03 19:16:47 UTC
Created attachment 526112 [details]
verification-screenshot

Result of verification

Comment 19 Jan Martiska 2011-10-03 19:18:00 UTC
Verified with EAP 5.1.2 ER1 + JON build 11140:81e26be20d, see screenshot.

Comment 20 Heiko W. Rupp 2013-09-02 07:27:27 UTC
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.


Note You need to log in before you can comment on or make changes to this bug.