Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

David,

Can you please apply this patch as well.

* It reorders the execution of itests and modules.
* it configures the whole jar plugin to skip adding maven artifacts.

Thanx
prasad

On 11/20/06, Prasad Kashyap [EMAIL PROTECTED] wrote:

https://issues.apache.org/jira/browse/OPENEJB-305 is ready.

The java files from the OPENEJB-302 patch were not applied. Hence the
plans kept failing.

I have the same changes in the above patches too. Please apply them.

I have merged the cmp2 plans with itests-core.

Without the prefetch plan, the other 3 cmp2 plans when merged with
itests-core deploy and starts succeessfully

There is a problem with prefetch plan. After merging it, the jar fails
to start. See log in JIRA. Help needed here please !

Caused by: org.tranql.ql.QueryException: Finder [Finder
method=[findPrefetchAll]; EJB-QL=[
SELECT OBJECT(o) FROM Order AS o WHERE o.id = ?1
]]
at 
org.tranql.sql.EJBQLToPhysicalQuery.buildFinder(EJBQLToPhysicalQuery.java:143)
at 
org.tranql.sql.EJBQLToPhysicalQuery.buildFinders(EJBQLToPhysicalQuery.java:90)
... 86 more
Caused by: org.tranql.ql.QueryException: Finder does not return the
right abstract schema type.
at 
org.tranql.sql.EJBQLToPhysicalQuery.buildFinder(EJBQLToPhysicalQuery.java:137)
... 87 more



Thanx
Prasad

On 11/16/06, David Blevins [EMAIL PROTECTED] wrote:

 On Nov 14, 2006, at 8:47 AM, Prasad Kashyap wrote:

  I began by migrating just the itests-core DDs and then deployed it.
  It distributed the artifact but failed to start it.
 
  I hit the following error.
  http://rifers.org/paste/show/2308
 
  Can you please decipher this unknown reason error for me ? These DDs
  worked fine when I submitted the patch earlier. The only small diff
  between the DD then and now is the adjustment for the modified pkg
  structure (o.a.openejb)
 
  The patch for the migrated DD is attached here.
 

 Hmm, unfortunately I don't know what the unknown reason is
 either..  Is there something in your logs that has more detail?
 (hoping that what was posted wasn't the logs :)

 -David


  Thanx
  Prasad
 
 
  On 11/13/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
  Thanks for these comments, David.
 
  https://issues.apache.org/jira/browse/OPENEJB-302#action_12448245
 
  I'll create an ejbcontainer-testsuite now.
 
  Thanx
  Prasad
 
  On 11/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
   David,
  
   Can you please review and apply the patch here -
   https://issues.apache.org/jira/browse/OPENEJB-302
  
   Thanx
   Prasad
  
   On 11/3/06, David Blevins [EMAIL PROTECTED] wrote:
   
On Nov 2, 2006, at 6:30 PM, Prasad Kashyap wrote:
   
 OK. Sounds good. o.a.openejb it would be.

 The reasons I want to leave the tests in one single module are
 manifold.

 1) That is how they are today.
 2) To split them, it would have to be someone from openejb.
  I have no
 idea how they are structured.
 3) My top priority now is to get the testsuite framework
  integrated
 with the G build.
   
That's fine.  We can do that part later.
   
-David
   
   
 Cheers
 Prasad

 On 11/1/06, David Blevins [EMAIL PROTECTED] wrote:

 On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:

  On 10/30/06, David Blevins [EMAIL PROTECTED] wrote:
 
  On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:
 
   Thanx. Please see comments inline -
  
 
   Couple thoughts on the poms:
  
  - the parent would lineage would be
  org.apache.openejb:itests -
   org.apache.openejb:openejb
  - the groupId would be org.apache.openejb
  
   The groupId and the parent lineage looks good. As
  stated above,
  there
   would be many child modules for the beans under the
  itests
 parent
   module
  
   groupId: o.a.openejb
   openejb - itests - itests-security-xxx
   openejb - itests - itests-cmp2-xxx
 
  Exactly.
 
 
  After having built the itest beans as per our discussion
  above, the
  contents of the openejb directory in m2 local repo  are -
  ${settings.localRepository}/org/apache/openejb/
 
  itests-cmp2-cmrmapping
  itests-cmp2-petstore
  itests-cmp2-prefetch
  itests-cmp2-storage
  itests-itests-core
  itests-security-001
  itests-security-002
  itests-security-003
  openejb
  openejb-builder
  openejb-corba
  openejb-corba-builder
  openejb-core
  openejb-itests
  openejb-pkgen-builder
  openejb-sunorb
  openejb-yoko
 
  Does this look good ?  Or should we move the itests
  artifacts one
  level down to groupId o.a.openejb.itests ?

 Let's keep it in o.a.openejb for now as that's the way it
  is in 3.x.

  For now, I shall put all the tests into 1 artifact
  module. We
 should
  look at breaking them and putting them

Re: [discussion] openejb-itests in testsuite

[David Blevins]

On Nov 21, 2006, at 11:08 AM, Prasad Kashyap wrote:


David,

Can you please apply this patch as well.

* It reorders the execution of itests and modules.
* it configures the whole jar plugin to skip adding maven artifacts.


I applied what you described on IRC, let me know if that's not right.


Thanx
prasad

On 11/20/06, Prasad Kashyap [EMAIL PROTECTED] wrote:

https://issues.apache.org/jira/browse/OPENEJB-305 is ready.

The java files from the OPENEJB-302 patch were not applied. Hence the
plans kept failing.

I have the same changes in the above patches too. Please apply them.

I have merged the cmp2 plans with itests-core.

Without the prefetch plan, the other 3 cmp2 plans when merged with
itests-core deploy and starts succeessfully

There is a problem with prefetch plan. After merging it, the jar  
fails

to start. See log in JIRA. Help needed here please !

Caused by: org.tranql.ql.QueryException: Finder [Finder
method=[findPrefetchAll]; EJB-QL=[
SELECT OBJECT(o) FROM Order AS o WHERE o.id = ?1
]]
at org.tranql.sql.EJBQLToPhysicalQuery.buildFinder 
(EJBQLToPhysicalQuery.java:143)
at org.tranql.sql.EJBQLToPhysicalQuery.buildFinders 
(EJBQLToPhysicalQuery.java:90)

... 86 more
Caused by: org.tranql.ql.QueryException: Finder does not return the
right abstract schema type.
at org.tranql.sql.EJBQLToPhysicalQuery.buildFinder 
(EJBQLToPhysicalQuery.java:137)

... 87 more



Thanx
Prasad

On 11/16/06, David Blevins [EMAIL PROTECTED] wrote:

 On Nov 14, 2006, at 8:47 AM, Prasad Kashyap wrote:

  I began by migrating just the itests-core DDs and then  
deployed it.

  It distributed the artifact but failed to start it.
 
  I hit the following error.
  http://rifers.org/paste/show/2308
 
  Can you please decipher this unknown reason error for me ?  
These DDs
  worked fine when I submitted the patch earlier. The only small  
diff
  between the DD then and now is the adjustment for the modified  
pkg

  structure (o.a.openejb)
 
  The patch for the migrated DD is attached here.
 

 Hmm, unfortunately I don't know what the unknown reason is
 either..  Is there something in your logs that has more detail?
 (hoping that what was posted wasn't the logs :)

 -David


  Thanx
  Prasad
 
 
  On 11/13/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
  Thanks for these comments, David.
 
  https://issues.apache.org/jira/browse/ 
OPENEJB-302#action_12448245

 
  I'll create an ejbcontainer-testsuite now.
 
  Thanx
  Prasad
 
  On 11/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
   David,
  
   Can you please review and apply the patch here -
   https://issues.apache.org/jira/browse/OPENEJB-302
  
   Thanx
   Prasad
  
   On 11/3/06, David Blevins [EMAIL PROTECTED] wrote:
   
On Nov 2, 2006, at 6:30 PM, Prasad Kashyap wrote:
   
 OK. Sounds good. o.a.openejb it would be.

 The reasons I want to leave the tests in one single  
module are

 manifold.

 1) That is how they are today.
 2) To split them, it would have to be someone from  
openejb.

  I have no
 idea how they are structured.
 3) My top priority now is to get the testsuite framework
  integrated
 with the G build.
   
That's fine.  We can do that part later.
   
-David
   
   
 Cheers
 Prasad

 On 11/1/06, David Blevins [EMAIL PROTECTED] wrote:

 On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:

  On 10/30/06, David Blevins [EMAIL PROTECTED]  
wrote:

 
  On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:
 
   Thanx. Please see comments inline -
  
 
   Couple thoughts on the poms:
  
  - the parent would lineage would be
  org.apache.openejb:itests -
   org.apache.openejb:openejb
  - the groupId would be org.apache.openejb
  
   The groupId and the parent lineage looks good. As
  stated above,
  there
   would be many child modules for the beans under the
  itests
 parent
   module
  
   groupId: o.a.openejb
   openejb - itests - itests-security-xxx
   openejb - itests - itests-cmp2-xxx
 
  Exactly.
 
 
  After having built the itest beans as per our  
discussion

  above, the
  contents of the openejb directory in m2 local repo   
are -

  ${settings.localRepository}/org/apache/openejb/
 
  itests-cmp2-cmrmapping
  itests-cmp2-petstore
  itests-cmp2-prefetch
  itests-cmp2-storage
  itests-itests-core
  itests-security-001
  itests-security-002
  itests-security-003
  openejb
  openejb-builder
  openejb-corba
  openejb-corba-builder
  openejb-core
  openejb-itests
  openejb-pkgen-builder
  openejb-sunorb
  openejb-yoko
 
  Does this look good ?  Or should we move the itests
  artifacts one
  level down to groupId o.a.openejb.itests ?

 Let's keep it in o.a.openejb for now as that's the way

Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

https://issues.apache.org/jira/browse/OPENEJB-305 is ready.

The java files from the OPENEJB-302 patch were not applied. Hence the
plans kept failing.

I have the same changes in the above patches too. Please apply them.

I have merged the cmp2 plans with itests-core.

Without the prefetch plan, the other 3 cmp2 plans when merged with
itests-core deploy and starts succeessfully

There is a problem with prefetch plan. After merging it, the jar fails
to start. See log in JIRA. Help needed here please !

Caused by: org.tranql.ql.QueryException: Finder [Finder
method=[findPrefetchAll]; EJB-QL=[
   SELECT OBJECT(o) FROM Order AS o WHERE o.id = ?1
   ]]
at 
org.tranql.sql.EJBQLToPhysicalQuery.buildFinder(EJBQLToPhysicalQuery.java:143)
at 
org.tranql.sql.EJBQLToPhysicalQuery.buildFinders(EJBQLToPhysicalQuery.java:90)
... 86 more
Caused by: org.tranql.ql.QueryException: Finder does not return the
right abstract schema type.
at 
org.tranql.sql.EJBQLToPhysicalQuery.buildFinder(EJBQLToPhysicalQuery.java:137)
... 87 more



Thanx
Prasad

On 11/16/06, David Blevins [EMAIL PROTECTED] wrote:


On Nov 14, 2006, at 8:47 AM, Prasad Kashyap wrote:

 I began by migrating just the itests-core DDs and then deployed it.
 It distributed the artifact but failed to start it.

 I hit the following error.
 http://rifers.org/paste/show/2308

 Can you please decipher this unknown reason error for me ? These DDs
 worked fine when I submitted the patch earlier. The only small diff
 between the DD then and now is the adjustment for the modified pkg
 structure (o.a.openejb)

 The patch for the migrated DD is attached here.


Hmm, unfortunately I don't know what the unknown reason is
either..  Is there something in your logs that has more detail?
(hoping that what was posted wasn't the logs :)

-David


 Thanx
 Prasad


 On 11/13/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
 Thanks for these comments, David.

 https://issues.apache.org/jira/browse/OPENEJB-302#action_12448245

 I'll create an ejbcontainer-testsuite now.

 Thanx
 Prasad

 On 11/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
  David,
 
  Can you please review and apply the patch here -
  https://issues.apache.org/jira/browse/OPENEJB-302
 
  Thanx
  Prasad
 
  On 11/3/06, David Blevins [EMAIL PROTECTED] wrote:
  
   On Nov 2, 2006, at 6:30 PM, Prasad Kashyap wrote:
  
OK. Sounds good. o.a.openejb it would be.
   
The reasons I want to leave the tests in one single module are
manifold.
   
1) That is how they are today.
2) To split them, it would have to be someone from openejb.
 I have no
idea how they are structured.
3) My top priority now is to get the testsuite framework
 integrated
with the G build.
  
   That's fine.  We can do that part later.
  
   -David
  
  
Cheers
Prasad
   
On 11/1/06, David Blevins [EMAIL PROTECTED] wrote:
   
On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:
   
 On 10/30/06, David Blevins [EMAIL PROTECTED] wrote:

 On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:

  Thanx. Please see comments inline -
 

  Couple thoughts on the poms:
 
 - the parent would lineage would be
 org.apache.openejb:itests -
  org.apache.openejb:openejb
 - the groupId would be org.apache.openejb
 
  The groupId and the parent lineage looks good. As
 stated above,
 there
  would be many child modules for the beans under the
 itests
parent
  module
 
  groupId: o.a.openejb
  openejb - itests - itests-security-xxx
  openejb - itests - itests-cmp2-xxx

 Exactly.


 After having built the itest beans as per our discussion
 above, the
 contents of the openejb directory in m2 local repo  are -
 ${settings.localRepository}/org/apache/openejb/

 itests-cmp2-cmrmapping
 itests-cmp2-petstore
 itests-cmp2-prefetch
 itests-cmp2-storage
 itests-itests-core
 itests-security-001
 itests-security-002
 itests-security-003
 openejb
 openejb-builder
 openejb-corba
 openejb-corba-builder
 openejb-core
 openejb-itests
 openejb-pkgen-builder
 openejb-sunorb
 openejb-yoko

 Does this look good ?  Or should we move the itests
 artifacts one
 level down to groupId o.a.openejb.itests ?
   
Let's keep it in o.a.openejb for now as that's the way it
 is in 3.x.
   
 For now, I shall put all the tests into 1 artifact
 module. We
should
 look at breaking them and putting them with their
 respective bean
 modules later on.
   
What's the issue with doing that now?
   
-David
   
   
   
  
  
 

 itests-core.patch

Re: [discussion] openejb-itests in testsuite

[David Blevins]

On Nov 14, 2006, at 8:47 AM, Prasad Kashyap wrote:


I began by migrating just the itests-core DDs and then deployed it.
It distributed the artifact but failed to start it.

I hit the following error.
http://rifers.org/paste/show/2308

Can you please decipher this unknown reason error for me ? These DDs
worked fine when I submitted the patch earlier. The only small diff
between the DD then and now is the adjustment for the modified pkg
structure (o.a.openejb)

The patch for the migrated DD is attached here.



Hmm, unfortunately I don't know what the unknown reason is  
either..  Is there something in your logs that has more detail?  
(hoping that what was posted wasn't the logs :)


-David



Thanx
Prasad


On 11/13/06, Prasad Kashyap [EMAIL PROTECTED] wrote:

Thanks for these comments, David.

https://issues.apache.org/jira/browse/OPENEJB-302#action_12448245

I'll create an ejbcontainer-testsuite now.

Thanx
Prasad

On 11/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
 David,

 Can you please review and apply the patch here -
 https://issues.apache.org/jira/browse/OPENEJB-302

 Thanx
 Prasad

 On 11/3/06, David Blevins [EMAIL PROTECTED] wrote:
 
  On Nov 2, 2006, at 6:30 PM, Prasad Kashyap wrote:
 
   OK. Sounds good. o.a.openejb it would be.
  
   The reasons I want to leave the tests in one single module are
   manifold.
  
   1) That is how they are today.
   2) To split them, it would have to be someone from openejb.  
I have no

   idea how they are structured.
   3) My top priority now is to get the testsuite framework  
integrated

   with the G build.
 
  That's fine.  We can do that part later.
 
  -David
 
 
   Cheers
   Prasad
  
   On 11/1/06, David Blevins [EMAIL PROTECTED] wrote:
  
   On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:
  
On 10/30/06, David Blevins [EMAIL PROTECTED] wrote:
   
On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:
   
 Thanx. Please see comments inline -

   
 Couple thoughts on the poms:

- the parent would lineage would be
org.apache.openejb:itests -
 org.apache.openejb:openejb
- the groupId would be org.apache.openejb

 The groupId and the parent lineage looks good. As  
stated above,

there
 would be many child modules for the beans under the  
itests

   parent
 module

 groupId: o.a.openejb
 openejb - itests - itests-security-xxx
 openejb - itests - itests-cmp2-xxx
   
Exactly.
   
   
After having built the itest beans as per our discussion  
above, the

contents of the openejb directory in m2 local repo  are -
${settings.localRepository}/org/apache/openejb/
   
itests-cmp2-cmrmapping
itests-cmp2-petstore
itests-cmp2-prefetch
itests-cmp2-storage
itests-itests-core
itests-security-001
itests-security-002
itests-security-003
openejb
openejb-builder
openejb-corba
openejb-corba-builder
openejb-core
openejb-itests
openejb-pkgen-builder
openejb-sunorb
openejb-yoko
   
Does this look good ?  Or should we move the itests  
artifacts one

level down to groupId o.a.openejb.itests ?
  
   Let's keep it in o.a.openejb for now as that's the way it  
is in 3.x.

  
For now, I shall put all the tests into 1 artifact  
module. We

   should
look at breaking them and putting them with their  
respective bean

modules later on.
  
   What's the issue with doing that now?
  
   -David
  
  
  
 
 


itests-core.patch

Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

Thanks for these comments, David.

https://issues.apache.org/jira/browse/OPENEJB-302#action_12448245

I'll create an ejbcontainer-testsuite now.

Thanx
Prasad

On 11/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:

David,

Can you please review and apply the patch here -
https://issues.apache.org/jira/browse/OPENEJB-302

Thanx
Prasad

On 11/3/06, David Blevins [EMAIL PROTECTED] wrote:

 On Nov 2, 2006, at 6:30 PM, Prasad Kashyap wrote:

  OK. Sounds good. o.a.openejb it would be.
 
  The reasons I want to leave the tests in one single module are
  manifold.
 
  1) That is how they are today.
  2) To split them, it would have to be someone from openejb. I have no
  idea how they are structured.
  3) My top priority now is to get the testsuite framework integrated
  with the G build.

 That's fine.  We can do that part later.

 -David


  Cheers
  Prasad
 
  On 11/1/06, David Blevins [EMAIL PROTECTED] wrote:
 
  On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:
 
   On 10/30/06, David Blevins [EMAIL PROTECTED] wrote:
  
   On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:
  
Thanx. Please see comments inline -
   
  
Couple thoughts on the poms:
   
   - the parent would lineage would be
   org.apache.openejb:itests -
org.apache.openejb:openejb
   - the groupId would be org.apache.openejb
   
The groupId and the parent lineage looks good. As stated above,
   there
would be many child modules for the beans under the itests
  parent
module
   
groupId: o.a.openejb
openejb - itests - itests-security-xxx
openejb - itests - itests-cmp2-xxx
  
   Exactly.
  
  
   After having built the itest beans as per our discussion above, the
   contents of the openejb directory in m2 local repo  are -
   ${settings.localRepository}/org/apache/openejb/
  
   itests-cmp2-cmrmapping
   itests-cmp2-petstore
   itests-cmp2-prefetch
   itests-cmp2-storage
   itests-itests-core
   itests-security-001
   itests-security-002
   itests-security-003
   openejb
   openejb-builder
   openejb-corba
   openejb-corba-builder
   openejb-core
   openejb-itests
   openejb-pkgen-builder
   openejb-sunorb
   openejb-yoko
  
   Does this look good ?  Or should we move the itests artifacts one
   level down to groupId o.a.openejb.itests ?
 
  Let's keep it in o.a.openejb for now as that's the way it is in 3.x.
 
   For now, I shall put all the tests into 1 artifact module. We
  should
   look at breaking them and putting them with their respective bean
   modules later on.
 
  What's the issue with doing that now?
 
  -David
 
 
 

Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

David,

Can you please review and apply the patch here -
https://issues.apache.org/jira/browse/OPENEJB-302

Thanx
Prasad

On 11/3/06, David Blevins [EMAIL PROTECTED] wrote:


On Nov 2, 2006, at 6:30 PM, Prasad Kashyap wrote:

 OK. Sounds good. o.a.openejb it would be.

 The reasons I want to leave the tests in one single module are
 manifold.

 1) That is how they are today.
 2) To split them, it would have to be someone from openejb. I have no
 idea how they are structured.
 3) My top priority now is to get the testsuite framework integrated
 with the G build.

That's fine.  We can do that part later.

-David


 Cheers
 Prasad

 On 11/1/06, David Blevins [EMAIL PROTECTED] wrote:

 On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:

  On 10/30/06, David Blevins [EMAIL PROTECTED] wrote:
 
  On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:
 
   Thanx. Please see comments inline -
  
 
   Couple thoughts on the poms:
  
  - the parent would lineage would be
  org.apache.openejb:itests -
   org.apache.openejb:openejb
  - the groupId would be org.apache.openejb
  
   The groupId and the parent lineage looks good. As stated above,
  there
   would be many child modules for the beans under the itests
 parent
   module
  
   groupId: o.a.openejb
   openejb - itests - itests-security-xxx
   openejb - itests - itests-cmp2-xxx
 
  Exactly.
 
 
  After having built the itest beans as per our discussion above, the
  contents of the openejb directory in m2 local repo  are -
  ${settings.localRepository}/org/apache/openejb/
 
  itests-cmp2-cmrmapping
  itests-cmp2-petstore
  itests-cmp2-prefetch
  itests-cmp2-storage
  itests-itests-core
  itests-security-001
  itests-security-002
  itests-security-003
  openejb
  openejb-builder
  openejb-corba
  openejb-corba-builder
  openejb-core
  openejb-itests
  openejb-pkgen-builder
  openejb-sunorb
  openejb-yoko
 
  Does this look good ?  Or should we move the itests artifacts one
  level down to groupId o.a.openejb.itests ?

 Let's keep it in o.a.openejb for now as that's the way it is in 3.x.

  For now, I shall put all the tests into 1 artifact module. We
 should
  look at breaking them and putting them with their respective bean
  modules later on.

 What's the issue with doing that now?

 -David

Re: [discussion] openejb-itests in testsuite

[David Blevins]

On Nov 2, 2006, at 6:30 PM, Prasad Kashyap wrote:


OK. Sounds good. o.a.openejb it would be.

The reasons I want to leave the tests in one single module are  
manifold.


1) That is how they are today.
2) To split them, it would have to be someone from openejb. I have no
idea how they are structured.
3) My top priority now is to get the testsuite framework integrated
with the G build.


That's fine.  We can do that part later.

-David



Cheers
Prasad

On 11/1/06, David Blevins [EMAIL PROTECTED] wrote:


On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:

 On 10/30/06, David Blevins [EMAIL PROTECTED] wrote:

 On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:

  Thanx. Please see comments inline -
 

  Couple thoughts on the poms:
 
 - the parent would lineage would be
 org.apache.openejb:itests -
  org.apache.openejb:openejb
 - the groupId would be org.apache.openejb
 
  The groupId and the parent lineage looks good. As stated above,
 there
  would be many child modules for the beans under the itests  
parent

  module
 
  groupId: o.a.openejb
  openejb - itests - itests-security-xxx
  openejb - itests - itests-cmp2-xxx

 Exactly.


 After having built the itest beans as per our discussion above, the
 contents of the openejb directory in m2 local repo  are -
 ${settings.localRepository}/org/apache/openejb/

 itests-cmp2-cmrmapping
 itests-cmp2-petstore
 itests-cmp2-prefetch
 itests-cmp2-storage
 itests-itests-core
 itests-security-001
 itests-security-002
 itests-security-003
 openejb
 openejb-builder
 openejb-corba
 openejb-corba-builder
 openejb-core
 openejb-itests
 openejb-pkgen-builder
 openejb-sunorb
 openejb-yoko

 Does this look good ?  Or should we move the itests artifacts one
 level down to groupId o.a.openejb.itests ?

Let's keep it in o.a.openejb for now as that's the way it is in 3.x.

 For now, I shall put all the tests into 1 artifact module. We  
should

 look at breaking them and putting them with their respective bean
 modules later on.

What's the issue with doing that now?

-David

Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

OK. Sounds good. o.a.openejb it would be.

The reasons I want to leave the tests in one single module are manifold.

1) That is how they are today.
2) To split them, it would have to be someone from openejb. I have no
idea how they are structured.
3) My top priority now is to get the testsuite framework integrated
with the G build.

Cheers
Prasad

On 11/1/06, David Blevins [EMAIL PROTECTED] wrote:


On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:

 On 10/30/06, David Blevins [EMAIL PROTECTED] wrote:

 On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:

  Thanx. Please see comments inline -
 

  Couple thoughts on the poms:
 
 - the parent would lineage would be
 org.apache.openejb:itests -
  org.apache.openejb:openejb
 - the groupId would be org.apache.openejb
 
  The groupId and the parent lineage looks good. As stated above,
 there
  would be many child modules for the beans under the itests parent
  module
 
  groupId: o.a.openejb
  openejb - itests - itests-security-xxx
  openejb - itests - itests-cmp2-xxx

 Exactly.


 After having built the itest beans as per our discussion above, the
 contents of the openejb directory in m2 local repo  are -
 ${settings.localRepository}/org/apache/openejb/

 itests-cmp2-cmrmapping
 itests-cmp2-petstore
 itests-cmp2-prefetch
 itests-cmp2-storage
 itests-itests-core
 itests-security-001
 itests-security-002
 itests-security-003
 openejb
 openejb-builder
 openejb-corba
 openejb-corba-builder
 openejb-core
 openejb-itests
 openejb-pkgen-builder
 openejb-sunorb
 openejb-yoko

 Does this look good ?  Or should we move the itests artifacts one
 level down to groupId o.a.openejb.itests ?

Let's keep it in o.a.openejb for now as that's the way it is in 3.x.

 For now, I shall put all the tests into 1 artifact module. We should
 look at breaking them and putting them with their respective bean
 modules later on.

What's the issue with doing that now?

-David

Re: [discussion] openejb-itests in testsuite

[David Blevins]

On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:


On 10/30/06, David Blevins [EMAIL PROTECTED] wrote:


On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:

 Thanx. Please see comments inline -




 Couple thoughts on the poms:

- the parent would lineage would be  
org.apache.openejb:itests -

 org.apache.openejb:openejb
- the groupId would be org.apache.openejb

 The groupId and the parent lineage looks good. As stated above,  
there

 would be many child modules for the beans under the itests parent
 module

 groupId: o.a.openejb
 openejb - itests - itests-security-xxx
 openejb - itests - itests-cmp2-xxx

Exactly.



After having built the itest beans as per our discussion above, the
contents of the openejb directory in m2 local repo  are -
${settings.localRepository}/org/apache/openejb/

itests-cmp2-cmrmapping
itests-cmp2-petstore
itests-cmp2-prefetch
itests-cmp2-storage
itests-itests-core
itests-security-001
itests-security-002
itests-security-003
openejb
openejb-builder
openejb-corba
openejb-corba-builder
openejb-core
openejb-itests
openejb-pkgen-builder
openejb-sunorb
openejb-yoko

Does this look good ?  Or should we move the itests artifacts one
level down to groupId o.a.openejb.itests ?


Let's keep it in o.a.openejb for now as that's the way it is in 3.x.


For now, I shall put all the tests into 1 artifact module. We should
look at breaking them and putting them with their respective bean
modules later on.


What's the issue with doing that now?

-David

Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

On 10/30/06, David Blevins [EMAIL PROTECTED] wrote:


On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:

 Thanx. Please see comments inline -




 Couple thoughts on the poms:

- the parent would lineage would be org.apache.openejb:itests -
 org.apache.openejb:openejb
- the groupId would be org.apache.openejb

 The groupId and the parent lineage looks good. As stated above, there
 would be many child modules for the beans under the itests parent
 module

 groupId: o.a.openejb
 openejb - itests - itests-security-xxx
 openejb - itests - itests-cmp2-xxx

Exactly.



After having built the itest beans as per our discussion above, the
contents of the openejb directory in m2 local repo  are -
${settings.localRepository}/org/apache/openejb/

itests-cmp2-cmrmapping
itests-cmp2-petstore
itests-cmp2-prefetch
itests-cmp2-storage
itests-itests-core
itests-security-001
itests-security-002
itests-security-003
openejb
openejb-builder
openejb-corba
openejb-corba-builder
openejb-core
openejb-itests
openejb-pkgen-builder
openejb-sunorb
openejb-yoko

Does this look good ?  Or should we move the itests artifacts one
level down to groupId o.a.openejb.itests ?


-David


For now, I shall put all the tests into 1 artifact module. We should
look at breaking them and putting them with their respective bean
modules later on.

Cheers
Prasad.

Re: [discussion] openejb-itests in testsuite

[Jacek Laskowski]

On 10/31/06, Prasad Kashyap [EMAIL PROTECTED] wrote:

Does this look good ?  Or should we move the itests artifacts one
level down to groupId o.a.openejb.itests ?


It'd be great to move the itests one level below.

Jacek

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

Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

Thanx. Please see comments inline -

Cheers
Prasad

On 10/27/06, David Blevins [EMAIL PROTECTED] wrote:

Ok, I took look through where you're going and here's a slightly
altered proposal.

We group the tests with the beans as such:

  openejb-footests/src/main/# this is where the beans will go
  openejb-footests/src/test/# this is where the client test code
will go


Do you propose putting all the beans in one single module and thus one
single ejb-jar ? The many plans that we use forces us to have multiple
jars and thus separate modules(poms) for each. This is why I had the
beans spread across multiple modules.



We setup the poms to package and publish the test code with the beans:

  http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html


+1. I like this idea. It keeps the tests code with the beans. In
geronimo/testsuite/ejbcontainer-testsuite, I can just get this
test-jar, expand it and run the tests in them.


That will avoid spreading the code for a single test between two
modules and avoids the bucket module that would contain all test
client code for all modules and would needlessly have a dependency on
all modules.

Couple thoughts on the poms:

   - the parent would lineage would be org.apache.openejb:itests -
org.apache.openejb:openejb
   - the groupId would be org.apache.openejb


The groupId and the parent lineage looks good. As stated above, there
would be many child modules for the beans under the itests parent
module

groupId: o.a.openejb
openejb - itests - itests-security-xxx
openejb - itests - itests-cmp2-xxx



You and put any geronimo-specific plugins, descriptors, or
dependencies in pom.xmls (modules) in geronimo svn using any layout
you choose.  Those modules would just declare dependencies on the
openejb test libraries they wish to reuse.  That should be fine
unless you also plan to redo all the test source code to something
other than junit or introduce code dependencies on geronimo-specific
bits of test framework.  If that's the ultimate goal, then it might
just be better to take a copy of the test code.


Well, the other tests in geronimo are written in TestNG. Until we move
to JDK 1.5, it doesn't make sense to move the openejb itests to
TestNG. The annotations all have to change. Moreover, it may not make
practical sense to move these 400+ tests from junit to TestNG. So we
may stay with this arrangement. But IF ever we do so for any reason,
then yes,  we should make another copy of the test code.



Thoughts?

-David




Thanx
Prasad

Re: [discussion] openejb-itests in testsuite

[David Blevins]

On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:


Thanx. Please see comments inline -

Cheers
Prasad

On 10/27/06, David Blevins [EMAIL PROTECTED] wrote:

Ok, I took look through where you're going and here's a slightly
altered proposal.

We group the tests with the beans as such:

  openejb-footests/src/main/# this is where the beans will go
  openejb-footests/src/test/# this is where the client test code
will go


Do you propose putting all the beans in one single module and thus one
single ejb-jar ?


I meant one of the above for each set of beans/tests/descriptors.



We setup the poms to package and publish the test code with the  
beans:


  http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html


+1. I like this idea. It keeps the tests code with the beans. In
geronimo/testsuite/ejbcontainer-testsuite, I can just get this
test-jar, expand it and run the tests in them.


That will avoid spreading the code for a single test between two
modules and avoids the bucket module that would contain all test
client code for all modules and would needlessly have a dependency on
all modules.

Couple thoughts on the poms:

   - the parent would lineage would be org.apache.openejb:itests -
org.apache.openejb:openejb
   - the groupId would be org.apache.openejb


The groupId and the parent lineage looks good. As stated above, there
would be many child modules for the beans under the itests parent
module

groupId: o.a.openejb
openejb - itests - itests-security-xxx
openejb - itests - itests-cmp2-xxx


Exactly.



You and put any geronimo-specific plugins, descriptors, or
dependencies in pom.xmls (modules) in geronimo svn using any layout
you choose.  Those modules would just declare dependencies on the
openejb test libraries they wish to reuse.  That should be fine
unless you also plan to redo all the test source code to something
other than junit or introduce code dependencies on geronimo-specific
bits of test framework.  If that's the ultimate goal, then it might
just be better to take a copy of the test code.


Well, the other tests in geronimo are written in TestNG. Until we move
to JDK 1.5, it doesn't make sense to move the openejb itests to
TestNG. The annotations all have to change. Moreover, it may not make
practical sense to move these 400+ tests from junit to TestNG. So we
may stay with this arrangement. But IF ever we do so for any reason,
then yes,  we should make another copy of the test code.


Sounds like a plan.

-David

Re: [discussion] openejb-itests in testsuite

[Jacek Laskowski]

On 10/28/06, David Blevins [EMAIL PROTECTED] wrote:

Ok, I took look through where you're going and here's a slightly
altered proposal.

We group the tests with the beans as such:

  openejb-footests/src/main/# this is where the beans will go
  openejb-footests/src/test/# this is where the client test code
will go

We setup the poms to package and publish the test code with the beans:

  http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html

That will avoid spreading the code for a single test between two
modules and avoids the bucket module that would contain all test
client code for all modules and would needlessly have a dependency on
all modules.


That sound very promising. I like it.


Couple thoughts on the poms:

   - the parent would lineage would be org.apache.openejb:itests -
org.apache.openejb:openejb
   - the groupId would be org.apache.openejb


Unless I'm mistaken, it implies that itests are a submodule of the
top-level module of OpenEJB, doesn't it? If so, I'm fine with it, too.


You and put any geronimo-specific plugins, descriptors, or
dependencies in pom.xmls (modules) in geronimo svn using any layout
you choose.  Those modules would just declare dependencies on the
openejb test libraries they wish to reuse.


Does it mean that Geronimo tests would be dependent on OpenEJB? These
should be separate as much as possible. If there's no other way, let's
start with it and think about it later.


That should be fine
unless you also plan to redo all the test source code to something
other than junit or introduce code dependencies on geronimo-specific
bits of test framework.


That's what I didn't catch. What do you mean by that?

Jacek

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

Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

http://people.apache.org/~prasad/ejb-modules.zip

You may remove the parent from the top level pom and adjust the
groupId appropriately to build this.

Cheers
Prasad

On 10/25/06, David Blevins [EMAIL PROTECTED] wrote:

Great, I'll be looking forward to it.

-David

On Oct 23, 2006, at 9:36 PM, Prasad Kashyap wrote:

 Thanx David. I shall try to put it in a sandbox if I can, or else send
 you a a patch.

 Cheers
 Prasad

 On 10/23/06, David Blevins [EMAIL PROTECTED] wrote:

 On Oct 23, 2006, at 2:34 PM, Prasad Kashyap wrote:

  I have migrated the openejb-itests module to m2 with the
 intention of
  using it for G's testsuite.  The junit test code will have to go
 under
  the ejbcontainer-testsuite under the testsuite framework
  (geronimo/testsuite).

 I don't know which approach would make sense or if there is some
 middle ground.  You have a copy of this migrated code somewhere I
 could look at/try out?

 If we did #2 it'd obviously be a copy as OpenEJB 3 runs those tests
 about 7 times during an average build and another 5 more times on a
 build with assemblies.

 -David

  The beans and the ejub jars can go just about anywhere.  So I'd
 like
  to solicit the suggestion of openejb and geronimo folks on where we
  should place them
 
  1) Leave them where they are under openejb2/modules/openejb-itests.
  Get help from openejb commiters to get this commited. Unlike in
  previous G releases, this module would now only build the ejb
 jars. No
  tests would actually run here.
 
  2) Move/copy the ejbs to some place under testsuite and create the
  jars there. This will keep the ejbs and the tests together.
 Since the
  moduleId (configId) in the plans should match the m2
 artifactItem id
  (g:a:v:t), the moduleId in the ejb plans would then become
  o.a.g.testsuite.*
 
 
  Apart from this decision, other things that need to resolved
 before we
  put this code in are
 
  http://issues.apache.org/jira/browse/OPENEJB-288
  http://www.mail-archive.com/dev@geronimo.apache.org/msg34995.html
 
 
  Cheers
  Prasad
 

Re: [discussion] openejb-itests in testsuite

[David Blevins]

On Oct 27, 2006, at 7:34 AM, Prasad Kashyap wrote:


http://people.apache.org/~prasad/ejb-modules.zip

You may remove the parent from the top level pom and adjust the
groupId appropriately to build this.


Looks like you have the beans in there.  Where is the test code?

-David


Cheers
Prasad

On 10/25/06, David Blevins [EMAIL PROTECTED] wrote:

Great, I'll be looking forward to it.

-David

On Oct 23, 2006, at 9:36 PM, Prasad Kashyap wrote:

 Thanx David. I shall try to put it in a sandbox if I can, or  
else send

 you a a patch.

 Cheers
 Prasad

 On 10/23/06, David Blevins [EMAIL PROTECTED] wrote:

 On Oct 23, 2006, at 2:34 PM, Prasad Kashyap wrote:

  I have migrated the openejb-itests module to m2 with the
 intention of
  using it for G's testsuite.  The junit test code will have to go
 under
  the ejbcontainer-testsuite under the testsuite framework
  (geronimo/testsuite).

 I don't know which approach would make sense or if there is some
 middle ground.  You have a copy of this migrated code somewhere I
 could look at/try out?

 If we did #2 it'd obviously be a copy as OpenEJB 3 runs those  
tests
 about 7 times during an average build and another 5 more times  
on a

 build with assemblies.

 -David

  The beans and the ejub jars can go just about anywhere.  So I'd
 like
  to solicit the suggestion of openejb and geronimo folks on  
where we

  should place them
 
  1) Leave them where they are under openejb2/modules/openejb- 
itests.

  Get help from openejb commiters to get this commited. Unlike in
  previous G releases, this module would now only build the ejb
 jars. No
  tests would actually run here.
 
  2) Move/copy the ejbs to some place under testsuite and  
create the

  jars there. This will keep the ejbs and the tests together.
 Since the
  moduleId (configId) in the plans should match the m2
 artifactItem id
  (g:a:v:t), the moduleId in the ejb plans would then become
  o.a.g.testsuite.*
 
 
  Apart from this decision, other things that need to resolved
 before we
  put this code in are
 
  http://issues.apache.org/jira/browse/OPENEJB-288
  http://www.mail-archive.com/dev@geronimo.apache.org/ 
msg34995.html

 
 
  Cheers
  Prasad
 

Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

I haven't changed the test code at all. It is essentially the same as
it is in the openejb-itests module. Neverthless, here it is.

http://people.apache.org/~prasad/test-ejbcontainer.zip

I have simply moved it under
geronimo/testsuite/ejbcontainer-testsuite/test-ejbcontainer and have
ensured that it compiles fine.

The reason I didn't bring it up for discussion is because it has to be
located under the testsuite directory by convention.

The beans can be built anywhere and the ejb-jars made available in the
repo. Hence this discussion.

Thanx David.

Cheers
Prasad




On 10/27/06, David Blevins [EMAIL PROTECTED] wrote:

On Oct 27, 2006, at 7:34 AM, Prasad Kashyap wrote:

 http://people.apache.org/~prasad/ejb-modules.zip

 You may remove the parent from the top level pom and adjust the
 groupId appropriately to build this.

Looks like you have the beans in there.  Where is the test code?

-David

 Cheers
 Prasad

 On 10/25/06, David Blevins [EMAIL PROTECTED] wrote:
 Great, I'll be looking forward to it.

 -David

 On Oct 23, 2006, at 9:36 PM, Prasad Kashyap wrote:

  Thanx David. I shall try to put it in a sandbox if I can, or
 else send
  you a a patch.
 
  Cheers
  Prasad
 
  On 10/23/06, David Blevins [EMAIL PROTECTED] wrote:
 
  On Oct 23, 2006, at 2:34 PM, Prasad Kashyap wrote:
 
   I have migrated the openejb-itests module to m2 with the
  intention of
   using it for G's testsuite.  The junit test code will have to go
  under
   the ejbcontainer-testsuite under the testsuite framework
   (geronimo/testsuite).
 
  I don't know which approach would make sense or if there is some
  middle ground.  You have a copy of this migrated code somewhere I
  could look at/try out?
 
  If we did #2 it'd obviously be a copy as OpenEJB 3 runs those
 tests
  about 7 times during an average build and another 5 more times
 on a
  build with assemblies.
 
  -David
 
   The beans and the ejub jars can go just about anywhere.  So I'd
  like
   to solicit the suggestion of openejb and geronimo folks on
 where we
   should place them
  
   1) Leave them where they are under openejb2/modules/openejb-
 itests.
   Get help from openejb commiters to get this commited. Unlike in
   previous G releases, this module would now only build the ejb
  jars. No
   tests would actually run here.
  
   2) Move/copy the ejbs to some place under testsuite and
 create the
   jars there. This will keep the ejbs and the tests together.
  Since the
   moduleId (configId) in the plans should match the m2
  artifactItem id
   (g:a:v:t), the moduleId in the ejb plans would then become
   o.a.g.testsuite.*
  
  
   Apart from this decision, other things that need to resolved
  before we
   put this code in are
  
   http://issues.apache.org/jira/browse/OPENEJB-288
   http://www.mail-archive.com/dev@geronimo.apache.org/
 msg34995.html
  
  
   Cheers
   Prasad
  
 
 
 

Re: [discussion] openejb-itests in testsuite

[David Blevins]

On Oct 27, 2006, at 10:20 AM, Prasad Kashyap wrote:


I haven't changed the test code at all. It is essentially the same as
it is in the openejb-itests module. Neverthless, here it is.

http://people.apache.org/~prasad/test-ejbcontainer.zip

I have simply moved it under
geronimo/testsuite/ejbcontainer-testsuite/test-ejbcontainer and have
ensured that it compiles fine.

The reason I didn't bring it up for discussion is because it has to be
located under the testsuite directory by convention.

The beans can be built anywhere and the ejb-jars made available in the
repo. Hence this discussion.


I get Forbidden: You don't have permission to access /~prasad/test- 
ejbcontainer.zip on this server.


-David


Thanx David.

Cheers
Prasad




On 10/27/06, David Blevins [EMAIL PROTECTED] wrote:

On Oct 27, 2006, at 7:34 AM, Prasad Kashyap wrote:

 http://people.apache.org/~prasad/ejb-modules.zip

 You may remove the parent from the top level pom and adjust the
 groupId appropriately to build this.

Looks like you have the beans in there.  Where is the test code?

-David

 Cheers
 Prasad

 On 10/25/06, David Blevins [EMAIL PROTECTED] wrote:
 Great, I'll be looking forward to it.

 -David

 On Oct 23, 2006, at 9:36 PM, Prasad Kashyap wrote:

  Thanx David. I shall try to put it in a sandbox if I can, or
 else send
  you a a patch.
 
  Cheers
  Prasad
 
  On 10/23/06, David Blevins [EMAIL PROTECTED] wrote:
 
  On Oct 23, 2006, at 2:34 PM, Prasad Kashyap wrote:
 
   I have migrated the openejb-itests module to m2 with the
  intention of
   using it for G's testsuite.  The junit test code will have  
to go

  under
   the ejbcontainer-testsuite under the testsuite framework
   (geronimo/testsuite).
 
  I don't know which approach would make sense or if there is  
some
  middle ground.  You have a copy of this migrated code  
somewhere I

  could look at/try out?
 
  If we did #2 it'd obviously be a copy as OpenEJB 3 runs those
 tests
  about 7 times during an average build and another 5 more times
 on a
  build with assemblies.
 
  -David
 
   The beans and the ejub jars can go just about anywhere.   
So I'd

  like
   to solicit the suggestion of openejb and geronimo folks on
 where we
   should place them
  
   1) Leave them where they are under openejb2/modules/openejb-
 itests.
   Get help from openejb commiters to get this commited.  
Unlike in

   previous G releases, this module would now only build the ejb
  jars. No
   tests would actually run here.
  
   2) Move/copy the ejbs to some place under testsuite and
 create the
   jars there. This will keep the ejbs and the tests together.
  Since the
   moduleId (configId) in the plans should match the m2
  artifactItem id
   (g:a:v:t), the moduleId in the ejb plans would then become
   o.a.g.testsuite.*
  
  
   Apart from this decision, other things that need to resolved
  before we
   put this code in are
  
   http://issues.apache.org/jira/browse/OPENEJB-288
   http://www.mail-archive.com/dev@geronimo.apache.org/
 msg34995.html
  
  
   Cheers
   Prasad
  
 
 
 

Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

Please try now. Sorry 'bout that.

Cheers
Prasad

On 10/27/06, David Blevins [EMAIL PROTECTED] wrote:


On Oct 27, 2006, at 10:20 AM, Prasad Kashyap wrote:

 I haven't changed the test code at all. It is essentially the same as
 it is in the openejb-itests module. Neverthless, here it is.

 http://people.apache.org/~prasad/test-ejbcontainer.zip

 I have simply moved it under
 geronimo/testsuite/ejbcontainer-testsuite/test-ejbcontainer and have
 ensured that it compiles fine.

 The reason I didn't bring it up for discussion is because it has to be
 located under the testsuite directory by convention.

 The beans can be built anywhere and the ejb-jars made available in the
 repo. Hence this discussion.

I get Forbidden: You don't have permission to access /~prasad/test-
ejbcontainer.zip on this server.

-David

 Thanx David.

 Cheers
 Prasad




 On 10/27/06, David Blevins [EMAIL PROTECTED] wrote:
 On Oct 27, 2006, at 7:34 AM, Prasad Kashyap wrote:

  http://people.apache.org/~prasad/ejb-modules.zip
 
  You may remove the parent from the top level pom and adjust the
  groupId appropriately to build this.

 Looks like you have the beans in there.  Where is the test code?

 -David

  Cheers
  Prasad
 
  On 10/25/06, David Blevins [EMAIL PROTECTED] wrote:
  Great, I'll be looking forward to it.
 
  -David
 
  On Oct 23, 2006, at 9:36 PM, Prasad Kashyap wrote:
 
   Thanx David. I shall try to put it in a sandbox if I can, or
  else send
   you a a patch.
  
   Cheers
   Prasad
  
   On 10/23/06, David Blevins [EMAIL PROTECTED] wrote:
  
   On Oct 23, 2006, at 2:34 PM, Prasad Kashyap wrote:
  
I have migrated the openejb-itests module to m2 with the
   intention of
using it for G's testsuite.  The junit test code will have
 to go
   under
the ejbcontainer-testsuite under the testsuite framework
(geronimo/testsuite).
  
   I don't know which approach would make sense or if there is
 some
   middle ground.  You have a copy of this migrated code
 somewhere I
   could look at/try out?
  
   If we did #2 it'd obviously be a copy as OpenEJB 3 runs those
  tests
   about 7 times during an average build and another 5 more times
  on a
   build with assemblies.
  
   -David
  
The beans and the ejub jars can go just about anywhere.
 So I'd
   like
to solicit the suggestion of openejb and geronimo folks on
  where we
should place them
   
1) Leave them where they are under openejb2/modules/openejb-
  itests.
Get help from openejb commiters to get this commited.
 Unlike in
previous G releases, this module would now only build the ejb
   jars. No
tests would actually run here.
   
2) Move/copy the ejbs to some place under testsuite and
  create the
jars there. This will keep the ejbs and the tests together.
   Since the
moduleId (configId) in the plans should match the m2
   artifactItem id
(g:a:v:t), the moduleId in the ejb plans would then become
o.a.g.testsuite.*
   
   
Apart from this decision, other things that need to resolved
   before we
put this code in are
   
http://issues.apache.org/jira/browse/OPENEJB-288
http://www.mail-archive.com/dev@geronimo.apache.org/
  msg34995.html
   
   
Cheers
Prasad
   
  
  
  
 
 
 

Re: [discussion] openejb-itests in testsuite

[David Blevins]

Great, I'll be looking forward to it.

-David

On Oct 23, 2006, at 9:36 PM, Prasad Kashyap wrote:


Thanx David. I shall try to put it in a sandbox if I can, or else send
you a a patch.

Cheers
Prasad

On 10/23/06, David Blevins [EMAIL PROTECTED] wrote:


On Oct 23, 2006, at 2:34 PM, Prasad Kashyap wrote:

 I have migrated the openejb-itests module to m2 with the  
intention of
 using it for G's testsuite.  The junit test code will have to go  
under

 the ejbcontainer-testsuite under the testsuite framework
 (geronimo/testsuite).

I don't know which approach would make sense or if there is some
middle ground.  You have a copy of this migrated code somewhere I
could look at/try out?

If we did #2 it'd obviously be a copy as OpenEJB 3 runs those tests
about 7 times during an average build and another 5 more times on a
build with assemblies.

-David

 The beans and the ejub jars can go just about anywhere.  So I'd  
like

 to solicit the suggestion of openejb and geronimo folks on where we
 should place them

 1) Leave them where they are under openejb2/modules/openejb-itests.
 Get help from openejb commiters to get this commited. Unlike in
 previous G releases, this module would now only build the ejb  
jars. No

 tests would actually run here.

 2) Move/copy the ejbs to some place under testsuite and create the
 jars there. This will keep the ejbs and the tests together.  
Since the
 moduleId (configId) in the plans should match the m2  
artifactItem id

 (g:a:v:t), the moduleId in the ejb plans would then become
 o.a.g.testsuite.*


 Apart from this decision, other things that need to resolved  
before we

 put this code in are

 http://issues.apache.org/jira/browse/OPENEJB-288
 http://www.mail-archive.com/dev@geronimo.apache.org/msg34995.html


 Cheers
 Prasad

[discussion] openejb-itests in testsuite

[Prasad Kashyap]

I have migrated the openejb-itests module to m2 with the intention of
using it for G's testsuite.  The junit test code will have to go under
the ejbcontainer-testsuite under the testsuite framework
(geronimo/testsuite).

The beans and the ejub jars can go just about anywhere.  So I'd like
to solicit the suggestion of openejb and geronimo folks on where we
should place them

1) Leave them where they are under openejb2/modules/openejb-itests.
Get help from openejb commiters to get this commited. Unlike in
previous G releases, this module would now only build the ejb jars. No
tests would actually run here.

2) Move/copy the ejbs to some place under testsuite and create the
jars there. This will keep the ejbs and the tests together. Since the
moduleId (configId) in the plans should match the m2 artifactItem id
(g:a:v:t), the moduleId in the ejb plans would then become
o.a.g.testsuite.*


Apart from this decision, other things that need to resolved before we
put this code in are

http://issues.apache.org/jira/browse/OPENEJB-288
http://www.mail-archive.com/dev@geronimo.apache.org/msg34995.html


Cheers
Prasad

Re: [discussion] openejb-itests in testsuite

[Jacek Laskowski]

On 10/23/06, Prasad Kashyap [EMAIL PROTECTED] wrote:

I have migrated the openejb-itests module to m2 with the intention of
using it for G's testsuite.  The junit test code will have to go under
the ejbcontainer-testsuite under the testsuite framework
(geronimo/testsuite).

The beans and the ejub jars can go just about anywhere.  So I'd like
to solicit the suggestion of openejb and geronimo folks on where we
should place them

1) Leave them where they are under openejb2/modules/openejb-itests.
Get help from openejb commiters to get this commited. Unlike in
previous G releases, this module would now only build the ejb jars. No
tests would actually run here.


+1.

Geronimo doesn't need to know about EJBs at all unless configured
(which again is part of configuration nor building. When an EJB
container comes in, it should bring itests, too).

I volunteer to help committing necessary changes (and finally get rid
of M1). Just let me know what's necessary.


2) Move/copy the ejbs to some place under testsuite and create the
jars there. This will keep the ejbs and the tests together. Since the
moduleId (configId) in the plans should match the m2 artifactItem id
(g:a:v:t), the moduleId in the ejb plans would then become
o.a.g.testsuite.*


-1. See above.


Apart from this decision, other things that need to resolved before we
put this code in are

http://issues.apache.org/jira/browse/OPENEJB-288
http://www.mail-archive.com/dev@geronimo.apache.org/msg34995.html


Can't help much with them.

Jacek

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

Re: [discussion] openejb-itests in testsuite

[David Blevins]

On Oct 23, 2006, at 2:34 PM, Prasad Kashyap wrote:


I have migrated the openejb-itests module to m2 with the intention of
using it for G's testsuite.  The junit test code will have to go under
the ejbcontainer-testsuite under the testsuite framework
(geronimo/testsuite).


I don't know which approach would make sense or if there is some  
middle ground.  You have a copy of this migrated code somewhere I  
could look at/try out?


If we did #2 it'd obviously be a copy as OpenEJB 3 runs those tests  
about 7 times during an average build and another 5 more times on a  
build with assemblies.


-David


The beans and the ejub jars can go just about anywhere.  So I'd like
to solicit the suggestion of openejb and geronimo folks on where we
should place them

1) Leave them where they are under openejb2/modules/openejb-itests.
Get help from openejb commiters to get this commited. Unlike in
previous G releases, this module would now only build the ejb jars. No
tests would actually run here.

2) Move/copy the ejbs to some place under testsuite and create the
jars there. This will keep the ejbs and the tests together. Since the
moduleId (configId) in the plans should match the m2 artifactItem id
(g:a:v:t), the moduleId in the ejb plans would then become
o.a.g.testsuite.*


Apart from this decision, other things that need to resolved before we
put this code in are

http://issues.apache.org/jira/browse/OPENEJB-288
http://www.mail-archive.com/dev@geronimo.apache.org/msg34995.html


Cheers
Prasad

Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

Thanx David. I shall try to put it in a sandbox if I can, or else send
you a a patch.

Cheers
Prasad

On 10/23/06, David Blevins [EMAIL PROTECTED] wrote:


On Oct 23, 2006, at 2:34 PM, Prasad Kashyap wrote:

 I have migrated the openejb-itests module to m2 with the intention of
 using it for G's testsuite.  The junit test code will have to go under
 the ejbcontainer-testsuite under the testsuite framework
 (geronimo/testsuite).

I don't know which approach would make sense or if there is some
middle ground.  You have a copy of this migrated code somewhere I
could look at/try out?

If we did #2 it'd obviously be a copy as OpenEJB 3 runs those tests
about 7 times during an average build and another 5 more times on a
build with assemblies.

-David

 The beans and the ejub jars can go just about anywhere.  So I'd like
 to solicit the suggestion of openejb and geronimo folks on where we
 should place them

 1) Leave them where they are under openejb2/modules/openejb-itests.
 Get help from openejb commiters to get this commited. Unlike in
 previous G releases, this module would now only build the ejb jars. No
 tests would actually run here.

 2) Move/copy the ejbs to some place under testsuite and create the
 jars there. This will keep the ejbs and the tests together. Since the
 moduleId (configId) in the plans should match the m2 artifactItem id
 (g:a:v:t), the moduleId in the ejb plans would then become
 o.a.g.testsuite.*


 Apart from this decision, other things that need to resolved before we
 put this code in are

 http://issues.apache.org/jira/browse/OPENEJB-288
 http://www.mail-archive.com/dev@geronimo.apache.org/msg34995.html


 Cheers
 Prasad

Re: [discussion] openejb-itests in testsuite

[Prasad Kashyap]

Thanx Jacek. I might take you up on that offer :-)

Cheers
Prasad

On 10/23/06, Jacek Laskowski [EMAIL PROTECTED] wrote:

On 10/23/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
 I have migrated the openejb-itests module to m2 with the intention of
 using it for G's testsuite.  The junit test code will have to go under
 the ejbcontainer-testsuite under the testsuite framework
 (geronimo/testsuite).

 The beans and the ejub jars can go just about anywhere.  So I'd like
 to solicit the suggestion of openejb and geronimo folks on where we
 should place them

 1) Leave them where they are under openejb2/modules/openejb-itests.
 Get help from openejb commiters to get this commited. Unlike in
 previous G releases, this module would now only build the ejb jars. No
 tests would actually run here.

+1.

Geronimo doesn't need to know about EJBs at all unless configured
(which again is part of configuration nor building. When an EJB
container comes in, it should bring itests, too).

I volunteer to help committing necessary changes (and finally get rid
of M1). Just let me know what's necessary.

 2) Move/copy the ejbs to some place under testsuite and create the
 jars there. This will keep the ejbs and the tests together. Since the
 moduleId (configId) in the plans should match the m2 artifactItem id
 (g:a:v:t), the moduleId in the ejb plans would then become
 o.a.g.testsuite.*

-1. See above.

 Apart from this decision, other things that need to resolved before we
 put this code in are

 http://issues.apache.org/jira/browse/OPENEJB-288
 http://www.mail-archive.com/dev@geronimo.apache.org/msg34995.html

Can't help much with them.

Jacek

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

Re: Info needed: migrating openejb-itests to testsuite framework

[Prasad Kashyap]

Just FYI -

This issue has now been resolved. I did a build with a fully clean
repo and source again. That fixed it. The NPE bug around like 693 of
the current TranqlCmpSchemaBuilder.java still exists.   Where do I
open the JIRA and submit the patch ?

Cheers
Prasad

On 10/12/06, Prasad Kashyap [EMAIL PROTECTED] wrote:

OK. This is what is happening.

I built the server from scratch, clean repo and fresh checkout.  When
I deploy the openejb-itests.jar in this server, I get a deployment
exception that it needs a plan at META-INF/openejb-jar.xml. The plan
is embedded inside the jar.

I get the same error even when I pass the plan as a CLI arg to the
deploy command.

(Now why does this happen ?)

Then I replaced the openejb-builder-2.2-incubating-SNAPSHOT.jar in the
geronimo repository with the jar from the m2 local repo. This jar was
built from scratch.

Now when I try to deploy the same again, I get the previously
mentioned error with the plan (wrong ns and xsd).


Cheers
Prasad


On 10/12/06, David Jencks [EMAIL PROTECTED] wrote:

 On Oct 12, 2006, at 1:27 PM, Prasad Kashyap wrote:

  My efforts in deploying the openejb-itests.jar with the attached plan
  is failing b'coz of some errors in the plan. The errors in the plan
  are being introduced at some stage in the deploy process.
 
  My plan uses the pkgen ns for key-generator
 xmlns:pkgen=http://openejb.apache.org/xml/ns/pkgen-2.1;
  ...
  ...
  pkgen:key-generator
 
 
  But the deploy tool is seeing the following the ns
 xmlns:pkg=http://www.openejb.org/xml/ns/pkgen-2.0;
 ..
 ..
 pkg:key-generator
 
 
  Where is this coming from ?

 I can't find anywhere it could be coming from.  There are namespace
 substitutions in XmlBeansUtil and Upgrader but neither of those could
 produce this change.  They could change 2.0 to 2.1.

 Wish I could offer useful advice :-(

 david jencks

 
  Thanx
  Prasad
 
 
 
 
  On 10/11/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
  Hi Jacek,
 
  We now have a testsuite directory under geronimo which is the basis
  for a system and functional test framework for all of Geronimo. I
  have
  begun with a doc in the wiki about this.
  http://cwiki.apache.org/GMOxDEV/integration-testing.html The doc is
  still in a rudimentary stage but it will give you a general idea.
  I am
  enhancing it as I go along.
 
  This discussion revolves around migrating the openejb itests to this
  new framework. So after a G assembly is done, the build will continue
  to testing the various functional pieces of the server like
  webcontainer, ejbcontainer, console, clustering etc.
 
  Cheers
  Prasad
 
  On 10/11/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
   On 10/11/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
David,
   
Thanks for that write-up on the openejb itests. It helped me
understand the structure better.
   
All the client code (in src/itests) have a dependency on the
  beans (in
src/java) anyway. So this is what I did. I put all the beans
  in 1 core
project (openejb-itests). I put the plans and DDs in their
  individual
projects.  The individual projects then unpack just the needed
  classes
from that core project and build the ejb archive with it's
  plan and
DD.
   
testsuite/ejbcontainer-testsuite
   ejb-modules
   openejb-itests   -- core project with beans
   openejb-security-001  -- just plan and DD
   openejb-security-002
   openejb-security-003
   openejb-cmp2-prefetch
   openejb-cmp2-petstore
   openejb-cmp2-cmrmapping
   openejb-cmp2-storage
   test-ejbcontainer   --- junit tests in client
  
   Hi Prasad,
  
   Why are the matter being discussed here? Shouldn't it go to
  openejb-dev?
  
   Jacek
  
   --
   Jacek Laskowski
   http://www.laskowski.net.pl
  
 
  openejb-jar.xml
  itests-deploy.log

Re: Info needed: migrating openejb-itests to testsuite framework

[David Jencks]

On Oct 12, 2006, at 1:27 PM, Prasad Kashyap wrote:


My efforts in deploying the openejb-itests.jar with the attached plan
is failing b'coz of some errors in the plan. The errors in the plan
are being introduced at some stage in the deploy process.

My plan uses the pkgen ns for key-generator
   xmlns:pkgen=http://openejb.apache.org/xml/ns/pkgen-2.1;
...
...
pkgen:key-generator


But the deploy tool is seeing the following the ns
   xmlns:pkg=http://www.openejb.org/xml/ns/pkgen-2.0;
   ..
   ..
   pkg:key-generator


Where is this coming from ?


I can't find anywhere it could be coming from.  There are namespace  
substitutions in XmlBeansUtil and Upgrader but neither of those could  
produce this change.  They could change 2.0 to 2.1.


Wish I could offer useful advice :-(

david jencks



Thanx
Prasad




On 10/11/06, Prasad Kashyap [EMAIL PROTECTED] wrote:

Hi Jacek,

We now have a testsuite directory under geronimo which is the basis
for a system and functional test framework for all of Geronimo. I  
have

begun with a doc in the wiki about this.
http://cwiki.apache.org/GMOxDEV/integration-testing.html The doc is
still in a rudimentary stage but it will give you a general idea.  
I am

enhancing it as I go along.

This discussion revolves around migrating the openejb itests to this
new framework. So after a G assembly is done, the build will continue
to testing the various functional pieces of the server like
webcontainer, ejbcontainer, console, clustering etc.

Cheers
Prasad

On 10/11/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
 On 10/11/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
  David,
 
  Thanks for that write-up on the openejb itests. It helped me
  understand the structure better.
 
  All the client code (in src/itests) have a dependency on the  
beans (in
  src/java) anyway. So this is what I did. I put all the beans  
in 1 core
  project (openejb-itests). I put the plans and DDs in their  
individual
  projects.  The individual projects then unpack just the needed  
classes
  from that core project and build the ejb archive with it's  
plan and

  DD.
 
  testsuite/ejbcontainer-testsuite
 ejb-modules
 openejb-itests   -- core project with beans
 openejb-security-001  -- just plan and DD
 openejb-security-002
 openejb-security-003
 openejb-cmp2-prefetch
 openejb-cmp2-petstore
 openejb-cmp2-cmrmapping
 openejb-cmp2-storage
 test-ejbcontainer   --- junit tests in client

 Hi Prasad,

 Why are the matter being discussed here? Shouldn't it go to  
openejb-dev?


 Jacek

 --
 Jacek Laskowski
 http://www.laskowski.net.pl


openejb-jar.xml
itests-deploy.log

Re: Info needed: migrating openejb-itests to testsuite framework

[Prasad Kashyap]

OK. This is what is happening.

I built the server from scratch, clean repo and fresh checkout.  When
I deploy the openejb-itests.jar in this server, I get a deployment
exception that it needs a plan at META-INF/openejb-jar.xml. The plan
is embedded inside the jar.

I get the same error even when I pass the plan as a CLI arg to the
deploy command.

(Now why does this happen ?)

Then I replaced the openejb-builder-2.2-incubating-SNAPSHOT.jar in the
geronimo repository with the jar from the m2 local repo. This jar was
built from scratch.

Now when I try to deploy the same again, I get the previously
mentioned error with the plan (wrong ns and xsd).


Cheers
Prasad


On 10/12/06, David Jencks [EMAIL PROTECTED] wrote:


On Oct 12, 2006, at 1:27 PM, Prasad Kashyap wrote:

 My efforts in deploying the openejb-itests.jar with the attached plan
 is failing b'coz of some errors in the plan. The errors in the plan
 are being introduced at some stage in the deploy process.

 My plan uses the pkgen ns for key-generator
xmlns:pkgen=http://openejb.apache.org/xml/ns/pkgen-2.1;
 ...
 ...
 pkgen:key-generator


 But the deploy tool is seeing the following the ns
xmlns:pkg=http://www.openejb.org/xml/ns/pkgen-2.0;
..
..
pkg:key-generator


 Where is this coming from ?

I can't find anywhere it could be coming from.  There are namespace
substitutions in XmlBeansUtil and Upgrader but neither of those could
produce this change.  They could change 2.0 to 2.1.

Wish I could offer useful advice :-(

david jencks


 Thanx
 Prasad




 On 10/11/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
 Hi Jacek,

 We now have a testsuite directory under geronimo which is the basis
 for a system and functional test framework for all of Geronimo. I
 have
 begun with a doc in the wiki about this.
 http://cwiki.apache.org/GMOxDEV/integration-testing.html The doc is
 still in a rudimentary stage but it will give you a general idea.
 I am
 enhancing it as I go along.

 This discussion revolves around migrating the openejb itests to this
 new framework. So after a G assembly is done, the build will continue
 to testing the various functional pieces of the server like
 webcontainer, ejbcontainer, console, clustering etc.

 Cheers
 Prasad

 On 10/11/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
  On 10/11/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
   David,
  
   Thanks for that write-up on the openejb itests. It helped me
   understand the structure better.
  
   All the client code (in src/itests) have a dependency on the
 beans (in
   src/java) anyway. So this is what I did. I put all the beans
 in 1 core
   project (openejb-itests). I put the plans and DDs in their
 individual
   projects.  The individual projects then unpack just the needed
 classes
   from that core project and build the ejb archive with it's
 plan and
   DD.
  
   testsuite/ejbcontainer-testsuite
  ejb-modules
  openejb-itests   -- core project with beans
  openejb-security-001  -- just plan and DD
  openejb-security-002
  openejb-security-003
  openejb-cmp2-prefetch
  openejb-cmp2-petstore
  openejb-cmp2-cmrmapping
  openejb-cmp2-storage
  test-ejbcontainer   --- junit tests in client
 
  Hi Prasad,
 
  Why are the matter being discussed here? Shouldn't it go to
 openejb-dev?
 
  Jacek
 
  --
  Jacek Laskowski
  http://www.laskowski.net.pl
 

 openejb-jar.xml
 itests-deploy.log

Re: Info needed: migrating openejb-itests to testsuite framework

[Jacek Laskowski]

On 10/11/06, Prasad Kashyap [EMAIL PROTECTED] wrote:

David,

Thanks for that write-up on the openejb itests. It helped me
understand the structure better.

All the client code (in src/itests) have a dependency on the beans (in
src/java) anyway. So this is what I did. I put all the beans in 1 core
project (openejb-itests). I put the plans and DDs in their individual
projects.  The individual projects then unpack just the needed classes
from that core project and build the ejb archive with it's plan and
DD.

testsuite/ejbcontainer-testsuite
   ejb-modules
   openejb-itests   -- core project with beans
   openejb-security-001  -- just plan and DD
   openejb-security-002
   openejb-security-003
   openejb-cmp2-prefetch
   openejb-cmp2-petstore
   openejb-cmp2-cmrmapping
   openejb-cmp2-storage
   test-ejbcontainer   --- junit tests in client


Hi Prasad,

Why are the matter being discussed here? Shouldn't it go to openejb-dev?

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: Info needed: migrating openejb-itests to testsuite framework

[Prasad Kashyap]

Hi Jacek,

We now have a testsuite directory under geronimo which is the basis
for a system and functional test framework for all of Geronimo. I have
begun with a doc in the wiki about this.
http://cwiki.apache.org/GMOxDEV/integration-testing.html The doc is
still in a rudimentary stage but it will give you a general idea. I am
enhancing it as I go along.

This discussion revolves around migrating the openejb itests to this
new framework. So after a G assembly is done, the build will continue
to testing the various functional pieces of the server like
webcontainer, ejbcontainer, console, clustering etc.

Cheers
Prasad

On 10/11/06, Jacek Laskowski [EMAIL PROTECTED] wrote:

On 10/11/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
 David,

 Thanks for that write-up on the openejb itests. It helped me
 understand the structure better.

 All the client code (in src/itests) have a dependency on the beans (in
 src/java) anyway. So this is what I did. I put all the beans in 1 core
 project (openejb-itests). I put the plans and DDs in their individual
 projects.  The individual projects then unpack just the needed classes
 from that core project and build the ejb archive with it's plan and
 DD.

 testsuite/ejbcontainer-testsuite
ejb-modules
openejb-itests   -- core project with beans
openejb-security-001  -- just plan and DD
openejb-security-002
openejb-security-003
openejb-cmp2-prefetch
openejb-cmp2-petstore
openejb-cmp2-cmrmapping
openejb-cmp2-storage
test-ejbcontainer   --- junit tests in client

Hi Prasad,

Why are the matter being discussed here? Shouldn't it go to openejb-dev?

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: Info needed: migrating openejb-itests to testsuite framework

[Prasad Kashyap]

David,

Thanks for that write-up on the openejb itests. It helped me
understand the structure better.

All the client code (in src/itests) have a dependency on the beans (in
src/java) anyway. So this is what I did. I put all the beans in 1 core
project (openejb-itests). I put the plans and DDs in their individual
projects.  The individual projects then unpack just the needed classes
from that core project and build the ejb archive with it's plan and
DD.

testsuite/ejbcontainer-testsuite
  ejb-modules
  openejb-itests   -- core project with beans
  openejb-security-001  -- just plan and DD
  openejb-security-002
  openejb-security-003
  openejb-cmp2-prefetch
  openejb-cmp2-petstore
  openejb-cmp2-cmrmapping
  openejb-cmp2-storage
  test-ejbcontainer   --- junit tests in client


The test-ejbcontainer has a dependency on the openejb-itests and it
contains the 400+ tests in junit. I kept the tests in junit and didn't
move it to TestNG because there are like 400 tests to migrate.
Moreover, they have to annotated in jdk1.4 style now. Soon when we
move to jdk1.5, their annotation will have to change all over again.

Please feel free to share your comments and/or concerns.

I still have to fix a few plans to work with our version 1.2.

Thanx
Prasad

On 10/6/06, David Blevins [EMAIL PROTECTED] wrote:

Don't know if I have the best answers, but I'll i'll try my best...

On Oct 5, 2006, at 8:21 PM, Prasad Kashyap wrote:

 Can someone please shed some light on it
 and help me understand the present structure ?

There are actually two different structures there.

Structure One

 openejb-itests

There are some 21 beans 400 tests in this bucket.  The test suite is
divided into four sections; stateful, stateless, cmp (1.x), bmp.  The
tests in each section follow a pattern of starting simple and growing
in complexity and are in logical order as much as possible.  For
example, we test JNDI before we test that you can lookup a bean and
use it's create method.  We try not to put the cart before the horse
so that if something does break, you get as far though the test suite
as possible before you encounter the breakage (rather than the very
first test).  It's not uncommon for tests to break while refactoring.

Structure Two

 scenario1
 scenario2
 scenario3
 cmp2-prefetch
 cmp2-petstore
 cmp2-storage
 cmp2-cmrmapping

These are security and cmp2 tests.  The cmp2 tests may easily be able
to be folded into openejb-itests, which does not have and needs a
cmp2 section.  Dunno, haven't looked at them too much.  The security
tests (scenario1,2,3)  use pretty much the same beans but configured
with different plans (IIUC).  Alan and Gianny could probably fill in
more details on those.

 Now, are these java files disjoint enough that they can be split apart
 into as many projects as the ejb archives we need ?

I think they may group together like such:

openejb-itests

scenario1
scenario2
scenario3

cmp2-prefetch
cmp2-petstore
cmp2-storage
cmp2-cmrmapping

Don't know about the cmp2 tests, but the security tests definitely
reuse the same classes.

 Don't think we can
 build all the classes in one core m2 project and use the classes in
 another project which has just the plan DD. Can we ?

Ejbs can use third part jars, so yes.  The bean classes and other
classes don't actually have to be inside the same jar as the ejb-
jar.xml and plan.  The plan for that matter doesn't have to be in the
jar at all.

 Is the openejb-itests archive really needed ? It is the one big
 archive for the whole project that encompasses everything. It has it's
 own plan and DD and is also distributed into the server. But it also
 contains the other archives. This is kinda confusing.

The openejb-itests archive doesn't contain any other archives.  The
module does which is probably what you meant.  As noted above, those
other archives could likely go into their own modules.

Dunno if I really answered your question.

 I believe the test java files are in src/itest directory. However,
 they have a dependency on the java files in src/java.

IIRC, I think the ejbs themselves are in src/java and the client code
(the unit tests) are in src/itests.

 Like I said, the
 only a subset of files in src/java are used to create archives. The
 rest are either included in that big openejb-itests archive or simply
 needed to support the junit tests in src/itests. Now why is it
 structured this way ?  Why weren't they moved to the src/itests dir
 where they are needed ?

The beans need to get packaged and deployed into the server.  The
itests themselves could be run from maven ( no need to archive them
really unless you want to run them again as tests in another maven
module )

In reference to OpenEJB 3, which I guess is unlikely to be the way
Geronimo structures it's tests, the itests are in one module as a
plain ejb app.  We then deploy and test sever modules with them by
declaring a dep on them with 'test' as the scope and then create
JUnit

Re: Info needed: migrating openejb-itests to testsuite framework

[Prasad Kashyap]

Here is an excerpt from the log file of a maven build. Hope this helps.

The dir-list.txt gives the contents of the itests/target dir after the
ejb archives are created but before the geronimo binary is unpacked.

Cheers
Prasad

On 10/5/06, Prasad Kashyap [EMAIL PROTECTED] wrote:

I am looking at migrating the openejb-itests to the new testsuite framework.

I already have the plan migrated to the 1.1 format. However I have
some questions regarding the way the classes for the ejb jars are set
up and the classes for tests. Can someone please shed some light on it
and help me understand the present structure ?

The way I see it, the openejb-itests project creates 8 ejb archives by
jar'ing a set or subset of classes and combining it with different
plans and DDs.

The archives are :
scenario1
scenario2
scenario3
cmp2-prefetch
cmp2-petstore
cmp2-storage
cmp2-cmrmapping
openejb-itests

The classes come from the java source files in src/java.

The correct m2 way of building these many artifacts would be to create
their own projects.

Question 1
Now, are these java files disjoint enough that they can be split apart
into as many projects as the ejb archives we need ? Don't think we can
build all the classes in one core m2 project and use the classes in
another project which has just the plan DD. Can we ?

Question 2.
Is the openejb-itests archive really needed ? It is the one big
archive for the whole project that encompasses everything. It has it's
own plan and DD and is also distributed into the server. But it also
contains the other archives. This is kinda confusing.

I believe the test java files are in src/itest directory. However,
they have a dependency on the java files in src/java. Like I said, the
only a subset of files in src/java are used to create archives. The
rest are either included in that big openejb-itests archive or simply
needed to support the junit tests in src/itests. Now why is it
structured this way ?  Why weren't they moved to the src/itests dir
where they are needed ?

Thanx in advance

Cheers
Prasad



maven.log
Description: Binary data
openejb/modules/itests/target:
classes/
cmp2/
ejb/
itest-classes/
itest-reports/
openejb-cmp2-cmrmapping.jar
openejb-cmp2-petstore.jar
openejb-cmp2-prefetch.jar
openejb-cmp2-storage.jar
openejb-itests-2.0.1-SNAPSHOT.jar
openejb-security-001.jar
openejb-security-002.jar
openejb-security-003.jar
plan/
scenarios/
test-classes/
test-reports/

./classes:
org/

./classes/org:
openejb/

./classes/org/openejb:
test/

./classes/org/openejb/test:
ApplicationException.class
TestFailureException.class
beans/
entity/
interop/
object/
security/
stateful/
stateless/

./classes/org/openejb/test/beans:
Calculator.class
CalculatorBean.class
CalculatorHome.class
Database.class
DatabaseBean.class
DatabaseHome.class
Employee.class
EmployeeBean.class
EmployeeHome.class
ShoppingCart.class
ShoppingCartBean.class
ShoppingCartHome.class

./classes/org/openejb/test/entity:
bmp/
cmp/
cmp2/

./classes/org/openejb/test/entity/bmp:
AllowedOperationsBmpBean.class
BasicBmp2DataSourcesBean.class
BasicBmp2DataSourcesHome.class
BasicBmp2DataSourcesObject.class
BasicBmpBean.class
BasicBmpHome.class
BasicBmpObject.class
EncBmpBean.class
EncBmpHome.class
EncBmpObject.class
RmiIiopBmpBean.class
RmiIiopBmpHome.class
RmiIiopBmpObject.class

./classes/org/openejb/test/entity/cmp:
AllowedOperationsCmp2Bean.class
AllowedOperationsCmpBean.class
BasicCmp2Bean.class
BasicCmpBean.class
BasicCmpHome.class
BasicCmpObject.class
EncCmp2Bean.class
EncCmpBean.class
EncCmpHome.class
EncCmpObject.class
RmiIiopCmp2Bean.class
RmiIiopCmpBean.class
RmiIiopCmpHome.class
RmiIiopCmpObject.class
SessionFacadeBean.class
SessionFacadeHome.class
SessionFacadeObject.class

./classes/org/openejb/test/entity/cmp2:
cmrmapping/
model/
petstore/
prefetch/

./classes/org/openejb/test/entity/cmp2/cmrmapping:
AbstractEntityBean.class
CMRMappingFacadeBean.class
CMRMappingFacadeHome.class
CMRMappingFacadeRemote.class
CompoundPK.class
ManyOwningSideBean.class
ManyOwningSideLocal.class
ManyOwningSideLocalHome.class
OneInverseSideBean.class
OneInverseSideLocal.class
OneInverseSideLocalHome.class
OneOwningSideBean.class
OneOwningSideLocal.class
OneOwningSideLocalHome.class

./classes/org/openejb/test/entity/cmp2/model:
AddressBean.class
AddressLocal.class
AddressLocalHome.class
LineItemBean.class
LineItemLocal.class
LineItemLocalHome.class
OrderBean.class
OrderLocal.class
OrderLocalHome.class
ProductBean.class
ProductLocal.class
ProductLocalHome.class
StorageBean.class
StorageHome.class
StorageRemote.class

./classes/org/openejb/test/entity/cmp2/petstore:
AddressEJB.class
AddressLocal.class
AddressLocalHome.class

./classes/org/openejb/test/entity/cmp2/prefetch:
PrefetchFacadeBean$1.class
PrefetchFacadeBean$2.class
PrefetchFacadeBean$3.class
PrefetchFacadeBean$4.class
PrefetchFacadeBean$5.class
PrefetchFacadeBean$TestAction.class
PrefetchFacadeBean$TestTemplate.class
PrefetchFacadeBean.class
PrefetchFacadeHome.class

Re: Info needed: migrating openejb-itests to testsuite framework

[David Blevins]

Don't know if I have the best answers, but I'll i'll try my best...

On Oct 5, 2006, at 8:21 PM, Prasad Kashyap wrote:


Can someone please shed some light on it
and help me understand the present structure ?


There are actually two different structures there.

Structure One


openejb-itests


There are some 21 beans 400 tests in this bucket.  The test suite is  
divided into four sections; stateful, stateless, cmp (1.x), bmp.  The  
tests in each section follow a pattern of starting simple and growing  
in complexity and are in logical order as much as possible.  For  
example, we test JNDI before we test that you can lookup a bean and  
use it's create method.  We try not to put the cart before the horse  
so that if something does break, you get as far though the test suite  
as possible before you encounter the breakage (rather than the very  
first test).  It's not uncommon for tests to break while refactoring.


Structure Two


scenario1
scenario2
scenario3
cmp2-prefetch
cmp2-petstore
cmp2-storage
cmp2-cmrmapping


These are security and cmp2 tests.  The cmp2 tests may easily be able  
to be folded into openejb-itests, which does not have and needs a  
cmp2 section.  Dunno, haven't looked at them too much.  The security  
tests (scenario1,2,3)  use pretty much the same beans but configured  
with different plans (IIUC).  Alan and Gianny could probably fill in  
more details on those.



Now, are these java files disjoint enough that they can be split apart
into as many projects as the ejb archives we need ?


I think they may group together like such:

openejb-itests

scenario1
scenario2
scenario3

cmp2-prefetch
cmp2-petstore
cmp2-storage
cmp2-cmrmapping

Don't know about the cmp2 tests, but the security tests definitely  
reuse the same classes.



Don't think we can
build all the classes in one core m2 project and use the classes in
another project which has just the plan DD. Can we ?


Ejbs can use third part jars, so yes.  The bean classes and other  
classes don't actually have to be inside the same jar as the ejb- 
jar.xml and plan.  The plan for that matter doesn't have to be in the  
jar at all.



Is the openejb-itests archive really needed ? It is the one big
archive for the whole project that encompasses everything. It has it's
own plan and DD and is also distributed into the server. But it also
contains the other archives. This is kinda confusing.


The openejb-itests archive doesn't contain any other archives.  The  
module does which is probably what you meant.  As noted above, those  
other archives could likely go into their own modules.


Dunno if I really answered your question.


I believe the test java files are in src/itest directory. However,
they have a dependency on the java files in src/java.


IIRC, I think the ejbs themselves are in src/java and the client code  
(the unit tests) are in src/itests.



Like I said, the
only a subset of files in src/java are used to create archives. The
rest are either included in that big openejb-itests archive or simply
needed to support the junit tests in src/itests. Now why is it
structured this way ?  Why weren't they moved to the src/itests dir
where they are needed ?


The beans need to get packaged and deployed into the server.  The  
itests themselves could be run from maven ( no need to archive them  
really unless you want to run them again as tests in another maven  
module )


In reference to OpenEJB 3, which I guess is unlikely to be the way  
Geronimo structures it's tests, the itests are in one module as a  
plain ejb app.  We then deploy and test sever modules with them by  
declaring a dep on them with 'test' as the scope and then create  
JUnit TestSuite instances to essentially import the tests we want to  
run.  I think we run the itests about 8 times total.


[INFO] OpenEJB :: iTests .  
SUCCESS [3.739s]
[INFO] OpenEJB :: Container ..  
SUCCESS [0.015s]
[INFO] OpenEJB :: Container :: Loader   
SUCCESS [0.394s]
[INFO] OpenEJB :: Container :: Java EE ...  
SUCCESS [2.513s]
[INFO] OpenEJB :: Container :: Core ..  
SUCCESS [23.354s]  (itests run 3 times)
[INFO] OpenEJB :: Container :: Persistence ...  
SUCCESS [7.373s]
[INFO] OpenEJB :: Server .  
SUCCESS [0.015s]
[INFO] OpenEJB :: Server :: Client ...  
SUCCESS [1.593s]
[INFO] OpenEJB :: Server :: Core .  
SUCCESS [2.155s]
[INFO] OpenEJB :: Server :: EJBd .  
SUCCESS [7.176s]  (itests run 2 times)
[INFO] OpenEJB :: Server :: Admin   
SUCCESS [1.827s]
[INFO] OpenEJB :: Server :: Http .  
SUCCESS [8.466s]  (itests run 2 times)
[INFO] OpenEJB :: Server :: Telnet ...  
SUCCESS [2.324s]
[INFO] OpenEJB :: Server :: XFire

Info needed: migrating openejb-itests to testsuite framework

[Prasad Kashyap]

I am looking at migrating the openejb-itests to the new testsuite framework.

I already have the plan migrated to the 1.1 format. However I have
some questions regarding the way the classes for the ejb jars are set
up and the classes for tests. Can someone please shed some light on it
and help me understand the present structure ?

The way I see it, the openejb-itests project creates 8 ejb archives by
jar'ing a set or subset of classes and combining it with different
plans and DDs.

The archives are :
scenario1
scenario2
scenario3
cmp2-prefetch
cmp2-petstore
cmp2-storage
cmp2-cmrmapping
openejb-itests

The classes come from the java source files in src/java.

The correct m2 way of building these many artifacts would be to create
their own projects.

Question 1
Now, are these java files disjoint enough that they can be split apart
into as many projects as the ejb archives we need ? Don't think we can
build all the classes in one core m2 project and use the classes in
another project which has just the plan DD. Can we ?

Question 2.
Is the openejb-itests archive really needed ? It is the one big
archive for the whole project that encompasses everything. It has it's
own plan and DD and is also distributed into the server. But it also
contains the other archives. This is kinda confusing.

I believe the test java files are in src/itest directory. However,
they have a dependency on the java files in src/java. Like I said, the
only a subset of files in src/java are used to create archives. The
rest are either included in that big openejb-itests archive or simply
needed to support the junit tests in src/itests. Now why is it
structured this way ?  Why weren't they moved to the src/itests dir
where they are needed ?

Thanx in advance

Cheers
Prasad

Re: maven m:eclipse issue on 1.1 in OpenEJB itests

[John Sisson]

I worked out that this zip wasn't in the local repository because my 
build script was specifying -Dgeronimo.assembly.zip=false, Doh!


Thanks for your help Kevan.

John

Kevan Miller wrote:


On Aug 9, 2006, at 10:04 PM, John Sisson wrote:


I am trying to build the eclipse project files for a clean 1.1 build.

I did the following:

* svn co https://svn.apache.org/repos/asf/geronimo/branches/1.1
* cd 1.1
* maven m:fresh-checkout
* maven new
* maven m:eclipse -o

The m:eclipse processing fails in OpenEJB itests.  How do I get the 
geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip file to be placed in my local 
repository as part of the build so it doesn't fail?


Sorry to ask the obvious, but are you sure 'maven new' completed 
successfully? I end up with the zip file in 
.maven/repository/geronimo/distributions/


One additional note, I have to run 'maven m:eclipse' online the first 
time. Otherwise, there's a missing dependency for 
maven-itest-plugin-1.0.jar. Since we don't currently run itests, 
'maven new' doesn't  download the dependency. Suppose we could figure 
out how to exclude OpenEJB itest from the m:eclipse goal...


--kevan



Thanks,

John

   SNIP
   [echo] Place java sources for xstream at 
R:\.geronimo-1.1.x-maven\repository\xstream\java-sources\xstream-1.1.3-sources.jar 
for

javadoc and debugging support in Eclipse
   [echo] Place java sources for xpp3 at 
R:\.geronimo-1.1.x-maven\repository\xpp3\java-sources\xpp3-1.1.3.3-sources.jar 
for javadoc

and debugging support in Eclipse
   [echo] Place java sources for commons-jelly-tags-velocity at 
R:\.geronimo-1.1.x-maven\repository\commons-jelly\java-sources\comm
ons-jelly-tags-velocity-1.0-sources.jar for javadoc and debugging 
support in Eclipse
   [echo] Place java sources for velocity at 
R:\.geronimo-1.1.x-maven\repository\velocity\java-sources\velocity-1.4-sources.jar 
for

javadoc and debugging support in Eclipse
   [echo] Setting default output directory to target/classes

   [echo] Now refresh your project in Eclipse (right click on the 
project and select Refresh)

+
| Executing eclipse OpenEJB :: Integration Tests
| Memory: 27M/32M
+
DEPRECATED: the default goal should be specified in the build 
section of project.xml instead of maven.xml
DEPRECATED: the default goal should be specified in the build 
section of project.xml instead of maven.xml


eclipse:

build:end:

You are working offline so the build will continue, but 
openejb-builder-2.1.2-SNAPSHOT.jar may be out of date!


BUILD FAILED
File.. 
R:\.geronimo-1.1.x-maven\cache\maven-multiproject-plugin-1.4.1\plugin.jelly 


Element... maven:reactor
Line.. 218
Column -1
The build cannot continue because of the following unsatisfied 
dependency:


geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip

Total time   : 6 minutes 37 seconds
Finished at  : Thursday, 10 August 2006 10:33:27

maven m:eclipse issue on 1.1 in OpenEJB itests

[John Sisson]

I am trying to build the eclipse project files for a clean 1.1 build.

I did the following:

* svn co https://svn.apache.org/repos/asf/geronimo/branches/1.1
* cd 1.1
* maven m:fresh-checkout
* maven new
* maven m:eclipse -o

The m:eclipse processing fails in OpenEJB itests.  How do I get the 
geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip file to be placed in my local 
repository as part of the build so it doesn't fail?


Thanks,

John

   SNIP
   [echo] Place java sources for xstream at 
R:\.geronimo-1.1.x-maven\repository\xstream\java-sources\xstream-1.1.3-sources.jar 
for

javadoc and debugging support in Eclipse
   [echo] Place java sources for xpp3 at 
R:\.geronimo-1.1.x-maven\repository\xpp3\java-sources\xpp3-1.1.3.3-sources.jar 
for javadoc

and debugging support in Eclipse
   [echo] Place java sources for commons-jelly-tags-velocity at 
R:\.geronimo-1.1.x-maven\repository\commons-jelly\java-sources\comm
ons-jelly-tags-velocity-1.0-sources.jar for javadoc and debugging 
support in Eclipse
   [echo] Place java sources for velocity at 
R:\.geronimo-1.1.x-maven\repository\velocity\java-sources\velocity-1.4-sources.jar 
for

javadoc and debugging support in Eclipse
   [echo] Setting default output directory to target/classes

   [echo] Now refresh your project in Eclipse (right click on the 
project and select Refresh)

+
| Executing eclipse OpenEJB :: Integration Tests
| Memory: 27M/32M
+
DEPRECATED: the default goal should be specified in the build section 
of project.xml instead of maven.xml
DEPRECATED: the default goal should be specified in the build section 
of project.xml instead of maven.xml


eclipse:

build:end:

You are working offline so the build will continue, but 
openejb-builder-2.1.2-SNAPSHOT.jar may be out of date!


BUILD FAILED
File.. 
R:\.geronimo-1.1.x-maven\cache\maven-multiproject-plugin-1.4.1\plugin.jelly

Element... maven:reactor
Line.. 218
Column -1
The build cannot continue because of the following unsatisfied dependency:

geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip

Total time   : 6 minutes 37 seconds
Finished at  : Thursday, 10 August 2006 10:33:27

Re: maven m:eclipse issue on 1.1 in OpenEJB itests

[Kevan Miller]

On Aug 9, 2006, at 10:04 PM, John Sisson wrote:


I am trying to build the eclipse project files for a clean 1.1 build.

I did the following:

* svn co https://svn.apache.org/repos/asf/geronimo/branches/1.1
* cd 1.1
* maven m:fresh-checkout
* maven new
* maven m:eclipse -o

The m:eclipse processing fails in OpenEJB itests.  How do I get the  
geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip file to be placed in my  
local repository as part of the build so it doesn't fail?


Sorry to ask the obvious, but are you sure 'maven new' completed  
successfully? I end up with the zip file in .maven/repository/ 
geronimo/distributions/


One additional note, I have to run 'maven m:eclipse' online the first  
time. Otherwise, there's a missing dependency for maven-itest- 
plugin-1.0.jar. Since we don't currently run itests, 'maven new'  
doesn't  download the dependency. Suppose we could figure out how to  
exclude OpenEJB itest from the m:eclipse goal...


--kevan



Thanks,

John

   SNIP
   [echo] Place java sources for xstream at R:\.geronimo-1.1.x-maven 
\repository\xstream\java-sources\xstream-1.1.3-sources.jar for

javadoc and debugging support in Eclipse
   [echo] Place java sources for xpp3 at R:\.geronimo-1.1.x-maven 
\repository\xpp3\java-sources\xpp3-1.1.3.3-sources.jar for javadoc

and debugging support in Eclipse
   [echo] Place java sources for commons-jelly-tags-velocity at R: 
\.geronimo-1.1.x-maven\repository\commons-jelly\java-sources\comm
ons-jelly-tags-velocity-1.0-sources.jar for javadoc and debugging  
support in Eclipse
   [echo] Place java sources for velocity at R:\.geronimo-1.1.x- 
maven\repository\velocity\java-sources\velocity-1.4-sources.jar for

javadoc and debugging support in Eclipse
   [echo] Setting default output directory to target/classes

   [echo] Now refresh your project in Eclipse (right click on the  
project and select Refresh)

+
| Executing eclipse OpenEJB :: Integration Tests
| Memory: 27M/32M
+
DEPRECATED: the default goal should be specified in the build  
section of project.xml instead of maven.xml
DEPRECATED: the default goal should be specified in the build  
section of project.xml instead of maven.xml


eclipse:

build:end:

You are working offline so the build will continue, but openejb- 
builder-2.1.2-SNAPSHOT.jar may be out of date!


BUILD FAILED
File.. R:\.geronimo-1.1.x-maven\cache\maven-multiproject- 
plugin-1.4.1\plugin.jelly

Element... maven:reactor
Line.. 218
Column -1
The build cannot continue because of the following unsatisfied  
dependency:


geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip

Total time   : 6 minutes 37 seconds
Finished at  : Thursday, 10 August 2006 10:33:27

Re: openejb itests?

[Prasad Kashyap]

Bill,

Here's the latest patch:

http://issues.apache.org/jira/secure/attachment/12336616/geronimo-deployment-plugin-RTC-VOTE.3.patch

Now let's see how itests are doing.

Cheers
Prasad.


On 7/7/06, Prasad Kashyap [EMAIL PROTECTED] wrote:

Hi Bill,

No. I applied the patch against an existing copy of the trunk tree and
local repo. Let me apply this against the latest tree (the one that
has Jason's big patch).  I'll also clean out the local repo. I'll let
you know shortly.

Cheers
Prasad

On 7/7/06, Bill Dudney [EMAIL PROTECTED] wrote:

 Hi Prasad,

 Perhaps I'm missing another patch or something?

 The top level pom (geronimo/pom.xml) sets the src directory to 'src/java'.
 The deployment plugin has its src in the standard m2 place of
 'src/main/java'. Thus nothing gets compiled. I reset the src directory to
 'src/main/java' and I get many compile errors.

 I applied the patch (and only that patch) to a fresh clean check out of
 geronimo Rev 419886 (head of trunk).

 I must be missing something if you are able to get a clean compile.

 TTFN,




 Bill Dudney
 MyFaces - http://myfaces.apache.org
 Cayenne - http://incubator.apache.org/projects/cayenne.html




 On Jul 6, 2006, at 8:04 PM, Prasad Kashyap wrote:

 Oh I forgot to mention.

 Check the *.log files in the top level module and individual modules.
 If I remember right, you can run the mvn site:site command to generate
 an HTML page of the results.

 Cheers
 Prasad

 On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote:

 Hi Prasad,

 Thanks, - I guess I was hoping that it was something smaller :-)

 I had to;
 1) install the jetty version but changed version to 1.1 and updated
 itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT
 2) install the tomcat version but changed version to 1.1 and updated
 itests/pom.xml  to reflect 1.1. instead of 1.1-SNAPSHOT
 3) enable the utils
 3) delete the explicit mention of version from the maven-site-plugin in
 teardown-tests.pom.xml
 4) add junit as a dependency otherwise the mvn failed unless
 -Dmaven.test.skip=true was specified
 5) run mvn

 Although the build succeeds, nothing appears to happen (see attached log)

 From what I can tell the geronimo-deployment-plugin is not being built
 correctly, none of the src's are being compiled and placed into the jar
 file. I poked around but the reason escapes me...

 TTFN,


 Bill Dudney
 MyFaces - http://myfaces.apache.org
 Cayenne - http://incubator.apache.org/projects/cayenne.html



 [INFO] Scanning for projects...
 [INFO] Reactor build order:
 [INFO]   Geronimo Integration Tests
 [INFO]   Geronimo :: itests :: system
 [INFO]   Geronimo :: itests :: webcontainer
 [INFO]   Geronimo :: itests :: teardown
 [INFO]
 
 [INFO] Building Geronimo Integration Tests
 [INFO]task-segment: [install]
 [INFO]
 
 [INFO] [site:attach-descriptor]
 [INFO] [dependency:unpack {execution: unpack}]
 [INFO] Configured Artifact:
 org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1:zip
 [INFO] geronimo-jetty-j2ee-1.1.zip already unpacked.
 Downloading:
 
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
 [WARNING] Unable to get resource from repository Maven snapshots
 (http://cvs.apache.org/maven-snapshot-repository)
 Downloading:
 
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
 [WARNING] Unable to get resource from repository central
 (http://repo1.maven.org/maven2)
 Downloading:
 
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
 [WARNING] Unable to get resource from repository Maven snapshots
 (http://cvs.apache.org/maven-snapshot-repository)
 Downloading:
 
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
 [WARNING] Unable to get resource from repository central
 (http://repo1.maven.org/maven2)
 [INFO] [antrun:run {execution: prepare}]
 [INFO] Executing tasks
[delete] Deleting 1 files from
 /private/tmp/foo/sandbox/itests/target/logs
 [touch] Creating
 /private/tmp/foo/sandbox/itests/target/logs/results.log
 [INFO] Executed tasks
 [INFO] [install:install]
 [INFO] Installing /private/tmp/foo/sandbox/itests/pom.xml
 to
 
/Users/bdudney/.m2/repository/org/apache/geronimo/itests/geronimo-itests-parent/1.0/geronimo-itests-parent-1.0.pom
 [INFO]
 
 [INFO] Building Geronimo :: itests :: system
 [INFO]task-segment: [install]
 [INFO]
 
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:compile]
 [INFO] Nothing 

Re: openejb itests?

[Prasad Kashyap]

Hi Bill,

No. I applied the patch against an existing copy of the trunk tree and
local repo. Let me apply this against the latest tree (the one that
has Jason's big patch).  I'll also clean out the local repo. I'll let
you know shortly.

Cheers
Prasad

On 7/7/06, Bill Dudney [EMAIL PROTECTED] wrote:


Hi Prasad,

Perhaps I'm missing another patch or something?

The top level pom (geronimo/pom.xml) sets the src directory to 'src/java'.
The deployment plugin has its src in the standard m2 place of
'src/main/java'. Thus nothing gets compiled. I reset the src directory to
'src/main/java' and I get many compile errors.

I applied the patch (and only that patch) to a fresh clean check out of
geronimo Rev 419886 (head of trunk).

I must be missing something if you are able to get a clean compile.

TTFN,




Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html




On Jul 6, 2006, at 8:04 PM, Prasad Kashyap wrote:

Oh I forgot to mention.

Check the *.log files in the top level module and individual modules.
If I remember right, you can run the mvn site:site command to generate
an HTML page of the results.

Cheers
Prasad

On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote:

Hi Prasad,

Thanks, - I guess I was hoping that it was something smaller :-)

I had to;
1) install the jetty version but changed version to 1.1 and updated
itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT
2) install the tomcat version but changed version to 1.1 and updated
itests/pom.xml  to reflect 1.1. instead of 1.1-SNAPSHOT
3) enable the utils
3) delete the explicit mention of version from the maven-site-plugin in
teardown-tests.pom.xml
4) add junit as a dependency otherwise the mvn failed unless
-Dmaven.test.skip=true was specified
5) run mvn

Although the build succeeds, nothing appears to happen (see attached log)

From what I can tell the geronimo-deployment-plugin is not being built
correctly, none of the src's are being compiled and placed into the jar
file. I poked around but the reason escapes me...

TTFN,


Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html



[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Geronimo Integration Tests
[INFO]   Geronimo :: itests :: system
[INFO]   Geronimo :: itests :: webcontainer
[INFO]   Geronimo :: itests :: teardown
[INFO]

[INFO] Building Geronimo Integration Tests
[INFO]task-segment: [install]
[INFO]

[INFO] [site:attach-descriptor]
[INFO] [dependency:unpack {execution: unpack}]
[INFO] Configured Artifact:
org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1:zip
[INFO] geronimo-jetty-j2ee-1.1.zip already unpacked.
Downloading:
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
[WARNING] Unable to get resource from repository Maven snapshots
(http://cvs.apache.org/maven-snapshot-repository)
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
Downloading:
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
[WARNING] Unable to get resource from repository Maven snapshots
(http://cvs.apache.org/maven-snapshot-repository)
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] [antrun:run {execution: prepare}]
[INFO] Executing tasks
   [delete] Deleting 1 files from
/private/tmp/foo/sandbox/itests/target/logs
[touch] Creating
/private/tmp/foo/sandbox/itests/target/logs/results.log
[INFO] Executed tasks
[INFO] [install:install]
[INFO] Installing /private/tmp/foo/sandbox/itests/pom.xml
to
/Users/bdudney/.m2/repository/org/apache/geronimo/itests/geronimo-itests-parent/1.0/geronimo-itests-parent-1.0.pom
[INFO]

[INFO] Building Geronimo :: itests :: system
[INFO]task-segment: [install]
[INFO]

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[WARNING] JAR will be empty - no content was marked for 

Re: openejb itests?

[Bill Dudney]

Hi Prasad,



First we needed the geronimo-deployment-plugin to be in m2. So in
http://issues.apache.org/jira/browse/GERONIMO-1738, I got the
deployment-plugin migarted to m2. The RTC for this is pending 2 more
votes. Now, if you and Jason can review and approve it, we can get it
in the build.



I applied the patch but it appears that there is a problem with it,  
AppTest.java has 3 copies of the code in it for example (as well as  
pom.xml and many if not all the other files).


 Here is the url to what I downloaded and I'm looking at;
http://issues.apache.org/jira/secure/attachment/12324416/geronimo- 
deployment-plugin.patch


which is the first patch from JIRA #1738 referenced above.


Next, I came up with a simple m2 multi-build project for itests.
Jacek put it in the sandbox for us.
http://issues.apache.org/jira/browse/GERONIMO-1654.

(I think I also opened some JIRAs in OpenEJB project with itest
patches. Let me search for those).



Sounds good, looking forward to reviewing the jira's.


I used to take an m1 binary distribution and manually put it into an
m2 local repo for this work. Now that we are working on m2, hopefully
we shall soon have the binary distributions for us to work with
directly.



An m1 distribution of G or something else?

We could then to try to bring itests out of the sandbox and merge  
it with trunk.


The vision I have for itests is to make it the all encompassing system
integration test for Geronimo. We have unit tests in the individual
modules. Even that covers only a third of our code approx. Then we
have the J2EE CTK tests that ensures G's J2EE compliance.  But
geronimo being a sum of many individual parts, there must be a whole
range of tests that are applicable to the whole system when put
together but fall beyond the purview of CTK. These are what I hope
itests will catch.



Agreed that having more tests would be a very 'good thing'


I began playing with itests but quickly moved on the m2 migration work
since that was so much necessary both for G and for itests. It would
be nice to get the itests running and into the project soon.



agreed

TTFN,

-bd-


Cheers
Prasad.

On 7/5/06, Bill Dudney [EMAIL PROTECTED] wrote:


Hi Prasad,

I would like to see the itests for openejb running from m2. David  
mentioned
that you might have already done a bunch of work on that front.  
Could you
update me on the status of that? I'm happy to jump in where ever  
to help

make them functional again.

Thanks!


Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html

Re: openejb itests?

[Prasad Kashyap]

Hi Bill,

Inline-

On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote:

Hi Prasad,


 First we needed the geronimo-deployment-plugin to be in m2. So in
 http://issues.apache.org/jira/browse/GERONIMO-1738, I got the
 deployment-plugin migarted to m2. The RTC for this is pending 2 more
 votes. Now, if you and Jason can review and approve it, we can get it
 in the build.


I applied the patch but it appears that there is a problem with it,
AppTest.java has 3 copies of the code in it for example (as well as
pom.xml and many if not all the other files).

  Here is the url to what I downloaded and I'm looking at;
http://issues.apache.org/jira/secure/attachment/12324416/geronimo-
deployment-plugin.patch

which is the first patch from JIRA #1738 referenced above.


You might want to pick up the latest patch from the Manage
Attachments link. The patches on the JIRA page are sorted
alphabetically. The patch that you downloaded was my initial
submission. The other one with (
http://issues.apache.org/jira/secure/attachment/12335875/geronimo-deployment-plugin-RTC-VOTE.2.patch
) is what you need. This was uploaded by David Jencks after reviewing
mine and making some changes based on other reviews.


 I used to take an m1 binary distribution and manually put it into an
 m2 local repo for this work. Now that we are working on m2, hopefully
 we shall soon have the binary distributions for us to work with
 directly.


An m1 distribution of G or something else?



Yes, of G.


Cheers
Prasad

Re: openejb itests?

[Prasad Kashyap]

Yep. This is it.

So what you could do is take a m1 binary and run the mvn
install:install-file command to install it into your m2 local repo.

The exact syntax of that command is in the error message that you have pasted.

Cheers
Prasad



On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote:

Hi Prasad,

Is this error that causes you to manually install an m1 built bit
into the m2 repo?

If so could you point me to exactly what bits to copy?

Thanks!

-bd-

[INFO] Configured Artifact:
org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1-
SNAPSHOT:zip
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

GroupId: org.apache.geronimo.distributions
ArtifactId: geronimo-jetty-j2ee
Version: 1.1-SNAPSHOT

Reason: Unable to download the artifact from any repository

Try downloading the file manually from the project website.

Then, install it using the command:
 mvn install:install-file -
DgroupId=org.apache.geronimo.distributions -DartifactId=geronimo-
jetty-j2ee \
 -Dversion=1.1-SNAPSHOT -Dpackaging=zip -Dfile=/path/to/file


   org.apache.geronimo.distributions:geronimo-jetty-j2ee:zip:1.1-
SNAPSHOT

from the specified remote repositories:
   central (http://repo1.maven.org/maven2),
   Maven snapshots (http://cvs.apache.org/maven-snapshot-repository)


[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 4 seconds
[INFO] Finished at: Thu Jul 06 12:32:17 MDT 2006
[INFO] Final Memory: 5M/9M
[INFO]



On Jul 6, 2006, at 8:35 AM, Prasad Kashyap wrote:

 Hi Bill,

 Inline-

 On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote:
 Hi Prasad,

 
  First we needed the geronimo-deployment-plugin to be in m2. So in
  http://issues.apache.org/jira/browse/GERONIMO-1738, I got the
  deployment-plugin migarted to m2. The RTC for this is pending 2
 more
  votes. Now, if you and Jason can review and approve it, we can
 get it
  in the build.
 

 I applied the patch but it appears that there is a problem with it,
 AppTest.java has 3 copies of the code in it for example (as well as
 pom.xml and many if not all the other files).

   Here is the url to what I downloaded and I'm looking at;
 http://issues.apache.org/jira/secure/attachment/12324416/geronimo-
 deployment-plugin.patch

 which is the first patch from JIRA #1738 referenced above.

 You might want to pick up the latest patch from the Manage
 Attachments link. The patches on the JIRA page are sorted
 alphabetically. The patch that you downloaded was my initial
 submission. The other one with (
 http://issues.apache.org/jira/secure/attachment/12335875/geronimo-
 deployment-plugin-RTC-VOTE.2.patch
 ) is what you need. This was uploaded by David Jencks after reviewing
 mine and making some changes based on other reviews.

  I used to take an m1 binary distribution and manually put it
 into an
  m2 local repo for this work. Now that we are working on m2,
 hopefully
  we shall soon have the binary distributions for us to work with
  directly.
 

 An m1 distribution of G or something else?


 Yes, of G.


 Cheers
 Prasad

Re: openejb itests?

[Bill Dudney]

Hi Prasad,Thanks, - I guess I was hoping that it was something smaller :-)I had to;1) install the jetty version but changed version to 1.1 and updated itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT2) install the tomcat version but changed version to 1.1 and updated itests/pom.xml  to reflect 1.1. instead of 1.1-SNAPSHOT3) enable the utils 3) delete the explicit mention of version from the maven-site-plugin in teardown-tests.pom.xml4) add junit as a dependency otherwise the mvn failed unless -Dmaven.test.skip=true was specified5) run mvnAlthough the build succeeds, nothing appears to happen (see attached log)From what I can tell the geronimo-deployment-plugin is not being built correctly, none of the src's are being compiled and placed into the jar file. I poked around but the reason escapes me...TTFN,Bill DudneyMyFaces - http://myfaces.apache.orgCayenne - http://incubator.apache.org/projects/cayenne.html[INFO] Scanning for projects...[INFO] Reactor build order: [INFO]   Geronimo Integration Tests[INFO]   Geronimo :: itests :: system[INFO]   Geronimo :: itests :: webcontainer[INFO]   Geronimo :: itests :: teardown[INFO] [INFO] Building Geronimo Integration Tests[INFO]    task-segment: [install][INFO] [INFO] [site:attach-descriptor][INFO] [dependency:unpack {execution: unpack}][INFO] Configured Artifact: org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1:zip[INFO] geronimo-jetty-j2ee-1.1.zip already unpacked.Downloading: http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom[WARNING] Unable to get resource from repository Maven snapshots (http://cvs.apache.org/maven-snapshot-repository)Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom[WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2)Downloading: http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom[WARNING] Unable to get resource from repository Maven snapshots (http://cvs.apache.org/maven-snapshot-repository)Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom[WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2)[INFO] [antrun:run {execution: prepare}][INFO] Executing tasks   [delete] Deleting 1 files from /private/tmp/foo/sandbox/itests/target/logs    [touch] Creating /private/tmp/foo/sandbox/itests/target/logs/results.log[INFO] Executed tasks[INFO] [install:install][INFO] Installing /private/tmp/foo/sandbox/itests/pom.xml to /Users/bdudney/.m2/repository/org/apache/geronimo/itests/geronimo-itests-parent/1.0/geronimo-itests-parent-1.0.pom[INFO] [INFO] Building Geronimo :: itests :: system[INFO]    task-segment: [install][INFO] [INFO] [resources:resources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:compile][INFO] Nothing to compile - all classes are up to date[INFO] [resources:testResources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:testCompile][INFO] Nothing to compile - all classes are up to date[INFO] [surefire:test][INFO] No tests to run.[INFO] [jar:jar][WARNING] JAR will be empty - no content was marked for inclusion![INFO] Building jar: /private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar[INFO] [antrun:run {execution: prepare}][INFO] Executing tasks   [delete] Deleting 1 files from /private/tmp/foo/sandbox/itests/system-tests/target/logs    [touch] Creating /private/tmp/foo/sandbox/itests/system-tests/target/logs/results.log[INFO] Executed tasks[INFO] [install:install][INFO] Installing /private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar to /Users/bdudney/.m2/repository/org/apache/geronimo/itests/system-tests/1.0/system-tests-1.0.jar[INFO] [INFO] Building Geronimo :: itests :: webcontainer[INFO]    task-segment: [install][INFO] [INFO] [resources:resources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:compile][INFO] Nothing to compile - all classes are up to date[INFO] [resources:testResources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:testCompile][INFO] Nothing to compile - all classes are up to date[INFO] [surefire:test][INFO] Surefire report directory: 

Re: openejb itests?

[Prasad Kashyap]

I just built the geronimo-deployment-plugin from this patch (
http://issues.apache.org/jira/secure/attachment/12335875/geronimo-deployment-plugin-RTC-VOTE.2.patch
). It built successfully and installed in the local m2 repo.

It's been a good 3-4 months since I last worked on itests but it is
all coming back to me now. This seems to be a good time for me to
start looking at itests again. Currently I could make use of this
breather in the m2 migration work as issues like RTC, trunk or branch,
invalid poms etc are sorted out.  We still don't have a m2
distribution but we are slowly getting there.

Cheers
Prasad.


On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote:


Hi Prasad,

Thanks, - I guess I was hoping that it was something smaller :-)

I had to;
1) install the jetty version but changed version to 1.1 and updated
itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT
2) install the tomcat version but changed version to 1.1 and updated
itests/pom.xml  to reflect 1.1. instead of 1.1-SNAPSHOT
3) enable the utils
3) delete the explicit mention of version from the maven-site-plugin in
teardown-tests.pom.xml
4) add junit as a dependency otherwise the mvn failed unless
-Dmaven.test.skip=true was specified
5) run mvn

Although the build succeeds, nothing appears to happen (see attached log)

From what I can tell the geronimo-deployment-plugin is not being built
correctly, none of the src's are being compiled and placed into the jar
file. I poked around but the reason escapes me...

TTFN,


Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html



[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Geronimo Integration Tests
[INFO]   Geronimo :: itests :: system
[INFO]   Geronimo :: itests :: webcontainer
[INFO]   Geronimo :: itests :: teardown
[INFO]

[INFO] Building Geronimo Integration Tests
[INFO]task-segment: [install]
[INFO]

[INFO] [site:attach-descriptor]
[INFO] [dependency:unpack {execution: unpack}]
[INFO] Configured Artifact:
org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1:zip
[INFO] geronimo-jetty-j2ee-1.1.zip already unpacked.
Downloading:
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
[WARNING] Unable to get resource from repository Maven snapshots
(http://cvs.apache.org/maven-snapshot-repository)
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
Downloading:
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
[WARNING] Unable to get resource from repository Maven snapshots
(http://cvs.apache.org/maven-snapshot-repository)
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] [antrun:run {execution: prepare}]
[INFO] Executing tasks
   [delete] Deleting 1 files from
/private/tmp/foo/sandbox/itests/target/logs
[touch] Creating
/private/tmp/foo/sandbox/itests/target/logs/results.log
[INFO] Executed tasks
[INFO] [install:install]
[INFO] Installing /private/tmp/foo/sandbox/itests/pom.xml
to
/Users/bdudney/.m2/repository/org/apache/geronimo/itests/geronimo-itests-parent/1.0/geronimo-itests-parent-1.0.pom
[INFO]

[INFO] Building Geronimo :: itests :: system
[INFO]task-segment: [install]
[INFO]

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar:
/private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar
[INFO] [antrun:run {execution: prepare}]
[INFO] Executing tasks
   [delete] Deleting 1 files from
/private/tmp/foo/sandbox/itests/system-tests/target/logs
[touch] Creating
/private/tmp/foo/sandbox/itests/system-tests/target/logs/results.log
[INFO] Executed tasks
[INFO] [install:install]
[INFO] Installing
/private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar
to

openejb itests?

[Bill Dudney]

Hi Prasad,I would like to see the itests for openejb running from m2. David mentioned that you might have already done a bunch of work on that front. Could you update me on the status of that? I'm happy to jump in where ever to help make them functional again.Thanks! Bill DudneyMyFaces - http://myfaces.apache.orgCayenne - http://incubator.apache.org/projects/cayenne.html 

Re: openejb itests?

[Prasad Kashyap]

Oh cool. Yes !!

First we needed the geronimo-deployment-plugin to be in m2. So in
http://issues.apache.org/jira/browse/GERONIMO-1738, I got the
deployment-plugin migarted to m2. The RTC for this is pending 2 more
votes. Now, if you and Jason can review and approve it, we can get it
in the build.

Next, I came up with a simple m2 multi-build project for itests.
Jacek put it in the sandbox for us.
http://issues.apache.org/jira/browse/GERONIMO-1654.

(I think I also opened some JIRAs in OpenEJB project with itest
patches. Let me search for those).

I used to take an m1 binary distribution and manually put it into an
m2 local repo for this work. Now that we are working on m2, hopefully
we shall soon have the binary distributions for us to work with
directly.

We could then to try to bring itests out of the sandbox and merge it with trunk.

The vision I have for itests is to make it the all encompassing system
integration test for Geronimo. We have unit tests in the individual
modules. Even that covers only a third of our code approx. Then we
have the J2EE CTK tests that ensures G's J2EE compliance.  But
geronimo being a sum of many individual parts, there must be a whole
range of tests that are applicable to the whole system when put
together but fall beyond the purview of CTK. These are what I hope
itests will catch.

I began playing with itests but quickly moved on the m2 migration work
since that was so much necessary both for G and for itests. It would
be nice to get the itests running and into the project soon.

Cheers
Prasad.

On 7/5/06, Bill Dudney [EMAIL PROTECTED] wrote:


Hi Prasad,

I would like to see the itests for openejb running from m2. David mentioned
that you might have already done a bunch of work on that front. Could you
update me on the status of that? I'm happy to jump in where ever to help
make them functional again.

Thanks!


Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html

[jira] Closed: (GERONIMO-774) OpenEJB itests - GBeanInstance should already be stopped before die() is called

[Matt Hogstrom (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-774?page=all ]
 
Matt Hogstrom closed GERONIMO-774:
--

Resolution: Fixed

Please re-open if this is still an issue. Per Dave's comments and lack of 
additional information it looks like this is no longer an issue.

 OpenEJB itests - GBeanInstance should already be stopped before die() is 
 called
 ---

  Key: GERONIMO-774
  URL: http://issues.apache.org/jira/browse/GERONIMO-774
  Project: Geronimo
 Type: Bug
   Components: OpenEJB
 Versions: 1.0-M4
  Environment: Windows XP SP2
 java version 1.4.2_06
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
 Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
 Reporter: John Sisson
  Fix For: 1.0


 The message GBeanInstance should already be stopped before die() is called 
 is issued during OpenEJB integration tests.  Experienced this in HEAD.  
 Probably happens in M4 branch too.
 20:24:10,723 INFO  [LocalConfigStore:config-store] Uninstalled configuration 
 org/openejb/scenario002
 Module org/openejb/scenario002 uninstalled.
 Completed
 20:24:12,957 INFO  [TSSBean] org/openejb/POA - Unlinked container 
 openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=n
 ull,J2EEServer=openejb,j2eeType=StatelessSessionBean,name=BasicStatelessBean
 20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
 J2EEServer=openejb,j2eeType=StatelessSessionBean,name=BasicStatelessBean' 
 stopped
 20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
 J2EEServer=openejb,j2eeType=EntityBean,name=BasicCmp2Bean' stopped
 20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
 J2EEServer=openejb,j2eeType=EntityBean,name=BasicCmpBean' stopped
 20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
 J2EEServer=openejb,j2eeType=StatefulSessionBean,name=BasicStatefulBean' 
 stopped
 20:24:12,957 INFO  [Configuration] Stopping configuration 
 org/openejb/scenario001
 20:24:13,395 ERROR [GBeanInstance] Gbeaninstance Should Already Be Stopped 
 before die() is called: objectName=geronimo.server:role=C
 MPPKGenerator,name=SecurityEntity state=starting
 20:24:13,395 ERROR [GBeanInstance] GBeanInstance should already be stopped 
 before die() is called: objectName=geronimo.server:role=C
 MPPKGenerator,name=SecurityEntity,isWrapper=true state=starting
 20:24:14,067 INFO  [PersistentConfigurationList] Saved running configuration 
 list
 20:24:14,473 INFO  [ConfigurationManagerImpl] Unloaded Configuration 
 geronimo.config:name=org/openejb/scenario001
 Completed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Problems building openejb/itests module

[Prasad Kashyap]

I think most people run G builds by skipping tests and itests. Is there anybody out there that runs itests ?

I am finding that the itests happens to be quite a flaky module, especially in it's DDLExporterTask.java.I amost alwaysget the following exception when I do a top level build:

 [exec] BUILD FAILED [exec] File.. C:\Documents and Settings\Administrator\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.jelly [exec] Element... maven:reactor [exec] Line.. 217
 [exec] Column 9 [exec] Unable to obtain goal [ejb:install] -- C:\apache\geronimo\openejb\modules\itests\maven.xml:438:43: ddlExporter org/apache/xmlbeans/impl/validator/Validator
 .
 .
 [exec] Root cause [exec] java.lang.NoClassDefFoundError: org/apache/xmlbeans/impl/validator/Validator [exec] at org.apache.xmlbeans.impl.values.XmlObjectBase.validate(XmlObjectBase.java
:342) [exec] at org.apache.geronimo.schema.SchemaConversionUtils.validateDD(SchemaConversionUtils.java:580) [exec] at org.apache.geronimo.schema.SchemaConversionUtils.convertToEJBSchema(SchemaConversionUtils.java
:223) [exec] at org.openejb.deployment.ant.DDLExporterTask.execute(DDLExporterTask.java:337)
Is this being caused by the fact that itests does not have a dependency on the xmlbeans module ? (Validator class is a part of the xbean-2.0.0.jar)
But then when I re-run the top level build or run maven from the openejb/modules/itests directory, it completes successfully.

Platform: Windows XP.

[jira] Updated: (GERONIMO-774) OpenEJB itests - GBeanInstance should already be stopped before die() is called

[David Jencks (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-774?page=all ]

David Jencks updated GERONIMO-774:
--

Fix Version: 1.0
 (was: 1.0-M5)

I'm not sure this is really a bug.  This message occurs when you try to stop a 
gbean that never started, usually due to a missing dependency.

 OpenEJB itests - GBeanInstance should already be stopped before die() is 
 called
 ---

  Key: GERONIMO-774
  URL: http://issues.apache.org/jira/browse/GERONIMO-774
  Project: Geronimo
 Type: Bug
   Components: OpenEJB
 Versions: 1.0-M4
  Environment: Windows XP SP2
 java version 1.4.2_06
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
 Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
 Reporter: John Sisson
  Fix For: 1.0


 The message GBeanInstance should already be stopped before die() is called 
 is issued during OpenEJB integration tests.  Experienced this in HEAD.  
 Probably happens in M4 branch too.
 20:24:10,723 INFO  [LocalConfigStore:config-store] Uninstalled configuration 
 org/openejb/scenario002
 Module org/openejb/scenario002 uninstalled.
 Completed
 20:24:12,957 INFO  [TSSBean] org/openejb/POA - Unlinked container 
 openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=n
 ull,J2EEServer=openejb,j2eeType=StatelessSessionBean,name=BasicStatelessBean
 20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
 J2EEServer=openejb,j2eeType=StatelessSessionBean,name=BasicStatelessBean' 
 stopped
 20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
 J2EEServer=openejb,j2eeType=EntityBean,name=BasicCmp2Bean' stopped
 20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
 J2EEServer=openejb,j2eeType=EntityBean,name=BasicCmpBean' stopped
 20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
 'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
 J2EEServer=openejb,j2eeType=StatefulSessionBean,name=BasicStatefulBean' 
 stopped
 20:24:12,957 INFO  [Configuration] Stopping configuration 
 org/openejb/scenario001
 20:24:13,395 ERROR [GBeanInstance] Gbeaninstance Should Already Be Stopped 
 before die() is called: objectName=geronimo.server:role=C
 MPPKGenerator,name=SecurityEntity state=starting
 20:24:13,395 ERROR [GBeanInstance] GBeanInstance should already be stopped 
 before die() is called: objectName=geronimo.server:role=C
 MPPKGenerator,name=SecurityEntity,isWrapper=true state=starting
 20:24:14,067 INFO  [PersistentConfigurationList] Saved running configuration 
 list
 20:24:14,473 INFO  [ConfigurationManagerImpl] Unloaded Configuration 
 geronimo.config:name=org/openejb/scenario001
 Completed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-448) OpenEJB ITests Fail under Sun JDK 1.5.0 (RMIoverIIOP failure)

[Aaron Mulder (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-448?page=all ]
 
Aaron Mulder closed GERONIMO-448:
-

Fix Version: 1.0-M5
 Resolution: Invalid
  Assign To: (was: Aaron Mulder)

We're no longer using OpenORB AFAIK

 OpenEJB ITests Fail under Sun JDK 1.5.0 (RMIoverIIOP failure)
 -

  Key: GERONIMO-448
  URL: http://issues.apache.org/jira/browse/GERONIMO-448
  Project: Geronimo
 Type: Bug
   Components: OpenEJB
 Reporter: Aaron Mulder
  Fix For: 1.0-M5


 java -version
 java version 1.5.0
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
 Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)
 uname -a
 Linux sirius 2.6.8-24.3-smp #1 SMP Tue Oct 26 14:40:54 UTC 2004 i686 i686 
 i386 GNU/Linux
 Test Error:
 org.omg.CORBA.INITIALIZE: Unable to create CDROutputStream class 
 (java.lang.reflect.InvocationTargetException)  vmcid: 0x0  minor code: 0  
 completed: No
 at org.openorb.orb.iiop.CDRCodec.encode_value(CDRCodec.java:192)
 at 
 org.openorb.orb.iiop.IIOPProtocolInitializer.init(IIOPProtocolInitializer.java:165)
 at 
 org.openorb.orb.pi.OpenORBInitInfo.post_init(OpenORBInitInfo.java:166)
 at org.openorb.orb.config.OpenORBLoader.init(OpenORBLoader.java:311)
 at org.openorb.orb.core.ORB.set_parameters(ORB.java:1131)
 at org.omg.CORBA.ORB.init(ORB.java:337)
 at org.openejb.corba.CORBABean.doStart(CORBABean.java:115)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean.doStart(GBeanMBean.java:616)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:511)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.start(AbstractManagedObject.java:305)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:329)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean$11.invoke(GBeanMBean.java:1036)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844)
 at 
 com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
 at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
 at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
 at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:343)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean$11.invoke(GBeanMBean.java:1036)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844)
 at 
 com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
 at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
 at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
 at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
 at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:288)
 at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:283)
 at 
 org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:375)
 ... 1 more
 Caused by: java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at 
 org.openorb.orb.config.OpenORBLoader.constructClass(OpenORBLoader.java:557)
 at org.openorb.orb.iiop.CDRCodec.encode_value(CDRCodec.java:180)
 ... 29 more
 Caused by: java.lang.Error: Unknown VM vendor. RMIoverIIOP will not work with 
 this VM. Please contact support at [EMAIL PROTECTED]
 at 
 org.openorb.orb.rmi.DeserializationKernelFactory.init(DeserializationKernelFactory.java:182)
 at 
 org.openorb.orb.rmi.ValueHandlerImpl.clinit(ValueHandlerImpl.java:57)
 at 
 org.openorb.orb.iiop.CDROutputStream.init(CDROutputStream.java:358)
 ... 35 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-774) OpenEJB itests - GBeanInstance should already be stopped before die() is called

[John Sisson (JIRA)]

OpenEJB itests - GBeanInstance should already be stopped before die() is called
---

 Key: GERONIMO-774
 URL: http://issues.apache.org/jira/browse/GERONIMO-774
 Project: Geronimo
Type: Bug
  Components: OpenEJB  
Versions: 1.0-M4
 Environment: Windows XP SP2
java version 1.4.2_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
Reporter: John Sisson


The message GBeanInstance should already be stopped before die() is called is 
issued during OpenEJB integration tests.  Experienced this in HEAD.  Probably 
happens in M4 branch too.

20:24:10,723 INFO  [LocalConfigStore:config-store] Uninstalled configuration 
org/openejb/scenario002
Module org/openejb/scenario002 uninstalled.
Completed
20:24:12,957 INFO  [TSSBean] org/openejb/POA - Unlinked container 
openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=n
ull,J2EEServer=openejb,j2eeType=StatelessSessionBean,name=BasicStatelessBean
20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
J2EEServer=openejb,j2eeType=StatelessSessionBean,name=BasicStatelessBean' 
stopped
20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
J2EEServer=openejb,j2eeType=EntityBean,name=BasicCmp2Bean' stopped
20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
J2EEServer=openejb,j2eeType=EntityBean,name=BasicCmpBean' stopped
20:24:12,957 INFO  [GenericEJBContainer] GenericEJBContainer 
'openejb.server:EJBModule=org/openejb/scenario001,J2EEApplication=null,
J2EEServer=openejb,j2eeType=StatefulSessionBean,name=BasicStatefulBean' stopped
20:24:12,957 INFO  [Configuration] Stopping configuration 
org/openejb/scenario001
20:24:13,395 ERROR [GBeanInstance] Gbeaninstance Should Already Be Stopped 
before die() is called: objectName=geronimo.server:role=C
MPPKGenerator,name=SecurityEntity state=starting
20:24:13,395 ERROR [GBeanInstance] GBeanInstance should already be stopped 
before die() is called: objectName=geronimo.server:role=C
MPPKGenerator,name=SecurityEntity,isWrapper=true state=starting
20:24:14,067 INFO  [PersistentConfigurationList] Saved running configuration 
list
20:24:14,473 INFO  [ConfigurationManagerImpl] Unloaded Configuration 
geronimo.config:name=org/openejb/scenario001
Completed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Assigned: (GERONIMO-448) OpenEJB ITests Fail under Sun JDK 1.5.0 (RMIoverIIOP failure)

[Manoj Purohit]

---BeginMessage---
Hi There,

I m on leave from 6th - 10th December.

Pls contact the following people during my absence.

1) StarHub PPTA/Telco Server Project - Seenu/Audrey
2) SIA VR - Chee Ming/Kevin
3) ICA ePassport Payment Module - Ivan or Kevin/Yew Kong
4) General presentation stuff - Kevin
 

---End Message---

[jira] Commented: (GERONIMO-448) OpenEJB ITests Fail under Sun JDK 1.5.0 (RMIoverIIOP failure)

[Alan Cabrera (JIRA)]

 [ 
http://nagoya.apache.org/jira/browse/GERONIMO-448?page=comments#action_55412 ]
 
Alan Cabrera commented on GERONIMO-448:
---

OpenORB v1.4.0-B2 does not currently support JDK15

 OpenEJB ITests Fail under Sun JDK 1.5.0 (RMIoverIIOP failure)
 -

  Key: GERONIMO-448
  URL: http://nagoya.apache.org/jira/browse/GERONIMO-448
  Project: Apache Geronimo
 Type: Bug
   Components: OpenEJB
 Reporter: Aaron Mulder
 Assignee: Alan Cabrera


 java -version
 java version 1.5.0
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
 Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)
 uname -a
 Linux sirius 2.6.8-24.3-smp #1 SMP Tue Oct 26 14:40:54 UTC 2004 i686 i686 
 i386 GNU/Linux
 Test Error:
 org.omg.CORBA.INITIALIZE: Unable to create CDROutputStream class 
 (java.lang.reflect.InvocationTargetException)  vmcid: 0x0  minor code: 0  
 completed: No
 at org.openorb.orb.iiop.CDRCodec.encode_value(CDRCodec.java:192)
 at 
 org.openorb.orb.iiop.IIOPProtocolInitializer.init(IIOPProtocolInitializer.java:165)
 at 
 org.openorb.orb.pi.OpenORBInitInfo.post_init(OpenORBInitInfo.java:166)
 at org.openorb.orb.config.OpenORBLoader.init(OpenORBLoader.java:311)
 at org.openorb.orb.core.ORB.set_parameters(ORB.java:1131)
 at org.omg.CORBA.ORB.init(ORB.java:337)
 at org.openejb.corba.CORBABean.doStart(CORBABean.java:115)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean.doStart(GBeanMBean.java:616)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:511)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.start(AbstractManagedObject.java:305)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:329)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean$11.invoke(GBeanMBean.java:1036)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844)
 at 
 com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
 at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
 at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
 at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:343)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean$11.invoke(GBeanMBean.java:1036)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844)
 at 
 com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
 at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
 at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
 at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
 at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:288)
 at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:283)
 at 
 org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:375)
 ... 1 more
 Caused by: java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at 
 org.openorb.orb.config.OpenORBLoader.constructClass(OpenORBLoader.java:557)
 at org.openorb.orb.iiop.CDRCodec.encode_value(CDRCodec.java:180)
 ... 29 more
 Caused by: java.lang.Error: Unknown VM vendor. RMIoverIIOP will not work with 
 this VM. Please contact support at [EMAIL PROTECTED]
 at 
 org.openorb.orb.rmi.DeserializationKernelFactory.init(DeserializationKernelFactory.java:182)
 at 
 org.openorb.orb.rmi.ValueHandlerImpl.clinit(ValueHandlerImpl.java:57)
 at 
 org.openorb.orb.iiop.CDROutputStream.init(CDROutputStream.java:358)
 ... 35 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-448) OpenEJB ITests Fail under Sun JSK 1.5.0 (RMIoverIIOP failure)

[Aaron Mulder (JIRA)]

OpenEJB ITests Fail under Sun JSK 1.5.0 (RMIoverIIOP failure)
-

 Key: GERONIMO-448
 URL: http://nagoya.apache.org/jira/browse/GERONIMO-448
 Project: Apache Geronimo
Type: Bug
  Components: OpenEJB  
Reporter: Aaron Mulder


java -version
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)
uname -a
Linux sirius 2.6.8-24.3-smp #1 SMP Tue Oct 26 14:40:54 UTC 2004 i686 i686 i386 
GNU/Linux

Test Error:

org.omg.CORBA.INITIALIZE: Unable to create CDROutputStream class 
(java.lang.reflect.InvocationTargetException)  vmcid: 0x0  minor code: 0  
completed: No
at org.openorb.orb.iiop.CDRCodec.encode_value(CDRCodec.java:192)
at 
org.openorb.orb.iiop.IIOPProtocolInitializer.init(IIOPProtocolInitializer.java:165)
at 
org.openorb.orb.pi.OpenORBInitInfo.post_init(OpenORBInitInfo.java:166)
at org.openorb.orb.config.OpenORBLoader.init(OpenORBLoader.java:311)
at org.openorb.orb.core.ORB.set_parameters(ORB.java:1131)
at org.omg.CORBA.ORB.init(ORB.java:337)
at org.openejb.corba.CORBABean.doStart(CORBABean.java:115)
at org.apache.geronimo.gbean.jmx.GBeanMBean.doStart(GBeanMBean.java:616)
at 
org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:511)
at 
org.apache.geronimo.gbean.jmx.AbstractManagedObject.start(AbstractManagedObject.java:305)
at 
org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:329)
at 
org.apache.geronimo.gbean.jmx.GBeanMBean$11.invoke(GBeanMBean.java:1036)
at 
org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844)
at 
com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
at 
org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:343)
at 
org.apache.geronimo.gbean.jmx.GBeanMBean$11.invoke(GBeanMBean.java:1036)
at 
org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844)
at 
com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:288)
at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:283)
at 
org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:375)
... 1 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at 
org.openorb.orb.config.OpenORBLoader.constructClass(OpenORBLoader.java:557)
at org.openorb.orb.iiop.CDRCodec.encode_value(CDRCodec.java:180)
... 29 more
Caused by: java.lang.Error: Unknown VM vendor. RMIoverIIOP will not work with 
this VM. Please contact support at [EMAIL PROTECTED]
at 
org.openorb.orb.rmi.DeserializationKernelFactory.init(DeserializationKernelFactory.java:182)
at 
org.openorb.orb.rmi.ValueHandlerImpl.clinit(ValueHandlerImpl.java:57)
at org.openorb.orb.iiop.CDROutputStream.init(CDROutputStream.java:358)
... 35 more




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-448) OpenEJB ITests Fail under Sun JDK 1.5.0 (RMIoverIIOP failure)

[Aaron Mulder (JIRA)]

 [ http://nagoya.apache.org/jira/browse/GERONIMO-448?page=history ]

Aaron Mulder updated GERONIMO-448:
--

Summary: OpenEJB ITests Fail under Sun JDK 1.5.0 (RMIoverIIOP failure)  
(was: OpenEJB ITests Fail under Sun JSK 1.5.0 (RMIoverIIOP failure))

 OpenEJB ITests Fail under Sun JDK 1.5.0 (RMIoverIIOP failure)
 -

  Key: GERONIMO-448
  URL: http://nagoya.apache.org/jira/browse/GERONIMO-448
  Project: Apache Geronimo
 Type: Bug
   Components: OpenEJB
 Reporter: Aaron Mulder


 java -version
 java version 1.5.0
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
 Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)
 uname -a
 Linux sirius 2.6.8-24.3-smp #1 SMP Tue Oct 26 14:40:54 UTC 2004 i686 i686 
 i386 GNU/Linux
 Test Error:
 org.omg.CORBA.INITIALIZE: Unable to create CDROutputStream class 
 (java.lang.reflect.InvocationTargetException)  vmcid: 0x0  minor code: 0  
 completed: No
 at org.openorb.orb.iiop.CDRCodec.encode_value(CDRCodec.java:192)
 at 
 org.openorb.orb.iiop.IIOPProtocolInitializer.init(IIOPProtocolInitializer.java:165)
 at 
 org.openorb.orb.pi.OpenORBInitInfo.post_init(OpenORBInitInfo.java:166)
 at org.openorb.orb.config.OpenORBLoader.init(OpenORBLoader.java:311)
 at org.openorb.orb.core.ORB.set_parameters(ORB.java:1131)
 at org.omg.CORBA.ORB.init(ORB.java:337)
 at org.openejb.corba.CORBABean.doStart(CORBABean.java:115)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean.doStart(GBeanMBean.java:616)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:511)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.start(AbstractManagedObject.java:305)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:329)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean$11.invoke(GBeanMBean.java:1036)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844)
 at 
 com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
 at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
 at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
 at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
 at 
 org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:343)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean$11.invoke(GBeanMBean.java:1036)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
 at 
 org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844)
 at 
 com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
 at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
 at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
 at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
 at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:288)
 at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:283)
 at 
 org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:375)
 ... 1 more
 Caused by: java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at 
 org.openorb.orb.config.OpenORBLoader.constructClass(OpenORBLoader.java:557)
 at org.openorb.orb.iiop.CDRCodec.encode_value(CDRCodec.java:180)
 ... 29 more
 Caused by: java.lang.Error: Unknown VM vendor. RMIoverIIOP will not work with 
 this VM. Please contact support at [EMAIL PROTECTED]
 at 
 org.openorb.orb.rmi.DeserializationKernelFactory.init(DeserializationKernelFactory.java:182)
 at 
 org.openorb.orb.rmi.ValueHandlerImpl.clinit(ValueHandlerImpl.java:57)
 at 
 org.openorb.orb.iiop.CDROutputStream.init(CDROutputStream.java:358)
 ... 35 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira