Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/537476#537476
--------------------------------------------------------------
What we generate is effectively something along the lines of
public class JavassistMethod1 implements JavassistMethod
{
public Object invoke(Object target, Object[] args) throws Throwable
{
if (target == null)
throw new IllegalArgumentException("Null target");
if (target instanceof SomeClass == false)
throw new IllegalArgumentException("Wrong target");
if (args == null || args.length != 10)
throw new IllegalArgumentException("Wrong number of parameters");
if (args[0] == null)
throw new IllegalArgumentException("Parameter 1 cannot be null for SomeClass.someMethod(long, String)");
if (args[0] != null && args[0] instanceof Long == false)
throw new IllegalArgumentException("Parameter 1 is not an instance of Long for SomeClass.someMethod(long, String)");
if (args[1] != null && args[1] instanceof String == false)
throw new IllegalArgumentException("Parameter 2 is not an instance of String for SomeClass.someMethod(long, String)");
return ((SomeClass)target).someMethod(((Long)args[0]).longValue(), (String)args[1]);
}
}
Disabling the parameter checking so we end up with this instead reduces the time spent in C from about 4.8s to 3.8s
public class JavassistMethod1 implements JavassistMethod
{
public Object invoke(Object target, Object[] args) throws Throwable
{
return ((SomeClass)target).someMethod(((Long)args[0]).longValue(), (String)args[1]);
}
}
Profiling this, for each JavassistMethod implementation the time taken is roughly
50% generating the bytecode for the method
30% Converting the bytecode to a byte array and creating the class
13% creating the constructor
6% setting the interfaces
Maybe a better approach would be
1) to do the parameter checking in Javassist[Constructor/Method/Field]Info itself
2) to generate less classes? Something like:
public class SomeBeanAccessor implements JavassistBeanAccessor
{
public Object newInstance(int index, Object[] args) throws Throwable
{
if (index == 0)
return new SomeClass((String)args[0]);
else if (index == 1)
return new SomeClass((String)args[1]);
return null;
}
public Object invoke(long hash, Object target, Object[] args) throws Throwable
{
if (hash == 121267912)
return ((SomeClass)target).someMethod(((Long)args[0]).longValue(), (String)args[1]);
if (hash == 128172981)
return ((SomeClass)target).otherMethod(((Long)args[0]).longValue(), (String)args[1], (String)args[2]);
}
public Object get(String name, Object target) throws Throwable
{
if (name.equals("intField")
return Integer.valueOf(((SomeClass)target).intField);
if (name.equals("stringField")
return ((SomeClass)target).stringField;
}
public void set(String name, Object target, Object value) throws Throwable
{
if (name.equals("intField")
((SomeClass)target).intField = ((Integer)value).intValue();
return;
if (name.equals("stringField")
((SomeClass)target).stringField = (String)value;
}
}
First call by Javassist[Constructor/Method/Field]Info to access the member would result in this being created for ALL members, and cached in JavassistTypeInfo.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/537476#537476]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[EJB 3.0 Development] - Stateful beans from 2 Jars - 1 persistence unit
by Nick Dodd
Nick Dodd [http://community.jboss.org/people/baronDodd] created the discussion
"Stateful beans from 2 Jars - 1 persistence unit"
To view the discussion, visit: http://community.jboss.org/message/537473#537473
--------------------------------------------------------------
I have a persistence unit named FOO inside a jar file as follows:
<persistence-unit name="FOO">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>java:/MYDS</jta-data-source>
<properties>
<property name="hibernate.hbm2ddl.auto" value="update"/>
</properties>
<jar-file>file:../anotherDir/secondary.jar</jar-file>
</persistence-unit>
This jar contains several Entity Beans and Session Beans that use this persistence unit ok.
As you can see I also have a second jar referenced in the persistence unit, it is another jar (not within an ear) that contains 1 more Entity bean and also 1 Session Bean.
When I start the server +all+ tables are successfully created including the entity defined in the secondary jar.
However - the Session Bean in the secondary jar is causing problems.
public class SecondaryFacade implements SecondaryFacadeLocal, SecondaryFacadeRemote {
......
@PersistenceContext(unitName="FOO")
protected EntityManager em;
......
ObjectName: persistence.units:unitName=FOO
State: NOTYETINSTALLED
Depends On Me:
jboss.j2ee:service=EJB3,jar=secondary.jar,name= SecondaryFacade
This issue may be related but not sure:
http://community.jboss.org/message/344723#344723 http://community.jboss.org/message/344723#344723
Am running JBoss 4.3.0. What I am doing might not even be possible or legal but if so then why does it deploy the Entity Bean successfully but not the Session Bean?
Many thanks
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/537473#537473]
Start a new discussion in EJB 3.0 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years