October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1138) User extensible configuration should be centralised - configuration settings allowing <class> and <properties> defintions

by Galder Zamarreno (JIRA)

User extensible configuration should be centralised - configuration settings allowing <class> and <properties> defintions ------------------------------------------------------------------------------------------------------------------------- Key: JBCACHE-1138 URL: http://jira.jboss.com/jira/browse/JBCACHE-1138 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Galder Zamarreno Assigned To: Manik Surtani Priority: Minor Fix For: 2.1.0.GA There's a common pattern in configuration set for: - cache loader - buddy locator - and forthcoming singleton store cache loader The pattern is that all three are user extensible in the sense that: - user can redefine the class used to provide the functionality - properties of this functionality can be defined via <properties> element We should consolidate this into some kind of UserExtensibleConfigurationElement that includes class and properties logic. -- 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

18 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1251) Cannot remove a category if it was used in an archived rule

by Shahad Ahmed (JIRA)

Cannot remove a category if it was used in an archived rule ----------------------------------------------------------- Key: JBRULES-1251 URL: http://jira.jboss.com/jira/browse/JBRULES-1251 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.1 Reporter: Shahad Ahmed Assigned To: Mark Proctor The BRMS manual says you can delete a category if it is not in use by any current version of a rule. However, if you archive a rule that uses a category X, say, then you cannot remove category X in the Admin section, even if no other rules in the repository use category X. You get the following error message: "The category still has some assets linked to it. You will need to remove the links so you can delete the cateogory" (PS not the spelling mistake cateogory in the error message) Either the manual (Section 9.4.2.2) should be updated with a warning that you cannot remove a category used by archived rules, or is there is a bug in the remove category functionality for archived assets, as you can remove categories which are only used in old versions of a rule? -- 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

18 years, 1 month

4
4
0 / 0

[JBoss JIRA] Created: (JBRULES-1292) BRMS ignores "initial description" entered when creating new "Business rule using a DSL (text editor)" rule

by Phil Verghese (JIRA)

BRMS ignores "initial description" entered when creating new "Business rule using a DSL (text editor)" rule ----------------------------------------------------------------------------------------------------------- Key: JBRULES-1292 URL: http://jira.jboss.com/jira/browse/JBRULES-1292 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.2 Reporter: Phil Verghese Assigned To: Mark Proctor When creating a new rule asset through the BRMS using the type "Business rule using a DSL (text editor)", the initial description you put in is ignored. You always get the description "A dsl is a language mapping from a domain specific language to the rule language." -- 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

18 years, 1 month

6
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1290) BRMS does not allow rule names to contain an apostrophe character ( ' )

by Phil Verghese (JIRA)

BRMS does not allow rule names to contain an apostrophe character ( ' ) ----------------------------------------------------------------------- Key: JBRULES-1290 URL: http://jira.jboss.com/jira/browse/JBRULES-1290 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.2 Reporter: Phil Verghese Assigned To: Mark Proctor Rules with apostrophe characters are rejected by the BRMS. For example the rule name "Set employee's wage" works outside BRMS, but does not work in BRMS. If you attempt to enter a rule through the BRMS containing an apostrophe,the error stack trace says "An error occurred executing the action. Details com.google.gwt.user.client.rpc.SerializableException: javax.jcr.RepositoryException: failed to resolve path Set employee's relative to /drools:repository/drools:package_area/com.example/assets: Invalid name: Set employee's wage: Invalid name: Set employee's wage at org.drools.brms.server.ServiceImplementation.createNewRule(ServiceImplementation.java:166)..." If you attempt to import a .drl file with a rule that has an apostrophe in the title, you'll get this error message (including the <pre> tags): "Unable to import into the package. [<pre>Unable to process import: javax.jcr.RepositoryException: failed to resolve path Set employee's wage relative to /drools:repository/drools:package_area/com.soi/assets: Invalid name: Set employee's wage: Invalid name: Set employee's wage</pre>]". -- 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

18 years, 1 month

6
9
0 / 0

[JBoss JIRA] Created: (JBREM-816) Add instructions to Remoting Guide for overriding a transport or create a new transport

by Ron Sigal (JIRA)

Add instructions to Remoting Guide for overriding a transport or create a new transport --------------------------------------------------------------------------------------- Key: JBREM-816 URL: http://jira.jboss.com/jira/browse/JBREM-816 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP1 Reporter: Ron Sigal Assigned To: Trustin Lee Priority: Minor Fix For: 2.4.0.CR1 (Pinto) Client and server invokers are created by the org.jboss.remoting.InvokerRegistry class, which will look for classes called TransportClientFactory and TransportServerFactory in the directory org/jboss/remoting/transport/<transport> and use them to create client and server invokers for the <transport> transport. The current discussion of this facility in the Remoting Guide is rather brief. -- 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

18 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-633) Investigate timeout during org.jboss.test.remoting.transport.multiplex.invoker.MultiplexInvokerTestCase

by Ron Sigal (JIRA)

Investigate timeout during org.jboss.test.remoting.transport.multiplex.invoker.MultiplexInvokerTestCase ------------------------------------------------------------------------------------------------------- Key: JBREM-633 URL: http://jira.jboss.com/jira/browse/JBREM-633 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta1 (Bluto) Occurred on 11/4/06 and 11/5/06 for jdk 1.4. -- 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

18 years, 1 month

3
8
0 / 0

[JBoss JIRA] Created: (JBREM-628) Find source of EOFException in multiplex unit tests on cruisecontrol.

by Ron Sigal (JIRA)

Find source of EOFException in multiplex unit tests on cruisecontrol. --------------------------------------------------------------------- Key: JBREM-628 URL: http://jira.jboss.com/jira/browse/JBREM-628 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta1 (Bluto) Some multiplex unit tests, seemingly at random, are failing with EOFException. E.g., org.org.jboss.test.remoting.transport.multiplex.config.ConfigurationByMapDiffStaticObjectsTestServer. -- 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

18 years, 1 month

3
8
0 / 0

[JBoss JIRA] Created: (JBREM-549) remove dependancy on concurrent.jar within remoting client

by Tom Elrod (JIRA)

remove dependancy on concurrent.jar within remoting client ---------------------------------------------------------- Key: JBREM-549 URL: http://jira.jboss.com/jira/browse/JBREM-549 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.CR1 (Boon) Currently, the remoting clients will require concurrent.jar to be on the classpath because org.jboss.util.id.GUID is used to create the client session id. Problem is that org.jboss.util.id.GUID is what requires concurrent.jar. So will either need to modify the code within jboss common repository or find another class to use for generating the client session id. java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/SynchronizedLong at org.jboss.util.id.UID.<clinit>(UID.java:56) at org.jboss.util.id.VMID.create(VMID.java:259) at org.jboss.util.id.VMID.getInstance(VMID.java:223) at org.jboss.util.id.GUID.<init>(GUID.java:65) at org.jboss.remoting.Client.<init>(Client.java:133) at org.jboss.remoting.Client.<init>(Client.java:210) at org.jboss.remoting.Client.<init>(Client.java:191) at org.jboss.test.remoting.transport.InvokerClientTest.init(InvokerClientTest.java:80) -- 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

18 years, 1 month

3
12
0 / 0

[JBoss JIRA] Created: (JBREM-577) Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol

by Ron Sigal (JIRA)

Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol ---------------------------------------------------------------------------------------------------------------------- Key: JBREM-577 URL: http://jira.jboss.com/jira/browse/JBREM-577 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA (Boon) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.0.0.GA (Boon) This test is failing rather consistently in testRule4ServerFirst() on cruisecontrol, even though this particular failure can't be reproduced on any other environment. In case the problem is more than environmental, i.e., a real problem in Multiplex, some additional log statements will be added to MultiplexServerInvoker and OutputMultiplexor. What is happening is that in runPushCallbackTests(), the message "stopped callback Connector" appears, but then the test dies before the callback Connector completes its shut down. It would be nice to believe that there is a deadlock, but none is evident, unless it's due to a problem with Collections.synchronizedMap in jdk 1.4. Note that this problem never occurs in the jdk 1.5 cruisecontrol tests. -- 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

18 years, 1 month

3
10
0 / 0

[JBoss JIRA] Created: (JBREM-639) Allow stream factory to specified for all transports

by Tim Fox (JIRA)

Allow stream factory to specified for all transports ---------------------------------------------------- Key: JBREM-639 URL: http://jira.jboss.com/jira/browse/JBREM-639 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Tim Fox Assigned To: Tom Elrod Normally marshallers will receive the raw underlying transport Input/OuputStream. In some cases we want to wrap this in a different stream, e.g.in the case of JBossMessaging we want this wrapped in a DataInput/DataOutputStream. This is accomplished by specifiying a new Client/ServerSocketWrapper in the socket transport URI params which creates the DataInput/OutputStream. This works fine for the socket transport, but does not work for other transports which do not use SocketWrappers. E.g. JBM needs to use the HTTP transport too, and needs the underlying stream wrapped in a DataOutput/InputStream. The current remoting implementation will pass in the underlying stream to the marshaller when the HTTP transport is used, which means we have create and wrap a new DataInput/OuputStream on each invocation request and response which may have performance implications. Suggestion is to allow a InputStream/OuputStream factory to be specified for ANY transport, not just the socket transport. This would allow how streams are wrapped to be determined in a much more consistent way. Suggestion is to allow the stream factory to be specified in the URI params, e.g. &streamFactoryClass=org.jboss.tim.MyStreamFactory, and this to be allowed for any transport. If factory is not specified then raw stream is passed into marshaller. -- 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

18 years, 1 month

3
12
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 October 2007