[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3936) Client-side Interceptor: around and within priority order does not work
by Julien Kronegg (JIRA)
Client-side Interceptor: around and within priority order does not work
-----------------------------------------------------------------------
Key: JBSEAM-3936
URL: https://jira.jboss.org/jira/browse/JBSEAM-3936
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.1.GA
Environment: Seam trunk http://fisheye.jboss.com/browse/Seam/trunk/src/main/org/jboss/seam/Compon...
Reporter: Julien Kronegg
When the Component class initialize the Interceptor list (initInterceptors() method), it does the following operations:
1. initialize default Interceptors
2. initialize other Interceptors (e.g. the ones defined by annotations)
3. sort the "interceptors" list with respect to the priorities defined by "around" and "within" properties
However, the Interceptors are separated between "interceptors" list (for server-side interceptors) and "clientSideInterceptors" list (for client-side interceptors).
Thus, the "clientSideInterceptors" list is never sorted in the initInterceptors() method. This means that around/within priority sorting does not work for client-side Interceptors. So if you define an Interceptor, it will be always added at the end of the list.
Possible solutions:
1. the "clientSideInterceptors" must be sorted by a "newSort(clientSideInterceptors);" in initInterceptors()
2. the documentation must state that around/within priority sorting does not work for client-side interceptors
I would prefer Solution 1 :-)
--
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, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3921) rewrite-filter not working with scheme in page descriptor
by Eric Schneider (JIRA)
rewrite-filter not working with scheme in page descriptor
---------------------------------------------------------
Key: JBSEAM-3921
URL: https://jira.jboss.org/jira/browse/JBSEAM-3921
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.GA
Environment: Windows XP / jdk1.5.0_06 / jboss-4.2.3.GA
Reporter: Eric Schneider
Using scheme="http" (or https) in *.page.xml breaks rewrite of outgoing patterns. Incoming pattern still maps.
Given: Two pages, one with a scheme specified and on without
* s:links to /NoScheme.xhtml will rewrite properly
* s:links to /Scheme.xhtml will not be rewritten ( keeps Scheme.seam format)
* The scheme of the page containing the links has no effect.
* Incoming rewrites are applied: /Scheme, /Scheme.seam, /NoScheme, /NoScheme.seam all work
Same behavior with Seam 2.1.0.SP1. Briefly tried svn trunk, but there seems to be other problems there (losing project name from context path on rewrites).
--
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, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3925) java.lang.LinkageError: duplicate class definition in ProxyFactory
by Takayoshi Kimura (JIRA)
java.lang.LinkageError: duplicate class definition in ProxyFactory
------------------------------------------------------------------
Key: JBSEAM-3925
URL: https://jira.jboss.org/jira/browse/JBSEAM-3925
Project: Seam
Issue Type: Bug
Reporter: Takayoshi Kimura
Fix For: 2.0.0.GA
java.lang.LinkageError: duplicate class definition in ProxyFactory
The ProxyFactory#createClass() method is not thread safe and causes LinkageError under heavy load. This is same problem as JASSIST-28:
https://jira.jboss.org/jira/browse/JASSIST-28
Seam has a little bit modified version of ProxyFactory taken from Javassist 3.3. This race condition issue has been fixed in Javassist 3.4. In Javassist 3.4 this method has a synchronized block and also weak ref based cache mechanism has been added.
The ProxyFactory#createClass() is not thread safe and called from the following 3 methods:
1. Component#getProxyFactory(), this method is a synchronized method
2. ClientSideInterceptor#readResolve()
3. JavaBeanInterceptor#readResolve()
1 and (2 or 3) can run at the same time.
Possible options:
* Re-sync ProxyFacotory source code with 3.4 or later version
* Add a synchronized modifier/block to the ProxyFacotory#createClass() method
Exception stack trace:
Caused by: org.jboss.seam.InstantiationException: Could not instantiate Seam component: test
at org.jboss.seam.Component.newInstance(Component.java:1986)
at org.jboss.seam.Component.getInstance(Component.java:1876)
at org.jboss.seam.Component.getInstance(Component.java:1843)
at org.jboss.seam.Component.getInstanceInAllNamespaces(Component.java:2192)
at org.jboss.seam.Component.getValueToInject(Component.java:2144)
at org.jboss.seam.Component.injectAttributes(Component.java:1601)
at org.jboss.seam.Component.inject(Component.java:1419)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:45)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:42)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.persistence.EntityManagerProxyInterceptor.aroundInvoke(EntityManagerProxyInterceptor.java:26)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.persistence.HibernateSessionProxyInterceptor.aroundInvoke(HibernateSessionProxyInterceptor.java:27)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:50)
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:585)
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.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
... 184 more
Caused by: java.lang.RuntimeException: by java.lang.LinkageError: duplicate class definition: org/javassist/tmp/java/lang/Object_$$_javassist_95
at org.jboss.seam.util.ProxyFactory.createClass(ProxyFactory.java:190)
at org.jboss.seam.Component.createProxyFactory(Component.java:2270)
at org.jboss.seam.Component.getProxyFactory(Component.java:1378)
at org.jboss.seam.Component.wrap(Component.java:1369)
at org.jboss.seam.Component.instantiateSessionBean(Component.java:1291)
at org.jboss.seam.Component.instantiate(Component.java:1276)
at org.jboss.seam.Component.newInstance(Component.java:1970)
... 212 more
Caused by: javassist.CannotCompileException: by java.lang.LinkageError: duplicate class definition: org/javassist/tmp/java/lang/Object_$$_javassist_95
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:165)
at org.jboss.seam.util.ProxyFactory.createClass(ProxyFactory.java:186)
... 218 more
Caused by: java.lang.LinkageError: duplicate class definition: org/javassist/tmp/java/lang/Object_$$_javassist_95
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javassist.util.proxy.FactoryHelper.toClass2(FactoryHelper.java:177)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159)
... 219 more
--
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, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3935) <render> elements in pages.xml need to fallthrough like in case statements.
by Dan Hinojosa (JIRA)
<render> elements in pages.xml need to fallthrough like in case statements.
---------------------------------------------------------------------------
Key: JBSEAM-3935
URL: https://jira.jboss.org/jira/browse/JBSEAM-3935
Project: Seam
Issue Type: Feature Request
Reporter: Dan Hinojosa
I found a situation where having a Renderer object injected into a bean is not at all ideal. Case in point, resetting a password. In example 1, when I call renderer.render, the user object has not be outjected yet. Therefore if I have information in /email/password.xhtml referring to #{user.password} the email will send either nothing or the old password. In example 2, I can get around it with a kludge which is updating the user object injected and then do the render. This is inelegant. The best option I believe is to do the rendering outside of the method, so I propose doing something like in example 3.
Example 1:
@Name("registrationBean")
@Scope(ScopeType.CONVERSATION)
public class RegistrationBean implements Serializable {
@In
private EntityManager entityManager;
@In @Out
private User user;
@In
private Renderer renderer;
@In //Ostermiller random password utility
private RandPass randPass;
@Transactional
public void resetPassword() {
Query query = entityManager.createQuery("SELECT u from User u where UPPER(u.email) = UPPER(:email)");
query.setParameter("email", user.getEmail());
user = (User) query.getSingleResult();
String newPassword = randPass.getPass(8);
user.setPassword(newPassword);
entityManager.flush();
renderer.render("/email/password.xhtml"); //Oh oh, nothing has been updated!!!
}
}
Example 2:
@Name("registrationBean")
@Scope(ScopeType.CONVERSATION)
public class RegistrationBean implements Serializable {
@In
private EntityManager entityManager;
@In @Out
private User user;
@In
private Renderer renderer;
@In //Ostermiller random password utility
private RandPass randPass;
@Transactional
public void resetPassword() {
Query query = entityManager.createQuery("SELECT u from User u where UPPER(u.email) = UPPER(:email)");
query.setParameter("email", user.getEmail());
User dbUser = (User) query.getSingleResult();
String newPassword = randPass.getPass(8);
dbUser.setPassword(newPassword);
user.setFirstName(dbUser.getFirstName()); //kludge
user.setLastName(dbUser.getLastName()); //kludge
user.setPassword(newPassword); //kludge
entityManager.flush();
renderer.render("/email/password.xhtml");
}
}
Example 3 (My proposition) :
@Name("registrationBean")
@Scope(ScopeType.CONVERSATION)
public class RegistrationBean implements Serializable {
@In
private EntityManager entityManager;
@In @Out
private User user;
@In //Ostermiller random password utility
private RandPass randPass;
@Transactional
public void resetPassword() {
Query query = entityManager.createQuery("SELECT u from User u where UPPER(u.email) = UPPER(:email)");
query.setParameter("email", user.getEmail());
user = (User) query.getSingleResult();
user.setPassword(randPass.getPass(8));
entityManager.flush();
//NOTICE I TOOK OUT renderer.render("/email/password.xhtml")
}
}
Why did I take out renderer.render from the code? Because in pages.xml then we can make use of the render element to do the emailing,
.....
<page view-id="/registration/register.xhtml">
<begin-conversation join="true"/>
<navigation from-action="#{registrationBean.resetPassword}">
<render view-id="/email/password.xhtml"/> <!--Send one or more emails -->
<render view-id="/registration/register.xhtml"/> <!--I want to stay on the same page, or I could redirect, etc. -->
<end-conversation/>
</navigation>
</page>
....
If you try it out now currently, this works except that it doesn't follow through. What Seam does currently is that it renders /email/password.xhtml and stops. What I am proposing that <render> elements follow through until the last render or redirect element.
The advantages are highly numerous, one is as developers we would no longer need to be concerned about including renderer calls in our unit and non-page integration tests. We uncouple the view (emails, and pages) from the controller -- huge win. Another bigger advantage is that we can treat emails around a method as an AOP, we can easily add, remove emails based on the outcome of methods without us having to fidget with our code and have to test and retest our code. See example 4.
Example 4 (My proposition) :
@Name("registrationBean")
@Scope(ScopeType.CONVERSATION)
public class RegistrationBean implements Serializable {
@In
private EntityManager entityManager;
@In @Out
private User user;
@In //Ostermiller random password utility
private RandPass randPass;
@Transactional
public String resetPassword() {
Query query = entityManager.createQuery("SELECT u from User u where UPPER(u.email) = UPPER(:email)");
query.setParameter("email", user.getEmail());
try {
user = (User) query.getSingleResult();
user.setPassword(randPass.getPass(8));
entityManager.flush();
return "success"
} catch (NoResultException nre) {
return "noresult"
}
}
}
.....
<page view-id="/registration/register.xhtml">
<begin-conversation join="true"/>
<navigation from-action="#{registrationBean.resetPassword}">
<rule if-outcome="success">
<render view-id="/email/password.xhtml"/> <!--Send one or more emails -->
<redirect view-id="/index.xhtml"/>
<end-conversation/>
</rule>
</navigation>
</page>
....
--
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, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3934) Option for components to be bound to specific natural conversations.
by Dan Hinojosa (JIRA)
Option for components to be bound to specific natural conversations.
--------------------------------------------------------------------
Key: JBSEAM-3934
URL: https://jira.jboss.org/jira/browse/JBSEAM-3934
Project: Seam
Issue Type: Feature Request
Components: Core
Environment: JBoss Seam
Reporter: Dan Hinojosa
For the Seam connoisseurs, we find ourselves creating components of the same object, created from different circumstances with unfortunately very different and ugly names. I propose the ability reuse components while using natural conversation IDs as namespaces.
The following is a use case that is an all too common problem. When we want a user account to be created we instantiate a new user component (1). On the other hand when we want the user that's logged in to update their information we want the user object already associated associated with their credentials, possibly done with a factory (2). What we also would like to is to not to create strange variables like loggedInUser, newUser, user, unapprovedUser, just to make things work. So what I propose is the ability to attach a component based on a natural conversation id being used. Given the following scenario:
<!--(1) -->
<component name="user" scope="CONVERSATION"
class="com.manning.mymanning.data.User">
</component>
<!--(2), Note the conversationName attribute-->
<factory name="user" value="#{userBean.loggedInUser}"
scope="CONVERSATION" conversationName="updateUser"/>
Such a mapping would do the following. If a user object is required and if we are not in a natural conversationName called 'updateUser', then (1) will define how the user object gets created, in this case a straight-forward instantiation. If we are in a natural conversationName called 'updateUser', then (2) will define how the user object gets created, in this case it will be instantiated from a factory which makes use of Seam Security and the EntityManager to retrieve the correct user account.
If you wish to use annotations:
@Name("user")
@Scope(ScopeType.CONVERSATION)
public class User implements Serializable {...}
@Name("user")
@Scope(ScopeType.CONVERSATION)
@ConversationName("updateUser")
public class LoggedInUserBean {
....
@Unwrap
public User getLoggedInUser() {
Query query = entityManager.createQuery("SELECT user from User user WHERE user.name = #{identity.username}");
return query.getSingleResult();
}
}
The advantages for doing this: It would be better reuse of components, and better reuse of JSF pages without have to include a mess of <ui:param/> to track, better organization, save time from us developers for coming up with various long names for objects, and best of all it gives a contextual identity where the object is used.... "Oh this object is used when updating a user".
--
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, 10 months