Re: OpenEJB - Missing required persistence.xml

[Jacek Laskowski]

On Feb 11, 2008 10:34 AM,  <[EMAIL PROTECTED]> wrote:

> - FAIL ... PatternManagementDaoImpl:Missing required persistence.xml
> for @PersistenceContext ref "em" to unit "pattern-managementPu"
>
> What's wrong? It is there. And where should it be placed? In META-INF
> like usually? It seems that it is later found.

"like usually"? That's how EJB3 spec mandates it so we should follow
the rule and we do. Can you jar -tf  and send the output
here? Could you show persistence.xml too so we can look at it?

> Can I define the order in which the EJB modules are loaded?

Not in a spec-compliant way. I'm not sure if you can do it in openejb
either, but would rather wait for Dave/Dain's reply before counting on
mine.

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

OpenEJB - Missing required persistence.xml

[Karsten.Ohme]

Hi,

I'm experimenting for one day with OpenEJB 3.0-beta-2, but I'm stuck. I
have tried different approaches to test EJBs, ejb3unit, JBoss
embeddable, but OpenEJB seems to be the best, although it also does not
work for me.

I always get a 

- FAIL ... PatternManagementDaoImpl:Missing required persistence.xml
for @PersistenceContext ref "em" to unit "pattern-managementPu"

What's wrong? It is there. And where should it be placed? In META-INF
like usually? It seems that it is later found.

What I want to do is to use an Apache Derby database (in memory) which
is automatically initilialized. What do I have to define and where, that
this works?

Can I define the order in which the EJB modules are loaded?

Thanks,
Karsten

Apache OpenEJB 3.0-beta-2build: 20080131-03:38
http://openejb.apache.org/
- openejb.home = C:\workspace\pattern-management\pattern-management-impl
- openejb.base = C:\workspace\pattern-management\pattern-management-impl
- Configuring Service(id=Default Security Service, type=SecurityService,
provider-id=Default Security Service)
- Configuring Service(id=Default Transaction Manager,
type=TransactionManager, provider-id=Default Transaction Manager)
- Configuring Service(id=Derby Database, type=Resource,
provider-id=Default JDBC Database)
- Configuring Service(id=Default JDK 1.3 ProxyFactory,
type=ProxyFactory, provider-id=Default JDK 1.3 ProxyFactory)
- Configuring Service(id=Default Stateless Container, type=Container,
provider-id=Default Stateless Container)
- Found EjbModule in classpath:
C:\workspace\pattern-management\pattern-management-impl\src\main\resourc
es
- Found EjbModule in classpath:
C:\workspace\pattern-management\pattern-management-impl\src\test\resourc
es
- Configuring app:
C:\workspace\networkstorage-management\networkstorage-management-impl\ta
rget\classes
- Loaded Module:
C:\workspace\networkstorage-management\networkstorage-management-impl\ta
rget\classes
- Configuring app:
C:\workspace\pattern-management\pattern-management-impl\target\classes
- FAIL ... PatternManagementDaoImpl:Missing required persistence.xml
for @PersistenceContext ref "em" to unit "pattern-managementPu"
- FAIL ... TestFacadeImpl:  Missing required persistence.xml for
@PersistenceContext ref "em" to unit "pattern-managementPu"
- Jar not loaded.
C:\workspace\pattern-management\pattern-management-impl\target\classes.
Module failed validation.
AppModule(path=C:\workspace\pattern-management\pattern-management-impl\t
arget\classes)
- Configuring app:
C:\workspace\pattern-management\pattern-management-impl\src\main\resourc
es
- Configuring PersistenceUnit(name=pattern-managementPu, provider=null)
- Loaded Module:
C:\workspace\pattern-management\pattern-management-impl\src\main\resourc
es
- Configuring app:
C:\workspace\pattern-management\pattern-management-impl\src\test\resourc
es
- Configuring PersistenceUnit(name=pattern-managementPu, provider=null)
- Loaded Module:
C:\workspace\pattern-management\pattern-management-impl\src\test\resourc
es
- Creating ProxyFactory(id=Default JDK 1.3 ProxyFactory)
- Creating TransactionManager(id=Default Transaction Manager)
- Creating SecurityService(id=Default Security Service)
- Creating Resource(id=Derby Database)
- Creating Container(id=Default Stateless Container)
- Assembling app:
C:\workspace\networkstorage-management\networkstorage-management-impl\ta
rget\classes
- Jndi(name=NetworkStorageServiceImplRemote) -->
Ejb(deployment-id=NetworkStorageServiceImpl)
- Created Ejb(deployment-id=NetworkStorageServiceImpl,
ejb-name=NetworkStorageServiceImpl, container=Default Stateless
Container)
- Deployed
Application(path=C:\workspace\networkstorage-management\networkstorage-m
anagement-impl\target\classes)
- Assembling app:
C:\workspace\pattern-management\pattern-management-impl\src\main\resourc
es
- PersistenceUnit(name=pattern-managementPu, provider=null)
- JAVA AGENT NOT INSTALLED. The JPA Persistence Provider requested
installation of a ClassFileTransformer which requires a JavaAgent.  See
http://openejb.apache.org/3.0/javaagent.html
- Deployed
Application(path=C:\workspace\pattern-management\pattern-management-impl
\src\main\resources)
- Assembling app:
C:\workspace\pattern-management\pattern-management-impl\src\test\resourc
es
- PersistenceUnit(name=pattern-managementPu, provider=null)
- JAVA AGENT NOT INSTALLED. The JPA Persistence Provider requested
installation of a ClassFileTransformer which requires a JavaAgent.  See
http://openejb.apache.org/3.0/javaagent.html
- Deployed
Application(path=C:\workspace\pattern-management\pattern-management-impl
\src\test\resources)
- OpenEJB ready.
OpenEJB ready.

Re: Load time dependency ordering problem

[Jack Cox]

David Blevins wrote:
> 
> 
> On Feb 8, 2008, at 10:32 AM, Jack Cox wrote:
> 
>>
>> I'm trying to setup a 'out-of-container' test rig to test both a set  
>> of
>> session beans and entity beans with openEJB.  The session beans  
>> depend on
>> the entity beans.  The session bean class files are located in one  
>> directory
>> tree, and the entity beans in another (they are two different Eclipse
>> projects).
>>
>> I've defined the dependencies in the openejb.xml config file as:
>>
>> 
>> 
>>
>> OpenEJB finds EJBs in both directory trees (as it should).
>>
>> But when the container tries to inject the entity beans into the  
>> session
>> beans I get the following error (stack dump eliminated for brevity)
> [..]
>> This leads me to believe that the entities have not been resolved  
>> before the
>> session beans start loading.  Is there a way to instruct the loader  
>> as to
>> the order in which things are loaded so that the entities get  
>> defined before
>> they are required by the session beans?
> 
> It might be possible to create an application.xml in the module  
> containing the tests, which would ensure they're deployed as one group.
> 
> So say for example:
> 
>vwc-masterdata-entity/classes
>vwc-masterdata-service/classes
>vwc-masterdata-foo/classes/META-INF/application.xml
> 
> Where vwc-masterdata-foo is the module that has your test cases.  The  
> paths listed in an application.xml are resolved relative to the ear  
> path (in this case "vwc-masterdata-foo/classes"),  so something like  
> this should work:
> 
> 
>
>  ../../vwc-masterdata-entity/classes/
>
>
>  ../../vwc-masterdata-service/classes/
>
> 
> 
> Course, this is all assuming your tests are in some third eclipse  
> module and not in vwc-masterdata-service or vwc-masterdata-entity.   
> Definitely let us know if that's not the case.
> 
> The thing, aside from order, that would prevent it from working as-is  
> is that local references between ejb-jars not in the same ear don't  
> work as we assume they are in different classloaders and we must  
> serialize/deserialize to get from one classloader to the other.  But  
> I'd guess that your eclipse project is smushing everything into the  
> same classloader already and we could find a way to detect that and  
> roll them together automatically as an ear for you.
> 
> Let us know if the suggestion doesn't work or doesn't really fit what  
> you'd like to do -- we are very happy to add support to really fit  
> what you need.  We support auto finding apps in the classpath  
> (eliminating the need for the Deployments elements in an openejb.xml),  
> when we do that we know in advance what classloader they come from and  
> could easily roll them into one ear instead of creating one ear each  
> as we do now.
> 
> -David
> 
> 
> 

David,

Thanks for the response.  Using the application.xml to group the class
directories did not have the desired effect.  The loader still sees them as
separate 'jars' and appear to be classloaded separately.  In their
'in-container' deployment the jar files from these directories are within
the same ear, so they are classloaded together.  

-Jack
-- 
View this message in context: 
http://www.nabble.com/Load-time-dependency-ordering-problem-tp15361292p15412772.html
Sent from the OpenEJB User mailing list archive at Nabble.com.