[JBoss JIRA] Created: (JBSEAM-4514) org.jboss.seam.core.Locale cookie
by Frank Cornelis (JIRA)
org.jboss.seam.core.Locale cookie
---------------------------------
Key: JBSEAM-4514
URL: https://jira.jboss.org/jira/browse/JBSEAM-4514
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.2.0.GA
Environment: Firefox
Reporter: Frank Cornelis
Priority: Critical
The org.jboss.seam.core.Locale cookie has different values for the Path and Secure attributes compared to the JSESSIONID cookie. Probably because of this an SSL-secured web application cannot persist the locale selection when running your application on a remote JBoss AS. I guess the org.jboss.seam.core.Locale cookie should inherent some of the flags (Path, Secure) from the JSESSIONID to make it work. This logic should be implemented as part of Selector.setCookieValueIfEnabled. I haven't tested it out yet, but the code should probably look something like this:
boolean secure = false;
String path = this.cookiePath;
HttpServletRequest request = (HttpServletRequest) ctx.getExternalContext().getRequest();
Cookie[] cookies = request.getCookies();
if (null != cookies) {
for (Cookie cookie : cookies) {
if ("JSESSIONID".equals(cookie.getName()) {
secure = cookie.getSecure();
path = cookie.getPath();
break;
}
}
}
HttpServletResponse response = (HttpServletResponse) ctx.getExternalContext().getResponse();
Cookie cookie = new Cookie( getCookieName(), value );
cookie.setMaxAge( getCookieMaxAge() );
cookie.setPath(path);
cookie.setSecure(secure);
response.addCookie(cookie);
See also: http://seamframework.org/Community/SeamLocaleIssues#comment111698
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1814) DataModel wrapped data is set to null by ManagedEntityIdentityInterceptor
by Matt Drees (JIRA)
DataModel wrapped data is set to null by ManagedEntityIdentityInterceptor
-------------------------------------------------------------------------
Key: JBSEAM-1814
URL: http://jira.jboss.com/jira/browse/JBSEAM-1814
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.0.BETA1
Environment: seam cvs (20070816.1709)
Reporter: Matt Drees
Priority: Minor
The following test fails:
@Name("dataModelComponent")
@Scope(ScopeType.CONVERSATION)
public class DataModelComponent extends EntityQuery {
@Override
public String getEjbql() {
return "from java.lang.Object o";
}
}
public class DataModelComponentTest extends SeamTest{
@Test
public void test() throws Exception {
new FacesRequest() {
@Override
protected void renderResponse() throws Exception {
DataModel model = (DataModel) getValue("#{dataModelComponent.dataModel}");
assert model.getWrappedData() != null;
}
}.run();
}
}
Because the component is conversation-scoped, a ManagedEntityIdentityInterceptor is attached, which nulls the wrapped List after getDataModel() is called.
In the referenced forum, Gavin indicated he hadn't decided whether this should be expected behavior or not, and asked for a jira issue.
If it is expected behavior (I hope not), I think either EntityQuery should not have a getDataModel() attribute, or it should be documented and/or programmatically enforced that EntityQuerys should not be conversation-scoped.
--
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
15 years
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3991) Asynchronous HTTP support in Seam+RESTeasy
by Balazs Pataki (JIRA)
Asynchronous HTTP support in Seam+RESTeasy
------------------------------------------
Key: JBSEAM-3991
URL: https://jira.jboss.org/jira/browse/JBSEAM-3991
Project: Seam
Issue Type: Feature Request
Components: WS
Affects Versions: 2.1.1.GA
Reporter: Balazs Pataki
Fix For: 2.1.2.CR1
There should be support for handling asynchronous HTTP connections in a way similar to the plain RESTeasy solution:
http://www.jboss.org/file-access/default/members/resteasy/freezone/docs/1...
It actually seems very straightforward to implement it in Seam, the only problem is that there needs to be 3 different implementations for Tomcat6+JBoss 4.2.x, JBoss 5, and Servlet 3. At least, in RESTeasy it is implemented this way.
For me I took the Tomcat6+JBoss 4.2.x implementation of org.jboss.resteasy.plugins.server.servlet.Tomcat6CometDispatcherServlet and based on this I added "implements CometProcessor" to ResteasyDispatcher + copied the event() and createHttpRequest() methods over from Tomcat6CometDispatcherServlet . Then I also added ResteasyAsyncHttpRequest, which is a clone of org.jboss.resteasy.plugins.server.servlet.Tomcat6AsyncHttpRequest. With this setup plus adding the
<Connector port="8080" address="${jboss.bind.address}"
emptySessionPath="true" protocol="org.apache.coyote.http11.Http11NioProtocol"
enableLookups="false" redirectPort="6443" acceptorThreadCount="2" pollerThreadCount="10"
/>
connector instead of the vanilla one to JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml seem to make it all work form me.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2678) improve docs for conversation propagation
by Martin Trummer (JIRA)
improve docs for conversation propagation
-----------------------------------------
Key: JBSEAM-2678
URL: http://jira.jboss.com/jira/browse/JBSEAM-2678
Project: JBoss Seam
Issue Type: Feature Request
Components: Documentation Issues
Environment: n.A.
Reporter: Martin Trummer
following points should be emphasized in the docs:
* the fact, that ending a conversation demotes the long-running conversation to a temporary conversation should be emphasized in the docs or explained in more detail
* the difference between ending a conversation and ending a conversation before-redirect should also be explained in more detail
* the docs should mention, that any facesMessages are lost, when you end the conversation and use before-redirect=true (and maybe how to work around this)
discussion can be found in the forum
I will attach a text file with a draft, of what these improvements could be (hope this helps)
--
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
15 years