[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2911) GWT-RPC fails with java.lang.SecurityException
by Rainer Schuster (JIRA)
GWT-RPC fails with java.lang.SecurityException
----------------------------------------------
Key: JBSEAM-2911
URL: http://jira.jboss.com/jira/browse/JBSEAM-2911
Project: Seam
Issue Type: Bug
Components: GWT, Remoting
Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA, 2.0.1.CR2, 2.0.1.CR1, 2.0.0.GA, 2.0.0.CR3, 2.0.0.CR2, 2.0.0.CR1, 2.0.0.BETA1
Environment: WinXP Pro SP 2, Maven 2.0.9, GWT 1.5 Milestone 2, Seam 2.1 Revision 7916
Reporter: Rainer Schuster
After http://jira.jboss.org/jira/browse/JBSEAM-2880 was fixed a new problem appeared:
2008-04-13 16:19:14,839 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/ASDF]] Exception while dispatching incoming RPC call
java.lang.SecurityException: Unable to access a service method called [myservice] on class [com.myproject.asdf.server.MyServiceX] without the @WebRemote attribute. This may be a hack attempt, or someone simply neglected to use the @WebRemote attribute to indicate a method as remotely accessible.
at org.jboss.seam.remoting.gwt.GWTToSeamAdapter.getMethod(GWTToSeamAdapter.java:128)
at org.jboss.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:98)
at org.jboss.seam.remoting.gwt.GWTService.processCall(GWTService.java:246)
at org.jboss.seam.remoting.gwt.GWTService$1.process(GWTService.java:146)
at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:53)
at org.jboss.seam.remoting.gwt.GWTService.getResource(GWTService.java:130)
at org.jboss.seam.servlet.SeamResourceServlet.doGet(SeamResourceServlet.java:75)
at org.jboss.seam.servlet.SeamResourceServlet.doPost(SeamResourceServlet.java:92)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:73)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:595)
This error seams to occur independent of the content-type problem (http://jira.jboss.org/jira/browse/JBSEAM-2880), because it also occurs with older versions of GWT.
--
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
13 years, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1250) Socket write error with Seam JMS Remoting
by Scott McNab (JIRA)
Socket write error with Seam JMS Remoting
-----------------------------------------
Key: JBSEAM-1250
URL: http://jira.jboss.com/jira/browse/JBSEAM-1250
Project: JBoss Seam
Issue Type: Bug
Components: Remoting
Affects Versions: 1.2.1.GA, 1.2.0.GA
Environment: WindowsXP, JBossAS 4.2.0.CR1
Reporter: Scott McNab
Assigned To: Shane Bryzak
Full details are given in the corresponding forum topic, however a summary is:
* Client-side javascript subscribes to a JMS topic by calling Seam.Remoting.subscribe().
* The client then navigates to a new page.
* Approximately 30 seconds later, a SocketException (socket write error) occurs on the server within Seam Remoting (presumably because my Seam poll-timeout is set to 30 seconds).
This occurs consistently with JBoss running under Windows, but does not seem to occur when the server is run on Linux. It is also not affected by browser type (i.e. it happens when using Firefox or IE). This bug did not occur previously when the same code was running with Seam 1.0.1.GA.
--
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
13 years, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2935) Seam Remoting/GWT1.5M2, change to 'Long' behavior (impacts Date?)
by darren hartford (JIRA)
Seam Remoting/GWT1.5M2, change to 'Long' behavior (impacts Date?)
-----------------------------------------------------------------
Key: JBSEAM-2935
URL: http://jira.jboss.com/jira/browse/JBSEAM-2935
Project: Seam
Issue Type: Bug
Components: GWT
Affects Versions: 2.1.x
Reporter: darren hartford
From: 1.5M2 announcement post -- http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thr...
" - "long" emulation. The Java language defines "long" types to be 64-bit
signed integers, whereas JavaScript only supports 64-bit floating point
numbers, which cannot accurately represent the same whole-number range as a
true "long" type. GWT 1.5 M2 transparently emulates long types properly to
more faithfully maintain Java semantics in web mode. "
Although this is from GWT 1.5M2, the risk/return of them changing this is unlikely. It appears that this also impacts Dates.
This has been tested against Seam 2.1-snapshot (4/25/2008) and GWT 1.5M2 on jboss 4.2. Other datatypes are working correctly, Long and Dates are not. This seems to only impact the RPC mechanism.
symptoms (on client side) for Long. Same symptoms for java.util.Date:
==============
getLong had a failure: com.google.gwt.core.client.JavaScriptException: (TypeError): orig has no properties
message: orig has no properties
fileName: http://dhartford:8080/sample-ejb3-gwt-client/com.domain.app.gwt.SeamEjbRe...
lineNumber: 7172
stack: java_lang_Long_parseLong__Ljava_lang_String_2I(undefined,16)@http://dhartford:8080/sample-ejb3-gwt-client/com.domain.app.gwt.SeamEjbRemote/0838C54E584391EEA8D10F2AD23CB3D5.cache.html:7172
com_google_gwt_user_client_rpc_core_java_lang_Long_1CustomFieldSerializer_instantiate__Lcom_google_gwt_user_client_rpc_SerializationStreamReader_2([object Object])@http://dhartford:8080/sample-ejb3-gwt-client/com.domain.app.gwt.SeamEjbRemote/0838C54E584391EEA8D10F2AD23CB3D5.cache.html:4258
com_domain_app_gwt_client_SeamGwtStandardDataService_1TypeSerializer_instantiate__Lcom_google_gwt_user_client_rpc_SerializationStreamReader_2Ljava_lang_String_2([object Object],"java.lang.Long/4227064769")@http://dhartford:8080/sample-ejb3-gwt-client/com.domain.app.gwt.SeamEjbRemote/0838C54E584391EEA8D10F2AD23CB3D5.cache.html:2102
--
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
13 years, 5 months
[JBoss JIRA] Created: (JBSEAM-4800) s:link does not work on failover in a clustered environment
by Samuel Mendenhall (JIRA)
s:link does not work on failover in a clustered environment
-----------------------------------------------------------
Key: JBSEAM-4800
URL: https://issues.jboss.org/browse/JBSEAM-4800
Project: Seam 2
Issue Type: Bug
Components: JSF Integration
Affects Versions: 2.2.1.Final
Environment: EAP 5.1
Seam 2.2.2.EAP5
Reporter: Samuel Mendenhall
Fix For: 2.3.0.BETA1
When clicking on an s:link after a node has been taken down, the exception below is thrown.
Method of reproducing:
* Two EAP 5.1 nodes fronted with mod_jk. No firewall, sticky sessions + session replication definitely enabled.
* JBDS Seam generated ear + a simple @Clustered EJB3 which has a method that takes a parameter and prints the EL parametrized text (I don't think EL parametrization is relevant here)
* Click on the s:link on the page, it invokes fine, go back in the browser. Shutdown the active JBoss instance. Click the s:link again which is redirected to the 2nd JBoss now and receive:
14:17:42,995 ERROR [Exceptions] handled and logged exception
java.lang.IllegalStateException: Unable to read view /home.xhtml to execute action "#{someComponent.printText('Hello World')}"
at org.jboss.seam.navigation.SafeActions.isActionSafe(SafeActions.java:67)
at org.jboss.seam.navigation.Pages.callAction(Pages.java:699)
at org.jboss.seam.navigation.Pages.preRender(Pages.java:331)
at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:561)
at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:472)
at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:148)
at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:118)
SafeActions.java:67 isn't so telling:
===================
String viewId = id.substring(0, loc);
String action = "\"#{" + id.substring(loc+1) + "}\"";
InputStream is = FacesContext.getCurrentInstance().getExternalContext().getResourceAsStream(viewId);
if (is==null) throw new IllegalStateException("Unable to read view " + "/" + viewId + " to execute action " + action);
===================
The code says the InputStream is null on failover, so the getResourceAsStream(viewId) failed to return anything.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months