[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
[JBoss JIRA] Created: (EJBTHREE-1330) EJB timer service should use a thread pool to avoid OOM
by Galder Zamarreno (JIRA)
EJB timer service should use a thread pool to avoid OOM
-------------------------------------------------------
Key: EJBTHREE-1330
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1330
Project: EJB 3.0
Issue Type: Bug
Components: pool
Affects Versions: AS 4.2.2.GA
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
The default EJB timer service used by the EJB3 layer is based on
org.jboss.ejb3.timerservice.jboss.JBossTimerServiceFactory which delegates
to the standard org.jboss.ejb.txtimer.EJBTimerService.
For EJB3 beans using the EJB timer service the thread local pool should not be used.
Since the current EJB timer service creates a new thread for each timer being created, the
thread local pool will create a matching instance of the bean for that thread. Thus the number
of active instances in total can effectively grow unchecked and thus an OOM will occur.
--
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, 11 months
[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException
by John Mazzitelli (JIRA)
cannot init cause of ClassCastException
---------------------------------------
Key: JBREM-552
URL: http://jira.jboss.com/jira/browse/JBREM-552
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.Beta2 (Boon)
Reporter: John Mazzitelli
Assigned To: Tom Elrod
Priority: Minor
Fix For: 2.0.0.CR1 (Boon)
I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown:
java.lang.IllegalStateException: Can't overwrite cause
at java.lang.Throwable.initCause(Throwable.java:320)
at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447)
at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324)
at org.jboss.remoting.Client.connect(Client.java:385)
at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470)
at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430)
at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167)
at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820)
at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102)
Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written).
The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor.
e.g.:
new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e);
(notice the ", e" parameter).
There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here.
--
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
13 years, 1 month