[JBoss JIRA] Created: (JBAS-9049) Need way to override the boot.log in start scripts
by Scott Stark (JIRA)
Need way to override the boot.log in start scripts
--------------------------------------------------
Key: JBAS-9049
URL: https://issues.jboss.org/browse/JBAS-9049
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: 7.0.0.Beta1
Reporter: Scott Stark
Assignee: David Lloyd
We need the ability to specify the location of the boot.log. Right now the boot.log location is specified via the org.jboss.boot.log.file java system property, but this is always set to $JBOSS_HOME/standalone/log/boot.log in the server start scripts. This should either not be set and simply default to $JBOSS_HOME/standalone/log/boot.log when unset so that it may be passed into the jvm, or, we need a JBOSS_BOOT_LOG env property that can override this value along the line of:
if [ "x$JBOSS_BOOT_LOG" = "x" ]; then
JBOSS_BOOT_LOG="$JBOSS_HOME/standalone/log/boot.log"
fi
while true; do
if [ "x$LAUNCH_JBOSS_IN_BACKGROUND" = "x" ]; then
# Execute the JVM in the foreground
eval \"$JAVA\" $JAVA_OPTS \
\"-Dorg.jboss.boot.log.file=$JBOSS_BOOT_LOG\" \
...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[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
12 years, 8 months
[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
12 years, 8 months
[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
12 years, 8 months
[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
12 years, 8 months