[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...]
15 years, 11 months
Re: [jboss-dev-forums] [EJB 3.0 Development] - Wrong JNDI context returned from EJB
by Richard Opalka
Richard Opalka [http://community.jboss.org/people/richard.opalka%40jboss.com] replied to the discussion
"Wrong JNDI context returned from EJB"
To view the discussion, visit: http://community.jboss.org/message/537414#537414
--------------------------------------------------------------
<bgeorges> ropalka: I was wondering what is happening with https://jira.jboss.org/jira/browse/JBAS-7888 https://jira.jboss.org/jira/browse/JBAS-7888 as we still have regressions with WS
<JiraBot> [#JBAS-7888] Investigate EJB3 Injection Integration Issue [Reopened, Major, Richard Opalka]
<ropalka> bgeorges, https://community.jboss.org/message/535366#535366 https://community.jboss.org/message/535366#535366
<ropalka> bgeorges, I'm waiting for Alessios and Carlos opinion on this topic
<bgeorges> ropalka: ok, thank you. carlo: can you have a look
<ropalka> bgeorges, However IMHO it's not a blocker for M3 release
<carlo> I don't know how a Handler is scoped.
<carlo> But JSR-250 injection happens from java:comp
<bgeorges> ropalka: that would be good, carlo: wdyt
<JiraBot> JIRA at jira.jboss.org reports that JSR-250 does not exist. https://jira.jboss.org/jira/browse/JSR-250 https://jira.jboss.org/jira/browse/JSR-250
<carlo> bgeorges: okay by me
<ropalka> carlo, bgeorges If JSR 250 injection happens from java:comp only then I know how to fix it. I'll remove this handler.
<ropalka> carlo, bgeorges I'll review also JSR 250 to be 100% sure
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/537414#537414]
Start a new discussion in EJB 3.0 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months
[JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/537409#537409
--------------------------------------------------------------
I have created a simple benchmark where I test the performance of different things using the different implementations. It can be found at https://svn.jboss.org/repos/jbossas/projects/jboss-reflect/trunk/src/test... https://svn.jboss.org/repos/jbossas/projects/jboss-reflect/trunk/src/test...
It first generates 100 classes, each with 100 fields and 100 methods, then it:
* A) Obtains a ClassInfo for each class
* B) Goes through each class and calls getDeclaredField() and getDeclaredMethod() for each field/method. This is done 50 times
* C) Calls FieldInfo.get/set and MethodInfo.get/set once for each field/method
* D) Same as C, but now it happens 50 times
Here are the times:
>
> ========== IntrospectionTypeInfoFactory
>
> A - Creating 100 ClassInfos 141ms
>
> B - Getting 100 fields and methods for 100 classes 50 times 1446ms
>
> C - First accessing 100 fields and methods for 100 classes 50 times 116ms
>
> D - Accessing 100 fields and methods for 100 classes 50 times 3545ms
>
> Done!
>
>
>
>
> ========== JavassistTypeInfoFactory
>
> A - Creating 100 ClassInfos 164ms
>
> B - Getting 100 fields and methods for 100 classes 50 times 820ms
>
> C - First accessing 100 fields and methods for 100 classes 50 times 4557ms
>
> D - Accessing 100 fields and methods for 100 classes 50 times 272ms
>
> Done!
>
* Creating the ClassInfos (A) takes about the same time with the two implementations.
* Calling getDeclaredMethod()/-Field() (B) is about twice as fast using Javassist as introspection.
* The first time a joinpoint is invoked is very slow with Javassist (due to generating the class), while subsequent calls are very fast
I'll profile C to see if it can be made faster somehow. Although, 20,000 classes are created so my guess is that creating an output stream for the class bytes for each class and then it with the classloader is the real overhead
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/537409#537409]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months
Re: [jboss-dev-forums] [EJB 3.0 Development] - Wrong JNDI context returned from EJB
by Richard Opalka
Richard Opalka [http://community.jboss.org/people/richard.opalka%40jboss.com] replied to the discussion
"Wrong JNDI context returned from EJB"
To view the discussion, visit: http://community.jboss.org/message/537334#537334
--------------------------------------------------------------
The situation is little bit more complicated.
*First of all I need to verify if the following usecase is valid.*
There's a *EJB3Bean* web service bean
with the following DD. It defines *boolean1* env entry.
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>EJB3Bean</ejb-name>
<ejb-class>org.jboss.test.ws.jaxws.ejb3Integration.injection.webservice.EJB3Bean</ejb-class>
* <env-entry>
<env-entry-name>boolean1</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>true</env-entry-value>
</env-entry>*
</session>
</enterprise-beans>
</ejb-jar>
There's a handler associated with this EJB3Bean
@WebService
*@HandlerChain(file = "jaxws-handler.xml")
*@Stateless
public class EJB3Bean extends AbstractEndpointImpl
{
public String echo(String msg)
{
return super.echo(msg) + ":EJB3Bean";
}
}
The content of jaxws-handler.xml is:
<handler-chains>
<handler-chain>
<handler>
<handler-name>TestHandler</handler-name>
* <handler-class>org.jboss.test.ws.jaxws.ejb3Integration.injection.shared.handlers.TestHandler</handler-class>
* </handler>
</handler-chain>
</handler-chains>
This TestHandler tries to access both EJB3Bean and it's env-entry
public final class TestHandler extends GenericSOAPHandler {
* @Resource private Boolean boolean1;
@EJB private BeanIface bean1;*
...
}**
Using global JNDI I'm able to fix @EJB injection.
*Question for EJB3 team:*
Do you think this JAX-WS handler should see env-entry of EJB3Bean?
That would mean required access to EJB3Bean specific JNDI context (the reason why we're using it instead of global JNDI).
I'll double check JAX-WS and EE6 specification for clarification, but would like to know your opinion ;)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/537334#537334]
Start a new discussion in EJB 3.0 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months