August 2011 - seam-issues - Jboss List Archives

[JBoss JIRA] Created: (JBSEAM-4837) CLONE - High CPU usage because of concurrent use of WeakHashmap

by Marek Novotny (JIRA)

CLONE - High CPU usage because of concurrent use of WeakHashmap --------------------------------------------------------------- Key: JBSEAM-4837 URL: https://issues.jboss.org/browse/JBSEAM-4837 Project: Seam 2 Issue Type: Bug Components: EL Affects Versions: 2.2.0.GA, 2.2.1.Final, 2.2.2.Final Reporter: Mark Torres Assignee: Marek Novotny Fix For: 2.3.0.ALPHA Concurrent access to WeakHashmap by org.jboss.el.util.ConcurrentCache causes High CPU. This issue is similar to https://issues.jboss.org/browse/JBWEB-185 because they use the same codebase. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (SEAMREST-19) ValidationInterceptor not triggered on GF

by Jozef Hartinger (JIRA)

ValidationInterceptor not triggered on GF ----------------------------------------- Key: SEAMREST-19 URL: https://issues.jboss.org/browse/SEAMREST-19 Project: Seam REST Issue Type: Bug Components: Bean Validation Affects Versions: 3.0.0.Alpha3 Environment: GF 3.1b37 JDK6U23 Reporter: Jozef Hartinger Assignee: Jozef Hartinger Seam Tasks example - the ValidationInterceptor is not triggered. Probably a bug in GF. Need to write a test for that. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (SEAMFACES-126) Throw an some kind of unauthorized exception when auth fails, rather than returning a 401 response

by Brian Leathem (JIRA)

Throw an some kind of unauthorized exception when auth fails, rather than returning a 401 response -------------------------------------------------------------------------------------------------- Key: SEAMFACES-126 URL: https://issues.jboss.org/browse/SEAMFACES-126 Project: Seam Faces Issue Type: Enhancement Components: Security, View Configuration Reporter: Brian Leathem Fix For: 3.0.1 If authorization fails, and the user is not logged in, Faces looks for a @LoginViewId to redirect to, and returns a 401 response if none is found. A similar story applies for the @AccessDeniedViewId It would be better to instead throw an exception, that Seam Catch can intercept. If not intercepted, this exception would eventually lead to a 401 response. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (SEAMFACES-198) If a user fails an authorization check when using the Seam Security hooks via ViewConfig there is no way to add a message

by Jason Porter (JIRA)

If a user fails an authorization check when using the Seam Security hooks via ViewConfig there is no way to add a message ------------------------------------------------------------------------------------------------------------------------- Key: SEAMFACES-198 URL: https://issues.jboss.org/browse/SEAMFACES-198 Project: Seam Faces Issue Type: Enhancement Components: Documentation, Security Affects Versions: 3.0.2 Reporter: Jason Porter An exception (or preferably event) should be raised to allow a message to be added when an authorization attempt fails. This could be done in the enforce method of https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/s..., raise an event and allow developers to listen to it to supply a message or other actions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
4
0 / 0

[JBoss JIRA] Created: (SEAMCRON-15) CL issues on redeployment

by Peter Royle (JIRA)

CL issues on redeployment ------------------------- Key: SEAMCRON-15 URL: https://issues.jboss.org/browse/SEAMCRON-15 Project: Seam Cron Issue Type: Bug Reporter: Peter Royle Assignee: Peter Royle Diablo-D3 gets it on every redeployment (from Eclipse to JBoss AS 6) and I have seen it once (using NetBeans redeploying after sitting overnight). The sumptom is the 'Singleton is not set' error. In a conversation about this Stuart Douglas explained how I can solve this: (04:42:51 PM) stuartdouglas: something that did just occur to me is that weld will probably not work very well in this new thread anyway, unless you set the TCCL to the correct one (04:43:07 PM) PeteRoyle: TCCL? (04:43:16 PM) stuartdouglas: Thread Context Class Loader (04:43:28 PM) stuartdouglas: weld uses it a lot, even for stuff that should not need it to be set (04:43:51 PM) stuartdouglas: so if it is not set you end up with highly informative 'Singleton is not set' errors (04:44:30 PM) PeteRoyle: Ahah! I've been getting those sporadically on redeployment (04:44:45 PM) PeteRoyle: But to do with scheduling, not asynch (04:44:49 PM) PeteRoyle: (so far) (04:45:20 PM) stuartdouglas: those are pretty much always due to the wrong class loader being set as the TCCL (04:45:54 PM) stuartdouglas: also the only beans that will be accessible is @ApplicationScoped and @Dependant (04:46:10 PM) stuartdouglas: unless you put in some non-portable code to set up the contexts (04:46:11 PM) PeteRoyle: Is there a typical cure for that which doesn (04:46:29 PM) PeteRoyle: ''t require knowledge of how classloading works? (04:47:34 PM) stuartdouglas: not really, it depends where you get the errors, it should only be a problem when you start trying to use threads that you have spawned yourself to interact with weld (04:48:31 PM) stuartdouglas: for @Async the solution is to set the TCCL to the same as the original threads TCCL, and set it back in a finally block (04:49:11 PM) stuartdouglas: and it should really be run as a PriviliedAction, because a security manager might not let you set it (04:50:22 PM) marekn [~mnovotny@nat/redhat/x-wgsrrhabedyogdbb] entered the room. (04:50:39 PM) PeteRoyle: I get what you're saying, but I'm not sure how to do that stuff (04:50:54 PM) PeteRoyle: (setting the TCCL and running as PrivAction) (04:51:57 PM) stuartdouglas: https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java... (04:52:11 PM) stuartdouglas: https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java... (04:52:43 PM) stuartdouglas: note that SecurityActions is package private, otherwise any class can use it to set the TCCL (04:53:42 PM) stuartdouglas: basically it just wraps Thread.currentThread().set/getContextClassLoader (04:54:38 PM) PeteRoyle: Should I copy this code into Cron, (or Solder) to make it portable? (04:55:09 PM) stuartdouglas: it needs to be copied each time (04:55:38 PM) stuartdouglas: otherwise any code can get/set the TCCL (04:56:02 PM) kevinpollet [~kevinpoll(a)217.112.54.72] entered the room. (04:56:56 PM) PeteRoyle: OK so do I set the TCCL as the first thing in the new thread? (04:56:59 PM) amitev [~amitev(a)212.25.36.84] entered the room. (04:57:06 PM) stuartdouglas: yes (04:57:11 PM) PeteRoyle: (frm within the thread, say inside the run() method)? (04:57:17 PM) stuartdouglas: yes (04:57:34 PM) PeteRoyle: and unset it from a finally block from the original thread which screate the new thread (04:57:52 PM) PeteRoyle: screate=created (04:58:21 PM) stuartdouglas: yes, although you can just set it to null rather than saving and restoring the existing TCCL (04:59:01 PM) stuartdouglas: otherwise if you are using a thread pool the TCCL can hang around after redeployment, which results in a memory leak (04:59:47 PM) PeteRoyle: actually it looks like all the examples in WeldContainer do both those things in the same thread. Can I unset the TCCL at the end of the run() method (in a finally)? (04:59:58 PM) maschmid [~maschmid@nat/redhat/x-fjnivohxvbmhnpfw] entered the room. (05:00:00 PM) stuartdouglas: yes (05:00:06 PM) PeteRoyle: ok (05:00:33 PM) stuartdouglas: oops, sorry, I mis-read your earlier question (05:00:50 PM) stuartdouglas: you should only manipulate it inside the run method (05:00:57 PM) PeteRoyle: ok gotchya -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
6
0 / 0

[JBoss JIRA] Created: (SEAMCRON-2) Implement asynchronous method invocation for managed beans

by Dan Allen (JIRA)

Implement asynchronous method invocation for managed beans ---------------------------------------------------------- Key: SEAMCRON-2 URL: https://issues.jboss.org/browse/SEAMCRON-2 Project: Seam Cron Issue Type: Feature Request Reporter: Dan Allen Assignee: Peter Royle Fix For: 3.0.0.Alpha1 Implement thread pool-based asynchronous method invocation for managed (non-EJB) beans. This feature allows developers to mark a method for background execution using an annotation. {code:java} public class BeanWithAsyncMethod { @Asynchronous public void doLongOperation() { ... } } {code} To be forward thinking, we should put the @Asynchronous annotation (and related) and the dispatcher interface in Solder so that we can have different providers. For instance, Seam JMS could alternatively be used to execute the method over JMS to provide guaranteed execution instead of Seam Cron's default thread pool approach. You can use similar functionality from Seam 2 as a reference: http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_3/src/main/... We may consider offering the task control (Future) that EJB 3.1 provides, though you can create that as a separate issue if you deem it follow-up work. See: http://download.oracle.com/javaee/6/tutorial/doc/gkkqg.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (SEAMPERSIST-65) Support ViewScoped for Seam Managed Persistence Context

by Andrew Wheeler (JIRA)

Support ViewScoped for Seam Managed Persistence Context ------------------------------------------------------- Key: SEAMPERSIST-65 URL: https://issues.jboss.org/browse/SEAMPERSIST-65 Project: Seam Persistence Issue Type: Feature Request Affects Versions: 3.0.0.Final Environment: JBoss AS7 Reporter: Andrew Wheeler It would be nice to extend the SMPC to the view scope. When using ajax frameworks view scoped pages often have many action requests. On each invocation the bean state must be resynchronised with the persistence context using merge. This is a little unpleasant as: * It can lead to lots of checks to see if an entity is attached and if not to re-attach it. * This sometimes can cause the entity manager to flush, thus persisting merged entities pre-maturly. Currently it is not possible to do the following as the ViewScoped annotation is not permitted in this context: @ExtensionManaged @Produces @PersistenceUnit @ViewScoped EntityManagerFactory viewScopedScoped; Secondly, even if you could then it would probably stop conversation scoped pages from working. Perhaps the scope qualifier could be wrapped using an annotation like @PersistenceScope(ViewScoped.class). It would probably also require producing two entity managers and choosing the right one to inject on the bean using the qualifier. E.g: @Produces @PersistenceScope(ViewScoped.class) EntityManager viewScoped; @Produces @PersistenceScope(ConversationScoped.class) EntityManager conversationScoped; -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
7
0 / 0

[JBoss JIRA] Created: (JBSEAM-4815) clean up icefaces example

by judy guglielmin (JIRA)

clean up icefaces example -------------------------- Key: JBSEAM-4815 URL: https://issues.jboss.org/browse/JBSEAM-4815 Project: Seam 2 Issue Type: Task Components: Examples Affects Versions: 2.2.2.Final Environment: ICEfaces-1.8.3, jsf1.2 various application servers Reporter: judy guglielmin Assignee: judy guglielmin Fix For: 2.3.0.ALPHA to ensure ice:dataTable has ice:columns as children, and the import.xml has an extra space at the bottom of the file which causes grief in some of the application servers. Mostly for going forwards with (not-released) versions of ICEfaces. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (SEAMSECURITY-82) TransactionInceptor dupliated error when tomcat startup...

by hantsy bai (JIRA)

TransactionInceptor dupliated error when tomcat startup... ---------------------------------------------------------- Key: SEAMSECURITY-82 URL: https://issues.jboss.org/browse/SEAMSECURITY-82 Project: Seam Security Issue Type: Bug Reporter: hantsy bai I create a Seam 3 web project and run on tomcat 6. when I start up tomcat 6, I get a TransactionInterceptor duplicated error. I commented out the configuration in my beans.xml. I works, but I adds another security-external dependencies, it occurs again. 2011-7-25 14:39:22 org.apache.catalina.core.StandardContext listenerStart 严重: Exception sending context initialized event to listener instance of class org.jboss.weld.environment.servlet.Listener org.jboss.weld.exceptions.DeploymentException: WELD-001416 Enabled interceptor c lass [<class>org.jboss.seam.security.external.dialogues.DialoguedInterceptor</cl ass> in jar:file:/E:/Users/hantsy/.m2/repository/org/jboss/seam/security/seam-se curity-external/3.0.0.Final/seam-security-external-3.0.0.Final.jar!/META-INF/bea ns.xml@11, <class>org.jboss.seam.transaction.TransactionInterceptor</class> in j ar:file:/E:/Users/hantsy/.m2/repository/org/jboss/seam/security/seam-security/3. 0.0.Final/seam-security-3.0.0.Final.jar!/META-INF/beans.xml@8, <class>org.jboss. seam.rest.validation.ValidationInterceptor</class> in file:/E:/MyWorks/bifincan/ bifincan-web/target/classes/META-INF/beans.xml@8, <class>org.jboss.seam.transact ion.TransactionInterceptor</class> in jar:file:/E:/Users/hantsy/.m2/repository/o rg/jboss/seam/security/seam-security-impl/3.0.0.Final/seam-security-impl-3.0.0.F inal.jar!/META-INF/beans.xml@8] specified twice at org.jboss.weld.manager.Enabled.createMetadataMap(Enabled.java:147) at org.jboss.weld.manager.Enabled.<init>(Enabled.java:113) at org.jboss.weld.manager.Enabled.of(Enabled.java:95) at org.jboss.weld.bootstrap.BeanDeployment.<init>(BeanDeployment.java:10 4) at org.jboss.weld.bootstrap.WeldBootstrap$DeploymentVisitor.visit(WeldBo otstrap.java:185) at org.jboss.weld.bootstrap.WeldBootstrap$DeploymentVisitor.visit(WeldBo otstrap.java:156) at org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.j ava:293) at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listen er.java:170) at org.apache.catalina.core.StandardContext.listenerStart(StandardContex t.java:3972) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4 467) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardHost.start(StandardHost.java:785) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443 ) at org.apache.catalina.startup.Embedded.start(Embedded.java:825) at org.codehaus.mojo.tomcat.AbstractRunMojo.startContainer(AbstractRunMo jo.java:533) at org.codehaus.mojo.tomcat.AbstractRunMojo.execute(AbstractRunMojo.java :239) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu ild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl eStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun cher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav a:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La uncher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: 352) 2011-07-25 14:39:23,045 INFO seam-servlet - CDI BeanManager cannot be found. No t sending event org.jboss.seam.servlet.event.ImplicitServletObjectsHolder$Intern -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (SEAMSECURITY-76) seam security external ScopeProducers doesn't work anywhere except AS6

by Marek Schmidt (JIRA)

seam security external ScopeProducers doesn't work anywhere except AS6 ---------------------------------------------------------------------- Key: SEAMSECURITY-76 URL: https://issues.jboss.org/browse/SEAMSECURITY-76 Project: Seam Security Issue Type: Bug Affects Versions: 3.0.0.Final Reporter: Marek Schmidt The design of the Security External module depends on undefined behaviour of alternatives. It defines alternatives (*ApplicationScopeProducer and *VirtualApplicationScopeProducer) in the module and expects the application to set the alternatives in its beans.xml, which isn't supported by CDI spec (see CDI-18) and doesn't seem to work anywhere except JBoss AS 6. We should probably just remove the Producers and make the beans @ApplicationScoped directly. Users interested in changing the scope of those beans could still use Seam Config for that. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues August 2011