April 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8873) Unexpected error forwarding to login page - No active contexts for scope type javax.enterprise.context.RequestScoped

by q q (JIRA)

Unexpected error forwarding to login page - No active contexts for scope type javax.enterprise.context.RequestScoped -------------------------------------------------------------------------------------------------------------------- Key: JBAS-8873 URL: https://issues.jboss.org/browse/JBAS-8873 Project: JBoss Application Server Issue Type: Bug Components: Weld/CDI Environment: JBoss 6.0.0.M2, Windows XP SP3 Reporter: q q 2010-04-22 09:55:36,484 WARN [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-1) Unexpected error forwarding to login page: javax.servlet.ServletException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

3
7
0 / 0

[JBoss JIRA] Created: (JBAS-9276) Make the annotation @Management works in association with @Singleton

by Laurent Vandwalle (JIRA)

Make the annotation @Management works in association with @Singleton -------------------------------------------------------------------- Key: JBAS-9276 URL: https://issues.jboss.org/browse/JBAS-9276 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: 6.0.0.Final Reporter: Laurent Vandwalle Fix For: 6.1.0 In JBoss 5.1, the use of @Management in association with @Service allowed to manage (JMX Management) the singleton EJB. In JBoss 6.0 Final, @Service annotations can be replace by the JEE6 standard annotation @Singleton. The problem is that the @Management annoation does not work if used in association with the @Singleton annotation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2914) Rule misfires due to "not matches" not working

by Wolfgang Laun (JIRA)

Rule misfires due to "not matches" not working ----------------------------------------------- Key: JBRULES-2914 URL: https://issues.jboss.org/browse/JBRULES-2914 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.2.0.M1 Reporter: Wolfgang Laun Assignee: Mark Proctor Priority: Critical A constraint such as owner != $code || (owner == $code && mode not matches "-.{2}x.*") can be shown to fail, apparently due to the "not matches" returning true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2917) matching of field==v1 || field==v2 breaks when variable binding is added

by Wolfgang Laun (JIRA)

matching of field==v1 || field==v2 breaks when variable binding is added ------------------------------------------------------------------------ Key: JBRULES-2917 URL: https://issues.jboss.org/browse/JBRULES-2917 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.2.0.M1 Reporter: Wolfgang Laun Assignee: Mark Proctor Priority: Critical Fix For: 5.2.0.M1 class Assignment { Class source, target; } The following rule fails to match when target == java.lang.Object.class rule ObjectIsAssignable when Assignment( $t: target == (java.lang.Object.class) || target == source ) then end The following rule fails to match when target == source rule ObjectIsAssignable when Assignment( $t: target == source || target == (java.lang.Object.class) ) then end The error does not occur if the binding ($t) is omitted. See Workaround. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2982) Massive performance degradation from 5.2.0.M1 to 5.2.0.M2

by Roman Novak (JIRA)

Massive performance degradation from 5.2.0.M1 to 5.2.0.M2 --------------------------------------------------------- Key: JBRULES-2982 URL: https://issues.jboss.org/browse/JBRULES-2982 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.2.0.M2 Reporter: Roman Novak Assignee: Mark Proctor Priority: Critical the drools-planner SolutionInitializer takes 75 minutes to complete im 5.2.0.M2 5.2.0.M1 took 9,5 Minutes It also seems that accumulation queries with init, action, result sections break down completely in performance. The following query takes now 3 minutes 45 secs to complete. Before it was ~1 sec. The cardinalities: PostingPeriodOpt = 5 MediumLocationOpt = 25000 MediumBookingOpt = 13000 query "queryMediumPartlyTaken" $pp : PostingPeriodOpt() $mlo : MediumLocationOpt(mTypeId == $pp.mTypeId) $mp: MediumPeriodUsage( subOptimal > 0 ) from accumulate( $mbo : MediumBookingOpt ( mediId == $mlo.mediId, eval(timeInterval.overlaps($pp.getCycle())) ), init ( MediumPeriodUsage $mpu = new MediumPeriodUsage($mlo, $pp); ), action( $mpu.addBooking( $mbo.getIndexRange() ); ), result( $mpu ) ) end -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-9366) OSGi bundles dropped in standalone/deployments do not get started any more

by David Bosschaert (JIRA)

OSGi bundles dropped in standalone/deployments do not get started any more -------------------------------------------------------------------------- Key: JBAS-9366 URL: https://issues.jboss.org/browse/JBAS-9366 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: OSGi integration Affects Versions: 7.0.0.Beta3 Reporter: David Bosschaert Up until Beta2 OSGi bundles dropped in the standalone/deployments folder were started automatically. This is pretty important for people getting started with the system. Since Beta3 this doesn't happen any more. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-9367) Failure to start OSGi subsystem eagerly

by Thomas Diesler (JIRA)

Failure to start OSGi subsystem eagerly --------------------------------------- Key: JBAS-9367 URL: https://issues.jboss.org/browse/JBAS-9367 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Beta3 Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: 7.0.0.Beta4 11:54:09,816 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jbosgi.AutoInstallBundles: org.jboss.msc.service.StartException in service jbosgi.AutoInstallBundles: Failed to create auto install list at org.jboss.as.osgi.service.AutoInstallIntegration.start(AutoInstallIntegration.java:153) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_21] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21] at java.lang.Thread.run(Thread.java:619) [:1.6.0_21] Caused by: java.lang.NullPointerException at org.jboss.osgi.framework.internal.BundleManager.installBundle(BundleManager.java:317) at org.jboss.as.osgi.service.AutoInstallIntegration.start(AutoInstallIntegration.java:115) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-8869) AS trunk/build/docs folder contains the readme.html with 5.0.0.CR2 release notes

by jaikiran pai (JIRA)

AS trunk/build/docs folder contains the readme.html with 5.0.0.CR2 release notes -------------------------------------------------------------------------------- Key: JBAS-8869 URL: https://issues.jboss.org/browse/JBAS-8869 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Build System Environment: JBoss AS trunk Reporter: jaikiran pai Assignee: Paul Gier Priority: Minor JBoss AS trunk build/docs folder contains a readme.html http://anonsvn.jboss.org/repos/jbossas/trunk/build/docs/readme.html which is 5.0.0.CR2 release notes. This gets copied over to the distribution. I think we should get rid of that file from that build/docs folder. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (JBREM-1282) ServerInvoker does not close StreamHandler in the case of "addstreamcallback"

by Ramesh Reddy (JIRA)

ServerInvoker does not close StreamHandler in the case of "addstreamcallback" ----------------------------------------------------------------------------- Key: JBREM-1282 URL: https://issues.jboss.org/browse/JBREM-1282 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.1 (Flounder) Reporter: Ramesh Reddy Attachments: JBossRemoting.patch This started out http://community.jboss.org/thread/163742 and in Teiid project we created a JIRA for this https://issues.jboss.org/browse/TEIID-1511 while debugging for this issue, I found that in ServerInvoker, for "AddStreamCallback" block in the "handleInternalInvocation" method it does not close the stream handler once it is done. This results in open socket connection. I am not sure if this connection closes after some idle time, but in our case user is rapidly going through deploy and undeploy action, results in too many open files. I created a patch and tested with our usecase, the problem no longer exists. Please find attached patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
15
0 / 0

[JBoss JIRA] Created: (JBRULES-2999) When using fusion's 'after' or 'before' operator the ConsequenceException (caused by NPE) is thrown.

by Tihomir Surdilovic (JIRA)

When using fusion's 'after' or 'before' operator the ConsequenceException (caused by NPE) is thrown. ---------------------------------------------------------------------------------------------------- Key: JBRULES-2999 URL: https://issues.jboss.org/browse/JBRULES-2999 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.2.0.M2 Reporter: Tihomir Surdilovic Assignee: Edson Tirelli Priority: Blocker When using 'after' or 'before' operator (maybe also other operators) in simple rule, the ConseqeunceException (cased by NPE) is thrown. The rule and simple test that reproduce this exception are attached. I discussed this with Edson Tirelli and it's a regression. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2011