December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1156) implementation of LoginModule that synchronizes users from LDAP to DB

by Boleslaw Dawidowicz (JIRA)

implementation of LoginModule that synchronizes users from LDAP to DB --------------------------------------------------------------------- Key: JBPORTAL-1156 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1156 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Identity Affects Versions: 2.6.Beta1 Reporter: Boleslaw Dawidowicz Assigned To: Boleslaw Dawidowicz Priority: Optional Fix For: 2.6.Beta1 create implementation of LoginModule (for of LdapLoginModule) that checks if user is present in DB, if not checks in LDAP and then replicates to DB. -- 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
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-768) MDB deployment error

by Ramil Israfilov (JIRA)

MDB deployment error -------------------- Key: EJBTHREE-768 URL: http://jira.jboss.com/jira/browse/EJBTHREE-768 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - FD Environment: JDK1.5.0_06, UNIX and windows platforms Reporter: Ramil Israfilov Fix For: EJB 3.0 RC10 - FD I have an MDB which is defined like that import javax.jms.MessageListener; @MessageDriven(name = "EJBExecutorMDB", activationConfig = { @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/ExecutorQueue"), @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "AUTO_ACKNOWLEDGE"), @ActivationConfigProperty(propertyName = "maxSession", propertyValue = "4"), @ActivationConfigProperty(propertyName = "SubscriptionDurability", propertyValue = "Durable") }) public class EJBExecutorMDB implements MessageListener { .... It works perfect during in JBOSS, but then I run it in JUNIT it fails with exception: "unable to determine messagingType interface for MDB" Only one difference that in JUNIT test I instrument built classes using cobertura - in that case my class implements two interfaces: MessageListener and cobertura interface. After looking in source code I found in org.jboss.ejb3.mdb.MDB: if (messagingType.getName().equals(Object.class.getName())) { ArrayList<Class> list = ProxyFactoryHelper.getBusinessInterfaces(clazz); if (list.size() > 1 || list.size() == 0) throw new RuntimeException("unable to determine messagingType interface for MDB"); messagingType = list.get(0); } Why such a dummy check is done ??? Why class must implement one and only one interface ?? could you check superclasses and allow multiple interfaces implementations on the class. Also on the link to forum people has similar problem: they don't implement interface, but extend superclass. And they got the same exception. -- 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: (JGRP-354) If response unmarshalling fails, RequestCorrelator passes garbage as the response

by Brian Stansberry (JIRA)

If response unmarshalling fails, RequestCorrelator passes garbage as the response --------------------------------------------------------------------------------- Key: JGRP-354 URL: http://jira.jboss.com/jira/browse/JGRP-354 Project: JGroups Issue Type: Bug Affects Versions: 2.4 Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.5 >From RequestCorrelator.receiveMessage: RspCollector coll=findEntry(hdr.id); if(coll != null) { Address sender=msg.getSrc(); Object retval=null; byte[] buf=msg.getBuffer(); try { retval=marshaller != null? marshaller.objectFromByteBuffer(buf) : Util.objectFromByteBuffer(buf); } catch(Exception e) { log.error("failed unmarshalling buffer into return value", e); try { retval=marshaller != null? marshaller.objectToByteBuffer(e) : Util.objectToByteBuffer(e); } catch(Exception e1) { log.error("failed marshalling exception " + e1 + " into buffer", e1); } } coll.receiveResponse(retval, sender); } The outer catch block should just be catch (Exception e) { log.error("failed unmarshalling buffer into return value", e); retval = e; } Looks like the bit about marshalling the exception came from handleRequest(), where it's needed. -- 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

[JBoss JIRA] Created: (JGRP-274) Don't bind to a NIC if bind address is not set

by Bela Ban (JIRA)

Don't bind to a NIC if bind address is not set ---------------------------------------------- Key: JGRP-274 URL: http://jira.jboss.com/jira/browse/JGRP-274 Project: JGroups Issue Type: Feature Request Affects Versions: 2.3 SP1, 2.3, 2.2.9 SP3 (2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8, 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 If -Dbind.address or bind_addr are not set, JGroups picks the NIC to bind sockets to itself. However, especially for ServerSockets, this may not be desirable because we may want to have ServerSockets be able to receive packets through all interfaces, e.g. - NICs are 192.168.5.2, 192.168.0.2 and 127.0.0.1 (loopback) - When the bind address is set to 192.168.5.2, a given ServerSocket on port 7500 will *only accept packets from this NIC* - If someone connects to 192.168.0.2:7500 or 127.0.0.1:7500, the client will not be able to establish a connection because nobody is listening on those ports on the given NICs - If bind address was not set, this would be possible - Affected: FD_SOCK, FD_PING, TCP, TCP_NIO etc - We need to think about semantics for MulticastSockets where a wildcard address (not setting the bind address) means that the operating system picks the NIC, and *not* that the MulticastSocket will listen on all interfaces for incoming packets -- 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

[JBoss JIRA] Created: (JGRP-385) TLS: provide OOB method calls for RpcDispatcher and MessageDispatcher

by Bela Ban (JIRA)

TLS: provide OOB method calls for RpcDispatcher and MessageDispatcher --------------------------------------------------------------------- Key: JGRP-385 URL: http://jira.jboss.com/jira/browse/JGRP-385 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 E.g. RcpDispatcher.callRemoteMethods(..., boolean oob) -- 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
3
0 / 0

[JBoss JIRA] Created: (JGRP-277) Threadpool for timer (TimeScheduler)

by Bela Ban (JIRA)

Threadpool for timer (TimeScheduler) ------------------------------------ Key: JGRP-277 URL: http://jira.jboss.com/jira/browse/JGRP-277 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 Current, TimeScheduler is single threaded; long running tasks delay the execution of other tasks. Introduce a thread pool and let the user configure it: e.g. single-threaded, max of 5 threads etc -- 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
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-674) Propagate changes in server list back to client when server side view change occurs

by Ovidiu Feodorov (JIRA)

Propagate changes in server list back to client when server side view change occurs ----------------------------------------------------------------------------------- Key: JBMESSAGING-674 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-674 Project: JBoss Messaging Issue Type: Sub-task Components: JMS Clustering Reporter: Ovidiu Feodorov Fix For: 1.2.0.Beta1 Piggyback? Asynchronous notification? -- 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: (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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2006