January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-727) ServerPeer.destroyQueue/destroTopic just undeploys, does not destroy

by Tim Fox (JIRA)

ServerPeer.destroyQueue/destroTopic just undeploys, does not destroy -------------------------------------------------------------------- Key: JBMESSAGING-727 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-727 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Beta1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.CR1 The server peer methods destroyQueue/destroyTopic only undeploy the queue/topic, but do not destroy them (i.e. remove their messages). This differs from JBossMQ functionality where the destroy methods remove the messages too. We should change the implementation of destroyQueue/destroyTopic to actually destroy the destinations and introduce new methods undeploy/deploy to do the deployment. -- 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

19 years, 5 months

3
2
0 / 0

[JBoss JIRA] Created: (JBREM-693) Make sure "bisocket" can fully replace "socket" as Messaging's default transport

by Ovidiu Feodorov (JIRA)

Make sure "bisocket" can fully replace "socket" as Messaging's default transport -------------------------------------------------------------------------------- Key: JBREM-693 URL: http://jira.jboss.com/jira/browse/JBREM-693 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ovidiu Feodorov Assigned To: Ron Sigal Priority: Blocker Fix For: 2.2.0.Alpha7 -- 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

19 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-586) DefaultExpander incorrectly strips leading and trailing spaces

by Adam Lewandowski (JIRA)

DefaultExpander incorrectly strips leading and trailing spaces -------------------------------------------------------------- Key: JBRULES-586 URL: http://jira.jboss.com/jira/browse/JBRULES-586 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.5 Reporter: Adam Lewandowski Assigned To: Mark Proctor When using a DSL expander, token values with leading or trailing spaces get the spaces stripped when inserted into the target template. This causes the resulting rule definition to be incorrect. Example: DSL: [when]String is "{value}"=SomeFact(value=="{value}") Input string (note the trailing space): String is "blah " Expanded string (note the lack of a trailing space): SomeFact(value=="blah") The same thing occurs for leading spaces as well. Internal spaces are fine. Also interesting is that if there are more than one leading/trailing space, NLExpressionCompiler throws an IllegalArgumentException: Expression was not expandable: String is " blah" The problem seems to be in the org.drools.lang.dsl.template.Chunk class. It is stripping the leading/trailing spaces from values in the map populated by buildValueMap(). Unit Test: import java.io.StringReader; import org.drools.lang.dsl.DefaultExpander; import junit.framework.TestCase; public class DroolsDslTemplateTest extends TestCase { private DefaultExpander expander; public void setUp() { String DSL = "[when]String is \"{value}\"=SomeFact(value==\"{value}\")"; StringReader dslSrc = new StringReader(DSL); expander = new DefaultExpander(dslSrc); } public void testExpandNoSpaces() { String result = expander.expand("when", "String is \"blah\""); assertEquals("SomeFact(value==\"blah\")", result); } public void testExpandWithLeadingSpace() { String result = expander.expand("when", "String is \" blah\""); assertEquals("SomeFact(value==\" blah\")", result); } public void testExpandWithMultipleLeadingSpaces() { String result = expander.expand("when", "String is \" blah\""); assertEquals("SomeFact(value==\" blah\")", result); } public void testExpandWithTrailingSpace() { String result = expander.expand("when", "String is \" blah \""); assertEquals("SomeFact(value==\"blah \")", result); } public void testExpandWithMultipleTrailingSpaces() { String result = expander.expand("when", "String is \"blah \""); assertEquals("SomeFact(value==\"blah \")", result); } public void testExpandWithInternalSpace() { String result = expander.expand("when", "String is \"bl ah\""); assertEquals("SomeFact(value==\"bl ah\")", result); } public void testExpandWithMultipleInternalSpaces() { String result = expander.expand("when", "String is \"bl ah\""); assertEquals("SomeFact(value==\"bl ah\")", result); } } -- 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

19 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-476) DSL constraint appending needs to be tolerant of spaces

by Michael Neale (JIRA)

DSL constraint appending needs to be tolerant of spaces ------------------------------------------------------- Key: JBRULES-476 URL: http://jira.jboss.com/jira/browse/JBRULES-476 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.4 Reporter: Michael Neale Assigned To: Michael Neale If you do [when]-foo bar=Baz() it will fail to expand unless you put a space after the "-". -- 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

19 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-694) Integrate, test and document the "bisocket" remoting transport.

by Ovidiu Feodorov (JIRA)

Integrate, test and document the "bisocket" remoting transport. --------------------------------------------------------------- Key: JBMESSAGING-694 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-694 Project: JBoss Messaging Issue Type: Feature Request Reporter: Ovidiu Feodorov Assigned To: Ron Sigal Priority: Critical Fix For: 1.2.0.Beta2 The "bisocket" transport should become the default transport for LAN. The work is to be carried out on the "bisocket" branch and later merged into the trunk when all items below are completed: - Apply all necessary API changes (if any, there actually shouldn't be) - Make sure the full functional and stress testsuites pass with "bisocket" replacing "socket" as default transport (leave HTTP in place, though) - Document configuration changes in the user guide and wiki pages -- 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

19 years, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-777) Revise creation of Object*Stream on Remoting/our Marshallers

by Clebert Suconic (JIRA)

Revise creation of Object*Stream on Remoting/our Marshallers ------------------------------------------------------------ Key: JBMESSAGING-777 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-777 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Beta2 Reporter: Clebert Suconic Assigned To: Ovidiu Feodorov Fix For: 1.2.0.CR1 We have requested to create a new Object*Stream on every request... delegating the Object*Stream creation to the marshaller. A Object*Stream should be reused.. and created only once... Especially if using JavaSerialization, since : I - its creation is considered expensive II - Object*Stream has a weird internal buffer. overusing that stream creationg might cause intermitent errors IMO. It would be better if we could avoid recreating the streaming every time. -- 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

19 years, 5 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-3431) AuthorizationInterceptor throwing ArrayIndexOutOfBoundsException

by Anil Saldhana (JIRA)

AuthorizationInterceptor throwing ArrayIndexOutOfBoundsException ---------------------------------------------------------------- Key: JBAS-3431 URL: http://jira.jboss.com/jira/browse/JBAS-3431 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX, Security Affects Versions: JBossAS-4.0.4.GA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1 As Originally reported in JBJMX-97, the user says: ========================================================================================== I have secured the jmx-invoker-service using JAAS and the standard UsersRolesLoginModule. I am able to authenticate (basic authentication) through the web UI and manage the console using the same login config. I am getting a remote connection to the JMX server from an InitialContext that is populated with the user name and password: env.put(Context.SECURITY_PRINCIPAL, userName); env.put(Context.SECURITY_CREDENTIALS, password); Then I look up the MBeanServerConnection and try to get the MBeanInfo MBeanServerConnection server = lookup("jmx/invoker/RMIAdaptor", MBeanServerConnection.class); ObjectName name = new ObjectName(theName); MBeanInfo info = server.getMBeanInfo(name); At this point the server throws an ArrayIndexOutOfBoundsException from org.jboss.jmx.connector.invoker.AuthorizationInterceptor line 107. If I try and set an attribute: server.setAttribute(name, new Attribute("searchText", searchText)); I get instead at the same line: java.lang.ClassCastException: javax.management.Attribute at org.jboss.jmx.connector.invoker.AuthorizationInterceptor.invoke(AuthorizationInterceptor.java:107) at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:108) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) ========================================================================================== -- 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

19 years, 5 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-965) Localization Support bug

by 吴奕雄 (JIRA)

Localization Support bug ------------------------ Key: JBPORTAL-965 URL: http://jira.jboss.com/jira/browse/JBPORTAL-965 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.4 Final Environment: windowxp,ie6,charset=zh-ch Reporter: 吴奕雄 Priority: Minor Fix For: 2.0 Branch, 2.0.2 Final, 2.2 Branch, 2.4 Final -- 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

19 years, 5 months

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-3887) Upgrade Javassist to v3.4.0

by Dimitris Andreadis (JIRA)

Upgrade Javassist to v3.4.0 --------------------------- Key: JBAS-3887 URL: http://jira.jboss.com/jira/browse/JBAS-3887 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Other Reporter: Dimitris Andreadis Fix For: JBossAS-4.2.0.CR1 Upgrade to the latest Javassist -- 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

19 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1170) Extended implementation of LDAP identity modules

by Boleslaw Dawidowicz (JIRA)

Extended implementation of LDAP identity modules ------------------------------------------------ Key: JBPORTAL-1170 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1170 Project: JBoss Portal Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Portal Identity Affects Versions: 2.6.Beta1 Reporter: Boleslaw Dawidowicz Assigned To: Boleslaw Dawidowicz Fix For: 2.6.Beta1 Implementation of LDAP identity modules that will handle: - more sophisticated search capabilities of users and roles Features that could be handled are those present in LdapExtLoginModule in JBossSX -- 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

19 years, 5 months

2
1
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 January 2007