December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3931) Synch up ejb3x transport configs

by Scott M Stark (JIRA)

Synch up ejb3x transport configs -------------------------------- Key: JBAS-3931 URL: http://jira.jboss.com/jira/browse/JBAS-3931 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: EJB3, Remoting Reporter: Scott M Stark Assigned To: Carlo de Wolf We need to synch up on the remoting configuration of ejb3 with jbossas. Issues include merging the AOP subsystem handler into the unified invoker config, factoring out common remoting aspects, 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3930) Synch up ejb2x transport configs

by Scott M Stark (JIRA)

Synch up ejb2x transport configs -------------------------------- Key: JBAS-3930 URL: http://jira.jboss.com/jira/browse/JBAS-3930 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: EJB2, Naming Reporter: Scott M Stark Assigned To: Scott M Stark We need to validate the standardjboss.xml transport configs and associated tests to align on remoting based transports. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3929) RMIAdaptorExt view of org.jboss.mx.remoting.service.JMXConnectorServerService

by Scott M Stark (JIRA)

RMIAdaptorExt view of org.jboss.mx.remoting.service.JMXConnectorServerService ----------------------------------------------------------------------------- Key: JBAS-3929 URL: http://jira.jboss.com/jira/browse/JBAS-3929 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JMX, Management services, Remoting Reporter: Scott M Stark Assigned To: Scott M Stark For backward compatibility, we should have support for an org.jboss.jmx.adaptor.rmi.RMIAdaptorExt binding in JNDI that legacy clients such as the testsuite can make use of. This needs to layer on top of the org.jboss.mx.remoting.service.JMXConnectorServerService. -- 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

17 years, 9 months

1
0
0 / 0

RESPALDO EN LINEA, REMOTO, SIMPLE, EFICIENTE Y SEGURO, PARA WINDOWS, LINUX Y MAC, OTRO SERVICIO DE HOSTEX.CL -- SIEMPRE INNOVANDO

by Respaldo de Datos

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3539) CLONE -jboss-client.jar misses MarshalledInvocation$DeclaredMethods

by Matthew L Daniel (JIRA)

CLONE -jboss-client.jar misses MarshalledInvocation$DeclaredMethods ------------------------------------------------------------------- Key: JBAS-3539 URL: http://jira.jboss.com/jira/browse/JBAS-3539 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.0 Final Reporter: Matthew L Daniel Assigned To: Scott M Stark Fix For: Closed issues from sourceforge Attachments: JBAS-1163_2.patch SourceForge Submitter: igorfie . Latest CVS version of JBoss 4.0.0 is missing org/jboss/invocation/MarshalledInvocation$DeclaredMethodsAction from the jboss-client.jar. As a result org.jboss.ant.JMX fails with NoClassDefFoundError. The following patch should fix the problem. Index: build.xml =================================================================== RCS file: /cvsroot/jboss/jboss/build.xml,v retrieving revision 1.173.2.2 diff -u -r1.173.2.2 build.xml --- build.xml 17 Oct 2004 18:49:28 -0000 1.173.2.2 +++ build.xml 26 Oct 2004 03:57:20 -0000 @@ -470,6 +470,7 @@ <include name="org/jboss/invocation/MarshallingInvokerInterceptor.class"/> <include name="org/jboss/invocation/PayloadKey.class"/> <include name="org/jboss/invocation/MarshalledInvocation.class"/> + <include name="org/jboss/invocation/MarshalledInvocation$DeclaredMethodsAction.class"/> <include name="org/jboss/invocation/MarshalledValue.class"/> <include name="org/jboss/invocation/MarshalledValueInputStream.class"/> <include name="org/jboss/invocation/MarshalledValueOutputStream*.class"/> -- 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

17 years, 9 months

2
3
0 / 0

[JBoss JIRA] Updated: (JBPM-583) add jms support for the messaging service

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-583?page=all ] Tom Baeyens updated JBPM-583: ----------------------------- Fix Version/s: jBPM 3.2 alpha 2 (was: jBPM 3.2) > add jms support for the messaging service > ----------------------------------------- > > Key: JBPM-583 > URL: http://jira.jboss.com/jira/browse/JBPM-583 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Jim Rigsbee > Priority: Critical > Fix For: jBPM 3.1.4, jBPM 3.2 alpha 2 > > > postponed. work is in progress on HEAD. but as long as it is not stable there, it is not ported to 3.1 branch. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBPM-583) add jms support for the messaging service

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-583?page=comments#action_12348290 ] Tom Baeyens commented on JBPM-583: ---------------------------------- it is already implemented in 3.2.Alpha2. which has been released recently. but i don't close the case yet cause it's not yet backported to 3.1.4. > add jms support for the messaging service > ----------------------------------------- > > Key: JBPM-583 > URL: http://jira.jboss.com/jira/browse/JBPM-583 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Jim Rigsbee > Priority: Critical > Fix For: jBPM 3.1.4, jBPM 3.2 > > > postponed. work is in progress on HEAD. but as long as it is not stable there, it is not ported to 3.1 branch. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1820) JCA 1.5 compliance bug

by Weston Price (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1820?page=all ] Weston Price closed JBAS-1820. ------------------------------ Resolution: Out of Date The current JCA implementation covers what is required by the spec. Being that this is the case and this issue has been sitting for awhile, I am closing it for now. Note, the JCA (1.6/2.0) specification should address this type of requirement in more detail. > JCA 1.5 compliance bug > ---------------------- > > Key: JBAS-1820 > URL: http://jira.jboss.com/jira/browse/JBAS-1820 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.2 Final > Environment: Windows 2000 > Reporter: guillaume holler > Assigned To: Weston Price > Priority: Minor > Attachments: jcasample.zip > > > This is a deployment bug that affects inflow messages. > JCA 1.5 specification states states that "Before a rsource adapter is undeployed, the application server must deactivate all active enpoints consuming messages from that specific resource adapter". This doesn't seem to be the case: > 1 - start the server with a RAR and an MDB endpoint setup (the test connector accept messages from network and the mdb merely print them on the console after wainting 10s to easealy test enpoint concurrency issues). > OK: I see the start() and endpointActivation(...) callback called > 2 - run the client test several times (in a way that enables concurrent message consumption): OK (client OK, console prints all messages) > 3 - undeploy RAR: I can see the stop callback, but no MDB undeploy or endpointDeactivation(...) callback on resource adapter. > 4 - deploy RAR again: deployment OK, I can see the start() callback but no endpointActivation(...) callback called > 5 - run the client test again: client OK, demonstrating the network endpoint is working, but no message printed on the console (no endpoint consumption). > 6 - undeploy/deploy MDB: everything works again as in 2 (plus, messages pending from step 5 are obviously consumed) > I think we should have, according to spec, an undeployment of MDBs that depend on the RAR service when the service is undeployed, and a furter restart should trigger a new endpointActivation callback. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-434) WEBDAV deployment

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-434?page=all ] Dimitris Andreadis closed JBAS-434. ----------------------------------- Resolution: Won't Fix Assignee: (was: Scott M Stark) > WEBDAV deployment > ----------------- > > Key: JBAS-434 > URL: http://jira.jboss.com/jira/browse/JBAS-434 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMX > Affects Versions: JBossAS-3.2.6 Final > Reporter: SourceForge User > > SourceForge Submitter: ikar . > currectly there's some support for WebDAV in JBoss. > Namely, packed archives (*.war, *.sar, *.ear) can be > detected on WebDAV-enabled sites and deployed. > The point is that Unpacked archives are detected but > cannot be deployed; the automatic deployment of > Unpacked archives would be the best option for me. > I would even develop this functionality, just need a > hint where to start from. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-1820) JCA 1.5 compliance bug

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1820?page=all ] Dimitris Andreadis reassigned JBAS-1820: ---------------------------------------- Assignee: Weston Price Probably outdated. > JCA 1.5 compliance bug > ---------------------- > > Key: JBAS-1820 > URL: http://jira.jboss.com/jira/browse/JBAS-1820 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.2 Final > Environment: Windows 2000 > Reporter: guillaume holler > Assigned To: Weston Price > Priority: Minor > Attachments: jcasample.zip > > > This is a deployment bug that affects inflow messages. > JCA 1.5 specification states states that "Before a rsource adapter is undeployed, the application server must deactivate all active enpoints consuming messages from that specific resource adapter". This doesn't seem to be the case: > 1 - start the server with a RAR and an MDB endpoint setup (the test connector accept messages from network and the mdb merely print them on the console after wainting 10s to easealy test enpoint concurrency issues). > OK: I see the start() and endpointActivation(...) callback called > 2 - run the client test several times (in a way that enables concurrent message consumption): OK (client OK, console prints all messages) > 3 - undeploy RAR: I can see the stop callback, but no MDB undeploy or endpointDeactivation(...) callback on resource adapter. > 4 - deploy RAR again: deployment OK, I can see the start() callback but no endpointActivation(...) callback called > 5 - run the client test again: client OK, demonstrating the network endpoint is working, but no message printed on the console (no endpoint consumption). > 6 - undeploy/deploy MDB: everything works again as in 2 (plus, messages pending from step 5 are obviously consumed) > I think we should have, according to spec, an undeployment of MDBs that depend on the RAR service when the service is undeployed, and a furter restart should trigger a new endpointActivation callback. -- 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

17 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2006