[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-944) Parallel root conversations with dynamic conversation entries
by Christian Bauer (JIRA)
Parallel root conversations with dynamic conversation entries
-------------------------------------------------------------
Key: JBSEAM-944
URL: http://jira.jboss.com/jira/browse/JBSEAM-944
Project: JBoss Seam
Issue Type: Feature Request
Components: Core
Reporter: Christian Bauer
Priority: Minor
The use case here is two navigation links are visible on all pages and they are supposed to start new root conversations whenever they are clicked (not nest, not join). Navigation via conversation list/switcher.
<s:link action="doFoo" propagation="none"/>
<s:link action="doBar" propagation="none"/>
Mapping:
<page view-id="/mypage.xhtml">
<rule if-outcome="foo">
<begin-conversation flush-mode="MANUAL"/>
<redirect view-id="/fooConversation.xhtml"/>
</rule>
<rule if-outcome="bar">
<begin-conversation flush-mode="MANUAL"/>
<redirect view-id="/barConversation.xhtml"/>
</rule>
<page>
<page view-id="/fooConversation.xhtml">
My Name is #{fooBackingBean.name}
</page>
<page view-id="/barConversation.xhtml">
My Name is #{barBackingBean.name}
</page>
The issue is how page descriptions in conversation entries are stored, in the SeamPhaseListener after RENDER RESPONSE.
Sequence:
1. Call /mypage.xhtml and click on 'foo', a conversation is created and /fooConversation.xhtml is rendered
2. Click on 'doBar', a request is send to /fooConversation.xhtml?actionOutcome=doBar - no conversation is propagated
3. The navigation rule kicks in and does the redirect, before that happens, AFTER RENDER RESPONSE is executed and the prepareBackswitch() stores the conversation entries, /barConversation.xhtml is rendered
4. Click on 'doFoo', a request is send to /barConversation.xhtml?actionOutcome=doFoo - no conversation is propagated
5. The navigation rule kicks in and does the redirect, before that happens, AFTER RENDER RESPONSE is executed and the prepareBackswitch() stores the conversation entries, I GET EXCEPTIONS in the log because "My name is #{fooBackingBean.name}' triggers create() of fooBackingBean which can't be created without the right request parameters - the interesting part is that I still get the name from somewhere, I see it in the conversation switcher
So this could either be a bug (because visually it's working, I see the correct conversation description in the switcher UI) that involves resolving of view-id descriptions or I need a different approach to get new root conversations in parallel on every click.
--
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
19 years
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-777) Subsequent Remoting-Calls loose conversation-context.
by Stefan Frank (JIRA)
Subsequent Remoting-Calls loose conversation-context.
-----------------------------------------------------
Key: JBSEAM-777
URL: http://jira.jboss.com/jira/browse/JBSEAM-777
Project: JBoss Seam
Issue Type: Bug
Components: Remoting
Affects Versions: 1.1.5.GA
Environment: jboss-4.0.4.GA, WinXP, jdk1.5.0_06
Reporter: Stefan Frank
Subsequent calls to a StatefulSessionBean which has methodes exposed via @WebRemote loose their conversation-context.
The Scenario:
User loads Page with a Multiple-Choice-Test. All questions are fetched from the server, each question is setup via javascript on the client. Each answer is sent to the server. At the end of the test, we redirect to a page to display the test-results.
We try to implement this using:
- Seam.Remoting to make up the Connection
- Javascript to setup the questions
- A stateful session Bean to hold the test and the results.
- A conversation to demarcate start and end of the test.
The problem is, that the remoting does not reconnect to the SSB, but instead starts new SSB's. Here is a rough sketch of the code:
@Stateful
@Name ("examManager")
@Scope(ScopeType.SESSION)
public class ExamManagerBean implements ExamManager {
@Begin
public Test startTest(int testId) {
....
}
public void sendAnswer(int questionId, int answerId){
....
}
@End
public String getResults(){
...;
}
}
the javascript:
var remoteManager = Seam.Component.getInstance("examManager");
remoteManager.startTest(id, testLoaded)
function testLoaded(test){
setupNextQuestion(test);
....
}
function evaluateAnswer(){
remoteManager.sendAnswer(test.questions[questionIdx].id, answerId, answerCallback);
....
}
The Test is fetched correctly and the first two calls to remoteManager.sendAnswer go to the same SSB with which the Test was started, the third call triggers the create of a new SSB and fails becaus the startTest() was never called and therefore the test not initialized.
It appears, that conversation-context is lost and a new Conversation started. Calls to Seam.Remoting.getContext().getConversationId() confirm, that the Conversation-Context is still correct in the client.
--
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
19 years
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-835) After Upload the Conversation id seems to be lost when use a button to move forward from the "upload" screen.
by Tony Herstell (JIRA)
After Upload the Conversation id seems to be lost when use a button to move forward from the "upload" screen.
-------------------------------------------------------------------------------------------------------------
Key: JBSEAM-835
URL: http://jira.jboss.com/jira/browse/JBSEAM-835
Project: JBoss Seam
Issue Type: Bug
Components: ICE Faces Integration
Affects Versions: 1.1.6.GA
Reporter: Tony Herstell
Assigned To: Gregory Dick
11:13:27,070 ERROR [[Blocking Servlet]] Servlet.service() for servlet Blocking Servlet threw exception
javax.faces.FacesException: Error calling action method of component with id _id62:done
at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:74)
at javax.faces.component.UICommand.broadcast(UICommand.java:106)
at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:94)
at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:136)
at org.apache.myfaces.lifecycle.LifecycleImpl.applyRequestValues(LifecycleImpl.java:219)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:71)
at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.renderCycle(BlockingServlet.java:456)
at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.receiveUpdates(BlockingServlet.java:444)
at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.executeRequest(BlockingServlet.java:324)
at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.service(BlockingServlet.java:186)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.faces.el.EvaluationException: /upload.xhtml @61,49 action="#{uploadController.done}": javax.ejb.EJBException: java.lang.IllegalStateException: no long-running conversation for @Conversational bean: uploadController
at com.sun.facelets.el.LegacyMethodBinding.invoke(LegacyMethodBinding.java:73)
at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:63)
... 29 more
Caused by: javax.ejb.EJBException: java.lang.IllegalStateException: no long-running conversation for @Conversational bean: uploadController
at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateful.StatefulInstanceInterceptor.invoke(StatefulInstanceInterceptor.java:83)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateful.StatefulContainer.localInvoke(StatefulContainer.java:203)
at org.jboss.ejb3.stateful.StatefulLocalProxy.invoke(StatefulLocalProxy.java:98)
at $Proxy129.done(Unknown Source)
at nz.co.risingstars.actions.upload.UploadController$$FastClassByCGLIB$$cd1d79c6.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
at org.jboss.seam.intercept.ClientSideInterceptor$1.proceed(ClientSideInterceptor.java:74)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:55)
at org.jboss.seam.interceptors.RemoveInterceptor.removeIfNecessary(RemoveInterceptor.java:40)
at sun.reflect.GeneratedMethodAccessor181.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:18)
at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:169)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:64)
at org.jboss.seam.intercept.RootInterceptor.createSeamInvocationContext(RootInterceptor.java:144)
at org.jboss.seam.intercept.RootInterceptor.invokeInContexts(RootInterceptor.java:129)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:102)
at org.jboss.seam.intercept.ClientSideInterceptor.interceptInvocation(ClientSideInterceptor.java:83)
at org.jboss.seam.intercept.ClientSideInterceptor.intercept(ClientSideInterceptor.java:52)
at nz.co.risingstars.actions.upload.UploadController$$EnhancerByCGLIB$$f25dc804.done(<generated>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.el.parser.AstValue.invoke(AstValue.java:130)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:274)
at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68)
at com.sun.facelets.el.LegacyMethodBinding.invoke(LegacyMethodBinding.java:69)
... 30 more
Caused by: java.lang.IllegalStateException: no long-running conversation for @Conversational bean: uploadController
at org.jboss.seam.interceptors.ConversationalInterceptor.checkConversationForConversationalBean(ConversationalInterceptor.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:18)
at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:169)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:64)
at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
at sun.reflect.GeneratedMethodAccessor99.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:18)
at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:169)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:64)
at org.jboss.seam.intercept.RootInterceptor.createSeamInvocationContext(RootInterceptor.java:144)
at org.jboss.seam.intercept.RootInterceptor.invokeInContexts(RootInterceptor.java:129)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:102)
at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:50)
at sun.reflect.GeneratedMethodAccessor180.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:71)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
... 72 more
>From code:
<ice:panelGrid columns="1">
<ice:inputFile style="border:none; width:400px; height:70px;"
actionListener="#{uploadController.action}"/> <!-- progressListener="#{uploadController.progress}" -->
<ice:outputProgress id="progress" value="#{uploadController.percent}"/>
</ice:panelGrid>
<ice:panelGrid columns="1" width="100%">
<div align="right">
<ice:commandButton action="#{uploadController.cancel}"
value="#{messages.button_cancel}" immediate="true"
type="submit" />
<ice:commandButton id="done" type="submit"
value="#{messages.button_done}" immediate="true"
action="#{uploadController.done}" />
</div>
</ice:panelGrid>
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public void action(ActionEvent event) {
log.info("> action");
InputFile inputFile = (InputFile) event.getSource();
if (inputFile.getStatus() == InputFile.SAVED) {
String fileName = inputFile.getFileInfo().getFileName();
String contentType = inputFile.getFileInfo().getContentType();
File file = inputFile.getFile();
byte[] inputFileAsBytes = getAsBytes(file);
Image image = (Image)Component.getInstance("image", true);
image.setName(fileName);
image.setType(contentType);
image.setThumbnail(inputFileAsBytes);
image.setImage(inputFileAsBytes);
image.setVersion(0);
em.persist(image);
if (parentObjectKind == ParentObjectKind.ORGANISATION) {
Organisation organisationToBeUploadedTo = em.find(Organisation.class, primaryKey);
if (organisationToBeUploadedTo == null) {
log.warn("Organisation to be Uploaded to is not found." + primaryKey);
} else {
organisationToBeUploadedTo.setPicture(image);
em.persist(organisationToBeUploadedTo);
}
} else if (parentObjectKind == ParentObjectKind.USER) {
User userToBeUploadedTo = em.find(User.class, primaryKey);
if (userToBeUploadedTo == null) {
log.warn("User to be Uploaded to is not found." + primaryKey);
} else {
userToBeUploadedTo.setPicture(image);
em.persist(userToBeUploadedTo);
}
} else {
log.error("action called with object type not supported.");
}
} else if (inputFile.getStatus() == InputFile.INVALID) {
inputFile.getFileInfo().getException().printStackTrace();
} else if (inputFile.getStatus() == InputFile.SIZE_LIMIT_EXCEEDED) {
inputFile.getFileInfo().getException().printStackTrace();
} else if (inputFile.getStatus() == InputFile.UNKNOWN_SIZE) {
inputFile.getFileInfo().getException().printStackTrace();
}
log.info("< action");
}
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
private byte[] getAsBytes(File file) {
byte[] valueToReturn = null;
log.info("> getAsBytes");
InputStream in = null;
OutputStream out = null;
try {
in = new BufferedInputStream(new FileInputStream(file));
ByteArrayOutputStream baos = new ByteArrayOutputStream();
out = new BufferedOutputStream(baos);
final int toRead = 1024;
byte[] buffy = new byte[toRead];
int read;
while ((read = in.read(buffy)) != -1) {
out.write(buffy, 0, read);
out.flush();
}
valueToReturn = baos.toByteArray();
} catch (IOException e) {
throw new IllegalStateException(e.getMessage());
} finally { // Try to release any resources.
try {
if (in != null) {
in.close();
}
} catch (IOException ignored) {}
try {
if (out != null) {
out.close();
}
} catch (IOException ignored) {}
}
log.info("< getAsBytes");
return valueToReturn;
}
@End
public String done() {
log.info("> done");
String valueToReturn = null;
if (parentObjectKind == ParentObjectKind.ORGANISATION) {
valueToReturn = "findOrganisation";
} else if (parentObjectKind == ParentObjectKind.USER) {
valueToReturn = "findUser";
} else {
log.error("done called with object type not supported.");
}
log.info("< done");
return valueToReturn;
}
--
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
19 years
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-961) jsessionid=xxx in url breaks RESTful parameter rewriting
by Radu Aghinii (JIRA)
jsessionid=xxx in url breaks RESTful parameter rewriting
----------------------------------------------------------
Key: JBSEAM-961
URL: http://jira.jboss.com/jira/browse/JBSEAM-961
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 1.2.0.GA, 1.1.6.GA
Environment: jboss 4.0.5.GA sun jvm 1.5.0_10 , JSF Sun RI 1.3_03 , facelets 1.1.12
Seam 1.1.6.GA, 1.2.0.GA
Reporter: Radu Aghinii
I have a Seam application that uses page parameters defined in pages.xml and uses "redirect after post " navigation.
The expected behavior is that when a redirect to a seam view happens the current values of the parameters referenced in pages.xml are attached to the URL.
( In the 1.1.6.GA documentation this is described in 5.1.1.1 of the documentation.
The specific point :
"Any navigation rule with a <redirect/> to the view id transparently includes the request parameter. The value of the parameter is determined by evaluating the value binding at the end of the invoke application phase." )
This works fine in the normal case where cookies are used for Servlet session management, however, if cookies are disabled, the functionality breaks and the parameters are not added.
The behavior is the same using 1.2.0.GA jars.
--
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
19 years
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-885) Restricting pages in pages.xml with wildcards
by Joshua Jackson (JIRA)
Restricting pages in pages.xml with wildcards
---------------------------------------------
Key: JBSEAM-885
URL: http://jira.jboss.com/jira/browse/JBSEAM-885
Project: JBoss Seam
Issue Type: Feature Request
Components: Security
Affects Versions: 1.1.6.GA
Environment: JBoss AS 5.0.0.Beta1
Reporter: Joshua Jackson
Priority: Optional
If I have directory structure for pages as such:
/department/home.xhtml
/distributor/home.xhtml
I'll be able to secure it in pages.xml with wildcards as such:
<page view-id="/**/*">
<restrict />
</page>
If I have directory structure as such:
/order/purchase/home.xhtml
/order/sales/home.xhtml
I'll be able to secure it in pages.xml with wildcards as such:
<page view-id="/order/purchase/*">
<restrict />
</page>
Since with this pattern it only works if we define the role in <restrict> element as such:
<page view-id="/order/purchase/*">
<restrict>#{s:hasRole('admin')}</restrict>
</page>
Also this pattern:
<page view-id="/order/**/*">
<restrict />
</page>
And this pattern:
<page view-id="/**/**/*">
<restrict />
</page>
--
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
19 years