[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1855) FacesMessages.instance().addToControl and Datatable do not work properly
by Andy Bosch (JIRA)
FacesMessages.instance().addToControl and Datatable do not work properly
------------------------------------------------------------------------
Key: JBSEAM-1855
URL: http://jira.jboss.com/jira/browse/JBSEAM-1855
Project: JBoss Seam
Issue Type: Bug
Components: JSF
Affects Versions: 1.2.0.GA
Reporter: Andy Bosch
It is possible do add FacesMessages via the Seam functionality with FacesMessages.instance().addToControl. In the parameters you have to pass the component id. In the plain JSF way, you can add FacesMessages via FacesContext ... addMessage. In the JSF-way you have to pass the client-id.
With normal input components you can use both ways. But when you work with datatables, you MUST work with the client-id, the Seam-way with using only the component-id does NOT work.
Explanation: When using a datatable-tag, you only have one component. The renderer generates the various rows. In the component-tree there is yet only one component! If you want to add a FacesMessage to one row, you can only work with client-ids (because you have to include the row-index).
My wish: Please change FacesMessages.instance().addToControl. for using with client-ids.
--
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, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4212) JMS feature does not work after cluster failover
by Scott McNab (JIRA)
JMS feature does not work after cluster failover
------------------------------------------------
Key: JBSEAM-4212
URL: https://jira.jboss.org/jira/browse/JBSEAM-4212
Project: Seam
Issue Type: Bug
Components: Remoting
Affects Versions: 2.0.2.SP1
Environment: JBoss 4.2.3.GA (clustered)
Reporter: Scott McNab
Assignee: Shane Bryzak
We have configured Seam to work in a clustered environment by using a custom JMSConnectionProvider that fetches the UIL2ConnectionFactory from HA-JNDI. This arrangements works perfectly fine while both servers are up - i.e. a web client connected to the slave server will correctly receive Asynchronous Seam notifications from a JMS topic hosted on the master server.
However, when the master server fails over to the slave, the Seam JMS support on the slave stops working. We get the following exception:
06-02 12:52:45.405 ERROR [seam.remoting.messaging.SubscriptionRegistry] (http-192.168.100.140-80-2:) org.jboss.mq.SpyJMSException: Cannot get the Topic from the provider; - nested throwable: (java.io.IOE
xception: Client is not connected)
06-02 12:52:45.406 ERROR [jboss.seam.remoting.Remoting] (http-192.168.100.140-80-2:) Error
java.lang.NullPointerException
at org.jboss.seam.remoting.messaging.SubscriptionRequest.marshal(SubscriptionRequest.java:31)
at org.jboss.seam.remoting.SubscriptionHandler.marshalResponse(SubscriptionHandler.java:107)
at org.jboss.seam.remoting.SubscriptionHandler.handle(SubscriptionHandler.java:96)
at org.jboss.seam.remoting.Remoting.getResource(Remoting.java:111)
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:68)
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.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.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:182)
at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:97)
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.jboss.web.tomcat.service.sso.ClusteredSingleSignOn.invoke(ClusteredSingleSignOn.java:677)
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)
We have diagnosed this issue and have developed a fix. The problem is as follows:
- once failover occurs, the topicConnection field in the SubscriptionRegistry object becomes invalid, as the connection to the master server has died.
- every subsequent call to SubscriptionRegistry.subscribe() will fail with SpyJMSException: Cannot get the Topic from the provider; Client is not connected.
- even if the master server recovers, this connection is dead and all Seam JMS subscriptions will no longer work.
The fix is to catch the Exception and retry with a new topicConnection if a subscribe request fails. The following patch on jboss-seam-2.0.2.SP1/src/remoting/org/jboss/seam/remoting/messaging/SubscriptionRegistry.java works for us:
Index: SubscriptionRegistry.java
===================================================================
--- SubscriptionRegistry.java (revision 5528)
+++ SubscriptionRegistry.java (working copy)
@@ -139,7 +139,21 @@
RemoteSubscriber sub = new RemoteSubscriber(UUID.randomUUID().toString(), topicName);
try {
- sub.subscribe(getTopicConnection());
+ try {
+ sub.subscribe(getTopicConnection());
+ } catch (Exception e) {
+ // If we failed during the first attempt, we might have a dead JMS connection.
+ // Clear the topic connection and try again.
+ if (topicConnection != null) {
+ try {
+ topicConnection.close();
+ } catch (Exception e1) {
+ // Ignore any exception during the close, since this connection is probably dead anyway
+ }
+ }
+ topicConnection = null;
+ sub.subscribe(getTopicConnection());
+ }
subscriptions.put(sub.getToken(), sub);
// Save the client's token in their session context
--
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, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2921) Wiki permission checking sometimes results in "no file extension in servlet path"
by Christian Bauer (JIRA)
Wiki permission checking sometimes results in "no file extension in servlet path"
---------------------------------------------------------------------------------
Key: JBSEAM-2921
URL: http://jira.jboss.com/jira/browse/JBSEAM-2921
Project: Seam
Issue Type: Bug
Components: Wiki
Reporter: Christian Bauer
Assigned To: Christian Bauer
I've seen this in the live log sometimes, couldn't reproduce it until now: Trigger a @Factory method on a page, the component that has the @Factory method has
@Create
public void create() {
if (!Identity.instance().hasPermission("User", "isAdmin", (User)Component.getInstance("currentUser") ) ) {
throw new AuthorizationException("You don't have permission for this operation");
}
}
This is from AdminHome.java. So for example try to access 'systemPreferenceEntities' variable without being an admin. This will result in a permission exception which is hidden and obscured by another exception in the exception handling phase:
>>> 12:45:02,053 DEBUG [org.jboss.seam.contexts.FacesLifecycle] >>> Begin exception recovery
>>> 12:45:02,055 DEBUG [org.jboss.seam.core.Manager] No stored conversation, or concurrent call to the stored conversation
>>> 12:45:02,059 DEBUG [org.jboss.seam.exception.Exceptions] reading exception mappings from /WEB-INF/pages.xml
>>> 12:45:02,064 DEBUG [org.jboss.seam.faces.Navigator] redirecting to: /wiki.xhtml
>>> 12:45:02,064 DEBUG [org.jboss.seam.contexts.FacesLifecycle] After render response, destroying contexts
>>> 12:45:02,066 DEBUG [org.jboss.seam.contexts.FacesLifecycle] <<< End JSF request for /wiki/
>>> 12:45:02,066 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/wiki].[default]] Servlet.service() for servlet default threw exception
java.lang.IllegalArgumentException: no file extension in servlet path: /
at org.jboss.seam.mock.MockViewHandler.getActionURL(MockViewHandler.java:44)
at org.jboss.seam.jsf.SeamViewHandler.getActionURL(SeamViewHandler.java:74)
at org.jboss.seam.faces.FacesManager.redirect(FacesManager.java:162)
at org.jboss.seam.faces.Navigator.redirect(Navigator.java:50)
at org.jboss.seam.exception.RedirectHandler.handle(RedirectHandler.java:51)
at org.jboss.seam.exception.Exceptions.handle(Exceptions.java:76)
at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:114)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:70)
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:613)
--
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, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4323) Allow EL-based StyleClass and Style Attributes to be Reevaluated After the First Row of a Spreadsheet, i.e. Support Conditional Styles on Any Cell
by Sean Gurevich (JIRA)
Allow EL-based StyleClass and Style Attributes to be Reevaluated After the First Row of a Spreadsheet, i.e. Support Conditional Styles on Any Cell
--------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBSEAM-4323
URL: https://jira.jboss.org/jira/browse/JBSEAM-4323
Project: Seam
Issue Type: Feature Request
Components: Excel
Affects Versions: 2.1.2.GA
Environment: Developing on Windows XP.
Reporter: Sean Gurevich
Currently, the Seam Excel library caches (maps) the worksheet cell's styles by the cell's UIComponent. Effectively, this leads to the styleClass and style attributes' evaluation to occur only once for the first row of data, then all subsequent rows inherit the styles. I have a need to apply conditional styling to cells in a row where the value expression in a styleClass/style attribute is reevaluated for each row of data, similar in behavior to a typical data iterator in JSF.
In my discussion with Nicklas Karlsson, he's proposed a solution involving an attribute to disable this caching behavior; however retaining the default behavior for anyone that relies on the performance advantage of the caching.
--
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, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4264) add ability to get current index from within e:worksheet
by Eric Jung (JIRA)
add ability to get current index from within e:worksheet
--------------------------------------------------------
Key: JBSEAM-4264
URL: https://jira.jboss.org/jira/browse/JBSEAM-4264
Project: Seam
Issue Type: Feature Request
Components: Excel
Reporter: Eric Jung
Priority: Minor
Fix For: 2.1.2.GA
If you have a collection of items with an arbitrary count, there is currently no straightforward way to dynamically output the collection row-wise. Is there any way to add a varStatus attribute like c:forEach and ui:repeat have? I'm open to other ideas, too, like using a binding for e:worksheet, but that doesn't seem to help the problem.
Here's an example of what I'd like to do:
<e:worksheet name="#{messages.mySheet}" value="#{myService.someList}" var="d" startRow="31" varStatus="status">
<e:cell column="1" row="#{status.rowIndex}" value="#[d.foo}"/>
<e:cell column="2" row="#{status.rowIndex}" value="#[d.foo2}"/>
<e:cell column="3" row="#{status.rowIndex}" value="#[d.foo3}"/>
<e:cell column="1" row="#{status.rowIndex}" value="#[d.foo4}"/>
<e:cell column="2" row="#{status.rowIndex}" value="#[d.foo5}"/>
<e:cell column="3" row="#{status.rowIndex}" value="#[d.foo6}"/>
</e:worksheet>
--
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, 4 months