January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (HIBERNATE-120) Hibernate maps type "timestamp" to Mysql's type "datetime" not "timestamp"

by zhou yanming (JIRA)

Hibernate maps type "timestamp" to Mysql's type "datetime" not "timestamp" -------------------------------------------------------------------------- Key: HIBERNATE-120 URL: https://jira.jboss.org/jira/browse/HIBERNATE-120 Project: Hibernate Integration Issue Type: Bug Reporter: zhou yanming Assignee: Steve Ebersole Priority: Critical datetime will trim millisecond record.setLastModified(new Date(1250053078708)); session.save(record); .... record = session.load(record.getId()); System.out.println(record.getLastModified()); // here is 125005307000 not expected 1250053078708 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBSER-119) Ensure compatibility with Trove

by Christian Effertz (JIRA)

Ensure compatibility with Trove ------------------------------- Key: JBSER-119 URL: https://jira.jboss.org/jira/browse/JBSER-119 Project: JBoss Serialization Issue Type: Thirdparty Change Affects Versions: 1.0.3 GA Reporter: Christian Effertz Assignee: Clebert Suconic Fix For: 1.1.0 Beta The version of [Trove|http://trove4j.sourceforge.net] that is shipped with the latest version of JBoss Serialization is quite old. Trove has had a major release since it was bundled last time for Version 1.0.3 and seems to be facing a next major version 3.0. As it is stated in their release notes that they had some performance improvements and Bug Fixes I would assume that JBoss Serialization would profit in terms of stability and performance if using the newer versions. I will give it a try in our dev system, but it would be more comforting to get a statement if your testsuite turned green if using the newer version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBEE-22) Add jboss-jaxrs-api_1.1_spec

by Shelly McGowan (JIRA)

Add jboss-jaxrs-api_1.1_spec ---------------------------- Key: JBEE-22 URL: https://jira.jboss.org/jira/browse/JBEE-22 Project: JBoss JavaEE APIs Issue Type: Sub-task Reporter: Shelly McGowan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
9
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1330) EJB timer service should use a thread pool to avoid OOM

by Galder Zamarreno (JIRA)

EJB timer service should use a thread pool to avoid OOM ------------------------------------------------------- Key: EJBTHREE-1330 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1330 Project: EJB 3.0 Issue Type: Bug Components: pool Affects Versions: AS 4.2.2.GA Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Priority: Minor The default EJB timer service used by the EJB3 layer is based on org.jboss.ejb3.timerservice.jboss.JBossTimerServiceFactory which delegates to the standard org.jboss.ejb.txtimer.EJBTimerService. For EJB3 beans using the EJB timer service the thread local pool should not be used. Since the current EJB timer service creates a new thread for each timer being created, the thread local pool will create a matching instance of the bean for that thread. Thus the number of active instances in total can effectively grow unchecked and thus an OOM will occur. -- 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

14 years, 2 months

5
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2166) no-interface view implementation based on MC constructs is brittle

by jaikiran pai (JIRA)

no-interface view implementation based on MC constructs is brittle ------------------------------------------------------------------ Key: EJBTHREE-2166 URL: https://jira.jboss.org/browse/EJBTHREE-2166 Project: EJB 3.0 Issue Type: Bug Components: nointerface Affects Versions: depchain-1.0.0-alpha-4 Reporter: jaikiran pai Assignee: jaikiran pai Currently the no-interface view proxy that gets bound into JNDI, internally uses a KernelControllerContext (MC construct) corresponding to the endpoint container of the EJB. The proxy depends just on DESCRIBED state of the endpoint. The invocation handler of that proxy, on first invocation, pushes the context to INSTALLED state (if not already in INSTALLED stated) and then invokes on the endpoint. This approach won't work out because MC returns an UnModifiable kernel controller context which throws an exception when we try to change the state of that context. More on this in the "Important" note at the end of this MC chapter http://docs.jboss.org/jbossmc/docs/2.0.x/userGuide/ch11s04.html: <quote> All context information is wrapped into unmodifiable objects to prevent the user from changing anything outside of the microcontainer's control. </quote> It's just plain luck that no-interface view works currently, because the first invocation on the nointerface view happens after the context has already been set to INSTALLED state by MC. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

3
8
0 / 0

[JBoss JIRA] Created: (JBSER-117) Problem with JBoss serializing of dynamic proxies

by Maksym Ivanchenko (JIRA)

Problem with JBoss serializing of dynamic proxies ------------------------------------------------- Key: JBSER-117 URL: https://jira.jboss.org/jira/browse/JBSER-117 Project: JBoss Serialization Issue Type: Bug Affects Versions: 1.0.3 GA Reporter: Maksym Ivanchenko Assignee: Clebert Suconic When we try to serialize a proxy that contains some child entity which points to proxy itself the following exception occurs: org.jboss.serial.exception.SerializationException: Object reference 1 was not found Simple test case for problem reproducing: import java.io.Serializable; import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; import java.lang.reflect.Proxy; import org.jboss.serial.io.JBossObjectOutputStream; import org.junit.Test; public class StandaloneProxySerializationTest { @Test public void testSerialization() throws Exception { ISampleEntity entity = new SampleEntityImpl(); Class<?>[] interfaces = new Class<?>[] {ISampleEntity.class}; SampleEntityInvocationHandler handler = new SampleEntityInvocationHandler(entity); ISampleEntity proxy = (ISampleEntity) Proxy.newProxyInstance(Thread.currentThread() .getContextClassLoader(), interfaces, handler); ISampleEntity childEntity = new SampleEntityImpl(); proxy.setChild(childEntity); childEntity.setParent(proxy); JBossObjectOutputStream jbossSerializer = new JBossObjectOutputStream(null); jbossSerializer.smartClone(proxy); } private static interface ISampleEntity { public ISampleEntity getParent(); public void setParent(ISampleEntity parent); public ISampleEntity getChild(); public void setChild(ISampleEntity child); } private static class SampleEntityImpl implements ISampleEntity, Serializable { private static final long serialVersionUID = 1L; private ISampleEntity parent; private ISampleEntity child; @Override public ISampleEntity getParent() { return parent; } @Override public void setParent(ISampleEntity parent) { this.parent = parent; } @Override public ISampleEntity getChild() { return child; } @Override public void setChild(ISampleEntity child) { this.child = child; } } private static class SampleEntityInvocationHandler implements InvocationHandler, Serializable { private static final long serialVersionUID = 1L; private ISampleEntity entity; public SampleEntityInvocationHandler(ISampleEntity entity) { this.entity = entity; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { return method.invoke(entity, args); } } } Upon ivestigating this issue we found that the problem is in ProxyPersister.readData() method. It reads the handler, the proxy class, constructs a proxy and only then puts it to cache. But if a proxy data contains proxy itself then it tries to find it by reference (which is not in cache yet, because the handler is still being read). So it throws "Object reference not found" exception. We worked around this problem by introducing an InvocationHandler wrapper in ProxyPersister: Patched ProxyPersister.java: /* * JBoss, Home of Professional Open Source * Copyright 2005, JBoss Inc., and individual contributors as indicated * by the @authors tag. See the copyright.txt in the distribution for a * full listing of individual contributors. * * This is free software; you can redistribute it and/or modify it * under the terms of the GNU Lesser General Public License as * published by the Free Software Foundation; either version 2.1 of * the License, or (at your option) any later version. * * This software is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this software; if not, write to the Free * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA * 02110-1301 USA, or see the FSF site: http://www.fsf.org. */ package org.jboss.serial.persister; import java.io.IOException; import java.io.ObjectInput; import java.io.ObjectOutput; import java.lang.reflect.Constructor; import java.lang.reflect.InvocationHandler; import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method; import java.lang.reflect.Proxy; import org.jboss.serial.classmetamodel.ClassMetaData; import org.jboss.serial.classmetamodel.StreamingClass; import org.jboss.serial.exception.SerializationException; import org.jboss.serial.objectmetamodel.ObjectSubstitutionInterface; import org.jboss.serial.objectmetamodel.ObjectsCache; /** * $Id: ProxyPersister.java,v 1.11 2006/04/24 23:49:40 csuconic Exp $ * * @author <a href="mailto:clebert.suconic@jboss.com">Clebert Suconic</a> */ public class ProxyPersister implements Persister { private byte id; public byte getId() { return id; } public void setId(byte id) { this.id = id; } public void writeData(ClassMetaData metaData, ObjectOutput output, Object obj, ObjectSubstitutionInterface substitution) throws IOException{ Object handler = Proxy.getInvocationHandler(obj); output.writeObject(obj.getClass()); output.writeObject(handler); } static class InvocationHandlerWrapper implements InvocationHandler { private InvocationHandler wrappedHandler; public void setWrappedHandler(InvocationHandler wrappedHandler) { this.wrappedHandler = wrappedHandler; } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { return wrappedHandler.invoke(proxy, method, args); } } public Object readData (ClassLoader loader, StreamingClass streaming, ClassMetaData metaData, int referenceId, ObjectsCache cache, ObjectInput input, ObjectSubstitutionInterface substitution) throws IOException{ try { Class proxy = (Class)input.readObject(); Constructor constructor = proxy.getConstructor(new Class[] { InvocationHandler.class }); InvocationHandlerWrapper wrapper = new InvocationHandlerWrapper(); Object obj = constructor.newInstance(new Object[]{wrapper}); cache.putObjectInCacheRead(referenceId,obj); Object handler = input.readObject(); wrapper.setWrappedHandler((InvocationHandler) handler); return obj; } catch (ClassNotFoundException e) { throw new SerializationException(e); } catch (NoSuchMethodException e) { throw new SerializationException(e); } catch (IllegalAccessException e) { throw new SerializationException(e); } catch (InstantiationException e) { throw new SerializationException(e); } catch (InvocationTargetException e) { throw new SerializationException(e); } } public boolean canPersist(Object obj) { // not implemented return false; } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-8827) Deal with expression values in all operation handlers

by Brian Stansberry (JIRA)

Deal with expression values in all operation handlers ----------------------------------------------------- Key: JBAS-8827 URL: https://issues.jboss.org/browse/JBAS-8827 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Priority: Critical Fix For: 7.0.0.Beta1 Pretty much any simple value in a detyped operation can be of type ModelType.EXPRESSION instead something an OperationHandler might expect, like ModelType.STRING or ModelType.INT. All handlers need to deal with this fact. There are two main aspects to this: 1) Any parameter validation that goes on needs to account for the presence of expression values. Basically that means a) accept the expression for storage in the model b) call resolve() on the operation and use the resolved version for application to the runtime. c) re-validation of the resolved value may be necessary -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

6
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2110) Add flag to enable an optimization to skip serialization/deserialization of Remote interfaces running locally

by Ben Schofield (JIRA)

Add flag to enable an optimization to skip serialization/deserialization of Remote interfaces running locally ------------------------------------------------------------------------------------------------------------- Key: EJBTHREE-2110 URL: https://jira.jboss.org/browse/EJBTHREE-2110 Project: EJB 3.0 Issue Type: Feature Request Reporter: Ben Schofield When an application uses a remote EJB3 interface the call is serialized and deserialized. While mandated by spec this is unnecessary if the EJB is running in the same JVM as the calling client. Having the option to skip serialization would bring JBoss inline with other major JEE vendors. Performance tests on a transactional application that has all business logic in stateless session bean methods is showing 20% cpu overhead just for the serialization. Having 20% more production CPU capacity is more important than claiming strict EJB3 compliance. JBoss AS response times are better too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

5
12
0 / 0

[JBoss JIRA] Created: (JBJCA-496) IronJacamar under a security manager

by Jesper Pedersen (JIRA)

IronJacamar under a security manager ------------------------------------ Key: JBJCA-496 URL: https://issues.jboss.org/browse/JBJCA-496 Project: IronJacamar Issue Type: Task Components: Test suite Reporter: Jesper Pedersen Assignee: Peter Skopek We should have a test case which tests deploying a resource adapter to IronJacamar running under a security manager. The rules should be as strict as possible to catch any issues. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8135) By default use a common identifier anywhere a server "id" notion is exposed in the configuration

by Brian Stansberry (JIRA)

By default use a common identifier anywhere a server "id" notion is exposed in the configuration ------------------------------------------------------------------------------------------------ Key: JBAS-8135 URL: https://jira.jboss.org/browse/JBAS-8135 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.0.0.M1 This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010: >> * JBoss Transactions, jvm-route, jboss messaging all require a >> unique identifier for them to behave properly in a clustered >> environment. I would like one unique identifier for each server >> configuration and for all services that need a unique identifier >> to reference it by default. Then I don't have to worry about >> unique identifiers when creating new servers. (The jboss messaging bit is out of date with respect to AS 7, which will use HornetQ and thus has no ServerPeerId configuration required. But the basic point is spot-on.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

6
14
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 2011