July 2010 - seam-issues - Jboss List Archives

[JBoss JIRA] Created: (SEAMFACES-22) create an input field container component that supplements a composite component

by Dan Allen (JIRA)

create an input field container component that supplements a composite component -------------------------------------------------------------------------------- Key: SEAMFACES-22 URL: https://jira.jboss.org/browse/SEAMFACES-22 Project: Seam Faces Issue Type: Feature Request Components: UI Components Affects Versions: 3.0.0.Alpha2 Reporter: Dan Allen Assignee: Dan Allen Fix For: 3.0.0.Alpha3 Seam 2 provided the ui:decorate tag, which enhanced the composite template in Facelets by creating implicit variables to indicate whether the template contained required or invalid inputs. JSF 2 offers a much more advanced facility for supplementing a template-based component by allowing a real Java component to bind to a composite component. Use this facility to provide similar functionality to ui:decorate. -- 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

14 years, 1 month

2
4
0 / 0

[JBoss JIRA] Created: (SEAMFACES-21) raise before navigate event

by Dan Allen (JIRA)

raise before navigate event --------------------------- Key: SEAMFACES-21 URL: https://jira.jboss.org/browse/SEAMFACES-21 Project: Seam Faces Issue Type: Feature Request Components: JSF CDI Integration Affects Versions: 3.0.0.Alpha2 Reporter: Dan Allen Fix For: 3.0.0.Alpha3 One of the system event candidates that was overlooked in JSF 2.0 was a before navigation event, which would get fired just before the call to NavigationHandler#handleNavigation(). This is a very interesting transition and would open up a lot of possibilities for application developers, because JSF really don't accommodate this extension well. (Seam 2 had some functionality for setting context variables before navigation, but IMHO it would be far more powerful if we just raised an event so that the developer could execute any sort of logic before navigation). Forget even making a JSF system event out of it. Let's just raise it using CDI events (since we are bridging the JSF events anyway). I propose that we introduce the event qualifier: @Qualifier @Target( { FIELD, PARAMETER }) @Retention(RUNTIME) public @interface FacesNavigation { } and the event object would be the NavigationCase. public void preNavigate(@Observes @Before @FacesNavigation NavigationCase nc) { nc.getParameters().put("foo", Arrays.asList("bar")); } This can be combined with @Before and @View for filtering the event. We may even want @ToView to filter both the current and target view. Not sure how fine-grained to get. Here's a rough sketch of how this might be implemented. Unfortunately, this exposes the nastiness of the ConfigurableNavigationHandler in JSF 2.0, but at least we can leverage the NavigationCase resolution method we added for ourselves. public class SeamNavigationHandler extends ConfigurableNavigationHandler { private final NavigationHandler delegate; public SeamNavigationHandler(NavigationHandler delegate) { this.delegate = delegate; } @Override public NavigationCase getNavigationCase(FacesContext context, String fromAction, String outcome) { if (delegate instanceof ConfigurableNavigationHandler) { return ((ConfigurableNavigationHandler) delegate).getNavigationCase(context, fromAction, outcome); } // I guess return null; } @Override public Map<String, Set<NavigationCase>> getNavigationCases() { if (delegate instanceof ConfigurableNavigationHandler) { return ((ConfigurableNavigationHandler) delegate).getNavigationCases(); } // I guess return null; } @Override public void handleNavigation(FacesContext context, String fromAction, String outcome) { if (delegate instanceof ConfigurableNavigationHandler) { // we need to perform the resolution before JSF gets it so that we know where we are headed NavigationCase navigationCase = ((ConfigurableNavigationHandler) delegate).getNavigationCase(context, fromAction, outcome); if (navigationCase != null) { // this is solved elsewhere in Seam Faces, so just use that same hook BeanManager beanManager = ...; beanManager.fireEvent(navigationCase, new AnnotationLiteral<Before>() {}, new AnnotationLiteral<FacesNavigation>() {}, new ViewLiteral(context.getViewRoot().getViewId()))); } } delegate.handleNavigation(context, fromAction, outcome); } } We could support short-circuiting the view handler by checking for context.getResponseComplete() (redirect occurred) or if the view root changed (render occurred), but that might be abusing this hook. -- 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

14 years, 1 month

2
4
0 / 0

[JBoss JIRA] Created: (SEAMFACES-42) IllegalProductException: WELD-000052 Cannot return null from a non-dependent producer method

by Brian Leathem (JIRA)

IllegalProductException: WELD-000052 Cannot return null from a non-dependent producer method -------------------------------------------------------------------------------------------- Key: SEAMFACES-42 URL: https://jira.jboss.org/browse/SEAMFACES-42 Project: Seam Faces Issue Type: Bug Components: Messages & i18n Affects Versions: 3.0.0.Alpha3 Environment: Glassfish 3.0.1, Weld 1.0.1-FINAL, Seam3 Faces 1.0-ALPHA3 Reporter: Brian Leathem I created a Custom Exception handler to trap "NonexistentConversationException" exceptions as per Ed Burns howto: http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefull... The exception handler attempts to redirect the faces navigation: nav.handleNavigation(fc, null, "/workrequest/index.xhtml"); This results in the stack trace: org.jboss.weld.exceptions.IllegalProductException: WELD-000052 Cannot return null from a non-dependent producer method: org.jboss.weld.bean.ProducerMethod$1@32ac538c at org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:255) at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:361) at org.jboss.weld.context.AbstractMapContext.get(AbstractMapContext.java:112) at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.getProxiedInstance(ClientProxyMethodHandler.java:143) at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:100) at org.jboss.weld.util.CleanableMethodHandler.invoke(CleanableMethodHandler.java:43) at org.jboss.seam.faces.context.FlashContext_$$_javassist_785.put(FlashContext_$$_javassist_785.java) at org.jboss.seam.faces.status.MessagesAdapter.flushBeforeNavigate(MessagesAdapter.java:63) 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:597) at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:304) at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:298) at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:200) at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59) at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:194) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:241) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:216) at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:654) at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:647) at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:641) at org.jboss.seam.faces.event.PreNavigateEventProducer.handleNavigation(PreNavigateEventProducer.java:65) at ca.triumf.mis.qms.workrequest.jsf.exception.NonexistentConversationExceptionHandler.handle(NonexistentConversationExceptionHandler.java:48) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57) at com.sun.grizzly.ContextTask.run(ContextTask.java:69) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309) at java.lang.Thread.run(Thread.java:619) It seems as if the seam faces module is trying to put messages in the flash context, and this is causing a weld exception to be thrown. I hope I'm reading this as a Seam3 Faces error correctly :P Thanks as always, Brian -- 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

14 years, 1 month

4
15
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1839) Use HSQL to store Quartz jobs when deployed on JBoss AS

by Michael Yuan (JIRA)

Use HSQL to store Quartz jobs when deployed on JBoss AS ------------------------------------------------------- Key: JBSEAM-1839 URL: http://jira.jboss.com/jira/browse/JBSEAM-1839 Project: JBoss Seam Issue Type: Feature Request Reporter: Michael Yuan Assigned To: Michael Yuan Fix For: 2.0.0.GA Right now, Quartz jobs are stored "in-memory" and hence cannot be auto-started when the server reboots. The user can use persistence job stores by using a custom quartz property file. However, in JBoss AS, we should store jobs in the HSQL DB by default: * In the dispatcher component, we can have a "jboss=true" attribute * If this attribute is true, the QuartzDispatcher will setup Quartz tables for this particular app in the HSQL at startup, and then use the HSQL DB as persistent job store. This way, when the application deploys again, all the jobs for this application will be auto-started again. -- 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

14 years, 2 months

4
10
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2353) Quartz asynchronous events shceduled to fire while the server is shutdown fire before seam is initialized when the server is started.

by Yona Appletree (JIRA)

Quartz asynchronous events shceduled to fire while the server is shutdown fire before seam is initialized when the server is started. ------------------------------------------------------------------------------------------------------------------------------------- Key: JBSEAM-2353 URL: http://jira.jboss.com/jira/browse/JBSEAM-2353 Project: JBoss Seam Issue Type: Bug Components: Async Environment: Jboss 4.2.2.GA; Quartz scheduler. Reporter: Yona Appletree Fix For: 2.0.0.GA When the QuartzDispatcher is created, it causes any event scheduled to fire in the past to fire immediately (in a separate thread). Since QuartzDispatcher is marked @Startup, it may start before other components. If the handler of an event fired on startup relies on another component marked @Startup, it may not exist by the time the event is fired, and will therefore cause an error. I have a found a partial workaround for this issue, documented in the referenced forum thread. -- 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

14 years, 2 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1869) Example of Control Set for Quartz SEAM Interation

by Piergiuseppe Spinelli (JIRA)

Example of Control Set for Quartz SEAM Interation ------------------------------------------------- Key: JBSEAM-1869 URL: http://jira.jboss.com/jira/browse/JBSEAM-1869 Project: JBoss Seam Issue Type: Task Components: Examples Affects Versions: 2.0.0.BETA1 Environment: Any OS. JBoss2_0B project. Reporter: Piergiuseppe Spinelli Priority: Optional The attached sample is an attept to create a control interface to SEAM asynchronous method using Quartz as scheduling engine. I was asked to do this in the related forum thread: I am not sure it is near to the desired functionalities, but it could be used as a starting point (or possibly as a negative sample). The sample is very raw and I have used SEAM too short to be sure I did not make to stupid things, but if the idea is useful, I am sure other people will improve it. Notes: - The sample use quartz integrated in SEAM as it currently is: a support to asynchronous method - Quartz is used with its in-memory db, the persistent status is kept by the application usign custom Entities - Since I am a newby in SEAM, I preferred to make some custom classes for supporting CRUD operations since it was difficult to me to get the SEAM framework to do more that the simple things showed in the samples TODO: - it could be better to use some well known components library for the interface instead that my custom controls (i.e Trinidad) - the entities I made to keep the application status use a table schema very similar to the quartz schema: it could be a good idea in a future to be able to use some entity model over the quartz schema - it would be usefull to add the feature to upload the classes to be scheduler directly by the web interface, mayby using a classloader chain for supporting hot versioning. -- 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

14 years, 2 months

4
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-975) constraint by inclusion on remote calls object fields

by Zalder R (JIRA)

constraint by inclusion on remote calls object fields ----------------------------------------------------- Key: JBSEAM-975 URL: http://jira.jboss.com/jira/browse/JBSEAM-975 Project: JBoss Seam Issue Type: Feature Request Components: Remoting Reporter: Zalder R Assigned To: Shane Bryzak Priority: Optional I think it could be nice to define the fields of the objects returned in a "WebRemote call" with an "include" parameter (instead of the current exclude parameter). For instance : now you have : @WebRemote(exclude = {"secret"}) it would be nice to be able to define : @WebRemote(include = {"fieldIreallyNeed1", "fieldIreallyNeed2"}) The reasons for this are many : - security : if the object structure varies over time, you would not want the new fields to be available on the client side by default - in some cases it's a lot more lightweight (both in the code and in the volume of data sent) to define a minimum set of fields you want instead of the fields you don't want -- 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

14 years, 2 months

5
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-984) Progressbar for async methods

by Pete Muir (JIRA)

Progressbar for async methods ----------------------------- Key: JBSEAM-984 URL: http://jira.jboss.com/jira/browse/JBSEAM-984 Project: JBoss Seam Issue Type: Feature Request Components: Core, Remoting Affects Versions: 1.2.0.GA Reporter: Pete Muir Priority: Minor I think a fairly common use case is: * Call action * call async method to do a lengthy action * return to page * update progress bar and say when done based on async method I think we could wrap this all up: * user raises an event in the async method indicating completeness * remoting/ui component polls seam to update progress -- 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

14 years, 2 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3282) API for pluging and adding thirdparty suport to enhance Seam Remoting

by Francisco Jose Peredo Noguez (JIRA)

API for pluging and adding thirdparty suport to enhance Seam Remoting --------------------------------------------------------------------- Key: JBSEAM-3282 URL: https://jira.jboss.org/jira/browse/JBSEAM-3282 Project: Seam Issue Type: Feature Request Components: Remoting Reporter: Francisco Jose Peredo Noguez Assignee: Shane Bryzak Give us choice, expose an API to customize Seam Remoting (if it is available then it needs detailed documentation, or at least introductory documentation), so that if for some reason this never makes it in to Seam trunk, at least it becomes real easy to create some sort of plug-in to do it. -- 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

14 years, 2 months

3
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2215) Interface.js too large

by Robin Young (JIRA)

Interface.js too large ---------------------- Key: JBSEAM-2215 URL: http://jira.jboss.com/jira/browse/JBSEAM-2215 Project: JBoss Seam Issue Type: Bug Components: Remoting Affects Versions: 2.0.0.GA Reporter: Robin Young Assigned To: Shane Bryzak The interface.js file produced includes type definitions for EVERY seam component in my system and takes a couple of seconds to serve. The url is "/seam/resource/remoting/interface.js?navigationSystemService" and is generated by and s:remote tag. I have added exclude parameters to my WebRemote annotations and this restricts the data sent back back but does nothing to limit the interface.js file produced. Is there any way to slim this down and thus improve the speed of my site? -- 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

14 years, 2 months

4
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues July 2010