[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3429) Build for chatroom example needs to deploy chatroom-service.xml on AS5
by Stan Silvert (JIRA)
Build for chatroom example needs to deploy chatroom-service.xml on AS5
----------------------------------------------------------------------
Key: JBSEAM-3429
URL: https://jira.jboss.org/jira/browse/JBSEAM-3429
Project: Seam
Issue Type: Bug
Components: Build
Affects Versions: 2.1.0.CR1
Reporter: Stan Silvert
The build for the chatroom example fails to deploy chatroom-service.xml. It must do this to avoid startup errors. Otherwise, you see this:
13:10:56,487 ERROR [JmsActivation] Unable to reconnect org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@40eb2a(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter(a)14ecfa4 destination=topic/chatroomTopic destinationType=javax.jms.Topic tx=true durable=false reconnect=10 provider=java:/DefaultJMSProvider user=null maxMessages=1 minSession=1 maxSession=15 keepAlive=60000 useDLQ=true DLQHandler=org.jboss.resource.adapter.jms.inflow.dlq.GenericDLQHandler DLQJndiName=queue/DLQ DLQUser=null DLQMaxResent=5)
javax.naming.NameNotFoundException: chatroomTopic not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:564)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:572)
at org.jnp.server.NamingServer.getObject(NamingServer.java:578)
at org.jnp.server.NamingServer.lookup(NamingServer.java:317)
at org.jnp.server.NamingServer.lookup(NamingServer.java:291)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at org.jboss.util.naming.Util.lookup(Util.java:222)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupDestination(JmsActivation.java:464)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.setup(JmsActivation.java:352)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.handleFailure(JmsActivation.java:292)
at org.jboss.resource.adapter.jms.inflow.JmsActivation$SetupActivation.run(JmsActivation.java:733)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
--
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, 9 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3451) FacesMessages.createFacesMessageFromRessourceBundle interpolates twice the message (the first time being wrong)
by Stephane Epardaud (JIRA)
FacesMessages.createFacesMessageFromRessourceBundle interpolates twice the message (the first time being wrong)
---------------------------------------------------------------------------------------------------------------
Key: JBSEAM-3451
URL: https://jira.jboss.org/jira/browse/JBSEAM-3451
Project: Seam
Issue Type: Bug
Affects Versions: 2.0.1.GA
Reporter: Stephane Epardaud
If I call FacesMessages.addMessageFromResourceBundle("key", 3) with in my resource bundle:
key={0,choice,0#foo|0<bar}
I get "3" instead of "bar".
This is because in FacesMessages.createFacesMessage(Severity severity, String key, String defaultMessageTemplate, Object... params) the message is gotten from the SeamResourceBundle with calls Interpolator.interpolate("{0,choice,0#foo|0<bar}") (with NO parameter), which returns "{0}" because of the lack of parameters.
Then later on in FacesMessages.createFacesMessage(Severity severity, String messageTemplate, Object... params) the expected interpolation happens again and calls Interpolator.interpolate("{0}", 3) which returns "3" naturally.
I really doubt this double interpolation of message formats is wanted. Suppose that the first interpolation of EL "#{foo}" would return a string like "#{bar}", the second interpolation would evaluate "#{bar}" even though this might not be the desired behaviour.
In any case double interpolation breaks MessageFormat formatting (which is supposed to be handled) and I'm not sure it is documented. If it is expected behaviour it is really not clear to me why someone would want that.
--
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, 9 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3343) Bijection problem when page is deserialized from PageStore
by Marcell Barbacena (JIRA)
Bijection problem when page is deserialized from PageStore
----------------------------------------------------------
Key: JBSEAM-3343
URL: https://jira.jboss.org/jira/browse/JBSEAM-3343
Project: Seam
Issue Type: Bug
Components: Wicket
Affects Versions: 2.1.0.BETA1
Environment: Windows, JBoss 4.2.2
Reporter: Marcell Barbacena
I am receiving the following stacktrace when I double click in a link (from the stacktrace I am seeing it is trying to deserialize a page and I think that is because of the second click going to the same page as the first click):
java.lang.ClassCastException: cannot assign instance of org.jboss.seam.wicket.ioc.WicketHandler to field br.gov.tse.secad.elo.web.CustomerList$1.handler of type org.jboss.seam.wicket.ioc.WicketHandler in instance of br.gov.tse.secad.elo.web.CustomerList$1
at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2032)
at java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1953)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at org.apache.wicket.util.lang.Objects.byteArrayToObject(Objects.java:393)
at org.apache.wicket.protocol.http.pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228)
at org.apache.wicket.protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:706)
at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:311)
at org.apache.wicket.Session.getPage(Session.java:751)
at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:448)
at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1224)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1331)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:363)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194)
at org.jboss.seam.web.WicketFilter$1.process(WicketFilter.java:57)
at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:53)
at org.jboss.seam.web.WicketFilter.doFilter(WicketFilter.java:52)
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.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:619)
--
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, 9 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3435) Hot Deployment of minor changes terminates the session and triggers full app redeployment
by Luis Tama (JIRA)
Hot Deployment of minor changes terminates the session and triggers full app redeployment
-----------------------------------------------------------------------------------------
Key: JBSEAM-3435
URL: https://jira.jboss.org/jira/browse/JBSEAM-3435
Project: Seam
Issue Type: Bug
Components: Core, Hot Deploy, Security
Affects Versions: 2.1.0.BETA1
Environment: Windows XP SP2
JDK 1.5.0_16
JBoss AS 4.2.2.GA
Eclipse JEE Europa Winter (3.3.2)
JBoss Tools 2.1.2.GA
JBoss Seam 2.1.0-SNAPSHOT # 309 + Revision 9013 for Initialization.java
Reporter: Luis Tama
Note: This bug happens (at least) when using an extended Identity component, which is now correctly deployed from /WEB-INF/dev at application initialization, as hot deployment was fixed in JBSEAM-3404. See that issue for more details, and revision 9013 for http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/init/I....
To reproduce this bug, create a completely new project called "siplacad2" with JBoss Tools 2.1.2.GA (New Seam Web Project). It's a WAR project.
Add my extended Identity component, drop it in /src/action/org/ostion/siplacad2/session/Identity.java, in the same package as Authenticator.java, whose compiled class will be placed in /WEB-INF/dev for hot deployment. It includes a homePage property, and a renderHomePage method, which is called from home.page.xml. I ommited the code for dynamic assignment of the homePage depending on the user role. The getter is enough for the example.
Also, I create /WebContent/home.page.xml, which will be responsible for redirecting the user to the real home page, after login, when accessing /home.xhtml.
When making any little change in my xhtml pages, the whole app gets redeployed (or at least some components). AFAIK, Seam redeploys the whole app only when the session is quite dirty or the app is using old code. But that should not be the case with every xhtml page.
Try this and you'll see:
- Deploy the app. My components get loaded fine.
- Navigate to http://localhost:8080/siplacad2/. We get this log:
07:03:19,790 INFO [Identity] Rendering Home Page: /home.xhtml
- Login with any user and password. Everything fine up to here. We get this log:
07:04:01,555 INFO [Authenticator] authenticating luiggitama
07:04:01,602 INFO [Identity] Rendering Home Page: /home.xhtml
- Make any small change in home.xhtml, e.g. add any word in the description of "This empty shell application includes:", maybe "...includes a lot of things:". Wait 5+ seconds until the changes are automatically published/redeployed to JBoss AS, and refresh the page in the browser. The problem is that my components get redeployed and the session is invalidated, so I must login again. This is the log:
07:08:32,790 INFO [Initialization] redeploying
07:08:32,899 INFO [Initialization] Installing components...
07:08:32,899 INFO [Component] Component: authenticator, scope: EVENT, type: JAVA_BEAN, class: org.ostion.siplacad2.session.Authenticator
07:08:32,899 INFO [Component] Component: org.jboss.seam.security.identity, scope: SESSION, type: JAVA_BEAN, class: org.ostion.siplacad2.session.Identity
07:08:32,899 INFO [Initialization] done redeploying
07:08:32,915 INFO [Identity] Rendering Home Page: /home.xhtml
This happens even when making the same kind of small changes to any other page, say "test.xhtml" which could be a copy of home.xhtml. I do not even need to be navigating to that recently changed page to get the problem. So the problem is not in the home.page.xml. I think it is a problem with component hot (re)deployment strategy or deployment and redeployment methods in initialization ...
So, with this new bug, my app or at least my components get redeployed and the session gets invalidated, so I lose a lot of time in the development process, having to login every time I make a little change to my pages. BTW, testing in my real project depends on a real session working, so turning off security is not an option.
Thanks in advance...
--
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, 9 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1277) ServerConversationContext does not process removals / additions when an exception propagates up
by Chris Rudd (JIRA)
ServerConversationContext does not process removals / additions when an exception propagates up
-----------------------------------------------------------------------------------------------
Key: JBSEAM-1277
URL: http://jira.jboss.com/jira/browse/JBSEAM-1277
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0.GA
Reporter: Chris Rudd
I have an Stateful EJB Component that throws an exception (this is expected, im testing that the system can recover from that error). This causes the component to be removed from the seam contexts (via the RemoveInterceptor). Then the exception floats up and is caught by the ExceptionFilter, and is redirected to a new view. All that works correctly. BUT when I return to the conversation that contained the EJB component, the component is still in it (even though the RemoveInterceptor removed it).
Ive traced it down to this :
ServerConversationContext.remove -- this adds the removal to the removals list, but does not update the session.attributes (the real storage for the context).
ServerConversationContext.flush -- this applies the removals / additions to the session attributes map.
The problem is that flush is never called when an exception propagates out. Thus the changes to that context are never flushed to the session attributes.
--
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, 9 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3422) Add basic method on Identity that checks for authenticated user
by Dan Allen (JIRA)
Add basic method on Identity that checks for authenticated user
---------------------------------------------------------------
Key: JBSEAM-3422
URL: https://jira.jboss.org/jira/browse/JBSEAM-3422
Project: Seam
Issue Type: Feature Request
Affects Versions: 2.1.0.BETA1, 2.0.3.CR1
Reporter: Dan Allen
Assignee: Dan Allen
Priority: Minor
Fix For: 2.0.3.CR2, 2.1.0.CR1
People often report the their authentication method is called more than once. While there are many different conditions that can lead to this problem, the most common is developers using #{identity.loggedIn} for conditional rendering in the UI.
Contrary to popular understanding, the #{identity.loggedIn} (alternatively written as #{identity.isLoggedIn()}) is not a simple JavaBean-style accessor method. It will attempt to perform a login if the user is not currently authenticated, thus making this method unsuitable to be used in the UI for conditional rendering. While nothing troublesome happens on successful login, when the login fails, or a guest user is browsing a page that calls this method, Seam triggers the authentication method at these arbitrary points in time.
A very simple workaround is use either #{identity.isLoggedIn(false)} or to simply create a new method on the identity component that merely checks if the user principal is null or non-null.
public boolean isAuthenticated() {
return getPrincipal() != null;
}
In the UI you can now use #{identity.authenticated}, which is now the preferred way to check if the user has a security principal.
Note: You only see the double message if you add a FacesMessage in the authenticate method. If you use Seam's built in authentication messages, you don't get the double message because the quietLogin() method (called by isLoggedIn()) skips adding the messages. You aren't privy to the information of whether the authentication method was called by quietLogin() for your own message registration purposes.
--
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, 9 months