December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBFORUMS-257) Not efficient admin view

by Ryszard Kozmik (JIRA)

Not efficient admin view ------------------------ Key: JBFORUMS-257 URL: http://jira.jboss.com/jira/browse/JBFORUMS-257 Project: JBoss Forums Issue Type: Bug Components: Forum Model Layer, Forum View Layer Reporter: Ryszard Kozmik Fix For: 1.0.1 RC, 1.1.0 Alpha When having lots of forums/categories in database, admin view breaks due to model layer problems. Probably something was messed up while doing view refactoring. -- 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

16 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1327) drools-ant task and java.lang.ClassCastException: org.drools.reteoo.ReteooRuleBase

by Brugger Antony (JIRA)

drools-ant task and java.lang.ClassCastException: org.drools.reteoo.ReteooRuleBase ------------------------------------------------------------------------------------ Key: JBRULES-1327 URL: http://jira.jboss.com/jira/browse/JBRULES-1327 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Environment: Windows XP / Eclipse 3.2 Reporter: Brugger Antony Priority: Blocker I try to use the drools-ant task to generate a package file like this: <target name="rules2" > <rulebase srcdir="../src/main/rules" tofile="../rulePackage/bcpRules.rules" classpathref="bcp.classpath" > <include name="testRuleBcp.drl" /> </rulebase> </target> it is working. But when I try to use it in my Java code with this code: RuleAgent agent = RuleAgent.newRuleAgent("/ruleAgent.properties"); RuleBase ruleBase = agent.getRuleBase(); ruleAgent.properties file: ## ## RuleAgent configuration file ## dir=./rulePackage poll=30 name=MyBcpConfig I have the following exception: RuleAgent(MyBcpConfig) INFO (Thu Nov 15 16:16:20 CET 2007): Configuring with newInstance=false, secondsToRefresh=30 RuleAgent(MyBcpConfig) INFO (Thu Nov 15 16:16:20 CET 2007): Configuring package provider : DirectoryScanner scanning dir: .\rulePackage found 1 file(s). java.lang.ClassCastException: org.drools.reteoo.ReteooRuleBase at org.drools.agent.FileScanner.readPackage(FileScanner.java:109) at org.drools.agent.FileScanner.getChangeSet(FileScanner.java:79) at org.drools.agent.FileScanner.loadPackageChanges(FileScanner.java:57 Indeed when I look at the code: - in the ant task org.drools.contrib.DroolsCompilerAntTask, this is a RuleBase object that is serialized: private void serializeRulebase(RuleBase ruleBase) throws FileNotFoundException, IOException { ObjectOutputStream outstream = null; try { FileOutputStream fout = new FileOutputStream(toFile); outstream = new ObjectOutputStream(fout); outstream.writeObject(ruleBase); } finally { if (outstream != null) { outstream.close(); } } } - in the ruleAgent class org.drools.agent.FileScanner is expecting a Package object to deserialized at line 109: p1_ = (Package) in.readObject(); hence the ClassCastException... -- 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

16 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAOP-495) run-precompiled refers wrong jar

by Oleg Mikheev (JIRA)

run-precompiled refers wrong jar -------------------------------- Key: JBAOP-495 URL: http://jira.jboss.com/jira/browse/JBAOP-495 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Oleg Mikheev Priority: Minor run-precompiled.bar always results in class not found exception b/c it refers wrong jar in the classpath. it refers ..\lib-50\jboss-container-metadata-spi.jar while it is not present in lib-50 folder. it should either refer jboss-container.jar or jboss-container-metadata-spi.jar should be present. same story with run-precompiled.sh -- 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

16 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAOP-496) run-precompiled.bat never runs the class

by Oleg Mikheev (JIRA)

run-precompiled.bat never runs the class ---------------------------------------- Key: JBAOP-496 URL: http://jira.jboss.com/jira/browse/JBAOP-496 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Environment: Win32 Reporter: Oleg Mikheev %MAINCLASS_AND_ARGS% is never set in run-precompiled.bat so, the class that is to be run can never be executed actually run-precompiled.bat is not functional at all with this kind of behavior :) -- 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

16 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-697) First concurrent call doesn't throw exception

by Carlo de Wolf (JIRA)

First concurrent call doesn't throw exception --------------------------------------------- Key: EJBTHREE-697 URL: http://jira.jboss.com/jira/browse/EJBTHREE-697 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Reporter: Carlo de Wolf Priority: Critical Fix For: EJB 3.0 RC10 - FD Concurrency check is in the server interceptor, while identity is established in the proxy after the first call. So if the first call is concurrent no exception is thrown. (see unit test concurrent) -- 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

16 years, 10 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-844) Put instance variable "isRemotingUserAgent" on stack in CoyoteInvoker

by Ron Sigal (JIRA)

Put instance variable "isRemotingUserAgent" on stack in CoyoteInvoker --------------------------------------------------------------------- Key: JBREM-844 URL: http://jira.jboss.com/jira/browse/JBREM-844 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) In org.jboss.remoting.transport.CoyoteInvoker, the variable "isRemotingUserAgent" is declared as an instance variable, which creates a race condition among multiple threads. -- 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

16 years, 10 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-826) JBoss Remoting logs at ERROR and WARN in many places

by Tim Fox (JIRA)

JBoss Remoting logs at ERROR and WARN in many places ---------------------------------------------------- Key: JBREM-826 URL: http://jira.jboss.com/jira/browse/JBREM-826 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Tim Fox Fix For: 2.4.0.Beta1 (Pinto) In many places JBoss Remoting logs at ERROR or WARN which seem inappropriate. JBR is a toolkit and should not log errors it does not handle. If every toolkit being used in the chain logged the same error then you end up with a complete mess in the logs every time an exeception occurs. There is a general principle of you shouldn't log unless you handle the error. If you just pass it up, don't log. This principle is adhered to in JBoss AS for example, and IMHO should be used throughout all JBoss projectsd Failover in JBoss Messaging is a good example. In JBM we detect failure of the remoting connection via the connection listener, and transparently reconnect on a different node. In this case, from the users POV *no error* has occurred - the process should be completely seamless. However JBoss Remoting spews a load of exceptions to the logs at ERROR and WARN, for example: @main 08:01:30,648 INFO [ServerManagement] Waiting for server to die @main 08:01:30,953 INFO [ServerManagement] server 1 killed and dead @Timer-3 08:01:31,253 ERROR [SocketClientInvoker] Got marshalling exception, exiting java.net.SocketException: end of file at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:577) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.ConnectionValidator.doCheckConnection(ConnectionValidator.java:133) at org.jboss.remoting.ConnectionValidator.run(ConnectionValidator.java:308) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) @Thread-9 08:01:31,277 WARN [ClientClusteredConnectionFactoryDelegate] org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2117/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat] org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2117/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:532) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.removeCallback(ClientClusteredConnectionFactoryDelegate.java:152) at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.closeCallback(ClientClusteredConnectionFactoryDelegate.java:168) at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.establishCallback(ClientClusteredConnectionFactoryDelegate.java:93) at org.jboss.jms.client.remoting.ConnectionFactoryCallbackHandler$CallbackConnectionListener.handleConnectionException(ConnectionFactoryCallbackHandler.java:105) at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:452) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:519) at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:187) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket(BisocketClientInvoker.java:420) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:815) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:525) ... 9 more @Thread-9 08:01:31,299 WARN [Client] unable to remove remote callback handler: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2117/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat] SERVER 0 STDOUT: @Timer-4 08:01:31,301 ERROR [SocketClientInvoker] Got marshalling exception, exiting SERVER 0 STDOUT: java.net.SocketException: end of file SERVER 0 STDOUT: at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:577) SERVER 0 STDOUT: at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413) SERVER 0 STDOUT: at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) @Thread-9 08:01:31,320 WARN [LeasePinger] LeasePinger[SocketClientInvoker[c0f1ec, bisocket://localhost:2117](3j001-bj8ucn-f8e4sbxc-1-f8e4sby7-3)] failed sending disconnect for client lease for client with session ID 3j001-bj8ucn-f8e4sbxc-1-f8e4sbxd-2 SERVER 0 STDOUT: at org.jboss.remoting.ConnectionValidator.doCheckConnection(ConnectionValidator.java:133) SERVER 0 STDOUT: at org.jboss.remoting.ConnectionValidator.run(ConnectionValidator.java:308) SERVER 0 STDOUT: at java.util.TimerThread.mainLoop(Timer.java:512) SERVER 0 STDOUT: at java.util.TimerThread.run(Timer.java:462) @Thread-9 08:01:31,345 WARN [LeasePinger] LeasePinger[SocketClientInvoker[c0f1ec, bisocket://localhost:2117](3j001-bj8ucn-f8e4sbxc-1-f8e4sby7-3)] failed to ping to server: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2117/?cli This completely messes up the logs and the customer believes something has gone wrong, phones support and they waste a lot of time trying to work out what the problem is, when actually there is no problem and this is perfectly successful failover from one node to another, but to the customer they have a flawed experience. If anything is to be logged in these cases it should be at DEBUG level at the highest, so it can be easily supressed in the standard log4j config. In the mean-time if you could provide a log4j config which supresses these messages for the specific classes so they don't appear even on ERROR level that would be much appreciated. -- 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

16 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-1286) Incorrect information in section 2.5.7.3. Agenda Filters

by Sergey Manukyan (JIRA)

Incorrect information in section 2.5.7.3. Agenda Filters -------------------------------------------------------- Key: JBRULES-1286 URL: http://jira.jboss.com/jira/browse/JBRULES-1286 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Manual Affects Versions: 4.0.2 Reporter: Sergey Manukyan Assigned To: Mark Proctor CORRECTION #1 Manual states : To use a filter specify it while calling FireAllRules. The following example will filter out all rules ending with the text "Test": workingMemory.fireAllRules( new RuleNameEndsWithAgendaFilter( "Test" ) ); Should be: To use a filter specify it while calling FireAllRules. The following example will only allow activation of rules ending with the text "Test". All others will be filtered out.: workingMemory.fireAllRules( new RuleNameEndsWithAgendaFilter( "Test" ) ); CORRECTION #2 Manual states : RuleNameEndWithAgendaFilter Should be : RuleNameEndsWithAgendaFilter -- 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

16 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1099) Split documentation in "reference manual" and "user guide"

by Gernot Starke (JIRA)

Split documentation in "reference manual" and "user guide" ---------------------------------------------------------- Key: JBRULES-1099 URL: http://jira.jboss.com/jira/browse/JBRULES-1099 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Documentation Environment: all Reporter: Gernot Starke Assigned To: Mark Proctor Priority: Minor imho documentation for a product like JBoss Drools should consist of several DISTINCT parts, at least reference manual and user guide. That'd make it two different manuals - but especially the language documentation should get a more promininent location... (reference manual) -- 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

16 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1212) Improve performance on JBMExecutor

by Clebert Suconic (JIRA)

Improve performance on JBMExecutor ---------------------------------- Key: JBMESSAGING-1212 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1212 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.4.0.SP3 Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: Stable branch Because of JBMESSAGING-1200 we had to play with classLoader on the executor, and because of that we had to play with Security checks, for classLoader operations. It would be better to not do it on the executor... So I should investigate about setting the classLoader only on createProducer, createConsumer and its respective close methods. I will need to validate this against JCA and the TCK that was failing because of JBMESSAGING-1200 before. -- 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

16 years, 10 months

2
7
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007