February 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1463) Debugging process instances

by Kris Verlaenen (JIRA)

Debugging process instances --------------------------- Key: JBRULES-1463 URL: http://jira.jboss.com/jira/browse/JBRULES-1463 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Eclipse IDE Reporter: Kris Verlaenen Assigned To: Kris Verlaenen The Eclipse IDE should support debugging of process instances -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1462) Improve audit to support realtime auditing

by Kris Verlaenen (JIRA)

Improve audit to support realtime auditing ------------------------------------------ Key: JBRULES-1462 URL: http://jira.jboss.com/jira/browse/JBRULES-1462 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder, Eclipse IDE Reporter: Kris Verlaenen Assigned To: Kris Verlaenen -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1891) Move portlet rendering ahead in the PortalAction phase

by Julien Viet (JIRA)

Move portlet rendering ahead in the PortalAction phase ------------------------------------------------------ Key: JBPORTAL-1891 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1891 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: Portlet-2.0 Reporter: Julien Viet Fix For: Portlet-2.0 This action phase is not really an action phase it is rather a prepare phase. This will allow to implement more of the spec in the demo portal: - header transport and markup contributions. -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1189) ClassCastException within EAR - Stateless Session Bean interface flattening hierarchy

by Ananda Debnath (JIRA)

ClassCastException within EAR - Stateless Session Bean interface flattening hierarchy ------------------------------------------------------------------------------------- Key: EJBTHREE-1189 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1189 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.0 GA Environment: Win XP Prof, Java 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03), Java HotSpot Client VM (build 1.5.0_14-b03, mixed mode, sharing) Reporter: Ananda Debnath Project structure ============= DVS3.ear/ +-Util.jar (J2EE utility project) | +-dvs3.Changelist (java interface) | +-Core.jar/ (EJB Project) | +dvs3.code.session.ChangelistService (java interface that extends dvs3.Changelist) | +dvs3.code.session.ChangelistServiceBean (stateless session bean that implements ChangelistService) | +-WebUI.war/ | +dvs3.code.action.JSFBackingBean (a bbean that calls a session bean service via JNDI) I'm assuming the manifest files are defined correctly since both Core.jar and Util.jar are referenced in the WebUI.war manifest file and Util.jar is referenced in the Core.jar manifest file. In the backing bean, I have this piece of code: String jndi = "DVS3EAR/ChangelistServiceBean/local"; Object service = new InitialContext().lookup(jndi); System.out.println(service instanceof ChangelistService) // prints true System.out.println(service instanceof Changelist) // prints false Changelist service = (Changelist) obj; // fails with a ClassCastException Why is this? At some level, isn't this violating a fundamental java principle? Since ChangelistService is a Changelist, why can't I cast the service object to be a Changelist, but can cast it to be of type ChangelistService? -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-518) Remove HTTPServerInvoker

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-518?page=all ] Ron Sigal closed JBREM-518. --------------------------- Resolution: Done Assignee: (was: Tom Elrod) Removed org.jboss.remoting.transport.http.HTTPServerInvoker and org.jboss.remoting.transport.http.ssl.HTTPSServerInvoker. > Remove HTTPServerInvoker > ------------------------ > > Key: JBREM-518 > URL: http://jira.jboss.com/jira/browse/JBREM-518 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: transport > Affects Versions: 2.0.0.CR1 (Boon) > Reporter: Tom Elrod > Fix For: 2.4.0.CR1 (Pinto) > > > Need to remove HTTPServerInvoker now that CoyoteInvoker has taken its place. Was deprecated in 2.0.0 (Boon), so can remove it in this release. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-116) Create public and implementors javadoc

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-116?page=all ] Ron Sigal updated JBREM-116: ---------------------------- Fix Version/s: 2.4.0.GA (was: 2.4.0.CR1 (Pinto)) > Create public and implementors javadoc > -------------------------------------- > > Key: JBREM-116 > URL: http://jira.jboss.com/jira/browse/JBREM-116 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.0.2 final > Reporter: Tom Elrod > Fix For: 2.4.0.GA > > > Need to produce javadoc for public API and for implementation API (which is subject to change). One idea would be to create seperate packages for the actual implementations, such as for the transports and marshallers, so will be easier to identify what is public and what is implementation. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2750) Create integration tests using JBossCache and JBoss TM

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2750?page=all ] Brian Stansberry updated JBAS-2750: ----------------------------------- Fix Version/s: JBossAS-5.0.0.GA (was: JBossAS-5.0.0.CR1) > Create integration tests using JBossCache and JBoss TM > ------------------------------------------------------ > > Key: JBAS-2750 > URL: http://jira.jboss.com/jira/browse/JBAS-2750 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: JBossAS-5.0.0.GA > > > Need to add integration tests that confirm that JBossCache works properly with JBoss TM as its transaction manager. The standalone cache unit tests use DummyTransactionManager, as use of JBoss TM requires the app server. Beginning with 4.0.4, the AS web-tier state replication tests also no longer use JBoss TM. > See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76306 for an example of the kind of thing such tests should find. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-772) HA-JNDI multicast reply not reaching client

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-772?page=all ] Brian Stansberry updated JBAS-772: ---------------------------------- Fix Version/s: JBossAS-5.0.1.CR1 (was: JBossAS-5.0.0.CR1) > HA-JNDI multicast reply not reaching client > ------------------------------------------- > > Key: JBAS-772 > URL: http://jira.jboss.com/jira/browse/JBAS-772 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: JBossAS-3.2.6 Final > Reporter: SourceForge User > Assigned To: Brian Stansberry > Fix For: JBossAS-5.0.1.CR1 > > Attachments: DeviceManager.jsp, DeviceModule.java, TelematicsJNDI.java > > > SourceForge Submitter: rmontag . > I just made some expiriences with the HA-JNDI multicast > and running multiple instances on a single machine. I > encountered some problems... > My setup: > - JBoss 3.2.2 > - JDK 1.4.2 > - Two instances running on a single W2K-PC, > alternatively I 'm using two instances running on a > single SUN solaris. instance 1 using 1200 as HA-JNDI > port, instance 2 using 1300. > - "JBoss Clustering" documentation, 4. edition > - Standalone testclient (JUnit) on PC or SUN, > configured for Multicast (url-property not set) > The problem: > Case A: Testclient and server instances on PC > Case B: Testclient on PC, server instances on SUN > When starting my testclient and making a lookup via > multicast, both instances receive the GET_ADDRESS > datagram. Then each server send a datagram packet back > NOT using a multcast. Since the testclient opens a > MulticastSocket on the Multigroup port 1102, each > server sends a response datagramm back to <client-ip>:1102. > I encountered two problems with this approach: > 1) If client and server are one the same instance like > in case A, they have the same ip-address. In my > environment one server instance always "catches" all > the answers, so the client timed-out with no answers > (Note: On W2K, I set "loopback" to true, on SUN to > false as described in the cluster document). > 2) Same problem if two clients on one instance make a > concurrent multicast call (servers on other machine): > Both waiting for responses, only one client catches all > the responses. The second client ever lose. > Two possible solutions come to my mind: > 1) Currently the NamingContext opens a MulticastSocket > on the multicast group port. If the client would use a > different dedicated port, he can send his call with the > multicast group address and the server could reply to > <client-ip>:<dedicated client-port> with his answer. No > one else (another client or server) would "catch" the > server response if using different port numbers > (Disadvantage: One additional HA-JNDI JNP property like > "jnp.multicastPort"). > 2) HANamingService currently sends a response datagram > back to a dedicated IP:port address (Unicast). Why > doesn't the server also sends a multicast call using > the well-known multicast group address to propagate his > answer ? A multicast answer seems to be a clean > solution because: a) All clients waiting for an answer > will receive them and b) other server(s) receiving the > answer will ignore them as they already do now. > Solution 2 simply means exchanging one line in > HANamingService.java: > Instead of > DatagramPacket p = new DatagramPacket (ipAddress, > ipAddress.length, packet.getAddress(), packet.getPort()); > do this one: > DatagramPacket p = new DatagramPacket(ipAddress, > ipAddress.length, group, adGroupPort); > Solution 1, as stated above would need one additinal > config property for the client port. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3540) Streamable based serialization for HAPartitionImpl

by Brian Stansberry (JIRA)

Streamable based serialization for HAPartitionImpl -------------------------------------------------- Key: JBAS-3540 URL: http://jira.jboss.com/jira/browse/JBAS-3540 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 JGroups has some utility functions that optimize serialization of its classes that implement its Streamable interface. But, HAPartitionImpl has to bypass those opimizations due to the need to use MarshalledValueInputStream. We should look into adding similar optimizations into a Marshaller for HAPartitionImpl. -- 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, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1876) wsrp consumer registration problem from admin ui

by Prabhat Jha (JIRA)

wsrp consumer registration problem from admin ui ------------------------------------------------ Key: JBPORTAL-1876 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1876 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Prabhat Jha Assigned To: Chris Laprun Chris, Given that wsrp code has not changed much, I am not sure what could have caused this unless I overlooked this in 2.6.3 release. I give bea's WSDL URL and intentionally give wrong consumer role and I get th following error: Couldn't register with producer 'bea' Cause: An unexpected error occured: org.jboss.portal.wsrp.core.OperationFailedFault But when I try to correct consumer role "public", it does not try to register with new role. I still see the above message. Also, there is a typo. Please change roll to role. -- 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, 5 months

3
4
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 February 2008