[JBoss JIRA] Created: (JBRULES-1801) drools-ant-4.0.7, DroolsCompilerAntTask, classloader mixup leads to ClassCastException if drools-compiler.jar part of classpathref
by Juergen none (JIRA)
drools-ant-4.0.7, DroolsCompilerAntTask, classloader mixup leads to ClassCastException if drools-compiler.jar part of classpathref
----------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-1801
URL: https://jira.jboss.org/jira/browse/JBRULES-1801
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-ant
Affects Versions: 4.0.7
Reporter: Juergen none
Assignee: Mark Proctor
drools-4.0.7:
Original error in build.xml:
/home/juergen/workspace/eclipse/kusss-dev/build.xml:777: RuleBaseTask failed: Unable to load dialect 'org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java'
Traceback to:
org.drools.compiler.PackageBuilderConfiguration, line 154+:
Class cls = classLoader.loadClass( dialectClass );
DialectConfiguration dialectConf = (DialectConfiguration) cls.newInstance();
cls is org.drools.rule.builder.dialect.java.JavaDialectConfiguration, but loaded via classloader given in drools compile ant task property classpathref, while DialectConfiguration is loaded via ant tool classpath used for taskdef
-->
java.lang.ClassCastException: org.drools.rule.builder.dialect.java.JavaDialectConfiguration
interim fix:
make sure drools-compiler.jar is not in classpath of classloaderref
suggested fix:
Class cls = DialectConfiguration.class.getClassLoader().loadClass( dialectClass );
--
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
12 years, 9 months
[JBoss JIRA] Created: (JBAS-5515) Failed to load users/passwords/role files
by Heiko Braun (JIRA)
Failed to load users/passwords/role files
-----------------------------------------
Key: JBAS-5515
URL: http://jira.jboss.com/jira/browse/JBAS-5515
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Heiko Braun
Fix For: JBossAS-5.0.0.CR1
21:25:41,277 ERROR [UsersRolesLoginModule] Failed to load users/passwords/role files
java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
at org.jboss.security.auth.spi.Util.loadProperties(Util.java:366)
at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186)
at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200)
at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127)
When executing
one-test:
[junit] Running org.jboss.test.ws.jaxws.samples.context.WebServiceContextEJBTestCase
[junit] Tests run: 3, Failures: 0, Errors: 3, Time elapsed: 2.421 sec
[junit] Test org.jboss.test.ws.jaxws.samples.context.WebServiceContextEJBTestCase FAILED
--
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
12 years, 9 months
[JBoss JIRA] Created: (JBRULES-681) Multi-threaded local search solving
by Geoffrey De Smet (JIRA)
Multi-threaded local search solving
-----------------------------------
Key: JBRULES-681
URL: http://jira.jboss.com/jira/browse/JBRULES-681
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Solver
Reporter: Geoffrey De Smet
Assigned To: Geoffrey De Smet
Priority: Optional
Use Future's to spread all possible moves in each step over a number of threads.
This number of threads is equal to the number of cpu's by default, as no IO is done during solving.
Problems:
- each thread will needs it own WorkingMemory and during a step, each working memory will need to be updated
- a bunch of classes will need to be thread safe, or at least visibility save, such as bestsolutionrecaller.
- Barriers will be needed to collect the result of each step
- decks might be a great way to spread out the load
--
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
12 years, 9 months
[JBoss JIRA] Created: (EJBTHREE-880) Hard-coded localhost in ejb3 test suite
by Aleksandar Kostadinov (JIRA)
Hard-coded localhost in ejb3 test suite
---------------------------------------
Key: EJBTHREE-880
URL: http://jira.jboss.com/jira/browse/EJBTHREE-880
Project: EJB 3.0
Issue Type: Bug
Reporter: Aleksandar Kostadinov
When the ejb3 testsuite is run with "-Dnode0=IP1 -Dnode1=IP2" and IP1!=localhost there are some tests failing with "Retries exceeded, couldn't reconnect to 127.0.0.1:####". I see this for 4_0 and 4_2 jboss branches, but guess it's the same with head.
One of the testcases is IiopRemoteUnitTestCase. I've checked ejb3/src/test/org/jboss/ejb3/test/iiop/unit/IiopRemoteUnitTestCase.java and there is 'props.put("java.naming.provider.url", "corbaloc::localhost:3528/NameService");'. Instead of localhost there should be used the node0 property. I guess the others have the same problem.
--
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
12 years, 9 months
[JBoss JIRA] Created: (JASSIST-44) Maven profiles for tools.jar should take account of Mac OS
by Martin Burger (JIRA)
Maven profiles for tools.jar should take account of Mac OS
----------------------------------------------------------
Key: JASSIST-44
URL: http://jira.jboss.com/jira/browse/JASSIST-44
Project: Javassist
Issue Type: Bug
Environment: Maven version: 2.0.8
Java version: 1.5.0_13
OS name: "mac os x" version: "10.4.11" arch: "i386" Family: "unix"
Reporter: Martin Burger
Assigned To: Shigeru Chiba
The pom.xml uses different profiles to add the tools.jar to the dependencies. However, it is already included in the runtime for Mac OS X and some free JDKs and does not exist as a separate file 'tools.jar'. See: http://maven.apache.org/general.html#tools-jar-dependency
As soon as http://jira.codehaus.org/browse/MNG-3106 gets fixed, activation should look like the following example:
<activation>
<jdk>1.6</jdk>
<property>
<name>java.vendor</name>
<value>Sun Microsystems Inc.</value>
</property>
</activation>
In the meantime
<profiles>
<profile>
<id>tools.jar</id>
<activation>
<property>
<name>java.vendor</name>
<value>Sun Microsystems Inc.</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.6</version>
<scope>system</scope>
<optional>true</optional>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
</profile>
</profiles>
should do the job. It could be a permanent solution because the different profiles differ only in the version element.
--
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
12 years, 9 months