[JBoss JIRA] Created: (JBWEB-72) html page and jsp are not display with in a Context defined in server.xml.
by Jean-Frederic Clere (JIRA)
html page and jsp are not display with in a Context defined in server.xml.
--------------------------------------------------------------------------
Key: JBWEB-72
URL: http://jira.jboss.com/jira/browse/JBWEB-72
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: JBoss Web Server 1.0.1 GA
Environment: any
Reporter: Jean-Frederic Clere
Assigned To: Jean-Frederic Clere
Priority: Minor
When using a Context definition in server.xml like:
<Context path="/test" docBase="/home/jfclere/TMP/MYAPP" />
The jsp and html pages of /home/jfclere/TMP/MYAPP are not displayed (404 is returned).
That is because the conf/web.xml is not used to set the defaults when the <Context/> is processed.
DefaultWebXml is set in TomcatDeployer and that is after the <Context/> needs it. The default value is used but it is set to "web.xml".
--
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, 8 months
[JBoss JIRA] Created: (JBRULES-680) Support real-time problem modification during solving with utils for the single thread subsystem
by Geoffrey De Smet (JIRA)
Support real-time problem modification during solving with utils for the single thread subsystem
------------------------------------------------------------------------------------------------
Key: JBRULES-680
URL: http://jira.jboss.com/jira/browse/JBRULES-680
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Solver
Reporter: Geoffrey De Smet
Assigned To: Geoffrey De Smet
Rete/Drools is single threaded, and so is the current implementation of the localsearchsolver,
but this single thread subsystem should be documented
and utils should be provided to allow for real-time problem modification
A simple way would be to use a producer-consumer pattern with a non blocking queue which holds "problem moves".
Each step the problem moves could be used.
Problems:
- bestsolutionrecalled also needs it's score adjusted. so we'll need a 2th working memory:
-- EITHER temporary, just for the problem move (or set of problem moves)
-- EITHER all the time, but then we'd have to hold a chain of moves, some of which might not be doable at the end
- cached selectors must be notified of refreshing their cache
- solution cloning normally doesn't clone the problem facts, just the proposed solution references. Do we need a full clone now?
--
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, 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
13 years, 10 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
13 years, 10 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
14 years, 1 month
[JBoss JIRA] Created: (JBREM-652) allow passing of config map when creating transporter client
by Tom Elrod (JIRA)
allow passing of config map when creating transporter client
------------------------------------------------------------
Key: JBREM-652
URL: http://jira.jboss.com/jira/browse/JBREM-652
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Components: transporter
Affects Versions: 2.2.0.Alpha4
Reporter: Tom Elrod
Assigned To: Tom Elrod
Fix For: 2.2.0.Beta1 (Bluto)
Currently the transporter client can only be created using invoker locator for configuration. Need to add to the api so can pass config map which gets passed to the remoting client that is created so can customize things such as ssl config. For example, would be need to be able to something like is done in org.jboss.test.remoting.transport.socket.ssl.custom.InvokerClientTest with a transporter client.
--
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
14 years, 1 month