May 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBRULES-3418) 5.3.x Regression: Declared Super-Types: Compile-time error

by Michael Anstis (JIRA)

Michael Anstis created JBRULES-3418: --------------------------------------- Summary: 5.3.x Regression: Declared Super-Types: Compile-time error Key: JBRULES-3418 URL: https://issues.jboss.org/browse/JBRULES-3418 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.3.1.Final Reporter: Michael Anstis Assignee: Mark Proctor Priority: Critical See test PackageBuilderTests.testDeclaredSuperTypeFields(). *5.3.x Branch only* org.drools.RuntimeDroolsException: Unable to resolve Type Declaration superclass 'foo.Bean1' at org.drools.compiler.PackageBuilder.mergeInheritedFields(PackageBuilder.java:1565) at org.drools.compiler.PackageBuilder.mergeInheritedFields(PackageBuilder.java:1485) at org.drools.compiler.PackageBuilder.processTypeDeclarations(PackageBuilder.java:1761) at org.drools.compiler.PackageBuilder.mergePackage(PackageBuilder.java:1123) at org.drools.compiler.PackageBuilder.newPackage(PackageBuilder.java:1109) at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:802) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:404) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:379) at org.drools.compiler.PackageBuilderTest.testDeclaredSuperTypeFields(PackageBuilderTest.java:1334) 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.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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) 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.runners.ParentRunner.run(ParentRunner.java:236) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
40
0 / 0

[JBoss JIRA] (REMJMX-12) Allow for protocol versions to be excluded client and server side

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-12?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-12: ----------------------------------- Priority: Blocker (was: Major) This is raised to Blocker level as once we have support for more than one protocol versions we need to be able to exclude versions - the reason being that if once version is identified as having a major flaw we may need to exclude it to prevent it's use. One example is a server that supports versions 1, 2, and 3 - a critical bug was found in 2 and fixed in 3. The client only supports 1, and 2 - by default they would negotiate to use 2 but as it has a critical bug it should be excluded and negotiate to use 1. > Allow for protocol versions to be excluded client and server side > ----------------------------------------------------------------- > > Key: REMJMX-12 > URL: https://issues.jboss.org/browse/REMJMX-12 > Project: Remoting JMX > Issue Type: Task > Components: Connection > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta1 > > > Once we start supporting multiple versions of the protocols we should also allow version to be excluded client and server side. > This will mean if a version is identified as being problematic is can be excluded to force the use of a previous version. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4674) Child resources displayed out of order

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-4674: ----------------------------------- Summary: Child resources displayed out of order Key: AS7-4674 URL: https://issues.jboss.org/browse/AS7-4674 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.1.1.Final Reporter: Thomas Diesler Assignee: Jason Greene Fix For: 7.2.0.Alpha1 A runtime resource may have child resource entries that have a natural ordering. Ordering should not be ignored {code} [standalone@localhost:9999 /] /subsystem=osgi:read-resource(include-runtime=true,recursive=true) { "outcome" => "success", "result" => { "activation" => "eager", "startlevel" => 1, "bundle" => { "1" => { "id" => 1L, "location" => "org.osgi.enterprise", "startlevel" => 1, "state" => "RESOLVED", "symbolic-name" => "osgi.enterprise", "type" => "bundle", "version" => "4.2.0.201003190513" }, "0" => { "id" => 0L, "location" => "System Bundle", "startlevel" => 0, "state" => "ACTIVE", "symbolic-name" => "system.bundle", "type" => "bundle", "version" => "0.0.0" }, "6" => { "id" => 6L, "location" => "org.jboss.as.osgi.configadmin", "startlevel" => 1, "state" => "ACTIVE", "symbolic-name" => "jboss-as-osgi-configadmin", "type" => "bundle", "version" => "7.1.2.Final-SNAPSHOT" }, "5" => { "id" => 5L, "location" => "org.apache.felix.configadmin", "startlevel" => 1, "state" => "ACTIVE", "symbolic-name" => "org.apache.felix.configadmin", "type" => "bundle", "version" => "1.2.8" }, "4" => { "id" => 4L, "location" => "org.jboss.osgi.logging", "startlevel" => 1, "state" => "ACTIVE", "symbolic-name" => "jboss-osgi-logging", "type" => "bundle", "version" => "1.0.0" }, "3" => { "id" => 3L, "location" => "org.apache.felix.log", "startlevel" => 1, "state" => "ACTIVE", "symbolic-name" => "org.apache.felix.log", "type" => "bundle", "version" => "1.0.0" }, "2" => { "id" => 2L, "location" => "javax.servlet.api:v25", "startlevel" => 1, "state" => "RESOLVED", "symbolic-name" => "javax.servlet.api", "type" => "bundle", "version" => "2.5.0.Final" } }, "capability" => { "javax.transaction.api" => {}, "org.jboss.osgi.logging" => {"startlevel" => "1"}, "javax.servlet.api:v25" => {}, "org.jboss.as.osgi.configadmin" => {"startlevel" => "1"}, "org.apache.felix.log" => {"startlevel" => "1"}, "org.apache.felix.configadmin" => {"startlevel" => "1"} }, "property" => {"org.osgi.framework.startlevel.beginning" => {"value" => "1"}} } } {code} In the case of OSGi, the runtime bundles should be sorted by id. For natural ordering, the ResourceEntry could implement Comparable<ResourceEntry> {code} Set<ResourceEntry> getChildren(String childType) {code} alternatively, the controller could preserve the implicit order of the returned set (i.e. internally using a List). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
3
0 / 0

[JBoss JIRA] (AS7-4840) OSGi subsystem does not call BundleActivator

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-4840?page=com.atlassian.jira.plugin.s... ] Thomas Diesler updated AS7-4840: -------------------------------- Forum Reference: https://community.jboss.org/thread/199949 > OSGi subsystem does not call BundleActivator > -------------------------------------------- > > Key: AS7-4840 > URL: https://issues.jboss.org/browse/AS7-4840 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP) > Reporter: Rico Neubauer > Assignee: Thomas Diesler > Labels: osgi > Attachments: SimpleOSGi_1.0.0.201205181614.jar > > > Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final > OSGi activators do not get called after bundle starts. Instead nothing happens. > Test bundle attached, but happens with any activator bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4840) OSGi subsystem does not call BundleActivator

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-4840?page=com.atlassian.jira.plugin.s... ] Thomas Diesler commented on AS7-4840: ------------------------------------- Lets take this to the forum: https://community.jboss.org/thread/199949 > OSGi subsystem does not call BundleActivator > -------------------------------------------- > > Key: AS7-4840 > URL: https://issues.jboss.org/browse/AS7-4840 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP) > Reporter: Rico Neubauer > Assignee: Thomas Diesler > Labels: osgi > Attachments: SimpleOSGi_1.0.0.201205181614.jar > > > Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final > OSGi activators do not get called after bundle starts. Instead nothing happens. > Test bundle attached, but happens with any activator bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBRULES-3275) MVEL Dialect: BigDecimal does not show the correct value

by Alessandro Lazarotti (Created) (JIRA)

MVEL Dialect: BigDecimal does not show the correct value -------------------------------------------------------- Key: JBRULES-3275 URL: https://issues.jboss.org/browse/JBRULES-3275 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.3.0.Final, 5.2.0.Final Environment: Fedora 15, JDK Oracle 1.6 Reporter: Alessandro Lazarotti Assignee: Mario Fusco MVEL does not show the correct value for BigDecimal instances, like: BigDecimal ale = 500.01B; System.out.println(ale); The result is: 500 BigDecimal should invoke toString, like any Java instance to show values of variables instead of .intValue(). The same happens to show result of arithmetic operations btw BigDecimals: BigDecimal test = new BigDecimal("50000"); System.out.println(test / new BigDecimal("1.13")); The result is: 44247 ... instead of 44247.78761061946902654867256637168. Anyway, the internal representation is correct, only the method invoked to show the values is wrong. The result for: System.out.println( (test / new BigDecimal("1.13")) == 44247.78761061946902654867256637168B) is true. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

6
10
0 / 0

[JBoss JIRA] (AS7-4840) OSGi subsystem does not call BundleActivator

by Rico Neubauer (JIRA)

[ https://issues.jboss.org/browse/AS7-4840?page=com.atlassian.jira.plugin.s... ] Rico Neubauer commented on AS7-4840: ------------------------------------ OK, understood - even if I find this disturbing as a change in behavior between 7.1.1 and 7.1.2. But how is one supposed to configure the start of OSGi bundles after deployment? Not using the CLI/Console of course, but to configure it to call the activator on each start-up? > OSGi subsystem does not call BundleActivator > -------------------------------------------- > > Key: AS7-4840 > URL: https://issues.jboss.org/browse/AS7-4840 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP) > Reporter: Rico Neubauer > Assignee: Thomas Diesler > Labels: osgi > Attachments: SimpleOSGi_1.0.0.201205181614.jar > > > Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final > OSGi activators do not get called after bundle starts. Instead nothing happens. > Test bundle attached, but happens with any activator bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBAS-9495) JBoss does not start when the installation path contains Japanese/Chinese characters

by Y D Prakash (JIRA)

Y D Prakash created JBAS-9495: --------------------------------- Summary: JBoss does not start when the installation path contains Japanese/Chinese characters Key: JBAS-9495 URL: https://issues.jboss.org/browse/JBAS-9495 Project: Application Server 3 4 5 and 6 Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.GA Environment: Windows-Japanese-OS Reporter: Y D Prakash JBossAS-5.0.0GA does not start properly if the installation path contains Japanese/Chinese characters. It throws the error as follows: 2012-05-18 11:56:34,489 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Instantiated: name=TransactionManager state=Described java.lang.ExceptionInInitializerError: java.net.MalformedURLException: unknown protocol: c -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] (AS7-4840) OSGi subsystem does not call BundleActivator

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-4840?page=com.atlassian.jira.plugin.s... ] Thomas Diesler edited comment on AS7-4840 at 5/21/12 3:47 AM: -------------------------------------------------------------- Yes, CLI/Console is the same thing. Operation 'deploy' does a 'bundle install' - there is no implicit 'bundle start' The reason is that we don't want to create an implicit ordering requirement on the 'deploy' operation. IOW it should be possible to deploy artefacts in any order. I suspect that future AS7 versions will have a --start flag on the deploy operation. was (Author: thomas.diesler): Yes, this CLI/Console is the same thing. Operation 'deploy' does a 'bundle install' - there is no implicit 'bundle start' The reason is that we don't want to create an implicit ordering requirement on the 'deploy' operation. IOW it should be possible to deploy artefacts in any order. I suspect that future AS7 versions will have a --start flag on the deploy operation. > OSGi subsystem does not call BundleActivator > -------------------------------------------- > > Key: AS7-4840 > URL: https://issues.jboss.org/browse/AS7-4840 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP) > Reporter: Rico Neubauer > Assignee: Thomas Diesler > Labels: osgi > Attachments: SimpleOSGi_1.0.0.201205181614.jar > > > Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final > OSGi activators do not get called after bundle starts. Instead nothing happens. > Test bundle attached, but happens with any activator bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4840) OSGi subsystem does not call BundleActivator

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-4840?page=com.atlassian.jira.plugin.s... ] Thomas Diesler commented on AS7-4840: ------------------------------------- Yes, this CLI/Console is the same thing. Operation 'deploy' does a 'bundle install' - there is no implicit 'bundle start' The reason is that we don't want to create an implicit ordering requirement on the 'deploy' operation. IOW it should be possible to deploy artefacts in any order. I suspect that future AS7 versions will have a --start flag on the deploy operation. > OSGi subsystem does not call BundleActivator > -------------------------------------------- > > Key: AS7-4840 > URL: https://issues.jboss.org/browse/AS7-4840 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP) > Reporter: Rico Neubauer > Assignee: Thomas Diesler > Labels: osgi > Attachments: SimpleOSGi_1.0.0.201205181614.jar > > > Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final > OSGi activators do not get called after bundle starts. Instead nothing happens. > Test bundle attached, but happens with any activator bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
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 May 2012