December 2010 - seam-issues - Jboss List Archives

[JBoss JIRA] Commented: (SEAMCATCH-7) Create a JSF bridge

by Dan Allen (JIRA)

[ https://jira.jboss.org/browse/SEAMCATCH-7?page=com.atlassian.jira.plugin.... ] Dan Allen commented on SEAMCATCH-7: ----------------------------------- It's probably possible through some wrapping of the JSF application object or equivalent. We can also register an entry in Seam Faces, but only delegate to the real handler if a certain bean is present. > Create a JSF bridge > ------------------- > > Key: SEAMCATCH-7 > URL: https://jira.jboss.org/browse/SEAMCATCH-7 > Project: Seam Catch > Issue Type: Feature Request > Reporter: Jason Porter > Assignee: Jason Porter > Fix For: Beta1 > > > We need a JSF2 bridge for Catch. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (SEAMCATCH-5) Conditionally enable built-in handlers

by Jason Porter (JIRA)

[ https://jira.jboss.org/browse/SEAMCATCH-5?page=com.atlassian.jira.plugin.... ] Jason Porter commented on SEAMCATCH-5: -------------------------------------- Seam Config seems like the best approach. Adding the veto annotation. There's no API change, you don't have to modify any code, and it works at the lowest level possible. We'd probably have to do something very similar in other solutions. > Conditionally enable built-in handlers > -------------------------------------- > > Key: SEAMCATCH-5 > URL: https://jira.jboss.org/browse/SEAMCATCH-5 > Project: Seam Catch > Issue Type: Feature Request > Reporter: Jason Porter > Assignee: Jason Porter > > Once integrations happen users may want the ability to conditionally enable / disable built-in handlers. We need to figure out how to do this. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (SEAMCATCH-7) Create a JSF bridge

by Jason Porter (JIRA)

[ https://jira.jboss.org/browse/SEAMCATCH-7?page=com.atlassian.jira.plugin.... ] Jason Porter commented on SEAMCATCH-7: -------------------------------------- That works for most things, but JSF requires an entry into faces-config, afaik, we can't do anything that. There's no programatic way of registering an exception handler. > Create a JSF bridge > ------------------- > > Key: SEAMCATCH-7 > URL: https://jira.jboss.org/browse/SEAMCATCH-7 > Project: Seam Catch > Issue Type: Feature Request > Reporter: Jason Porter > Assignee: Jason Porter > Fix For: Beta1 > > > We need a JSF2 bridge for Catch. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (SEAMCATCH-5) Conditionally enable built-in handlers

by Dan Allen (JIRA)

[ https://jira.jboss.org/browse/SEAMCATCH-5?page=com.atlassian.jira.plugin.... ] Dan Allen commented on SEAMCATCH-5: ----------------------------------- One possibility is to add the @Veto annotation to the built-in handler class using Seam Config. Another possibility is to use Seam Config to specify a list of enabled handlers, which will effectively disable any handler class not listed. Other ideas welcome. > Conditionally enable built-in handlers > -------------------------------------- > > Key: SEAMCATCH-5 > URL: https://jira.jboss.org/browse/SEAMCATCH-5 > Project: Seam Catch > Issue Type: Feature Request > Reporter: Jason Porter > Assignee: Jason Porter > > Once integrations happen users may want the ability to conditionally enable / disable built-in handlers. We need to figure out how to do this. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (SEAMCATCH-7) Create a JSF bridge

by Dan Allen (JIRA)

[ https://jira.jboss.org/browse/SEAMCATCH-7?page=com.atlassian.jira.plugin.... ] Dan Allen commented on SEAMCATCH-7: ----------------------------------- I think we should move the bridge JIRAs into the module that provides them. Btw, see the Servlet module for how to make the bridge contingent on Seam Catch being present on the classpath. https://github.com/seam/servlet/blob/master/impl/src/main/java/org/jboss/... > Create a JSF bridge > ------------------- > > Key: SEAMCATCH-7 > URL: https://jira.jboss.org/browse/SEAMCATCH-7 > Project: Seam Catch > Issue Type: Feature Request > Reporter: Jason Porter > Assignee: Jason Porter > Fix For: Beta1 > > > We need a JSF2 bridge for Catch. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (SEAMCATCH-22) Name improvements for flow directives

by Dan Allen (JIRA)

Name improvements for flow directives ------------------------------------- Key: SEAMCATCH-22 URL: https://jira.jboss.org/browse/SEAMCATCH-22 Project: Seam Catch Issue Type: Feature Request Components: Core API Affects Versions: Alpha2 Reporter: Dan Allen Assignee: Jason Porter PROCEED -> MARK_HANDLED The directive PROCEED is too vague, and doesn't address the fact that the exception is being marked as handled. Better is to name the directive MARK_HANDLED. This is similar to JTA's setRollbackOnly(). It doesn't perform the action until the frame is complete, but it does mark the eventual action. PROCEED_TO_CAUSE -> DROP_CAUSE The directive PROCEED_TO_CAUSE is problematic on two accounts. First, it has the same problem as PROCEED in that it's too vague. Second, we aren't moving to the cause, we are moving from the cause to the wrapper. So what we are really doing is dropping the cause, hence DROP_CAUSE. Also, this should not mark the exception as handled. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (SEAMCATCH-21) Add isHandled() to CaughtException

by Dan Allen (JIRA)

Add isHandled() to CaughtException ---------------------------------- Key: SEAMCATCH-21 URL: https://jira.jboss.org/browse/SEAMCATCH-21 Project: Seam Catch Issue Type: Feature Request Components: Core API Affects Versions: Alpha2 Reporter: Dan Allen Assignee: Jason Porter Priority: Minor Fix For: Alpha3 For cases when a handler calls proceed() (the default), subsequent handlers should be able to determine if the exception is marked as handled by consulting the isHandled() method on CaughtException. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

2
2
0 / 0

[JBoss JIRA] Commented: (SEAMCATCH-7) Create a JSF bridge

by Brian Leathem (JIRA)

[ https://jira.jboss.org/browse/SEAMCATCH-7?page=com.atlassian.jira.plugin.... ] Brian Leathem commented on SEAMCATCH-7: --------------------------------------- Notes from IRC: It's a matter of writing a FacesExceptionFactory and a lifecycle/navigation hook. In other words, create a JSF exception handler that will just fire the event into Seam Catch See: http://www.jsfsummit.com/blog/ed_burns/2009/09/dealing_gracefully_with_vi... > Create a JSF bridge > ------------------- > > Key: SEAMCATCH-7 > URL: https://jira.jboss.org/browse/SEAMCATCH-7 > Project: Seam Catch > Issue Type: Feature Request > Reporter: Jason Porter > Assignee: Jason Porter > Fix For: Beta1 > > > We need a JSF2 bridge for Catch. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (SEAMFORGE-10) windows xp mvn install error

by Lincoln Baxter III (JIRA)

[ https://jira.jboss.org/browse/SEAMFORGE-10?page=com.atlassian.jira.plugin... ] Lincoln Baxter III commented on SEAMFORGE-10: --------------------------------------------- Awesome! Is this Windows XP issue still occurring? > windows xp mvn install error > ---------------------------- > > Key: SEAMFORGE-10 > URL: https://jira.jboss.org/browse/SEAMFORGE-10 > Project: Seam Forge > Issue Type: Bug > Components: Shell > Environment: Microsoft Windows XP [版本 5.1.2600] > (C) 版权所有 1985-2001 Microsoft Corp. > C:\Documents and Settings\Administrator>mvn -version > Apache Maven 3.0 (r1004208; 2010-10-04 11:50:56+0000) > Java version: 1.6.0_22 > Java home: E:\java\jdk1.6.0_22\jre > Default locale: zh_CN, platform encoding: GBK > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" > C:\Documents and Settings\Administrator> > Reporter: stan xi > Assignee: Lincoln Baxter III > Fix For: 1.0.0.Alpha1 > > > Results : > Failed tests: > testAbsolutePath(org.jboss.seam.forge.shell.test.plugins.builtin.ChangeDirecto > ryPluginTest) > Tests run: 29, Failures: 1, Errors: 0, Skipped: 0 > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] Seam Forge - Parent ............................... SUCCESS [1.609s] > [INFO] Seam Forge - Targeted Event Bus ................... SUCCESS [4.844s] > [INFO] Seam Forge - Parser/Java .......................... SUCCESS [19.515s] > [INFO] Seam Forge - Project Model APIs ................... SUCCESS [7.953s] > [INFO] Seam Forge - Shell API ............................ SUCCESS [1.157s] > [INFO] Seam Forge - Test Harness ......................... SUCCESS [0.875s] > [INFO] Seam Forge - Shell ................................ FAILURE [31.078s] > [INFO] Seam Forge - Project Model API Tests .............. SKIPPED > [INFO] Seam Forge - Persistence Plugins .................. SKIPPED > [INFO] Seam Forge - Web Plugins .......................... SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 1:07.563s > [INFO] Finished at: Sun Dec 05 03:02:34 GMT 2010 > [INFO] Final Memory: 45M/108M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2. > 5:test (default-test) on project forge-shell: There are test failures. > [ERROR] > [ERROR] Please refer to E:\java\seam-forge\shell\target\surefire-reports for the > individual test results. > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit > ch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please rea > d the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureExc > eption > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn <goals> -rf :forge-shell > Administrator@PC-201010191529 /e/java/seam-forge (master) > ------------------------------------------------------------------------------- > Test set: org.jboss.seam.forge.shell.test.plugins.builtin.ChangeDirectoryPluginTest > ------------------------------------------------------------------------------- > Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.828 sec <<< FAILURE! > testAbsolutePath(org.jboss.seam.forge.shell.test.plugins.builtin.ChangeDirectoryPluginTest) Time elapsed: 0.141 sec <<< FAILURE! > org.junit.ComparisonFailure: expected:<...cuments and Settings[/Administrator]> but was:<...cuments and Settings[]> > at org.junit.Assert.assertEquals(Assert.java:123) > at org.junit.Assert.assertEquals(Assert.java:145) > at org.jboss.seam.forge.shell.test.plugins.builtin.ChangeDirectoryPluginTest.testAbsolutePath(ChangeDirectoryPluginTest.java:123) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:251) > at org.jboss.arquillian.protocol.local.LocalMethodExecutor.invoke(LocalMethodExecutor.java:40) > at org.jboss.arquillian.impl.handler.ContainerTestExecuter.callback(ContainerTestExecuter.java:50) > at org.jboss.arquillian.impl.handler.ContainerTestExecuter.callback(ContainerTestExecuter.java:40) > at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) > at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) > at org.jboss.arquillian.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:157) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:244) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:207) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) > at org.jboss.arquillian.junit.Arquillian$5$1.evaluate(Arquillian.java:225) > at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:221) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:163) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) > at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:186) > at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:182) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:127) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) > at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115) > at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102) > at org.apache.maven.surefire.Surefire.run(Surefire.java:180) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) > at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBSEAM-4739) Fix injection of seam components in reentrance cases

by Anahide Tchertchian (JIRA)

Fix injection of seam components in reentrance cases ---------------------------------------------------- Key: JBSEAM-4739 URL: https://jira.jboss.org/browse/JBSEAM-4739 Project: Seam Issue Type: Bug Components: Core Affects Versions: 2.2.1.CR2, 2.2.0.GA, 2.1.0.GA Reporter: Anahide Tchertchian In reentrance cases (same component called twice recursively for instance), the component is not injected/disinjected correctly, which can leave the component in an invalid state. This is due to a misplaced check on injection state of the component in BijectionInterceptor.java: instead of being performed in the finally block, it should be placed in the catch block. This is useful in case of unexpected errors (to let the component in a valid state) but also in case of expected errors (for instance when a method performs a JSF validation and throws a ValidatorException). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues December 2010