February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (HIBERNATE-50) Embedded Objects get set to null if all its members are null

by milan w?lke (JIRA)

Embedded Objects get set to null if all its members are null ------------------------------------------------------------ Key: HIBERNATE-50 URL: http://jira.jboss.com/jira/browse/HIBERNATE-50 Project: Hibernate Issue Type: Bug Environment: WinXP SP2, JBoss 4.0.4 GA as well as JBoss 4.0.5 GA, installation profile ejb3 Reporter: milan w?lke Assigned To: Steve Ebersole When having an embedded object only containing members of non-simple-types (e.g. String) and fetching it with the entity manager the following happens: If all columns, the embedded objects values are based on, are null the embedded object itself is set to null even if a non-arg-constructor set it to a non-null value before. A valid workaround is to include a member of a simple-type (e.g. int) in the embedded object. Doing this not all the values can be set to null, which results in not setting the embedded object itself to null, too. -- 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, 3 months

13
16
0 / 0

[JBoss JIRA] Created: (JBJMX-105) Reassess response to JBJMX-101

by David Wade (JIRA)

Reassess response to JBJMX-101 ------------------------------ Key: JBJMX-105 URL: http://jira.jboss.com/jira/browse/JBJMX-105 Project: JBoss JMX Issue Type: Sub-task Affects Versions: JBossAS-4.0.0 Reporter: David Wade The suggested work around for the NullPointerException reported in JBJMX-101 is a bit of a cop-out and disregards the often quite complex deployment environments in which we often find ourselves where communicating such a around is neither trivial or professional looking. Can we reassess the original response with a view to perhaps fixing the issue? -- 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, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-133) Multiplexer documentation

by Brian Stansberry (JIRA)

Multiplexer documentation ------------------------- Key: JBCLUSTER-133 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-133 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q4Y6 -- 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, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-134) Buddy replication documentation for http sessions

by Brian Stansberry (JIRA)

Buddy replication documentation for http sessions ------------------------------------------------- Key: JBCLUSTER-134 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-134 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q4Y6 -- 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, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-3647) Backport SingleRetryInterceptor to 3.2

by Scott M Stark (JIRA)

Backport SingleRetryInterceptor to 3.2 -------------------------------------- Key: JBAS-3647 URL: http://jira.jboss.com/jira/browse/JBAS-3647 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering, EJB2 Affects Versions: JBossAS-3.2.8.SP1 Reporter: Scott M Stark Assigned To: Brian Stansberry A 3.2.8.SP1 client attempting to connect to a 4.0.4 clustered bean fails with the following error due to the SingleRetryInterceptor not being available in 3.2.8.SP1: 2006-09-12 16:44:30,178 [Thread-0::] - javax.naming.CommunicationException. Root exception is java.lang.ClassNotFoundException: org.jboss.proxy.ejb.SingleRetryInterceptor (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:318) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:132) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:143) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) We should backport this. -- 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, 3 months

4
4
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-180) Calling getters/setters cluster wide - covenience feature

by Galder Zamarreno (JIRA)

Calling getters/setters cluster wide - covenience feature --------------------------------------------------------- Key: JBCLUSTER-180 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-180 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Galder Zamarreno Assigned To: Brian Stansberry Priority: Optional We'd like to check the values of an attirbute on all cluster nodes. Is there any quick way to do so? During the startup of your own JMX MBean service you first have to register it with HAPartition using registerRPCHandler method in HAPartition [1]. Provide a service name and your own MBean object as parameters. When checking a value of an attribute of your mbean in the whole cluster you would invoke HAPartition.callMethodOnCluster together with service name parameter provided for registerRPCHandler method. You have to expose this attribute as an operation However, it would be more convenient to just use getter or setter. thanks, -- 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, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-879) Injection metadata in ejb-jar.xml does not override @EJB annotation

by Justin (JIRA)

Injection metadata in ejb-jar.xml does not override @EJB annotation ------------------------------------------------------------------- Key: EJBTHREE-879 URL: http://jira.jboss.com/jira/browse/EJBTHREE-879 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - Patch 1 Environment: OS-System: Linux 2.6.16.27-0.6-smp,i386 Java VM: Java HotSpot(TM) Server VM 1.6.0-b105,Sun Microsystems Inc. JBoss [Zion] 4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339) JBoss EJB 3.0 RC9 Patch 1 Reporter: Justin I have 2 stateless session EJBs, RecipientServiceBean and InjectedServiceBean. RecipientService exposes a remote interface. InjectedService exposes only a local interface and is injected into the 'injectedService' field of the RecipientServiceBean --------------------------------------------------- RecipientServiceBean --------------------------------------------------- @Stateless(name="RecipientServiceBean") @Remote(RecipientService.class) public class RecipientServiceBean implements RecipientService { @EJB(mappedName="overrideinjection/InjectedServiceBean/local") private InjectedService injectedService; public String saySomething() { return "Hello: " + injectedService.getResponse(); } } --------------------------------------------------- InjectedServiceBean --------------------------------------------------- @Stateless(name="InjectedServiceBean") @Local(InjectedService.class) public class InjectedServiceBean implements InjectedService { public String getResponse() { return "This is the real service"; } } --------------------------------------------------------------------------------------------------------------------------------------------------------- I now want to override the injection specified by the @EJB annotation to inject a stub service. The stub service and ejb-jar.xml included is as follows --------------------------------------------------- RecipientServiceStubBean --------------------------------------------------- public class InjectedServiceStubBean implements InjectedService { public String getResponse() { return "THIS IS THE STUB"; } } --------------------------------------------------- ejb-jar.xml --------------------------------------------------- <?xml version="1.0" encoding="ISO-8859-1"?> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" version="3.0"> <enterprise-beans> <session> <ejb-name>RecipientServiceBean</ejb-name> <remote>com.sadalbari.test.overrideinjection.RecipientService</remote> <ejb-class>com.sadalbari.test.overrideinjection.impl.RecipientServiceBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> <ejb-local-ref> <ejb-ref-name>ejb/InjectedService</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <local>com.sadalbari.test.overrideinjection.InjectedService</local> <ejb-link>InjectedServiceStubBean</ejb-link> <injection-target> <injection-target-class>com.sadalbari.test.overrideinjection.impl.RecipientServiceBean</injection-target-class> <injection-target-name>injectedService</injection-target-name> </injection-target> </ejb-local-ref> </session> <session> <ejb-name>InjectedServiceStubBean</ejb-name> <local>com.sadalbari.test.overrideinjection.InjectedService</local> <ejb-class>com.sadalbari.test.overrideinjection.impl.InjectedServiceStubBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> </ejb-jar> --------------------------------------------------------------------------------------------------------------------------------------------------------- A dump of my JNDI view at this point +- overrideinjection (class: org.jnp.interfaces.NamingContext) | +- RecipientServiceBean (class: org.jnp.interfaces.NamingContext) | | +- remote (proxy: $Proxy61 implements interface com.sadalbari.test.overrideinjection.RecipientService,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBObject) | +- InjectedServiceStubBean (class: org.jnp.interfaces.NamingContext) | | +- local (proxy: $Proxy56 implements interface com.sadalbari.test.overrideinjection.InjectedService,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBLocalObject) | +- InjectedServiceBean (class: org.jnp.interfaces.NamingContext) | | +- local (proxy: $Proxy56 implements interface com.sadalbari.test.overrideinjection.InjectedService,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBLocalObject) --------------------------------------------------------------------------------------------------------------------------------------------------------- The result is that the injection is not overridden and the stub is not used in preference to the 'real service': Hello: This is the real service I can work around this issue by removing the @EJB annotation and ALWAYS declaring the injection in the ejb-jar.xml in which case I get: Hello: THIS IS THE STUB Thanks Justin -- 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, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-888) Allow injection of HibernateEntityManager

by Carlo de Wolf (JIRA)

Allow injection of HibernateEntityManager ----------------------------------------- Key: EJBTHREE-888 URL: http://jira.jboss.com/jira/browse/EJBTHREE-888 Project: EJB 3.0 Issue Type: Feature Request Reporter: Carlo de Wolf Fix For: EJB 3.0 RC10 - FD, EJB 3.0 RC11 - FD -- 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, 3 months

2
16
0 / 0

[JBoss JIRA] Created: (EJBTHREE-744) EJB3 JACC Layer Container Task

by Anil Saldhana (JIRA)

EJB3 JACC Layer Container Task ------------------------------ Key: EJBTHREE-744 URL: http://jira.jboss.com/jira/browse/EJBTHREE-744 Project: EJB 3.0 Issue Type: Task Components: Security Affects Versions: EJB 3.0 RC9 - FD Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: EJB 3.0 RC10 - FD Container Task for validation of the ejb3 jacc layer for correct permissions creation and checking, as per JACC 1.1 specification. In the future, the EJB3 security layer needs alignment with the security spi. -- 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, 3 months

5
16
0 / 0

[JBoss JIRA] Created: (JBAS-3926) Move remoting transports out of conf/jboss-service.xml to a

by Scott M Stark (JIRA)

Move remoting transports out of conf/jboss-service.xml to a remoting-beans.xml MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Move remoting transports out of conf/jboss-service.xml to a Move remoting transports out of conf/jboss-service.xml to a remoting-beans.xml ------------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-3926 URL: http://jira.jboss.com/jira/browse/JBAS-3926 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Deployment services, Remoting Reporter: Scott M Stark Assigned To: Dimitris Andreadis We need to remove remoting transports out of conf/jboss-service.xml to a remoting-beans.xml -- 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, 3 months

5
7
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 2007