[JBoss Seam] - Problem with app based on issues example
by Holy Joe
I've got an application that is structurally similar to the issues example, so I modeled my code and pages on those (where 'modeled' should be read 'copied and pasted'). Of course, I made numerous name changes and whatnot, but I believe that the relevant annotated methods are the same, as are the JSF pages that use them. Unfortunately, I must be wrong, since my app does not work.
After I edit an issue, for example, click Update and then Done, I am returned to the editProject page, but the changes I made are not persisted (of course, the names are not 'issue' and 'project' in my app, but the roles are the same). Also, the URL on the editIssue page has a conversationId parameter, and when I return to the editProject page, the conversationId is still there in the editProject URL, and it has the same number (i.e., it appears that the conversation is not ending). More specifically, when I click "View Issue", I'm taken to the editIssue page with, say, conversationId=4. After clicking Update and Done, I'm returned to the editProject page, and the URL now also says conversationId=4. If I repeat the process, the conversationId keeps incrementing. In the original example app, no conversationId ever appears on the URL.
I clearly have a serious gap in my understanding of this stuff. Does anyone have pointers for where I should look for what might be different between my app and the example that could cause this sort of behavior?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962578#3962578
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962578
19 years, 9 months
[Security & JAAS/JBoss] - Re: JDBC Realm
by bjornn
I have copied the query from login-config.xml.... from the policy "JBossMQ, and just make the necessary modifications.... Both policies(mine and jbossmq) are in the same file, under conf dir.
The JBossMQ policy looks like this:
| <!-- Security domain for JBossMQ -->
| <application-policy name = "jbossmq">
| <authentication>
| <login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule"
| flag = "required">
| <module-option name = "unauthenticatedIdentity">guest</module-option>
| <module-option name = "dsJndiName">java:/DefaultDS</module-option>
| <module-option name = "principalsQuery">SELECT PASSWD FROM JMS_USERS WHERE USERID=?</module-option>
| <module-option name = "rolesQuery">SELECT ROLEID, 'Roles' FROM JMS_ROLES WHERE USERID=?</module-option>
| </login-module>
| </authentication>
| </application-policy>
|
But wait... maybe i'm making a mistake... my tables contains these fields:
user's table: login, password
role's table: login(from user's table), role_name, role_group(I don't know the propose of this field, but in jboss wiki it seems mandatory to me)
By looking the declaration of jbossmq policy, my role query must retrive the id of the role(login?!) and a static text 'roles'. Is this right? wrong? why?
If my query looks bad, how it could be? Maybe a select *?
Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962573#3962573
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962573
19 years, 9 months
[JBoss Seam] - Re: where is <h:inputText> going?
by dbatcn
"peteroyle" wrote : 1: Will it help to add create=true to your @In annotation on the BQManagerBean.quux property?
Adding "create=true" causes:
anonymous wrote :
| javax.ejb.EJBException: Application Error: no concurrent calls on stateful beans
| at org.jboss.ejb3.stateful.StatefulInstanceInterceptor.invoke(StatefulInstanceInterceptor.java:71)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
| 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:188)
| at org.jboss.ejb3.stateful.StatefulLocalProxy.invoke(StatefulLocalProxy.java:98)
| at $Proxy489.findQuuxen(Unknown Source)
| ...
|
with a similar exception on the invocation (?) of the findBazs() method.
If I replace the "required=false" with the "create=true", then I get similar results.
With the original source, if I type a new quux name and press the rename quux button, then
1. Quux.setName() is called with the original value of quux.name (as seen in debug log), and
2. BQManagerBean.commitQuux() sees a null in its class's quux property (get the faces message: "BQManagerBean.commitQuux() called but quux is null!")
It seems to me that some instance of quux is being set, but not the one in BQManagerBean. Is there a way for an entity EJB to find out what context it's in?
"peteroyle" wrote : 2: Have you tried changing #{namefornewbaz} to #{nameForNewBaz} in bqmgr.xhtml to better match the name of the property on the SFSB?
That typo was an error on my part as I was trying to create a clean abstraction to post, sorry. Unfortunately, even when I change it to: anonymous wrote : <h:inputText value="#{nameForNewBaz}"/> I still get "BQManagerBean.createBazSpecifyingName(): nameForNewBaz is null!", showing that the value is never injected for "nameForNewBaz". The log shows that Seam is unable to find it:
anonymous wrote :
| 2006-08-02 10:08:36,423 DEBUG [org.jboss.seam.jsf.SeamVariableResolver] resolving name: nameForNewBaz
| 2006-08-02 10:08:36,423 DEBUG [org.jboss.seam.Component] seam component not found: nameForNewBaz
| 2006-08-02 10:08:36,423 DEBUG [org.jboss.seam.jsf.SeamVariableResolver] resolving name: nameForNewBaz
| 2006-08-02 10:08:36,423 DEBUG [org.jboss.seam.Component] seam component not found: nameForNewBaz
| 2006-08-02 10:08:36,423 DEBUG [org.jboss.seam.jsf.SeamVariableResolver] could not resolve name
| 2006-08-02 10:08:36,423 DEBUG [org.jboss.seam.jsf.SeamVariableResolver] could not resolve name
|
"quux" does seem to be found in the conversation context:
anonymous wrote :
| 2006-08-02 10:25:38,578 DEBUG [org.jboss.seam.interceptors.ConversationInterceptor] Beginning long-running conversation
| 2006-08-02 10:25:38,578 DEBUG [org.jboss.seam.Component] instantiating Seam component: conversation
| 2006-08-02 10:25:38,593 DEBUG [org.jboss.seam.contexts.Contexts] found in conversation context: quux
| 2006-08-02 10:25:38,593 DEBUG [org.jboss.seam.jsf.SeamVariableResolver] resolving name: quux
| 2006-08-02 10:25:38,593 DEBUG [org.jboss.seam.contexts.Contexts] found in conversation context: quux
| 2006-08-02 10:25:38,593 DEBUG [org.jboss.seam.jsf.SeamVariableResolver] resolved name to seam component
|
Is it possible that there are multiple conversations and my code is in the wrong one?
"bfo81" wrote : As far as I know there's a mistake in the documentation. The default scope is not Conversation but Event -> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=86491 - but I'm not sure if this only concerns normal JavaBeans (as shown in that topic's title) or also EJBs.
As long as the log isn't lying, I think my components are getting conversation scope:
anonymous wrote :
| 2006-08-02 10:25:12,481 INFO [org.jboss.seam.Component] Component: quux, scope: CONVERSATION, type: ENTITY_BEAN, class: com.orgmob.play.Quux
| ...
| 2006-08-02 10:25:12,513 INFO [org.jboss.seam.Component] Component: bqManager, scope: CONVERSATION, type: STATEFUL_SESSION_BEAN, class: com.orgmob.play.BQManagerBean, JNDI: member/BQManagerBean/local
| ...
| 2006-08-02 10:25:12,528 INFO [org.jboss.seam.Component] Component: baz, scope: CONVERSATION, type: ENTITY_BEAN, class: com.orgmob.play.Baz
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962569#3962569
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962569
19 years, 9 months
