Geronimo:wait-for-server is not waiting

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Geronimo:wait-for-server is not waiting

steveh
Hi,

I'm trying to automate a Geronimo deployment using v3.0.1.

I have tried starting a Geronimo server and immediately connecting using SSH. I can connect to the shell and run Geronimo:wait-for-server (interactively). However the command returns immediately even though the server is only half way through its start up.

Any help appreciated.

Steve
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo:wait-for-server is not waiting

David Jencks
Can you be more specific about what is started and what isn't?  I haven't looked at the shell command or the underlying functionality in a really long time but I think that the wait-for-server functionality was waiting for all the gbeans in all the cars mentioned in server.xml to start.  It won't wait for any apps deployed dynamically.

david jencks

On Dec 29, 2013, at 4:26 AM, Steve Higham <[hidden email]> wrote:

> Hi,
>
> I'm trying to automate a Geronimo deployment using v3.0.1.
>
> I have tried starting a Geronimo server and immediately connecting using SSH. I can connect to the shell and run Geronimo:wait-for-server (interactively). However the command returns immediately even though the server is only half way through its start up.
>
> Any help appreciated.
>
> Steve

Reply | Threaded
Open this post in threaded view
|

Re: Geronimo:wait-for-server is not waiting

steveh
In reply to this post by steveh
Hi David,

Thanks for responding - really appreciated :-)

I've downloaded the 3.0.1 source code. I'm building it with "mvn clean install". I'm running with the following commands

cd assemblies/geronimo-tomcat7-javaee6-web/target/assembly/bin
chmod a+x Geronimo
./Geronimo run

Once started I'm running Geronimo:wait-for-server. When this completes I shut down the server and look at the log file. I'm adding additional logging and fixing issues in the code as follows:

file framework/modules/geronimo-shell-base/.../WaitForServerCommand.Java

The method of interest is protected Object do execute ()

This starts with

if (is embedded ()) { return null; }

The isEmbedded () call is returning true so the method consistently returns immediately. I think this code needs deleting. I appreciate that the embedded case needs thought but an immediate return is inappropriate.

Further down we see the code

if (server != null) { started = ... }

if (!started) { Throwable error = server.getLastError (); ... }

This clearly fails when server == null. The fix is trivial.

Within the try section (in the !started loop) the problems get more interesting. connection.getDeploymentManager () is downcast to RemoteDeploymentManager. Unfortunately in my scenario the object returned is of type LocalDeploymentManager so this fails. I'm working to fix this with minimal code changes. I can clean up later. Therefore  I've started with the following:

DeploymentManager deploymentMgr = null;
try {
  connection = connect ();
  deploymentMgr = connection.getDeploymentManager ();
  if (deploymentMgr instanceof RemoteDeploymentManager) {
    ... existing solution ...
  } else if (deploymentMgr instanceof LocalDeploymentManager) {
    started = ((LocalDeploymentManager)deploymentMgr).isFullyStarted ();
  }

This looks OK, but to compile I need to add isFullyStarted () to the class LocalDeploymentManager. I've done this based on the same function in the ServerProxy class. The private utility methods have been cut and pasted over (can refactor later).

File framework/modules/geronimo-deploy-jsr88/.../LocalDeploymentManager.Java

public boolean isFullyStarted () {
  boolean fully started = true;
  // Do I need to mess about with class loaders in the Local case?
  Set<AbstractName> result = kernel.listGBeans (CONFIGURER_QUERY);
  try {
    for (AbstractName name : result) {
      boolean started = getBooleanAttribute (name, "kernelFullyStarted");
      if (!started) {
        fully started = false; break;
      }
    }
  }
  catch (IOException e) { ... }
  catch (Exception e) { ... }
  ...
}

This compiles but when I run it I'm getting a NoSuchAttributeException for attribute "kernelFullyStarted". I've traced this to a GBeanInstance:invoke call but that's as far as I've got.

Any insights very welcome as this is my first forray into the Geronimo code base.

Cheers,

Steve




David Jencks <[hidden email]> wrote:

>Can you be more specific about what is started and what isn't?  I haven't looked at the shell command or the underlying functionality in a really long time but I think that the wait-for-server functionality was waiting for all the gbeans in all the cars mentioned in server.xml to start.  It won't wait for any apps deployed dynamically.
>
>david jencks
>
>On Dec 29, 2013, at 4:26 AM, Steve Higham <[hidden email]> wrote:
>
>> Hi,
>>
>> I'm trying to automate a Geronimo deployment using v3.0.1.
>>
>> I have tried starting a Geronimo server and immediately connecting using SSH. I can connect to the shell and run Geronimo:wait-for-server (interactively). However the command returns immediately even though the server is only half way through its start up.
>>
>> Any help appreciated.
>>
>> Steve
>
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo:wait-for-server is not waiting

steveh
In reply to this post by steveh
Hi David,

I've got the code running for a LocalDeploymentManager and I'm querying for GBeans using kernel.listGBeans (CONFIGURER_QUERY). However only 2 beans are being returned. One has the attribute kernelFullyStarted. The other doesn't have this attribute. I was expecting more GBeans. Any idea what I'm doing wrong?

Cheers,

Steve

Steve Higham <[hidden email]> wrote:

>Hi David,
>
>Thanks for responding - really appreciated :-)
>
>I've downloaded the 3.0.1 source code. I'm building it with "mvn clean install". I'm running with the following commands
>
>cd assemblies/geronimo-tomcat7-javaee6-web/target/assembly/bin
>chmod a+x Geronimo
>./Geronimo run
>
>Once started I'm running Geronimo:wait-for-server. When this completes I shut down the server and look at the log file. I'm adding additional logging and fixing issues in the code as follows:
>
>file framework/modules/geronimo-shell-base/.../WaitForServerCommand.Java
>
>The method of interest is protected Object do execute ()
>
>This starts with
>
>if (is embedded ()) { return null; }
>
>The isEmbedded () call is returning true so the method consistently returns immediately. I think this code needs deleting. I appreciate that the embedded case needs thought but an immediate return is inappropriate.
>
>Further down we see the code
>
>if (server != null) { started = ... }
>
>if (!started) { Throwable error = server.getLastError (); ... }
>
>This clearly fails when server == null. The fix is trivial.
>
>Within the try section (in the !started loop) the problems get more interesting. connection.getDeploymentManager () is downcast to RemoteDeploymentManager. Unfortunately in my scenario the object returned is of type LocalDeploymentManager so this fails. I'm working to fix this with minimal code changes. I can clean up later. Therefore  I've started with the following:
>
>DeploymentManager deploymentMgr = null;
>try {
>  connection = connect ();
>  deploymentMgr = connection.getDeploymentManager ();
>  if (deploymentMgr instanceof RemoteDeploymentManager) {
>    ... existing solution ...
>  } else if (deploymentMgr instanceof LocalDeploymentManager) {
>    started = ((LocalDeploymentManager)deploymentMgr).isFullyStarted ();
>  }
>
>This looks OK, but to compile I need to add isFullyStarted () to the class LocalDeploymentManager. I've done this based on the same function in the ServerProxy class. The private utility methods have been cut and pasted over (can refactor later).
>
>File framework/modules/geronimo-deploy-jsr88/.../LocalDeploymentManager.Java
>
>public boolean isFullyStarted () {
>  boolean fully started = true;
>  // Do I need to mess about with class loaders in the Local case?
>  Set<AbstractName> result = kernel.listGBeans (CONFIGURER_QUERY);
>  try {
>    for (AbstractName name : result) {
>      boolean started = getBooleanAttribute (name, "kernelFullyStarted");
>      if (!started) {
>        fully started = false; break;
>      }
>    }
>  }
>  catch (IOException e) { ... }
>  catch (Exception e) { ... }
>  ...
>}
>
>This compiles but when I run it I'm getting a NoSuchAttributeException for attribute "kernelFullyStarted". I've traced this to a GBeanInstance:invoke call but that's as far as I've got.
>
>Any insights very welcome as this is my first forray into the Geronimo code base.
>
>Cheers,
>
>Steve
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo:wait-for-server is not waiting

steveh
In reply to this post by steveh
Hi David,

I think I`ve got this working now. I`m generating my list of GBeans as follows:

AbsractNameQuery query = new AbsractNameQuery (PersistentConfigurationList.class.getName ());
Set<AbstractName> result = kernel.listGBeans (query);

This generates a list of one GBean. However it has the kernelFullyStarted attribute and the state does seem to be an indicator of whether the server has completed start-up.

Should I clean this up and submit as a patch? I`m not really sure what`s going on here but it seems to be working.

Cheers,

Steve

Steve Higham <[hidden email]> wrote:

>Hi David,
>
>I've got the code running for a LocalDeploymentManager and I'm querying for GBeans using kernel.listGBeans (CONFIGURER_QUERY). However only 2 beans are being returned. One has the attribute kernelFullyStarted. The other doesn't have this attribute. I was expecting more GBeans. Any idea what I'm doing wrong?
>
>Cheers,
>
>Steve
>
>Steve Higham <[hidden email]> wrote:
>
>>Hi David,
>>
>>Thanks for responding - really appreciated :-)
>>
>>I've downloaded the 3.0.1 source code. I'm building it with "mvn clean install". I'm running with the following commands
>>
>>cd assemblies/geronimo-tomcat7-javaee6-web/target/assembly/bin
>>chmod a+x Geronimo
>>./Geronimo run
>>
>>Once started I'm running Geronimo:wait-for-server. When this completes I shut down the server and look at the log file. I'm adding additional logging and fixing issues in the code as follows:
>>
>>file framework/modules/geronimo-shell-base/.../WaitForServerCommand.Java
>>
>>The method of interest is protected Object do execute ()
>>
>>This starts with
>>
>>if (is embedded ()) { return null; }
>>
>>The isEmbedded () call is returning true so the method consistently returns immediately. I think this code needs deleting. I appreciate that the embedded case needs thought but an immediate return is inappropriate.
>>
>>Further down we see the code
>>
>>if (server != null) { started = ... }
>>
>>if (!started) { Throwable error = server.getLastError (); ... }
>>
>>This clearly fails when server == null. The fix is trivial.
>>
>>Within the try section (in the !started loop) the problems get more interesting. connection.getDeploymentManager () is downcast to RemoteDeploymentManager. Unfortunately in my scenario the object returned is of type LocalDeploymentManager so this fails. I'm working to fix this with minimal code changes. I can clean up later. Therefore  I've started with the following:
>>
>>DeploymentManager deploymentMgr = null;
>>try {
>>  connection = connect ();
>>  deploymentMgr = connection.getDeploymentManager ();
>>  if (deploymentMgr instanceof RemoteDeploymentManager) {
>>    ... existing solution ...
>>  } else if (deploymentMgr instanceof LocalDeploymentManager) {
>>    started = ((LocalDeploymentManager)deploymentMgr).isFullyStarted ();
>>  }
>>
>>This looks OK, but to compile I need to add isFullyStarted () to the class LocalDeploymentManager. I've done this based on the same function in the ServerProxy class. The private utility methods have been cut and pasted over (can refactor later).
>>
>>File framework/modules/geronimo-deploy-jsr88/.../LocalDeploymentManager.Java
>>
>>public boolean isFullyStarted () {
>>  boolean fully started = true;
>>  // Do I need to mess about with class loaders in the Local case?
>>  Set<AbstractName> result = kernel.listGBeans (CONFIGURER_QUERY);
>>  try {
>>    for (AbstractName name : result) {
>>      boolean started = getBooleanAttribute (name, "kernelFullyStarted");
>>      if (!started) {
>>        fully started = false; break;
>>      }
>>    }
>>  }
>>  catch (IOException e) { ... }
>>  catch (Exception e) { ... }
>>  ...
>>}
>>
>>This compiles but when I run it I'm getting a NoSuchAttributeException for attribute "kernelFullyStarted". I've traced this to a GBeanInstance:invoke call but that's as far as I've got.
>>
>>Any insights very welcome as this is my first forray into the Geronimo code base.
>>
>>Cheers,
>>
>>Steve
>>
>>
Reply | Threaded
Open this post in threaded view
|

[Geronimo 3.0.1 + MyFaces Trinidad] Only HttpServletRequest supported exception

eduardogt
In reply to this post by David Jencks
Hello buddies, I have 3 years doing some development using Geronimo + MyFaces + Trinidad.  Due some requirements I had to migrate a pair of apps from 3.0 to 3.0.1, and now I have the following problem:

Everytime I upload an application (WAR or WAB) via eclipse or uploading page from console, and try to use the application, I get the following error:

********************************************************************
Only HttpServletRequest supported

viewId=/index.xhtml
location=/home/eduardo/Desarrollo/Servers/geronimo-3.0.1/repository/application/bse.app/1.0.0-alpha/bse.app-1.0.0-alpha.eba/bse.web_1.0.0.alpha.jar/index.xhtml
phaseId=RENDER_RESPONSE(6)

Caused by:
java.lang.UnsupportedOperationException - Only HttpServletRequest supported
at org.apache.myfaces.context.servlet.ServletExternalContextImpl.checkHttpServletRequest(ServletExternalContextImpl.java:646)

********************************************************************

This error can be cleared only if I restart the Geronimo Application Server, and everything in the program start working OK.  Just restarting the application don't make any difference.  This only happens with web applications.

My configuration is:

- Geronimo 3.0.1
- MyFaces 2.1
- Trinidad 2.1 SNAPSHOT (There is no official release for Myfaces 2.1)

Thanks in advance,


Eduardo García


P.D.  The stack trace shows the following:

java.lang.UnsupportedOperationException: Only HttpServletRequest supported
	at org.apache.myfaces.context.servlet.ServletExternalContextImpl.checkHttpServletRequest(ServletExternalContextImpl.java:646)
	at org.apache.myfaces.context.servlet.ServletExternalContextImpl.encodeResourceURL(ServletExternalContextImpl.java:330)
	at org.apache.myfaces.trinidad.util.ExternalContextURLEncoder.encodeResourceURL(ExternalContextURLEncoder.java:79)
	at org.apache.myfaces.trinidadinternal.config.URLEncoderExternalContext.encodeResourceURL(URLEncoderExternalContext.java:119)
	at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:104)
	at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:104)
	at org.apache.myfaces.trinidad.render.CoreRenderer.renderEncodedResourceURI(CoreRenderer.java:1103)
	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.StyleSheetRenderer.encodeAll(StyleSheetRenderer.java:128)
	at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:679)
	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.HeadRenderer.encodeEnd(HeadRenderer.java:97)
	at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRendererEnd(CoreRenderer.java:719)
	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:108)
	at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:525)
	at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:1217)
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:792)
	at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
	at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
	at org.apache.myfaces.trinidad.view.ViewDeclarationLanguageWrapper.renderView(ViewDeclarationLanguageWrapper.java:101)
	at org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.renderView(ViewDeclarationLanguageFactoryImpl.java:338)
	at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
	at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:170)
	at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
	at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:731)
	at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:48)
	at org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(ProtectedTargetValve.java:53)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:947)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1009)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
	at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:267)
	at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:397)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)

Reply | Threaded
Open this post in threaded view
|

Re: [Geronimo 3.0.1 + MyFaces Trinidad] Only HttpServletRequest supported exception

David Jencks
Everything I say is pure speculation, and I don't know how to fix this.  

Geronimo includes MyFaces for jsf support.  I would guess that when you get the error your app has wired to the myfaces copy included in geronimo that probably doesn't work with trinidad 2.1, and for some reason when you restart the whole server your app wires to the myfaces 2.1 copy you have  deployed.

How are you deploying your app?  I think there's a way, in your geronimo-specific deployment plan, to exclude imports of various packages.  If you exclude all the javax.faces classes that might force your app to wire to the included myfaces copy.

sorry I can't be of more help
david jencks
  
On May 17, 2014, at 10:37 PM, Eduardo Garcia <[hidden email]> wrote:

Hello buddies, I have 3 years doing some development using Geronimo + MyFaces + Trinidad.  Due some requirements I had to migrate a pair of apps from 3.0 to 3.0.1, and now I have the following problem:

Everytime I upload an application (WAR or WAB) via eclipse or uploading page from console, and try to use the application, I get the following error:

********************************************************************
Only HttpServletRequest supported

viewId=/index.xhtml
location=/home/eduardo/Desarrollo/Servers/geronimo-3.0.1/repository/application/bse.app/1.0.0-alpha/bse.app-1.0.0-alpha.eba/bse.web_1.0.0.alpha.jar/index.xhtml
phaseId=RENDER_RESPONSE(6)

Caused by:
java.lang.UnsupportedOperationException - Only HttpServletRequest supported
at org.apache.myfaces.context.servlet.ServletExternalContextImpl.checkHttpServletRequest(ServletExternalContextImpl.java:646)

********************************************************************

This error can be cleared only if I restart the Geronimo Application Server, and everything in the program start working OK.  Just restarting the application don't make any difference.  This only happens with web applications.

My configuration is:

- Geronimo 3.0.1
- MyFaces 2.1
- Trinidad 2.1 SNAPSHOT (There is no official release for Myfaces 2.1)

Thanks in advance,


Eduardo GarcĂ­a


P.D.  The stack trace shows the following:

java.lang.UnsupportedOperationException: Only HttpServletRequest supported
	at org.apache.myfaces.context.servlet.ServletExternalContextImpl.checkHttpServletRequest(ServletExternalContextImpl.java:646)
	at org.apache.myfaces.context.servlet.ServletExternalContextImpl.encodeResourceURL(ServletExternalContextImpl.java:330)
	at org.apache.myfaces.trinidad.util.ExternalContextURLEncoder.encodeResourceURL(ExternalContextURLEncoder.java:79)
	at org.apache.myfaces.trinidadinternal.config.URLEncoderExternalContext.encodeResourceURL(URLEncoderExternalContext.java:119)
	at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:104)
	at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:104)
	at org.apache.myfaces.trinidad.render.CoreRenderer.renderEncodedResourceURI(CoreRenderer.java:1103)
	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.StyleSheetRenderer.encodeAll(StyleSheetRenderer.java:128)
	at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:679)
	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.HeadRenderer.encodeEnd(HeadRenderer.java:97)
	at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRendererEnd(CoreRenderer.java:719)
	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:108)
	at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:525)
	at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:1217)
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:792)
	at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
	at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
	at org.apache.myfaces.trinidad.view.ViewDeclarationLanguageWrapper.renderView(ViewDeclarationLanguageWrapper.java:101)
	at org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.renderView(ViewDeclarationLanguageFactoryImpl.java:338)
	at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
	at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:170)
	at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
	at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:731)
	at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:48)
	at org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(ProtectedTargetValve.java:53)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:947)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1009)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
	at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:267)
	at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:397)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)


Reply | Threaded
Open this post in threaded view
|

Re: [Geronimo 3.0.1 + MyFaces Trinidad] Only HttpServletRequest supported exception

eduardogt
Actually, I try not shipping any jar within the application.  I just use references to MyFaces library within the geronimo-web.xml file (case WAR), and in MANIFEST.MF (case WAB).  Trinidad 2.1 was previously installed via Geronimo Console, and referenced the same way.

I think something goes wrong during the deployment, that produce this error, otherwise why in the restart the applications start working normally.  


Eduardo.


On 05/18/2014 10:43 AM, David Jencks wrote:
Everything I say is pure speculation, and I don't know how to fix this.  

Geronimo includes MyFaces for jsf support.  I would guess that when you get the error your app has wired to the myfaces copy included in geronimo that probably doesn't work with trinidad 2.1, and for some reason when you restart the whole server your app wires to the myfaces 2.1 copy you have  deployed.

How are you deploying your app?  I think there's a way, in your geronimo-specific deployment plan, to exclude imports of various packages.  If you exclude all the javax.faces classes that might force your app to wire to the included myfaces copy.

sorry I can't be of more help
david jencks
  
On May 17, 2014, at 10:37 PM, Eduardo Garcia <[hidden email]> wrote:

Hello buddies, I have 3 years doing some development using Geronimo + MyFaces + Trinidad.  Due some requirements I had to migrate a pair of apps from 3.0 to 3.0.1, and now I have the following problem:

Everytime I upload an application (WAR or WAB) via eclipse or uploading page from console, and try to use the application, I get the following error:

********************************************************************
Only HttpServletRequest supported

viewId=/index.xhtml
location=/home/eduardo/Desarrollo/Servers/geronimo-3.0.1/repository/application/bse.app/1.0.0-alpha/bse.app-1.0.0-alpha.eba/bse.web_1.0.0.alpha.jar/index.xhtml
phaseId=RENDER_RESPONSE(6)

Caused by:
java.lang.UnsupportedOperationException - Only HttpServletRequest supported
at org.apache.myfaces.context.servlet.ServletExternalContextImpl.checkHttpServletRequest(ServletExternalContextImpl.java:646)

********************************************************************

This error can be cleared only if I restart the Geronimo Application Server, and everything in the program start working OK.  Just restarting the application don't make any difference.  This only happens with web applications.

My configuration is:

- Geronimo 3.0.1
- MyFaces 2.1
- Trinidad 2.1 SNAPSHOT (There is no official release for Myfaces 2.1)

Thanks in advance,


Eduardo García


P.D.  The stack trace shows the following:

java.lang.UnsupportedOperationException: Only HttpServletRequest supported
	at org.apache.myfaces.context.servlet.ServletExternalContextImpl.checkHttpServletRequest(ServletExternalContextImpl.java:646)
	at org.apache.myfaces.context.servlet.ServletExternalContextImpl.encodeResourceURL(ServletExternalContextImpl.java:330)
	at org.apache.myfaces.trinidad.util.ExternalContextURLEncoder.encodeResourceURL(ExternalContextURLEncoder.java:79)
	at org.apache.myfaces.trinidadinternal.config.URLEncoderExternalContext.encodeResourceURL(URLEncoderExternalContext.java:119)
	at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:104)
	at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:104)
	at org.apache.myfaces.trinidad.render.CoreRenderer.renderEncodedResourceURI(CoreRenderer.java:1103)
	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.StyleSheetRenderer.encodeAll(StyleSheetRenderer.java:128)
	at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:679)
	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.HeadRenderer.encodeEnd(HeadRenderer.java:97)
	at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRendererEnd(CoreRenderer.java:719)
	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:108)
	at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:525)
	at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:1217)
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:792)
	at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
	at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
	at org.apache.myfaces.trinidad.view.ViewDeclarationLanguageWrapper.renderView(ViewDeclarationLanguageWrapper.java:101)
	at org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.renderView(ViewDeclarationLanguageFactoryImpl.java:338)
	at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
	at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:170)
	at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
	at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:731)
	at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:48)
	at org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(ProtectedTargetValve.java:53)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:947)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1009)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
	at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:267)
	at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:397)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)