[JBoss JIRA] Created: (JBSEAM-4722) Build seam2.5
by he youlin (JIRA)
Build seam2.5
-------------
Key: JBSEAM-4722
URL: https://jira.jboss.org/browse/JBSEAM-4722
Project: Seam
Issue Type: Feature Request
Affects Versions: 2.2.1.CR2
Reporter: he youlin
Priority: Optional
I think seam team should consider building seam 2.5 version so we can upgrade our old project to jsf2.0,ejb3.1,hibernate 3.6,beanvalidation,glassfish3 or jboss6 and get rid of hibernate3.2 validation and richfaces3 dependcy.
I have upgraded my old project a few months ago from seam2.2 to use jsf2.1,hibernate 3.6,beanvalidation,granite-seam21,spring3.05 under tomcat 7.0.5-dev and used in the production environment.I test it on glassfish v3.1 and jboss6 but not test ejb.
If considered i can provide my patch to seam team as a reference or push full source code to github with your team permission.
Please consider.
heyoulin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (SEAMFACES-186) <s:validateForm>:
by Matija Mazi (JIRA)
<s:validateForm>:
------------------
Key: SEAMFACES-186
URL: https://issues.jboss.org/browse/SEAMFACES-186
Project: Seam Faces
Issue Type: Bug
Components: Validation & Conversion
Affects Versions: 3.0.2
Environment: JBAS 7
Mojarra 2.0.4
Reporter: Matija Mazi
Priority: Minor
This valitator:
{code:java}
@FacesValidator("passwordRepeatValidator")
@RequestScoped
@Named
public class PasswordRepeatValidator implements Validator {
@Inject @InputField private String password;
@Inject @InputField private String passwordRepeat;
@Override
public void validate(FacesContext facesContext, UIComponent uiComponent, Object o) throws ValidatorException {
if (!passwordRepeat.equals(password)) {
throw new ValidatorException(new FacesMessage("Passwords don't match."));
}
}
}
{code}
used like this:
{code:xhtml}
<h:form id="f">
<s:validateForm validatorId="passwordRepeatValidator"/>
<h:dataTable id="t" value="1" var="x">
<h:column id="c">
<h:inputSecret id="password"/>
<h:message for="password"/>
<h:inputSecret id="passwordRepeat"/>
<h:message for="passwordRepeat"/>
</h:column>
</h:dataTable>
<h:commandButton value="Submit"/>
</h:form>
{code}
fails with:
{code}
10:57:13,407 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[ppay-web].[/].[Faces Servlet]] (http--127.0.0.1-8080-2) Servlet.service() for servlet Faces Servlet threw exception: java.lang.IllegalArgumentException: org.jboss.seam.component.UIValidateForm-- Could not locate component [f:password]
at org.jboss.seam.faces.component.FormValidationFieldProducer.findComponent(FormValidationFieldProducer.java:160) [seam-faces-impl-3.0.2.Final.jar:]
at org.jboss.seam.faces.component.FormValidationFieldProducer.getInputFieldValue(FormValidationFieldProducer.java:76) [seam-faces-impl-3.0.2.Final.jar:]
at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source) [:1.6.0_24]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstance(MethodInjectionPoint.java:169) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bean.ProducerMethod$1.produce(ProducerMethod.java:149) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:361) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:67) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:693) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:775) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:138) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:875) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:887) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:182) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:176) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:142) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:170) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:339) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:122) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:87) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at com.example.PasswordRepeatValidator$Proxy$_$$_WeldClientProxy.validate(PasswordRepeatValidator$Proxy$_$$_WeldClientProxy.java) [backend-1.0.0-SNAPSHOT.jar:]
at org.jboss.seam.faces.component.UIValidateForm.validate(UIValidateForm.java:96) [seam-faces-api-3.0.2.Final.jar:]
at javax.faces.component.UIInput.executeValidate(UIInput.java:1209) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at javax.faces.component.UIInput.processValidators(UIInput.java:698) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at javax.faces.component.UIForm.processValidators(UIForm.java:244) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1085) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:1165) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:76) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
{code}
If the <h:dataTable><h:column> code is removed, it works as expected. It seems FormValidationFieldProducer is not able to locate the input components (password, passwordRepeat) if they are nested inside a NamingContainer (it this case a data table).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (SEAMCATCH-26) Make caught exception available as named bean
by Dan Allen (JIRA)
Make caught exception available as named bean
---------------------------------------------
Key: SEAMCATCH-26
URL: https://issues.jboss.org/browse/SEAMCATCH-26
Project: Seam Catch
Issue Type: Feature Request
Components: Core Implementation
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
As we get into error pages, it's going to be useful to have the caught exception available via a named bean. I think this is just a matter of adding a dependent-scoped producer that reads the value of the current CaughtException from a field in the exception dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way all the info is available, including the exception being handled, the original exception and the unwrapped stack.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (SEAMFACES-168) Error page navigation after Seam Catch
by Andrew Wheeler (JIRA)
Error page navigation after Seam Catch
--------------------------------------
Key: SEAMFACES-168
URL: https://issues.jboss.org/browse/SEAMFACES-168
Project: Seam Faces
Issue Type: Feature Request
Components: Conversations
Affects Versions: 3.0.1
Environment: JBoss AS6, Mojarra 2.1
Reporter: Andrew Wheeler
It would be nice to annotate a Seam Catch handler with an error page view that is restored after the exception has been handled. This should tidy (destroy) any active conversation as the view probably can't be restored. It could also mark the event as handled (some default behaviour) if it hasn't been handled by the exception handler method.
E.g:
@ErrorPage("error")
public void noConversationHandler(@Handles CaughtException<NonexistentConversationException> event) {
messages.info("The view you were editing has expired.");
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3848) Seam fails to create and inject components when multiple ajax-requests are fired from a commandLink or commandButton, using ajax4jsf.
by etirk etirk (JIRA)
Seam fails to create and inject components when multiple ajax-requests are fired from a commandLink or commandButton, using ajax4jsf.
-------------------------------------------------------------------------------------------------------------------------------------
Key: JBSEAM-3848
URL: https://jira.jboss.org/jira/browse/JBSEAM-3848
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0.BETA1
Environment: windows vista / rhel4
sun jdk5, jdk6 latest versions
jboss as 4.2.2 and 4.2.3
firefox2 and 3, ie 6 and 7.
Reporter: etirk etirk
Fix For: 2.1.2.GA
Seam fails to create and inject components when multiple ajax-requests are fired from a commandLink or commandButton, using ajax4jsf.
Replication found using seam-booking in examples, trunk as of 081216.
Rewrite the find-method in the HotelSearchAction-class, in the seam booking example application. It should look like this.
public void find() {
page = 0;
queryHotels();
try {
Thread.sleep(1000 * 5);
} catch (InterruptedException ignore) {
}
}
Now, start the application, register a user and enter main.html. Click multiple times on the search hotel button. Depending upon how fast your computer is, you might need to do more than a double-click. Sometimes you may need to klick fast up to 5-8 times. But it will occur.
You will end up with an exception that says:
Caused by javax.servlet.ServletException with message: javax.el.ELException: /main.xhtml @74,130 rendered=#{hotelSearch.nextPageAvailable}: Error reading nextPageAvailable on type org.javassist.tmp.java.lang.Object_$$_javassist_4
Which in turn comes from a synchronization problem.
Caused by org.jboss.seam.core.LockTimeoutException with message: could not acquire lock on @Synchronized component: hotelSearch
This is in a way funny, since the hotelSearch-component is not annotated with synchronized. Anyway, our application does not throw an exception like this, but we to have tried synchronizing our involved components, with no luck. Our exception is mostly this
Caused by javax.servlet.ServletException with message: javax.el.ELException: /layout/template.xhtml @18,59 rendered=#{authenticator.inSpecialMode}: Error reading inSpecialMode on type se.session.Authenticator_$$_javassist_4
Which in turn comes from the failed injections
Caused by org.jboss.seam.RequiredException with message: @In attribute requires non-null value: authenticator.entityManager
This problem occurs all over the application, always when an ajax request is double-clicked and seam tries to recreate seam components and runs out of time. In 99% of the case it is the first read property of our authenticator-component that fails, and most often it is that seam cannot create a entityManager to inject, and the system fails due to that the annotation is set to only inject, without create. Removing the entityManager from the component will only result in that seam cannot inject another component instead, until you have no injections left in authenticator, and it still fails!
Similar behaviour has been noticed using non-ajax calls, using standard h:commandButton/Link. This is however much more rare.
--
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
12 years, 3 months