date:20100811


 [ 
https://issues.apache.org/jira/browse/GERONIMO-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

janel Zhang updated GERONIMO-5520:
--

Attachment: managedbean1.0-test.patch


The testsuite testsuite/javaee6-testsuite/managedbean1.0-test can not run 
correctly.
When invoke the managed bean, an error occur as following:
java.lang.NullPointerException
org.apache.geronimo.sample.servlet.ManagedBeanJNDIServlet.doPost(ManagedBeanJNDIServlet.java:70)
org.apache.geronimo.sample.servlet.ManagedBeanJNDIServlet.doGet(ManagedBeanJNDIServlet.java:51)
javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
javax.servlet.http.HttpServlet.service(HttpServlet.java:668)

It look like can not find the managed bean.

 managedbean1.0   javax.annotation.ManagedBean
 -

 Key: GERONIMO-5520
 URL: https://issues.apache.org/jira/browse/GERONIMO-5520
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: testsuite
Affects Versions: 3.0
 Environment: OS:ubuntu 8.04
 JVM:sun   1.6.0_20
 Geronimo:Build at 2010.08.09-09:46:39.619+0800
Reporter: janel Zhang
 Fix For: 3.0

 Attachments: managedbean1.0-test.patch


 The testsuite testsuite/javaee6-testsuite/managedbean1.0-test can not run 
 correctly.
 When invoke the managed bean, an error occur as following:
 java.lang.NullPointerException
   
 org.apache.geronimo.sample.servlet.ManagedBeanJNDIServlet.doPost(ManagedBeanJNDIServlet.java:70)
   
 org.apache.geronimo.sample.servlet.ManagedBeanJNDIServlet.doGet(ManagedBeanJNDIServlet.java:51)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
 It look like can not find the managed bean.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-5152) Transaction manager doesn't retry stuff that might work later

2010-08-11 Thread David Jencks (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897169#action_12897169
 ] 

David Jencks commented on GERONIMO-5152:


rev 984318 ports rev 939929 to branches 2.1 txmanager.

 Transaction manager doesn't retry stuff that might work later
 -

 Key: GERONIMO-5152
 URL: https://issues.apache.org/jira/browse/GERONIMO-5152
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: connector, transaction manager
Affects Versions: 2.2, 3.0
Reporter: David Jencks
Assignee: David Jencks
 Fix For: 2.2.1, 3.0


 There are a number of situations where the transaction manager should respond 
 to failure by waiting a while and trying again.
 These include getting a retry error and the backend not being available when 
 the tm starts so a recovery connection is not available.
 To solve this we'll need to start by reorienting the relationship between 
 connectors and the tm by giving the tm a NamedXAResourceFactory so it can ask 
 for some way to retry stuff for a given name.
 Then we'll need a list of retry tasks and a timer to execute them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[BUILD] trunk: Failed for Revision: 984309

Geronimo Revision: 984309 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811/build-0300.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811/unit-test-reports
 
[INFO] Installing 
/home/geronimo/geronimo/trunk/plugins/tomcat/tomcat7-clustering-builder-wadi/target/tomcat7-clustering-builder-wadi-3.0-SNAPSHOT.car
 to 
/home/geronimo/.m2/repository/org/apache/geronimo/configs/tomcat7-clustering-builder-wadi/3.0-SNAPSHOT/tomcat7-clustering-builder-wadi-3.0-SNAPSHOT.car
[INFO] Installing 
/home/geronimo/geronimo/trunk/plugins/tomcat/tomcat7-clustering-builder-wadi/target/resources/META-INF/geronimo-plugin.xml
 to 
/home/geronimo/.m2/repository/org/apache/geronimo/configs/tomcat7-clustering-builder-wadi/3.0-SNAPSHOT/tomcat7-clustering-builder-wadi-3.0-SNAPSHOT.plugin-metadata
[INFO] [car:update-pluginlist {execution: default-update-pluginlist}]
[INFO] 
[INFO] Building Geronimo Plugins, Aries
[INFO]task-segment: [install]
[INFO] 
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [geronimo-property:set-property {execution: set-property}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
[INFO] [geronimo-osgi:verify-manifest {execution: verify-manifest}]
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing /home/geronimo/geronimo/trunk/plugins/aries/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/plugins/aries/3.0-SNAPSHOT/aries-3.0-SNAPSHOT.pom
[INFO] 
[INFO] Building Geronimo Plugins, Aries :: Builder
[INFO]task-segment: [install]
[INFO] 
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [geronimo-property:set-property {execution: set-property}]
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.utils:0.2-incubating-SNAPSHOT:
 checking for updates from local
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.utils:0.2-incubating-SNAPSHOT:
 checking for updates from jetty.oss.sonatype.org
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.utils:0.2-incubating-SNAPSHOT:
 checking for updates from openqa-snapshots
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.utils:0.2-incubating-SNAPSHOT:
 checking for updates from codehaus.snapshots
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.utils:0.2-incubating-SNAPSHOT:
 checking for updates from apache.snapshots
Downloading: 
http://repository.apache.org/snapshots/org/apache/aries/application/org.apache.aries.application.utils/0.2-incubating-SNAPSHOT/org.apache.aries.application.utils-0.2-incubating-20100811.011145-27.pom
3K downloaded  
(org.apache.aries.application.utils-0.2-incubating-20100811.011145-27.pom)
[INFO] snapshot 
org.apache.aries.application:application:0.2-incubating-SNAPSHOT: checking for 
updates from local
[INFO] snapshot 
org.apache.aries.application:application:0.2-incubating-SNAPSHOT: checking for 
updates from jetty.oss.sonatype.org
[INFO] snapshot 
org.apache.aries.application:application:0.2-incubating-SNAPSHOT: checking for 
updates from openqa-snapshots
[INFO] snapshot 
org.apache.aries.application:application:0.2-incubating-SNAPSHOT: checking for 
updates from codehaus.snapshots
[INFO] snapshot 
org.apache.aries.application:application:0.2-incubating-SNAPSHOT: checking for 
updates from apache.snapshots
Downloading: 
http://repository.apache.org/snapshots/org/apache/aries/application/application/0.2-incubating-SNAPSHOT/application-0.2-incubating-20100811.011145-27.pom
9K downloaded  (application-0.2-incubating-20100811.011145-27.pom)
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.api:0.2-incubating-SNAPSHOT:
 checking for updates from local
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.api:0.2-incubating-SNAPSHOT:
 checking for updates from jetty.oss.sonatype.org
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.api:0.2-incubating-SNAPSHOT:
 checking for updates from openqa-snapshots
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.api:0.2-incubating-SNAPSHOT:
 checking for updates from codehaus.snapshots
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.api:0.2-incubating-SNAPSHOT:
 checking for updates from apache.snapshots
Downloading: 
http://repository.apache.org/snapshots/org/apache/aries/application

[BUILD] branches/2.2: Failed for Revision: 984267

Geronimo Revision: 984267 built with tests included
 
See the full build-2000.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/build-2000.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 395 minutes 11 seconds
[INFO] Finished at: Wed Aug 11 02:41:27 EDT 2010
[INFO] Final Memory: 326M/839M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/logs-2000-tomcat/
 
[INFO] Running TestSuite
[INFO] Tests run: 40, Failures: 33, Errors: 0, Skipped: 0, Time elapsed: 
174.793 sec  FAILURE!
[INFO] Running TestSuite
[INFO] Tests run: 12, Failures: 10, Errors: 0, Skipped: 0, Time elapsed: 55.402 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 7, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 107.916 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 69.368 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 10, Failures: 10, Errors: 0, Skipped: 0, Time elapsed: 0.626 
sec  FAILURE!
 
Assembly: jetty
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/logs-2000-jetty/
 
[INFO] Running TestSuite
[INFO] Tests run: 116, Failures: 3, Errors: 0, Skipped: 113, Time elapsed: 
16.014 sec  FAILURE!
[INFO] Running TestSuite
[INFO] Tests run: 12, Failures: 9, Errors: 0, Skipped: 0, Time elapsed: 63.599 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 8.042 
sec  FAILURE!
[INFO] Running TestSuite
[INFO] Tests run: 7, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 92.537 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.631 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 10, Failures: 10, Errors: 0, Skipped: 0, Time elapsed: 0.649 
sec  FAILURE!
 
Samples: branches/2.2
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/samples-2000.log
 
Build status: FAILED

What happened to Geronimo plugins in 3.0

2010-08-11 Thread chi runhua

Hi devs,

I'm trying to sort out how the geronimo plugin works in 3.0 and what the
differences are comparing to the ones in the previous version. After reading
some code and JIRAs, I'm quite confused, such as
*  is a geronimo-plugin.xml file required any longer?
*  what's relationship between a geronimo plugin and an OSGi bundle?  A
plugin is a bundle actually now?
*  How to expose services from a geronimo plugin?
*  What purpose does a repository.xml in a geronimo-plugin package
serve?
*  How to manage the Lifecyle of a geronimo plugin?
 

Could anyone shed some light on me?

Thanks a lot.

Jeff

Geronimo Server Trunk - Compilation Errors shown in Eclipse workspace

2010-08-11 Thread Vamsavardhana Reddy

Hi,

After building the Geronimo 3.0 trunk, I see some errors shown in Eclipse
when I import the projects into workspace. The following are few such.

1)
Error: The blank final field parameterTypes may not have been initialized
Source location: Line 82 in
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/GBeanOperation.java

The source line is
private String[] types = (String[])
parameterTypes.toArray(new String[parameterTypes.size()]);

Examining the source indicates that the field parameterTypes is very much
initialized. Also, there is no build error while building the project using
maven.

2)
Error: The method getAllAppenders() is undefined for the type Logger
Source location: Line 342 in
geronimo-pax-logging/src/main/java/org/apache/geronimo/logging/impl/Log4jService.java

The source line is
for (Enumeration e = Logger.getRootLogger().getAllAppenders();
e.hasMoreElements();) {

A similar error is shown with 7 other source lines in the same file

Any idea how to get rid of these errors shown in Eclipse?
I am using Eclipse Platform Version: 3.4.1 Build id: M20080911-1700 on
Windows XP SP3, with Sun JDK 1.6.0_20.

-- 
Vamsi

Re: [Request] Geronimo Confluence admin right

Hi Ivan,
You should be all set.
--kevan
On Aug 11, 2010, at 3:12 AM, Ivan wrote:

 Hi,
 I found that some members of the same timezone with me are working on the 
 Geronimo docs, and could anyone help to grant me the admin right for Geronimo 
 confluence, so that I could trigger the async process quickly and aslo grant 
 permissions to those guys who would like contribute to the Geronimo docs.
Thanks !
 -- 
 Ivan

[jira] Assigned: (GERONIMO-5503) Run geronimo as Linux service update

2010-08-11 Thread viola.lu (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-5503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

viola.lu reassigned GERONIMO-5503:
--

Assignee: Forrest Xia  (was: viola.lu)

Pls apply it, thanks

 Run geronimo as Linux service update
 

 Key: GERONIMO-5503
 URL: https://issues.apache.org/jira/browse/GERONIMO-5503
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: general
Affects Versions: 3.0
 Environment: Linux
Reporter: viola.lu
Assignee: Forrest Xia
Priority: Minor
 Fix For: 3.0

 Attachments: G-5503.patch


 Gshell commands don't exist in 3.0. so should update gserviceReg.sh which is 
 responsible for run server as linux service funcion.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[DISCUSS] Policy for granting access to Geronimo TCK materials

All,
Our policy for granting access to the Geronimo TCK test harness is described
here --
https://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html#GeronimoProjectPolicies-AccesstoTCK

The policy describes a 72 hour waiting period when granting non-Geronimo
committers read-only access to our TCK test harness. This period was intended
to allow the Geronimo PMC time to provide oversight on these requests.
Presumably, a PMC member could block someone's request (though this has never
occurred and I can't, frankly, imagine a case where we would block someone's
request). If we had our preference, our TCK test harness would not be in a
private svn. It would instead be publicly readable by all.

I would like to remove the 72 hour waiting period from our policy. If an ASF
committer requests access to our test harness, I believe we should grant this
access immediately.

The 72 hour waiting period might have been more meaningful when the Geronimo
project maintained and distributed the Sun (now Oracle) TCK. As a reminder,
these materials are obtained via an agreement between the ASF and Sun/Oracle.
To gain access to these materials, an ASF committer must sign an NDA. We still
maintain/distribute the Sun/Oracle TCK for Java EE 5. However, the JCP project
is maintaining the newer TCK materials. The JCP does not have a waiting period
for granting access to the JCP maintained TCK materials.

Comments? Objections? If I don't hear any objections, I'll plan on updating our
policy and removing the 72 hour window...

--kevan

Re: XA_RBROLLBACK Exception when using Derby in transaction.roolback()

2010-08-11 Thread sghayal

U r using wrong url. Both the url point to same database.

This is what seems to be happening. A single transaction has been started which 
is being committed twice.

If using xa u need two physically different databases.

Hope this helps.

Cheers,

Sandip 
Sent from my “contract free” BlackBerry® smartphone on the WIND network.

-Original Message-
From: lilisacat lilisa...@gmail.com
Date: Wed, 11 Aug 2010 15:15:41 
To: devdev@geronimo.apache.org
Reply-To: dev@geronimo.apache.org
Subject: XA_RBROLLBACK Exception when using Derby in transaction.roolback()

Hi,
I encournter a problem when run the app in the G-3.0-SANPSHOT.
In the app, I used Datasource DS-A and Datasource DS-B to link two derby 
database. 
If UserTransaction.rollback() called, the server occured error:
org.apache.derby.client.am.XaException: XA_RBROLLBACK : Error executing a 
XAResource.end(), server returned XA_RBROLLBACK. 

Here is the details of two Datasource:
//DataSourceSH
@DataSourceDefinition(name=java:app/SHAcc,
   className=org.apache.derby.jdbc.ClientXADataSource,
   url=jdbc:derby://localhost:1527/SHAcc,
   user=system,
   databaseName=SHAcc,
   transactional=true,
   maxPoolSize=10,
   properties = {createDatabase = create})
//DataSourceBJ
@DataSourceDefinition(name=java:app/BJAcc,
   className=org.apache.derby.jdbc.ClientXADataSource,
   url=jdbc:derby://localhost:1527/BJAcc,
   user=system,
   databaseName=BJAcc,
   transactional=true,
   maxPoolSize=10,
   properties = {createDatabase = create})

In the Servlet, I used two datasources as following:
Context initContext = new InitialContext();
tx = (UserTransaction)initContext.lookup(java:comp/UserTransaction);
// Start a transaction
// First, use DataSourceSH
ds = (javax.sql.DataSource) initContext.lookup(java:app/SHAcc);
//get connection with database: SHAcc
//do some update on database: SHAcc
if(failFlag)
{tx.setRollBackOnly();}
// Second, use DataSourceBJ 
ds = (javax.sql.DataSource) initContext.lookup(java:app/BJAcc);
//get connection with database: BJAcc
//do some update on database: BJAcc
// commit all the operations
tx.commit();
}
catch(Exception e){
if(tx!=null){
try{
// rollback the operations
tx.rollback();
System.out.println(catch: roll back success.);}
catch(Exception e1){
System.out.println(catch: roll back fail.);}
}
System.out.println(catch:  + e.getClass() + ;  + e.getMessage()+);
}..

I have no idea why Error executing a XAResource.end() if tx.rollback() 
happens?

 Thanks !
2010-08-11 



Lisa

Re: Geronimo Server Trunk - Compilation Errors shown in Eclipse workspace

I don't have any answers. IIRC, this doesn't stop you from using eclipse. I 
always build outside of my IDE, anyway...

There are newer versions of Eclipse. Current is Helios (3.6).  Good chance that 
at least some of your problems are fixed...

On Aug 11, 2010, at 7:28 AM, Vamsavardhana Reddy wrote:

 Hi,
 
 After building the Geronimo 3.0 trunk, I see some errors shown in Eclipse 
 when I import the projects into workspace. The following are few such.
 
 1)
 Error: The blank final field parameterTypes may not have been initialized
 Source location: Line 82 in 
 geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/GBeanOperation.java
 
 The source line is
 private String[] types = (String[]) 
 parameterTypes.toArray(new String[parameterTypes.size()]);
 
 Examining the source indicates that the field parameterTypes is very much 
 initialized. Also, there is no build error while building the project using 
 maven.

Seems like an Eclipse compiler bug.

 
 2)
 Error: The method getAllAppenders() is undefined for the type Logger
 Source location: Line 342 in 
 geronimo-pax-logging/src/main/java/org/apache/geronimo/logging/impl/Log4jService.java
 
 The source line is
 for (Enumeration e = Logger.getRootLogger().getAllAppenders(); 
 e.hasMoreElements();) {
 
 A similar error is shown with 7 other source lines in the same file

Either a compiler bug, or the wrong version of Logger is being used for the 
compilation (assuming there's a version of log4j where getAllAppenders() is not 
a valid Category/Logger method...

--kevan

[discuss]atinject tck

Hi

I have been investigating how to run the JSR 330 tck (also called the
atinject tck), as this is a requirement for Java EE 6 compliance.

I am able to check out the open web bean project and run its atinject
tck from the open web bean project checkout dir, using the atinject
tck runner provided by open web bean   Basically the atinject tck
runner deploys the tck test classes (note it is not an archive) to a
stand-alone test container and the atinect tck tests verifies various
fields/constructors/methods are injected correctly.   The special part
of the atinject tck is that there is no Java EE archive and all tests
are written as junit tests.

My first thought is we could reuse the atinject tck runner from open
web bean project to run the tck, but the concern is that the tests are
only deployed to a stand-alone test container instead of the Geronimo
server.  So I am not sure if that is valid.

My current thoughts are that atinject tck is relatively small and are
junit tests thus it is reasonable to run in a stand-alone test
container.  The JCDI(JSR 299) tck overlaps some of the atinject tck
and should run with the real Application Server like Geronimo.

If we also agree with this approach, I think we can just reuse the
atinject tck runner in open web bean.   WDYT?

Lin


-- Forwarded message --
From: Kevan Miller kevan.mil...@gmail.com
Date: Tue, Aug 10, 2010 at 10:43 PM
Subject: Re: JCDI and Bean Validation TCKs
To: dev@geronimo.apache.org



On Jul 21, 2010, at 12:04 AM, Jarek Gawor wrote:

 Ok, it sounds like more people prefer to move these tcks into a public
 svn location.

 So I guess we should create a
 https://svn.apache.org/repos/asf/geronimo/tck repo and move the tcks
 over. There should be no problem with moving the following modules
 (since it's all Apache licensed stuff):

 1) jboss-test-harness-geronimo - integration code between jboss test
 harness  geronimo which is used by #2 and #3
 2) jcdi-testsuite - jcdi tck runner
 3) validator-testsuite - bean validation tck runner

All,
Please note that the above TCK tests are in our public SVN. Unlike the
mainstream Java EE TCK tests, which we are required to keep private,
these tests are Apache licensed. We can discuss them openly. This
means we have TCK materials in two places (public svn and private
svn). I *much* prefer to have our TCK materials in public svn. So,
although it complicates some things, IMO, we should err on the side of
openness, rather than simplicity...

--kevan

[BUILD] trunk: Failed for Revision: 984396

Geronimo Revision: 984396 built with tests included
 
See the full build-0900.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811/build-0900.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811/unit-test-reports
 
[INFO] Installing 
/home/geronimo/geronimo/trunk/plugins/tomcat/tomcat7-clustering-builder-wadi/target/tomcat7-clustering-builder-wadi-3.0-SNAPSHOT.car
 to 
/home/geronimo/.m2/repository/org/apache/geronimo/configs/tomcat7-clustering-builder-wadi/3.0-SNAPSHOT/tomcat7-clustering-builder-wadi-3.0-SNAPSHOT.car
[INFO] Installing 
/home/geronimo/geronimo/trunk/plugins/tomcat/tomcat7-clustering-builder-wadi/target/resources/META-INF/geronimo-plugin.xml
 to 
/home/geronimo/.m2/repository/org/apache/geronimo/configs/tomcat7-clustering-builder-wadi/3.0-SNAPSHOT/tomcat7-clustering-builder-wadi-3.0-SNAPSHOT.plugin-metadata
[INFO] [car:update-pluginlist {execution: default-update-pluginlist}]
[INFO] 
[INFO] Building Geronimo Plugins, Aries
[INFO]task-segment: [install]
[INFO] 
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [geronimo-property:set-property {execution: set-property}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
[INFO] [geronimo-osgi:verify-manifest {execution: verify-manifest}]
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing /home/geronimo/geronimo/trunk/plugins/aries/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/plugins/aries/3.0-SNAPSHOT/aries-3.0-SNAPSHOT.pom
[INFO] 
[INFO] Building Geronimo Plugins, Aries :: Builder
[INFO]task-segment: [install]
[INFO] 
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [geronimo-property:set-property {execution: set-property}]
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.utils:0.2-incubating-SNAPSHOT:
 checking for updates from local
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.utils:0.2-incubating-SNAPSHOT:
 checking for updates from jetty.oss.sonatype.org
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.utils:0.2-incubating-SNAPSHOT:
 checking for updates from openqa-snapshots
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.utils:0.2-incubating-SNAPSHOT:
 checking for updates from codehaus.snapshots
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.utils:0.2-incubating-SNAPSHOT:
 checking for updates from apache.snapshots
Downloading: 
http://repository.apache.org/snapshots/org/apache/aries/application/org.apache.aries.application.utils/0.2-incubating-SNAPSHOT/org.apache.aries.application.utils-0.2-incubating-20100811.011145-27.pom
3K downloaded  
(org.apache.aries.application.utils-0.2-incubating-20100811.011145-27.pom)
[INFO] snapshot 
org.apache.aries.application:application:0.2-incubating-SNAPSHOT: checking for 
updates from local
[INFO] snapshot 
org.apache.aries.application:application:0.2-incubating-SNAPSHOT: checking for 
updates from jetty.oss.sonatype.org
[INFO] snapshot 
org.apache.aries.application:application:0.2-incubating-SNAPSHOT: checking for 
updates from openqa-snapshots
[INFO] snapshot 
org.apache.aries.application:application:0.2-incubating-SNAPSHOT: checking for 
updates from codehaus.snapshots
[INFO] snapshot 
org.apache.aries.application:application:0.2-incubating-SNAPSHOT: checking for 
updates from apache.snapshots
Downloading: 
http://repository.apache.org/snapshots/org/apache/aries/application/application/0.2-incubating-SNAPSHOT/application-0.2-incubating-20100811.011145-27.pom
9K downloaded  (application-0.2-incubating-20100811.011145-27.pom)
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.api:0.2-incubating-SNAPSHOT:
 checking for updates from local
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.api:0.2-incubating-SNAPSHOT:
 checking for updates from jetty.oss.sonatype.org
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.api:0.2-incubating-SNAPSHOT:
 checking for updates from openqa-snapshots
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.api:0.2-incubating-SNAPSHOT:
 checking for updates from codehaus.snapshots
[INFO] snapshot 
org.apache.aries.application:org.apache.aries.application.api:0.2-incubating-SNAPSHOT:
 checking for updates from apache.snapshots
Downloading: 
http://repository.apache.org/snapshots/org/apache/aries/application

[jira] Created: (GERONIMO-5521) NoClassDefFoundError when deploying a datasource with non-OSGi jdbc lib dependencies

2010-08-11 Thread Forrest Xia (JIRA)

NoClassDefFoundError when deploying a datasource with non-OSGi jdbc lib 
dependencies


 Key: GERONIMO-5521
 URL: https://issues.apache.org/jira/browse/GERONIMO-5521
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: connector
Affects Versions: 3.0
 Environment: ubuntu 8.04 x86-32
sun java 1.6.0_20
Reporter: Forrest Xia


Steps:
1. start geronimo tomcat we profile assembly
2. install jdbc library via deploy install-library command. The jdbc libraries 
are not bundlized yet
3. define a datasource deployment plan with dependencies on the jdbc libraries
4. deploy the datasource via proper tranql adapter

An exception throws like this:
2010-08-11 09:02:59,585 ERROR [GBeanInstanceState] Error while starting; GBean 
is now in the FAILED state: 
abstractName=org.apache.geronimo.samples.daytrader.plugins/daytrader-db2-datasource/3.0-M1/car?J2EEApplication=null,JCAConnectionFactory=jdbc/TradeDataSource,JCAResource=tranql-connector-db2-xa-1.5,ResourceAdapter=tranql-connector-db2-xa-1.5,ResourceAdapterModule=org.apache.geronimo.samples.daytrader.plugins/daytrader-db2-datasource/3.0-M1/car,j2eeType=JCAManagedConnectionFactory,name=jdbc/TradeDataSource
java.lang.NoClassDefFoundError: com.ibm.db2.jcc.DB2XADataSource
at org.tranql.connector.db2.XAMCF.init(XAMCF.java:51)
at java.lang.J9VMInternals.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1325)
at 
org.apache.geronimo.connector.wrapper.outbound.ManagedConnectionFactoryWrapper.init(ManagedConnectionFactoryWrapper.java:115)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:44)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39)
at java.lang.reflect.Constructor.newInstance(Constructor.java:516)
at 
org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952)
at 
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:460)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:224)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:698)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:677)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872)
at 
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:344)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872)
at

plugins\aries\geronimo-aries-builder compile error in trunk

2010-08-11 Thread viola lu

Hi, dev:
 I met compile error when build module plugins\aries\geronimo-aries-builder
under g 3.0 trunk: its org.apache.geronimo.aries.builder.GeronimoApplication
class file,
   *new SimpleBundleInfo(applicationFactory, bm, url.toExternalForm())); * is
undefined,
which should be changed to *new SimpleBundleInfo(bm, url.toExternalForm())
avoiding build error.*
Seems 
*org.apache.aries.application.utils.management.SimpleBundleInfo*constructor
definition is updated in latest package
org.apache.aries.util-0.2-incubating-SNAPSHOT.jar. Currently, i used the new
SimpleBundleInfo definition to make build pass. Should we apply this change
to g 3.0 trunk? Thanks in advance!



-- 
viola

[jira] Assigned: (GERONIMO-5509) Invalid deployment descriptor error: cvc-attribute.4: The value '2.0' does not equal the fixed value '1.0' of attribute 'version'

2010-08-11 Thread viola.lu (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

viola.lu reassigned GERONIMO-5509:
--

Assignee: viola.lu

 Invalid deployment descriptor error: cvc-attribute.4: The value '2.0' does 
 not equal the fixed value '1.0' of attribute 'version'
 -

 Key: GERONIMO-5509
 URL: https://issues.apache.org/jira/browse/GERONIMO-5509
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 3.0
 Environment: ubuntu 8.04 x86-32
 sun java 1.6.0_20
Reporter: Forrest Xia
Assignee: viola.lu
 Attachments: dayTrader-derby-plan.xml, 
 daytrader-webprofile-ear-3.0-SNAPSHOT.ear


 Steps:
 1. start geronimo 3.0 snapshot web profile build
 2. deploy the attached daytrader application with the attached deployment 
 plan in the admin console
 3. then an deployment exception throws out like this:
 2010-08-09 12:24:03,465 ERROR [DeploymentPortlet] Deployment Failed
 Error parsing geronimo-openejb.xml with xmlbeans.  For debug purposes, XML 
 content written to: 
 /home/forrestxm/temp/geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT/var/temp/openejb-jar-5019648766953734149.xml
 org.apache.geronimo.common.DeploymentException: Error parsing 
 geronimo-openejb.xml with xmlbeans.  For debug purposes, XML content written 
 to: 
 /home/forrestxm/temp/geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT/var/temp/openejb-jar-5019648766953734149.xml
   at 
 org.apache.geronimo.openejb.deployment.XmlUtil.convertToXmlbeans(XmlUtil.java:107)
   at 
 org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:372)
   at 
 org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:258)
   at 
 org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:864)
   at 
 org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:457)
   at 
 org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:319)
   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:231)
   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:138)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
   at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872)
   at 
 org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
   at 
 org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
   at 
 org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
   at java.lang.Thread.run(Thread.java:619)
 Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: 
 errors:
 error: cvc-attribute.4: The value '2.0' does not equal the fixed value '1.0' 
 of attribute 'version'
 Descriptor:
 xml-fragment 
 xmlns:app=http://geronimo.apache.org/xml/ns/j2ee/application-2.0; 
 xmlns:pkgen=http://openejb.apache.org/xml/ns/pkgen-2.1; 
 xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; 
 xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.2; 
 xmlns:o=http://openejb.apache.org/xml/ns/openejb-jar-2.2; 
 xmlns:ns6=http://geronimo.apache.org/xml/ns/openejb-clustering-wadi-1.2; 
 xmlns:ns7=http://geronimo.apache.org/xml/ns/j2ee/ejb/openejb-2.0; 
 xmlns:ns8=http://geronimo.apache.org/xml/ns/security-2.0; 
 xmlns:ns9=http://java.sun.com/xml/ns/persistence;
   ns9:persistence version=2.0
 ns9:persistence-unit name=daytrader
   ns9:properties
 ns9:property name=openjpa.jdbc.DBDictionary value=derby/
   /ns9:properties
 /ns9:persistence-unit
   /ns9:persistence
 /xml-fragment
   at 
 org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.validateDD(XmlBeansUtil.java:188)
   at 
 org.apache.geronimo.schema.SchemaConversionUtils.fixGeronimoSchema(SchemaConversionUtils.java:114)
   at 
 org.apache.geronimo.openejb.deployment.XmlUtil.convertToXmlbeans(XmlUtil.java:93)
   ... 18 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [DISCUSS] Policy for granting access to Geronimo TCK materials

I agree we should drop the waiting period.

thanks
david jencks

On Aug 11, 2010, at 5:07 AM, Kevan Miller wrote:

All,
Our policy for granting access to the Geronimo TCK test harness is described
here --
https://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html#GeronimoProjectPolicies-AccesstoTCK

I would like to remove the 72 hour waiting period from our policy. If an ASF
committer requests access to our test harness, I believe we should grant this
access immediately.

The 72 hour waiting period might have been more meaningful when the Geronimo
project maintained and distributed the Sun (now Oracle) TCK. As a reminder,
these materials are obtained via an agreement between the ASF and Sun/Oracle.
To gain access to these materials, an ASF committer must sign an NDA. We
still maintain/distribute the Sun/Oracle TCK for Java EE 5. However, the JCP
project is maintaining the newer TCK materials. The JCP does not have a
waiting period for granting access to the JCP maintained TCK materials.

Comments? Objections? If I don't hear any objections, I'll plan on updating
our policy and removing the 72 hour window...

--kevan

[jira] Commented: (GERONIMO-5509) Invalid deployment descriptor error: cvc-attribute.4: The value '2.0' does not equal the fixed value '1.0' of attribute 'version'

2010-08-11 Thread viola.lu (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897289#action_12897289
 ] 

viola.lu commented on GERONIMO-5509:


This defect is related with jira: 
https://issues.apache.org/jira/browse/GERONIMO-5495 

 Invalid deployment descriptor error: cvc-attribute.4: The value '2.0' does 
 not equal the fixed value '1.0' of attribute 'version'
 -

 Key: GERONIMO-5509
 URL: https://issues.apache.org/jira/browse/GERONIMO-5509
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 3.0
 Environment: ubuntu 8.04 x86-32
 sun java 1.6.0_20
Reporter: Forrest Xia
Assignee: viola.lu
 Attachments: dayTrader-derby-plan.xml, 
 daytrader-webprofile-ear-3.0-SNAPSHOT.ear


 Steps:
 1. start geronimo 3.0 snapshot web profile build
 2. deploy the attached daytrader application with the attached deployment 
 plan in the admin console
 3. then an deployment exception throws out like this:
 2010-08-09 12:24:03,465 ERROR [DeploymentPortlet] Deployment Failed
 Error parsing geronimo-openejb.xml with xmlbeans.  For debug purposes, XML 
 content written to: 
 /home/forrestxm/temp/geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT/var/temp/openejb-jar-5019648766953734149.xml
 org.apache.geronimo.common.DeploymentException: Error parsing 
 geronimo-openejb.xml with xmlbeans.  For debug purposes, XML content written 
 to: 
 /home/forrestxm/temp/geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT/var/temp/openejb-jar-5019648766953734149.xml
   at 
 org.apache.geronimo.openejb.deployment.XmlUtil.convertToXmlbeans(XmlUtil.java:107)
   at 
 org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:372)
   at 
 org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:258)
   at 
 org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:864)
   at 
 org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:457)
   at 
 org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:319)
   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:231)
   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:138)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
   at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872)
   at 
 org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
   at 
 org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
   at 
 org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
   at java.lang.Thread.run(Thread.java:619)
 Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: 
 errors:
 error: cvc-attribute.4: The value '2.0' does not equal the fixed value '1.0' 
 of attribute 'version'
 Descriptor:
 xml-fragment 
 xmlns:app=http://geronimo.apache.org/xml/ns/j2ee/application-2.0; 
 xmlns:pkgen=http://openejb.apache.org/xml/ns/pkgen-2.1; 
 xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; 
 xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.2; 
 xmlns:o=http://openejb.apache.org/xml/ns/openejb-jar-2.2; 
 xmlns:ns6=http://geronimo.apache.org/xml/ns/openejb-clustering-wadi-1.2; 
 xmlns:ns7=http://geronimo.apache.org/xml/ns/j2ee/ejb/openejb-2.0; 
 xmlns:ns8=http://geronimo.apache.org/xml/ns/security-2.0; 
 xmlns:ns9=http://java.sun.com/xml/ns/persistence;
   ns9:persistence version=2.0
 ns9:persistence-unit name=daytrader
   ns9:properties
 ns9:property name=openjpa.jdbc.DBDictionary value=derby/
   /ns9:properties
 /ns9:persistence-unit
   /ns9:persistence
 /xml-fragment
   at 
 org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.validateDD(XmlBeansUtil.java:188)
   at 
 org.apache.geronimo.schema.SchemaConversionUtils.fixGeronimoSchema(SchemaConversionUtils.java:114)
   at 
 org.apache.geronimo.openejb.deployment.XmlUtil.convertToXmlbeans(XmlUtil.java:93)
   ... 18 more

-- 
This message is automatically generated by JIRA.

[BUILD] branches/2.2: Failed for Revision: 984384

Geronimo Revision: 984384 built with tests included
 
See the full build-0800.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/build-0800.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 41 minutes 44 seconds
[INFO] Finished at: Wed Aug 11 08:48:21 EDT 2010
[INFO] Final Memory: 346M/1010M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/logs-0800-tomcat/
 
[INFO] Running TestSuite
[INFO] Tests run: 40, Failures: 30, Errors: 0, Skipped: 0, Time elapsed: 
180.579 sec  FAILURE!
[INFO] Running TestSuite
[INFO] Tests run: 12, Failures: 11, Errors: 0, Skipped: 0, Time elapsed: 51.227 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 7, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 114.122 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 69.935 
sec  FAILURE!
 
Assembly: jetty
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/logs-0800-jetty/
 
[INFO] Running TestSuite
[INFO] Tests run: 116, Failures: 3, Errors: 0, Skipped: 113, Time elapsed: 
15.968 sec  FAILURE!
[INFO] Running TestSuite
[INFO] Tests run: 12, Failures: 8, Errors: 0, Skipped: 0, Time elapsed: 83.215 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 8.021 
sec  FAILURE!
[INFO] Running TestSuite
[INFO] Tests run: 7, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 66.986 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.391 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 10, Failures: 10, Errors: 0, Skipped: 0, Time elapsed: 0.696 
sec  FAILURE!
 
Samples: branches/2.2
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/samples-0800.log
 
Build status: FAILED

Re: [DISCUSS] Policy for granting access to Geronimo TCK materials

Agree to drop the 72 hour wait, as once the signed NDA is on file there
should be no further delays required.

-Donald

On 8/11/10 8:07 AM, Kevan Miller wrote:
All,
Our policy for granting access to the Geronimo TCK test harness is described
here --
https://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html#GeronimoProjectPolicies-AccesstoTCK

I would like to remove the 72 hour waiting period from our policy. If an ASF
committer requests access to our test harness, I believe we should grant this
access immediately.

The 72 hour waiting period might have been more meaningful when the Geronimo
project maintained and distributed the Sun (now Oracle) TCK. As a reminder,
these materials are obtained via an agreement between the ASF and Sun/Oracle.
To gain access to these materials, an ASF committer must sign an NDA. We
still maintain/distribute the Sun/Oracle TCK for Java EE 5. However, the JCP
project is maintaining the newer TCK materials. The JCP does not have a
waiting period for granting access to the JCP maintained TCK materials.

Comments? Objections? If I don't hear any objections, I'll plan on updating
our policy and removing the 72 hour window...

--kevan

Re: plugins\aries\geronimo-aries-builder compile error in trunk

2010-08-11 Thread Jarek Gawor

I'll get this resolved.

Jarek

On Wed, Aug 11, 2010 at 10:37 AM, viola lu viola...@gmail.com wrote:
 Hi, dev:
  I met compile error when build module plugins\aries\geronimo-aries-builder
 under g 3.0 trunk: its org.apache.geronimo.aries.builder.GeronimoApplication
 class file,
    new SimpleBundleInfo(applicationFactory, bm, url.toExternalForm()));  is
 undefined,
 which should be changed to new SimpleBundleInfo(bm, url.toExternalForm())
 avoiding build error.
 Seems org.apache.aries.application.utils.management.SimpleBundleInfo
 constructor definition is updated in latest package
 org.apache.aries.util-0.2-incubating-SNAPSHOT.jar. Currently, i used the new
 SimpleBundleInfo definition to make build pass. Should we apply this change
 to g 3.0 trunk? Thanks in advance!


 --
 viola

Re: XA_RBROLLBACK Exception when using Derby in transaction.roolback()

2010-08-11 Thread lilisacat

I use 
DataSourceDefinition(name=java:app/SHAcc) link to 
url=jdbc:derby://localhost:1527/SHAcc,
DataSourceDefinition(name=java:app/BJAcc)link to another 
url=jdbc:derby://localhost:1527/BJAcc,
so they point to two different databases.
The transaction can commit correctly.

The problem appears when I call the transaction.setRollBackOnly() method, 
transaction will rollback in fact,
but the server say: 
org.apache.derby.client.am.XaException: XA_RBROLLBACK : Error executing a 
XAResource.end(), server returned XA_RBROLLBACK

2010-08-11 



lilisacat 



发件人： sghayal 
发送时间： 2010-08-11  21:03:11 
收件人： dev 
抄送： 
主题： Re: XA_RBROLLBACK Exception when using Derby in transaction.roolback() 
 
U r using wrong url. Both the url point to same database.

This is what seems to be happening. A single transaction has been started which 
is being committed twice.

If using xa u need two physically different databases.

Hope this helps.

Cheers,

Sandip 
Sent from my “contract free” BlackBerry® smartphone on the WIND network.



From: lilisacat lilisa...@gmail.com 
Date: Wed, 11 Aug 2010 15:15:41 +0800
To: devdev@geronimo.apache.org
ReplyTo: dev@geronimo.apache.org 
Subject: XA_RBROLLBACK Exception when using Derby in transaction.roolback()


Hi,
I encournter a problem when run the app in the G-3.0-SANPSHOT.
In the app, I used Datasource DS-A and Datasource DS-B to link two derby 
database. 
If UserTransaction.rollback() called, the server occured error:
org.apache.derby.client.am.XaException: XA_RBROLLBACK : Error executing a 
XAResource.end(), server returned XA_RBROLLBACK. 

Here is the details of two Datasource:
//DataSourceSH
@DataSourceDefinition(name=java:app/SHAcc,
   className=org.apache.derby.jdbc.ClientXADataSource,
   url=jdbc:derby://localhost:1527/SHAcc,
   user=system,
   databaseName=SHAcc,
   transactional=true,
   maxPoolSize=10,
   properties = {createDatabase = create})
//DataSourceBJ
@DataSourceDefinition(name=java:app/BJAcc,
   className=org.apache.derby.jdbc.ClientXADataSource,
   url=jdbc:derby://localhost:1527/BJAcc,
   user=system,
   databaseName=BJAcc,
   transactional=true,
   maxPoolSize=10,
   properties = {createDatabase = create})

In the Servlet, I used two datasources as following:
Context initContext = new InitialContext();
tx = (UserTransaction)initContext.lookup(java:comp/UserTransaction);
// Start a transaction
// First, use DataSourceSH
ds = (javax.sql.DataSource) initContext.lookup(java:app/SHAcc);
//get connection with database: SHAcc
//do some update on database: SHAcc
if(failFlag)
{tx.setRollBackOnly();}
// Second, use DataSourceBJ 
ds = (javax.sql.DataSource) initContext.lookup(java:app/BJAcc);
//get connection with database: BJAcc
//do some update on database: BJAcc
// commit all the operations
tx.commit();
}
catch(Exception e){
if(tx!=null){
try{
// rollback the operations
tx.rollback();
System.out.println(catch: roll back success.);}
catch(Exception e1){
System.out.println(catch: roll back fail.);}
}
System.out.println(catch:  + e.getClass() + ;  + e.getMessage()+);
}..

I have no idea why Error executing a XAResource.end() if tx.rollback() 
happens?

 Thanks !
2010-08-11 



Lisa

Re: JCDI and Bean Validation TCKs

For the Bean Validation TCK, I compared the content that gets downloaded
from the JBoss maven repo to the 1.0.3 content provided from Oracle and
they were identical.  Not sure what that means for final JEE6
certification, but I don't see how they can tell from the logs which set
of artifacts were used.


-Donald


On 8/10/10 11:05 PM, Kevan Miller wrote:
 
 On Jul 21, 2010, at 12:04 AM, Jarek Gawor wrote:
 
 Ok, it sounds like more people prefer to move these tcks into a public
 svn location.

 So I guess we should create a
 https://svn.apache.org/repos/asf/geronimo/tck repo and move the tcks
 over. There should be no problem with moving the following modules
 (since it's all Apache licensed stuff):

 1) jboss-test-harness-geronimo - integration code between jboss test
 harness  geronimo which is used by #2 and #3
 2) jcdi-testsuite - jcdi tck runner
 3) validator-testsuite - bean validation tck runner
 
 There's one additional point to discuss. These TCK's are availably publicly 
 under an apache license and are also distributed by Oracle with the TCK 
 materials. Can we use the public materials or do we need to use the Oracle 
 distributed versions of these TCKs?
 
 --kevan

Re: [DISCUSS] Policy for granting access to Geronimo TCK materials

2010-08-11 Thread Joe Bohn

I agree seems like it isn't necessary and we might as well be
consistent.

Joe

On 8/11/10 8:07 AM, Kevan Miller wrote:

All,
Our policy for granting access to the Geronimo TCK test harness is described
here --
https://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html#GeronimoProjectPolicies-AccesstoTCK

I would like to remove the 72 hour waiting period from our policy. If an ASF
committer requests access to our test harness, I believe we should grant this
access immediately.

Comments? Objections? If I don't hear any objections, I'll plan on updating our
policy and removing the 72 hour window...

--kevan

Re: [discuss]atinject tck

It looks like the same general setup as the BVAL tck, in that it uses
the surefire plugin and a suiteXmlFiles which is either provided in the
downloaded TCK files or provided locally (which I don't think we can use
the open web beans overrides unless we have TCK challenges approved by
Oracle.)

You should be able to copy the content from
https://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-tck/
over into our geronimo/tck/branches/3.0/ area and make a
atinject-tck-runner project similar to the validator-tck-runner.  Jarek
already created the required jboss-test-harness-geronimo module to allow
the JBoss TCK testharness to start/stop a Geronimo server, so the
biggest part of the effort would be mapping the openwebbeans profile
from Tomcat over to using Geronimo

Since the JBoss provided TCKs use ASL 2.0, take a look at their website,
which usually describes in pretty good detail how to run the TCKs in
other app servers.


-Donald


On 8/11/10 9:30 AM, Lin Sun wrote:
 Hi
 
 I have been investigating how to run the JSR 330 tck (also called the
 atinject tck), as this is a requirement for Java EE 6 compliance.
 
 I am able to check out the open web bean project and run its atinject
 tck from the open web bean project checkout dir, using the atinject
 tck runner provided by open web bean   Basically the atinject tck
 runner deploys the tck test classes (note it is not an archive) to a
 stand-alone test container and the atinect tck tests verifies various
 fields/constructors/methods are injected correctly.   The special part
 of the atinject tck is that there is no Java EE archive and all tests
 are written as junit tests.
 
 My first thought is we could reuse the atinject tck runner from open
 web bean project to run the tck, but the concern is that the tests are
 only deployed to a stand-alone test container instead of the Geronimo
 server.  So I am not sure if that is valid.
 
 My current thoughts are that atinject tck is relatively small and are
 junit tests thus it is reasonable to run in a stand-alone test
 container.  The JCDI(JSR 299) tck overlaps some of the atinject tck
 and should run with the real Application Server like Geronimo.
 
 If we also agree with this approach, I think we can just reuse the
 atinject tck runner in open web bean.   WDYT?
 
 Lin
 
 
 -- Forwarded message --
 From: Kevan Miller kevan.mil...@gmail.com
 Date: Tue, Aug 10, 2010 at 10:43 PM
 Subject: Re: JCDI and Bean Validation TCKs
 To: dev@geronimo.apache.org
 
 
 
 On Jul 21, 2010, at 12:04 AM, Jarek Gawor wrote:
 
 Ok, it sounds like more people prefer to move these tcks into a public
 svn location.

 So I guess we should create a
 https://svn.apache.org/repos/asf/geronimo/tck repo and move the tcks
 over. There should be no problem with moving the following modules
 (since it's all Apache licensed stuff):

 1) jboss-test-harness-geronimo - integration code between jboss test
 harness  geronimo which is used by #2 and #3
 2) jcdi-testsuite - jcdi tck runner
 3) validator-testsuite - bean validation tck runner
 
 All,
 Please note that the above TCK tests are in our public SVN. Unlike the
 mainstream Java EE TCK tests, which we are required to keep private,
 these tests are Apache licensed. We can discuss them openly. This
 means we have TCK materials in two places (public svn and private
 svn). I *much* prefer to have our TCK materials in public svn. So,
 although it complicates some things, IMO, we should err on the side of
 openness, rather than simplicity...
 
 --kevan

Re: XA_RBROLLBACK Exception when using Derby in transaction.roolback()

You should be able to use two datasources on one database.  It's a bit odd but 
we should be able to handle it.  It's more plausible to get in this situation 
with a jms provider where you have inbound and outbound messaging, geronimo 
will treat the inbound XAResource and outbound XAResource as different.

It's possible that this is affected by whether what derby returns from 
isSameRM.  

I suspect this is from the second branch, derby is telling the tm that the tx 
has already been rolled back from the first branch.

It would be a lot easier to investigate this if you could provide a complete 
exception stack trace.

thanks!
david jencks

On Aug 11, 2010, at 8:30 AM, lilisacat wrote:

 I use
 DataSourceDefinition(name=java:app/SHAcc) link to 
 url=jdbc:derby://localhost:1527/SHAcc,
 DataSourceDefinition(name=java:app/BJAcc)link to another 
 url=jdbc:derby://localhost:1527/BJAcc,
 so they point to two different databases.
 The transaction can commit correctly.
  
 The problem appears when I call the transaction.setRollBackOnly() method, 
 transaction will rollback in fact,
 but the server say: 
 org.apache.derby.client.am.XaException: XA_RBROLLBACK : Error executing a 
 XAResource.end(), server returned XA_RBROLLBACK
  
 2010-08-11
 lilisacat
 发件人： sghayal
 发送时间： 2010-08-11  21:03:11
 收件人： dev
 抄送：
 主题： Re: XA_RBROLLBACK Exception when using Derby in transaction.roolback()
 U r using wrong url. Both the url point to same database.
 
 This is what seems to be happening. A single transaction has been started 
 which is being committed twice.
 
 If using xa u need two physically different databases.
 
 Hope this helps.
 
 Cheers,
 
 Sandip
 Sent from my “contract free” BlackBerry® smartphone on the WIND network.
 
 From: lilisacat lilisa...@gmail.com
 Date: Wed, 11 Aug 2010 15:15:41 +0800
 To: devdev@geronimo.apache.org
 ReplyTo: dev@geronimo.apache.org
 Subject: XA_RBROLLBACK Exception when using Derby in transaction.roolback()
 
 Hi,
 I encournter a problem when run the app in the G-3.0-SANPSHOT.
 In the app, I used Datasource DS-A and Datasource DS-B to link two derby 
 database.
 If UserTransaction.rollback() called, the server occured error:
 org.apache.derby.client.am.XaException: XA_RBROLLBACK : Error executing a 
 XAResource.end(), server returned XA_RBROLLBACK.

 Here is the details of two Datasource:
 //DataSourceSH
 @DataSourceDefinition(name=java:app/SHAcc,
className=org.apache.derby.jdbc.ClientXADataSource,
url=jdbc:derby://localhost:1527/SHAcc,
user=system,
databaseName=SHAcc,
transactional=true,
maxPoolSize=10,
properties = {createDatabase = create})
 //DataSourceBJ
 @DataSourceDefinition(name=java:app/BJAcc,
className=org.apache.derby.jdbc.ClientXADataSource,
url=jdbc:derby://localhost:1527/BJAcc,
user=system,
databaseName=BJAcc,
transactional=true,
maxPoolSize=10,
properties = {createDatabase = create})
  
 In the Servlet, I used two datasources as following:
 Context initContext = new InitialContext();
 tx = (UserTransaction)initContext.lookup(java:comp/UserTransaction);
 // Start a transaction
 // First, use DataSourceSH
 ds = (javax.sql.DataSource) initContext.lookup(java:app/SHAcc);
 //get connection with database: SHAcc
 //do some update on database: SHAcc
 if(failFlag)
 {tx.setRollBackOnly();}
 // Second, use DataSourceBJ 
 ds = (javax.sql.DataSource) initContext.lookup(java:app/BJAcc);
 //get connection with database: BJAcc
 //do some update on database: BJAcc
 // commit all the operations
 tx.commit();
 }
 catch(Exception e){
 if(tx!=null){
 try{
 // rollback the operations
 tx.rollback();
 System.out.println(catch: roll back success.);}
 catch(Exception e1){
 System.out.println(catch: roll back fail.);}
 }
 System.out.println(catch:  + e.getClass() + ;  + e.getMessage()+);
 }..
  
 I have no idea why Error executing a XAResource.end() if tx.rollback() 
 happens?
  
  Thanks !
 2010-08-11
 Lisa

Re: [discuss]atinject tck

2010-08-11 Thread Jarek Gawor

Donald,

As Lin pointed out the atinject is a bit different. Both JCDI and Bean
Validation TCKs can be run in standalone and in-container mode. For
Geronimo we run them in in-container mode. However, the atinject TCK
seems to only support the standalone mode. So the question is, is it
enough to just run the atinject TCK in standalone mode or do we have
to write some extra code to ensure it runs in in-container mode with
Geronimo?

Jarek

On Wed, Aug 11, 2010 at 12:06 PM, Donald Woods dwo...@apache.org wrote:
 It looks like the same general setup as the BVAL tck, in that it uses
 the surefire plugin and a suiteXmlFiles which is either provided in the
 downloaded TCK files or provided locally (which I don't think we can use
 the open web beans overrides unless we have TCK challenges approved by
 Oracle.)

 You should be able to copy the content from
 https://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-tck/
 over into our geronimo/tck/branches/3.0/ area and make a
 atinject-tck-runner project similar to the validator-tck-runner.  Jarek
 already created the required jboss-test-harness-geronimo module to allow
 the JBoss TCK testharness to start/stop a Geronimo server, so the
 biggest part of the effort would be mapping the openwebbeans profile
 from Tomcat over to using Geronimo

 Since the JBoss provided TCKs use ASL 2.0, take a look at their website,
 which usually describes in pretty good detail how to run the TCKs in
 other app servers.


 -Donald


 On 8/11/10 9:30 AM, Lin Sun wrote:
 Hi

 I have been investigating how to run the JSR 330 tck (also called the
 atinject tck), as this is a requirement for Java EE 6 compliance.

 I am able to check out the open web bean project and run its atinject
 tck from the open web bean project checkout dir, using the atinject
 tck runner provided by open web bean   Basically the atinject tck
 runner deploys the tck test classes (note it is not an archive) to a
 stand-alone test container and the atinect tck tests verifies various
 fields/constructors/methods are injected correctly.   The special part
 of the atinject tck is that there is no Java EE archive and all tests
 are written as junit tests.

 My first thought is we could reuse the atinject tck runner from open
 web bean project to run the tck, but the concern is that the tests are
 only deployed to a stand-alone test container instead of the Geronimo
 server.  So I am not sure if that is valid.

 My current thoughts are that atinject tck is relatively small and are
 junit tests thus it is reasonable to run in a stand-alone test
 container.  The JCDI(JSR 299) tck overlaps some of the atinject tck
 and should run with the real Application Server like Geronimo.

 If we also agree with this approach, I think we can just reuse the
 atinject tck runner in open web bean.   WDYT?

 Lin


 -- Forwarded message --
 From: Kevan Miller kevan.mil...@gmail.com
 Date: Tue, Aug 10, 2010 at 10:43 PM
 Subject: Re: JCDI and Bean Validation TCKs
 To: dev@geronimo.apache.org



 On Jul 21, 2010, at 12:04 AM, Jarek Gawor wrote:

 Ok, it sounds like more people prefer to move these tcks into a public
 svn location.

 So I guess we should create a
 https://svn.apache.org/repos/asf/geronimo/tck repo and move the tcks
 over. There should be no problem with moving the following modules
 (since it's all Apache licensed stuff):

 1) jboss-test-harness-geronimo - integration code between jboss test
 harness  geronimo which is used by #2 and #3
 2) jcdi-testsuite - jcdi tck runner
 3) validator-testsuite - bean validation tck runner

 All,
 Please note that the above TCK tests are in our public SVN. Unlike the
 mainstream Java EE TCK tests, which we are required to keep private,
 these tests are Apache licensed. We can discuss them openly. This
 means we have TCK materials in two places (public svn and private
 svn). I *much* prefer to have our TCK materials in public svn. So,
 although it complicates some things, IMO, we should err on the side of
 openness, rather than simplicity...

 --kevan

[jira] Commented: (GERONIMO-5519) Transaction recovery might commit the wrong branch on an XAResource

2010-08-11 Thread David Jencks (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897336#action_12897336
 ] 

David Jencks commented on GERONIMO-5519:


Likely fix for this committed:
2.1 branch rev 984273
trunk rev 984471

In addition, the server 2.1 branch was updated to use the snapshot 2.1 tm to 
pick up this fix.

 Transaction recovery might commit the wrong branch on an XAResource
 ---

 Key: GERONIMO-5519
 URL: https://issues.apache.org/jira/browse/GERONIMO-5519
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: transaction manager
Affects Versions: 2.1.6, 2.2.2, 3.0
Reporter: David Jencks
 Fix For: 2.1.7, 2.2.2, 3.0


 Transaction recovery will commit the first xid that is associated with a 
 prepared transaction that is recovered from an XAResource enrolled in that 
 transaction.  That might not be the branch that was prepared on that 
 XAResource.
 This can happen if more than one XAResource is attached to the same resource 
 manager with different names, for instance for inbound and outbound 
 connections.
 Thanks to Benedict Ritchie for discovering this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [discuss]atinject tck

Hi Donald

Thanks for the reply.  I am not familar with BVAL tck.  Can you point
me the suiteXmlFiles?   Also does the BVAL tck provides a valid
archive to be deployed to a App server?

Please see more comments in line.

Lin

On Wed, Aug 11, 2010 at 12:06 PM, Donald Woods dwo...@apache.org wrote:
 It looks like the same general setup as the BVAL tck, in that it uses
 the surefire plugin and a suiteXmlFiles which is either provided in the
 downloaded TCK files or provided locally (which I don't think we can use
 the open web beans overrides unless we have TCK challenges approved by
 Oracle.)

Could you please explain why we could not use the tck runner from open
web beans?   If we want to run the tests ourselves, we could copy some
files to make it happen.  They are all under ASL v2.0.

atinject tck itself didn't provide any instruction on how to run them,
other than the java doc.  In the javadoc, it indicates the test needs
to be configured with your injector.  There is no mentioning of
running this against a real App Server.  The fact that they didn't
provide a java ee archive and only provided .class files made me
believe deploy/configure the class files onto the injector is
sufficient.

Re: [discuss]atinject tck

BTW, I found this -

http://groups.google.com/group/atinject-observer/browse_thread/thread/6eb81864296495e3/7834cf0821c8f358?#7834cf0821c8f358

I think the instruction were from the authors of the tck, while they
gave examples of running this tck by itself with the injector, which
in our case is the open web bean jar(s).

Lin

On Wed, Aug 11, 2010 at 12:58 PM, Lin Sun linsun@gmail.com wrote:
 Hi Donald

 Thanks for the reply.  I am not familar with BVAL tck.  Can you point
 me the suiteXmlFiles?   Also does the BVAL tck provides a valid
 archive to be deployed to a App server?

 Please see more comments in line.

 Lin

 On Wed, Aug 11, 2010 at 12:06 PM, Donald Woods dwo...@apache.org wrote:
 It looks like the same general setup as the BVAL tck, in that it uses
 the surefire plugin and a suiteXmlFiles which is either provided in the
 downloaded TCK files or provided locally (which I don't think we can use
 the open web beans overrides unless we have TCK challenges approved by
 Oracle.)

 Could you please explain why we could not use the tck runner from open
 web beans?   If we want to run the tests ourselves, we could copy some
 files to make it happen.  They are all under ASL v2.0.

 atinject tck itself didn't provide any instruction on how to run them,
 other than the java doc.  In the javadoc, it indicates the test needs
 to be configured with your injector.  There is no mentioning of
 running this against a real App Server.  The fact that they didn't
 provide a java ee archive and only provided .class files made me
 believe deploy/configure the class files onto the injector is
 sufficient.

Re: [discuss]atinject tck

Yep, finally found the OWB email talking about the TCKs (see Q/A #3) -
http://mail-archives.apache.org/mod_mbox/openwebbeans-dev/201001.mbox/%3c683599.32550...@web38207.mail.mud.yahoo.com%3e

For build automation, I'd prefer we have copies of these OWB TCK
projects in our own svn in the geronimo/tck area.

-Donald

On 8/11/10 12:56 PM, Jarek Gawor wrote:
Donald,

As Lin pointed out the atinject is a bit different. Both JCDI and Bean
Validation TCKs can be run in standalone and in-container mode. For
Geronimo we run them in in-container mode. However, the atinject TCK
seems to only support the standalone mode. So the question is, is it
enough to just run the atinject TCK in standalone mode or do we have
to write some extra code to ensure it runs in in-container mode with
Geronimo?

Jarek

On Wed, Aug 11, 2010 at 12:06 PM, Donald Woods dwo...@apache.org wrote:
It looks like the same general setup as the BVAL tck, in that it uses
the surefire plugin and a suiteXmlFiles which is either provided in the
downloaded TCK files or provided locally (which I don't think we can use
the open web beans overrides unless we have TCK challenges approved by
Oracle.)

You should be able to copy the content from
https://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-tck/
over into our geronimo/tck/branches/3.0/ area and make a
atinject-tck-runner project similar to the validator-tck-runner. Jarek
already created the required jboss-test-harness-geronimo module to allow
the JBoss TCK testharness to start/stop a Geronimo server, so the
biggest part of the effort would be mapping the openwebbeans profile
from Tomcat over to using Geronimo

Since the JBoss provided TCKs use ASL 2.0, take a look at their website,
which usually describes in pretty good detail how to run the TCKs in
other app servers.

-Donald

On 8/11/10 9:30 AM, Lin Sun wrote:
Hi

I have been investigating how to run the JSR 330 tck (also called the
atinject tck), as this is a requirement for Java EE 6 compliance.

I am able to check out the open web bean project and run its atinject
tck from the open web bean project checkout dir, using the atinject
tck runner provided by open web bean Basically the atinject tck
runner deploys the tck test classes (note it is not an archive) to a
stand-alone test container and the atinect tck tests verifies various
fields/constructors/methods are injected correctly. The special part
of the atinject tck is that there is no Java EE archive and all tests
are written as junit tests.

My first thought is we could reuse the atinject tck runner from open
web bean project to run the tck, but the concern is that the tests are
only deployed to a stand-alone test container instead of the Geronimo
server. So I am not sure if that is valid.

My current thoughts are that atinject tck is relatively small and are
junit tests thus it is reasonable to run in a stand-alone test
container. The JCDI(JSR 299) tck overlaps some of the atinject tck
and should run with the real Application Server like Geronimo.

If we also agree with this approach, I think we can just reuse the
atinject tck runner in open web bean. WDYT?

Lin

-- Forwarded message --
From: Kevan Miller kevan.mil...@gmail.com
Date: Tue, Aug 10, 2010 at 10:43 PM
Subject: Re: JCDI and Bean Validation TCKs
To: dev@geronimo.apache.org

On Jul 21, 2010, at 12:04 AM, Jarek Gawor wrote:

Ok, it sounds like more people prefer to move these tcks into a public
svn location.

So I guess we should create a
https://svn.apache.org/repos/asf/geronimo/tck repo and move the tcks
over. There should be no problem with moving the following modules
(since it's all Apache licensed stuff):

1) jboss-test-harness-geronimo - integration code between jboss test
harness geronimo which is used by #2 and #3
2) jcdi-testsuite - jcdi tck runner
3) validator-testsuite - bean validation tck runner

All,
Please note that the above TCK tests are in our public SVN. Unlike the
mainstream Java EE TCK tests, which we are required to keep private,
these tests are Apache licensed. We can discuss them openly. This
means we have TCK materials in two places (public svn and private
svn). I *much* prefer to have our TCK materials in public svn. So,
although it complicates some things, IMO, we should err on the side of
openness, rather than simplicity...

--kevan

Re: [discuss]atinject tck



On 8/11/10 12:58 PM, Lin Sun wrote:
 Hi Donald
 
 Thanks for the reply.  I am not familar with BVAL tck.  Can you point
 me the suiteXmlFiles?   

After running the validator-tck-runner, take a look at -
target/dependency/jsr303-tck-suite.xml

Also does the BVAL tck provides a valid
 archive to be deployed to a App server?

Yes, it deploys WARs to the server, but the JBoss testharness creates
them based on the following setting -
nameorg.jboss.testharness.standalone/name
valuefalse/value
/property

If you turn on the write-artifacts-to-disk profile, then all of the
WARs that are used are created under target/jsr303-artifacts.


-Donald


 
 Please see more comments in line.
 
 Lin
 
 On Wed, Aug 11, 2010 at 12:06 PM, Donald Woods dwo...@apache.org wrote:
 It looks like the same general setup as the BVAL tck, in that it uses
 the surefire plugin and a suiteXmlFiles which is either provided in the
 downloaded TCK files or provided locally (which I don't think we can use
 the open web beans overrides unless we have TCK challenges approved by
 Oracle.)
 
 Could you please explain why we could not use the tck runner from open
 web beans?   If we want to run the tests ourselves, we could copy some
 files to make it happen.  They are all under ASL v2.0.
 
 atinject tck itself didn't provide any instruction on how to run them,
 other than the java doc.  In the javadoc, it indicates the test needs
 to be configured with your injector.  There is no mentioning of
 running this against a real App Server.  The fact that they didn't
 provide a java ee archive and only provided .class files made me
 believe deploy/configure the class files onto the injector is
 sufficient.

Re: What happened to Geronimo plugins in 3.0

Hi Jeff,

Thanks for nudging me to try to answer some of these questions.  I've been 
meaning to for a long time.

First of all, in my mind, most of the basic infrastructure in geronimo trunk is 
in a temporary state of transition.  My eventual goals include
- using osgi services for all inter-component wiring
- eliminating gbeans and the geronimo kernel
- wiring objects together in what is now a plugin using either blueprint or 
custom code adapted to Declarative Services
- use of config admin instead of artifact_aliases.propertes and 
config-substitutions.properties and config.xml
- using karaf features to install dependencies
- using OBR much more extensively
- consider relying on the bundles installed into the framework instead of the 
source bundles in our repository directory

At a slightly higher level I think that most of our ee support would benefit 
from using a strategy like openejb with basically a single component per module 
that includes an info tree that describes all the stuff for that module.  For 
example, openejb could have one component (currently a gbean) that contains the 
info tree for all the ejbs in the module.  Web apps could be converted to one 
component (again currently a gbean) that has an info tree for the entire web 
app.

However, we aren't there yet and I think we want to get pretty complete ee 
support in place before changing the fundamental architecture yet again.

On Aug 11, 2010, at 2:36 AM, chi runhua wrote:

 Hi devs,
 
 I'm trying to sort out how the geronimo plugin works in 3.0 and what the 
 differences are comparing to the ones in the previous version. After reading 
 some code and JIRAs, I'm quite confused, such as 
 *  is a geronimo-plugin.xml file required any longer?
yes. It has two essential purposes at the moment:
- act like a karaf features descriptor and tell what other dependencies need to 
be installed for this plugin
- act like a config admin descriptor and install stuff into config.xml, 
config-substitutions.properties and artifact_aliases.properties

 *  what's relationship between a geronimo plugin and an OSGi bundle?  A 
 plugin is a bundle actually now?
All plugins are bundles.  I think there's still some xml in a plan that has no 
effect that describes our previous classloading strategy (hidden-classes, 
non-overridable-classes, etc).  However you can specify explicit import-package 
and export-package (to extend what we generate automatically)
The plugins that we build to construct the server out of only have 
configuration in them, no classes.  This seems to be an unusual strategy for 
osgi, where people usually seem to have blueprint bundles with both classes and 
configuration.  I'm not sure what I think about trying to combine classes and 
configuration.  It seems to me that it makes use of the classes much more 
restricted, although it does allow much more encapsulation.

 *  How to expose services from a geronimo plugin? 
You can get any gbean into the osgi service registry with a little bit of 
configuration:
- use the org.apache.geronimo.gbean.annotation.OsgiService annotation on the 
gbean class. If desired you can specify the exposed service interfaces in this 
annotation.
- if desired have the gbean implement org.osgi.framework.ServiceFactory
- you can add service interfaces and service properties to the GBeanData. At 
the moment you can only do this in code in a builder but if there's a reason we 
could add xml for this.

 *  What purpose does a repository.xml in a geronimo-plugin package serve?
Geronimo has an OBR instance that is mostly used for aries EBA deployment right 
now.  Currently it is set up from scanning the repository directory in the 
server.  I'm not sure this reliance on the actual repository directory is a 
good idea.  My idea is that each plugin (or karaf feature) should have a 
repository.xml for its dependencies and that all of these should get merged 
together in the geronimo OBR.  The repository.xml is a first step towards 
trying this out to see if it is workable.

 *  How to manage the Lifecyle of a geronimo plugin?
One of the bad fits between geronimo and osgi is that our plugins have an 
additional lifecycle state beyond the bundle being started, namely having the 
gbeans started.  Theoretically we can eliminate this problem by using lazy 
service activation for osgi services.  One difference is that starting gbeans 
in a plugin is done through and explicit command and lazy service activation 
occurs whenever something requests the service.  We may have to be careful to 
be sure that deployment work doesn't start runtime services, e.g. processing a 
web app to fill out its deployment info doesn't start a web connector.

So, right now you have to use the geronimo ConfigurationManager to manage the 
state of a plugin.


Hopefully this will help :-)

thanks
david jencks

  
 
 Could anyone shed some light on me?
 
 Thanks a lot.
 
 Jeff

Transaction manager versions

I'm not sure we have plausible versions for our tm components.

trunk is at 3.1-SNAPSHOT has has (same as the released 3.0) improved recovery 
support which required an api change and also supports j2ca 1.6 which extends 
j2ca 1.5.  I'm not sure if this means we extended the geronimo APIs that 
support this stuff or changed them

branches 2.1 is at 2.1.5-SNAPSHOT.  This also contains the recovery API changes 
compared with the last release 2.1.4

All of these have been released as bundles with osgi versions 2.1.4 and 3.0.

trunk:  I think there are no api changes, just internal bug fixes between 3.0 
and 3.1.  So I think the osgi package version for the next release should be 
3.0.1.  I suggest we change the maven version to 3.0.0.1-SNAPSHOT and release 
it at 3.0.1 (so the release is after the snapshot using osgi version ordering)

branches 2.1.  This is harder.  The api change means the osgi version should be 
3, which is already used.  If the changes from j2ca 1.5 to 1.6 didn't actually 
change the api we could reuse the 3.0 version. I think they did however.  I 
suspect that no one was actually using the api that changed: the expected 
customer openejb wasn't.  So I'm inclined to ignore the osgi rules and put 
the version and osgi version at 2.2 when we release.

thoughts?  anyone have more sensible ideas on this?

thanks
david jencks

[jira] Created: (GERONIMO-5522) ActiveMQ + OSGi XML xBean configuration problem

2010-08-11 Thread Eduardo Zanni (JIRA)

ActiveMQ + OSGi XML xBean configuration problem
---

 Key: GERONIMO-5522
 URL: https://issues.apache.org/jira/browse/GERONIMO-5522
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: ActiveMQ
 Environment: Apache Felix, Spring DM
Reporter: Eduardo Zanni
Priority: Blocker


I'm trying to use an external .xml file to configure a broker. I have the 
following code in my spring bundle context:
{noformat}
bean id=brokerFactory 
class=org.apache.activemq.xbean.BrokerFactoryBean  
property name=config value=file:c:/activemq.xml /  
property name=start value=false /  
/bean 
{noformat}

This should link with the configuration file with no further problems. Here is 
what my activemq.xml file looks like:

{noformat}
beans 
  xmlns=http://www.springframework.org/schema/beans; 
  xmlns:amq=http://activemq.apache.org/schema/core;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
  http://activemq.apache.org/schema/core 
http://activemq.apache.org/schema/core/activemq-core.xsd;

  bean 
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer/

  amq:broker useJmx=true xmlns=http://activemq.apache.org/schema/core;

networkConnectors
  !-- 
  networkConnector uri=multicast://default?initialReconnectDelay=100 /
  networkConnector uri=static://(tcp://localhost:61616) /
   --
/networkConnectors

persistenceFactory
  journalPersistenceAdapterFactory journalLogFiles=5 
dataDirectory=${basedir}/target/foo /

/persistenceFactory

transportConnectors
  transportConnector uri=tcp://localhost:61636 /
/transportConnectors

  /amq:broker
/beans
{noformat}

As you can see it's a pretty standard one. When starting out my bundles I get 
the following exception:

{noformat}
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'brokerManager' defined in URL [bundle://7.0:0/META-INF/spring
/bundle-context.xml]: Cannot resolve reference to bean 'brokerFactory' while 
setting bean property 'brokerFactory'; nested exception is org.springfra
mework.beans.factory.BeanCreationException: Error creating bean with name 
'brokerFactory' defined in URL [bundle://7.0:0/META-INF/spring/bundle-conte
xt.xml]: Invocation of init method failed; nested exception is 
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 10 
in XML 
document from OSGi 
resource[file:c:/activemq.xml|bnd.id=7|bnd.sym=genericenqueuer-engine] is 
invalid; nested exception is org.xml.sax.SAXParseExcepti
on: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration 
can be found for element 'amq:broker'.
{noformat}

I have tried several configurations for the namaspaces involved. Using the 
broker tags with and without the amq: declaration (broker and amq:broker) 
and specifying the specific version number for the activemq .xsd declaration. 
Still, the .xsd file doesn't seem to be found.

I am using xbean-spring version 3.7 which can be found 
[here|http://mvnrepository.com/artifact/org.apache.xbean/xbean-spring]. I have 
tried extracting the .xsd file from my 
com.springsource.org.apache.activemq-5.3.0.jar bundle file and exporting it on 
a package in one of my bundles but the parser still can't seem to find it. Any 
help with this issue will be greatly appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [discuss]atinject tck

Thanks for the link - that is rather detailed and matches what I
discovered so far.

I have no prob in having their tck runner in our tck dir. I'll work on that.

Lin

On Wed, Aug 11, 2010 at 3:16 PM, Donald Woods dwo...@apache.org wrote:
Yep, finally found the OWB email talking about the TCKs (see Q/A #3) -
http://mail-archives.apache.org/mod_mbox/openwebbeans-dev/201001.mbox/%3c683599.32550...@web38207.mail.mud.yahoo.com%3e

For build automation, I'd prefer we have copies of these OWB TCK
projects in our own svn in the geronimo/tck area.

-Donald

On 8/11/10 12:56 PM, Jarek Gawor wrote:
Donald,

Jarek

Since the JBoss provided TCKs use ASL 2.0, take a look at their website,
which usually describes in pretty good detail how to run the TCKs in
other app servers.

-Donald

On 8/11/10 9:30 AM, Lin Sun wrote:
Hi

I have been investigating how to run the JSR 330 tck (also called the
atinject tck), as this is a requirement for Java EE 6 compliance.

If we also agree with this approach, I think we can just reuse the
atinject tck runner in open web bean. WDYT?

Lin

-- Forwarded message --
From: Kevan Miller kevan.mil...@gmail.com
Date: Tue, Aug 10, 2010 at 10:43 PM
Subject: Re: JCDI and Bean Validation TCKs
To: dev@geronimo.apache.org

On Jul 21, 2010, at 12:04 AM, Jarek Gawor wrote:

Ok, it sounds like more people prefer to move these tcks into a public
svn location.

--kevan

[BUILD] trunk: Failed for Revision: 984538

Geronimo Revision: 984538 built with tests included
 
See the full build-1500.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811/build-1500.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 41 minutes 16 seconds
[INFO] Finished at: Wed Aug 11 15:42:34 EDT 2010
[INFO] Final Memory: 511M/1002M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811/logs-1500-tomcat/
 
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.46 sec  
FAILURE!
 
Assembly: jetty
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811/logs-1500-jetty/
 
 
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; 
ignoring: java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.ServiceUnavailableException [Root exception is 
java.rmi.ConnectException: Connection refused to host: localhost; nested 
exception is: 
java.net.ConnectException: Connection refused]
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; 
ignoring: java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.ServiceUnavailableException [Root exception is 
java.rmi.ConnectException: Connection refused to host: localhost; nested 
exception is: 
java.net.ConnectException: Connection refused]
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; 
ignoring: java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.ServiceUnavailableException [Root exception is 
java.rmi.ConnectException: Connection refused to host: localhost; nested 
exception is: 
java.net.ConnectException: Connection refused]
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; 
ignoring: java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.ServiceUnavailableException [Root exception is 
java.rmi.ConnectException: Connection refused to host: localhost; nested 
exception is: 
java.net.ConnectException: Connection refused]
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; 
ignoring: java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.ServiceUnavailableException [Root exception is 
java.rmi.ConnectException: Connection refused to host: localhost; nested 
exception is: 
java.net.ConnectException: Connection refused]
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; 
ignoring: java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.ServiceUnavailableException [Root exception is 
java.rmi.ConnectException: Connection refused to host: localhost; nested 
exception is: 
java.net.ConnectException: Connection refused]
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; 
ignoring: java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.ServiceUnavailableException [Root exception is 
java.rmi.ConnectException: Connection refused to host: localhost; nested 
exception is: 
java.net.ConnectException: Connection refused]
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: 
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
[org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; 
ignoring: java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.ServiceUnavailableException [Root exception is 
java.rmi.ConnectException: Connection refused to host: localhost; nested 
exception

Re: JCDI and Bean Validation TCKs

The BVAL and JCDI builds have now been updated to allow extracting
Geronimo assemblies into the target directory for automated testing.

mvn test -Pincontainer,geronimo-assembly -DassemblyId=tomcat7-javaee6

Note, that the assemblyIds are different from the ones defined in the
parent server POM, as we have to pass in the fully qualified directory
to the server based on the provided assemblyId.


-Donald


On 7/21/10 12:04 AM, Jarek Gawor wrote:
 Ok, it sounds like more people prefer to move these tcks into a public
 svn location.
 
 So I guess we should create a
 https://svn.apache.org/repos/asf/geronimo/tck repo and move the tcks
 over. There should be no problem with moving the following modules
 (since it's all Apache licensed stuff):
 
 1) jboss-test-harness-geronimo - integration code between jboss test
 harness  geronimo which is used by #2 and #3
 2) jcdi-testsuite - jcdi tck runner
 3) validator-testsuite - bean validation tck runner
 
 But I also would like to move the following two modules:
 
 4) jaxb-testsuite - jaxb tck runner
 5) stax-testsuite - stax tck runner
 
 #4 and #5 are basically just pom files that download the right
 Geronimo dependencies and unix shell scripts that run the given tck in
 batch mode. The actual tck must be downloaded/setup separately. They
 do however contain a JavaTest configuration file that configures the
 tck. So I'm not 100% sure if these modules can be moved because of
 that config file.
 
 Also, should these modules move to
 https://svn.apache.org/repos/asf/geronimo/tck/trunk or to
 https://svn.apache.org/repos/asf/geronimo/tck/branches/3.0 to mimic
 the setup we have in geronimo-tck repo?
 
 If there are no major objections to this plan I'll start working on it 
 tomorrow.
 
 Jarek
 
 On Tue, Jul 20, 2010 at 1:19 PM, Kevan Miller kevan.mil...@gmail.com wrote:

 On Jul 20, 2010, at 3:05 AM, David Jencks wrote:


 On Jul 19, 2010, at 10:37 PM, Jarek Gawor wrote:

 My main concern is that if we move the JCDI and Bean Validation
 porting code to public svn location then we will effectively have two
 mailing lists for discussing tck issues, two jira places for filing
 and tracking tck challenges, possibly two wiki places for tck info,
 etc. And we will have to be extra careful to discuss a given tck
 problem on the right list... and sooner or later somebody will use the
 wrong list.
 Yes, it would be nice to have this stuff in open but I'm just
 wondering how much headache it will be to keep track of it all and
 maintain it.

 I think its going to be significantly harder to maintain out in the open 
 and there is much more likelyhood of slips in talking about NDA stuff on 
 public lists, but I don't think we have any good argument for keeping the 
 harnesses for these tcks in the private svn.  IMO ideally all the tcks 
 would be public so I feel a bit morally obligated to put anything that can 
 be public, in public.

 Good discussion. My preference would be to err on the side of openness. So, 
 would prefer to see the harnesses in public svn and documentation on public 
 Wiki. I think we can maintain any actual TCK challenges using TCK Jira and 
 TCK mailing list (i.e. use the existing mechanisms for ASF communications 
 with Oracle). Would assume that most challenges would have been preceded by 
 a public discussion...

 If we mess up and accidentally reveal some private TCK information, then so 
 be it. Accidents have (and will) happen. In my experience, you can find a 
 lot more TCK private information on Sun/Oracle's bug reports then we've ever 
 revealed. Not saying we should ignore the issue. Just saying we shouldn't 
 lose much sleep over it, either...

 -- kevan

[jira] Commented: (GERONIMO-5522) ActiveMQ + OSGi XML xBean configuration problem

2010-08-11 Thread David Jencks (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897456#action_12897456
 ] 

David Jencks commented on GERONIMO-5522:


I doubt we can help you with this problem.  We don't use spring dm in geronimo. 
 Maybe the activemq community can help.

we use apache aries blueprint with xbean-blueprint to configure activemq in 
geronimo 3.x.  Since the blueprint namespace handler stuff is not yet an osgi 
spec all the blueprint container namespace implementations are currently 
incompatible.  

 ActiveMQ + OSGi XML xBean configuration problem
 ---

 Key: GERONIMO-5522
 URL: https://issues.apache.org/jira/browse/GERONIMO-5522
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: ActiveMQ
 Environment: Apache Felix, Spring DM
Reporter: Eduardo Zanni
Priority: Blocker

 I'm trying to use an external .xml file to configure a broker. I have the 
 following code in my spring bundle context:
 {noformat}
 bean id=brokerFactory 
 class=org.apache.activemq.xbean.BrokerFactoryBean  
   property name=config value=file:c:/activemq.xml /  
   property name=start value=false /  
 /bean 
 {noformat}
 This should link with the configuration file with no further problems. Here 
 is what my activemq.xml file looks like:
 {noformat}
 beans 
   xmlns=http://www.springframework.org/schema/beans; 
   xmlns:amq=http://activemq.apache.org/schema/core;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://www.springframework.org/schema/beans 
 http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
   http://activemq.apache.org/schema/core 
 http://activemq.apache.org/schema/core/activemq-core.xsd;
   bean 
 class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer/
   amq:broker useJmx=true xmlns=http://activemq.apache.org/schema/core;
 networkConnectors
   !-- 
   networkConnector uri=multicast://default?initialReconnectDelay=100 /
   networkConnector uri=static://(tcp://localhost:61616) /
--
 /networkConnectors
 persistenceFactory
   journalPersistenceAdapterFactory journalLogFiles=5 
 dataDirectory=${basedir}/target/foo /
 /persistenceFactory
 transportConnectors
   transportConnector uri=tcp://localhost:61636 /
 /transportConnectors
   /amq:broker
 /beans
 {noformat}
 As you can see it's a pretty standard one. When starting out my bundles I get 
 the following exception:
 {noformat}
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 with name 'brokerManager' defined in URL [bundle://7.0:0/META-INF/spring
 /bundle-context.xml]: Cannot resolve reference to bean 'brokerFactory' while 
 setting bean property 'brokerFactory'; nested exception is org.springfra
 mework.beans.factory.BeanCreationException: Error creating bean with name 
 'brokerFactory' defined in URL [bundle://7.0:0/META-INF/spring/bundle-conte
 xt.xml]: Invocation of init method failed; nested exception is 
 org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 
 10 in XML 
 document from OSGi 
 resource[file:c:/activemq.xml|bnd.id=7|bnd.sym=genericenqueuer-engine] is 
 invalid; nested exception is org.xml.sax.SAXParseExcepti
 on: cvc-complex-type.2.4.c: The matching wildcard is strict, but no 
 declaration can be found for element 'amq:broker'.
 {noformat}
 I have tried several configurations for the namaspaces involved. Using the 
 broker tags with and without the amq: declaration (broker and 
 amq:broker) and specifying the specific version number for the activemq 
 .xsd declaration. Still, the .xsd file doesn't seem to be found.
 I am using xbean-spring version 3.7 which can be found 
 [here|http://mvnrepository.com/artifact/org.apache.xbean/xbean-spring]. I 
 have tried extracting the .xsd file from my 
 com.springsource.org.apache.activemq-5.3.0.jar bundle file and exporting it 
 on a package in one of my bundles but the parser still can't seem to find it. 
 Any help with this issue will be greatly appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Transaction manager versions


On Aug 11, 2010, at 3:58 PM, David Jencks wrote:

 I'm not sure we have plausible versions for our tm components.
 
 trunk is at 3.1-SNAPSHOT has has (same as the released 3.0) improved recovery 
 support which required an api change and also supports j2ca 1.6 which extends 
 j2ca 1.5.  I'm not sure if this means we extended the geronimo APIs that 
 support this stuff or changed them
 
 branches 2.1 is at 2.1.5-SNAPSHOT.  This also contains the recovery API 
 changes compared with the last release 2.1.4
 
 All of these have been released as bundles with osgi versions 2.1.4 and 3.0.
 
 trunk:  I think there are no api changes, just internal bug fixes between 3.0 
 and 3.1.  So I think the osgi package version for the next release should be 
 3.0.1.  I suggest we change the maven version to 3.0.0.1-SNAPSHOT and release 
 it at 3.0.1 (so the release is after the snapshot using osgi version ordering)

Sounds good.

 
 branches 2.1.  This is harder.  The api change means the osgi version should 
 be 3, which is already used.  If the changes from j2ca 1.5 to 1.6 didn't 
 actually change the api we could reuse the 3.0 version. I think they did 
 however.  I suspect that no one was actually using the api that changed: the 
 expected customer openejb wasn't.  So I'm inclined to ignore the osgi rules 
 and put the version and osgi version at 2.2 when we release.
 
 thoughts?  anyone have more sensible ideas on this?

2.2 seems like the only/most reasonable solution. So, agreed...

--kevan

[BUILD] branches/2.2: Failed for Revision: 984494

Geronimo Revision: 984494 built with tests included
 
See the full build-1400.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/build-1400.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 37 minutes 4 seconds
[INFO] Finished at: Wed Aug 11 14:43:49 EDT 2010
[INFO] Final Memory: 302M/1014M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/logs-1400-tomcat/
 
[INFO] Running TestSuite
[INFO] Tests run: 40, Failures: 33, Errors: 0, Skipped: 0, Time elapsed: 
169.782 sec  FAILURE!
[INFO] Running TestSuite
[INFO] Tests run: 12, Failures: 11, Errors: 0, Skipped: 0, Time elapsed: 60.367 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 7, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 86.953 
sec  FAILURE!
--
[INFO] Running TestSuite
[INFO] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 70.316 
sec  FAILURE!
 
Assembly: jetty
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/logs-1400-jetty/
 
 
[INFO] Scanning for projects...
[INFO] Reactor build order: 
[INFO]   Geronimo TestSuite
[INFO]   Geronimo TestSuite :: Commands TestSuite
[INFO]   Geronimo TestSuite :: Concurrent TestSuite
[INFO]   Geronimo TestSuite :: Console Testsuite
[INFO]   Geronimo TestSuite :: CORBA TestSuite
[INFO]   Geronimo TestSuite :: Deployment Testsuite
[INFO]   Geronimo TestSuite :: Enterprise Testsuite
[INFO]   Geronimo TestSuite :: Security Testsuite
[INFO]   Geronimo TestSuite :: Web-tier Testsuite
[INFO]   Geronimo TestSuite :: WebServices TestSuite
[INFO] 
[INFO] Building Geronimo TestSuite
[INFO]task-segment: [install]
[INFO] 
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] Setting property: classpath.resource.loader.class = 
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on = 'false'.
[INFO] Setting property: resource.loader = 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound = 'false'.
[INFO] [remote-resources:process {execution: default}]
[INFO] [site:attach-descriptor]
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] [install:install]
[INFO] Installing /home/geronimo/geronimo/2.2/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2.2-SNAPSHOT/testsuite-2.2.2-SNAPSHOT.pom
[INFO] 
[INFO] Building Geronimo TestSuite :: Commands TestSuite
[INFO]task-segment: [install]
[INFO] 
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [site:attach-descriptor]
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: jetty
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-jetty7-javaee5:2.2.2-SNAPSHOT: checking 
for updates from codehaus.snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-jetty7-javaee5:2.2.2-SNAPSHOT: checking 
for updates from apache.snapshots
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-jetty7-javaee5:zip:bin:2.2.2-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/2.2/testsuite/commands-testsuite/target/geronimo-jetty7-javaee5-2.2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty7-javaee5/2.2.2-SNAPSHOT/geronimo-jetty7-javaee5-2.2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/2.2/testsuite/commands-testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/2.2/testsuite/commands-testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] 
[ERROR] BUILD ERROR
 
Samples: branches/2.2
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20100811/samples-1400.log
 
Build status: FAILED

Re: Re: XA_RBROLLBACK Exception when using Derby in transaction.roolback()

2010-08-11 Thread lilisacat

Hi David, 
Below is the stack trance: 
2010-08-12 09:21:23,585 WARN  [Transaction] Error ending association for 
XAResource 
org.apache.geronimo.transaction.manager.wrappernamedxaresou...@1e77734; 
transaction will roll back. XA error code: 100
org.apache.derby.client.am.XaException: XA_RBROLLBACK : Error executing a 
XAResource.end(), server returned XA_RBROLLBACK.
at org.apache.derby.client.net.NetXAResource.throwXAException(Unknown Source)
at org.apache.derby.client.net.NetXAResource.end(Unknown Source)
at 
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.end(WrapperNamedXAResource.java:53)
at 
org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:570)
at 
org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:549)
at 
org.apache.geronimo.transaction.manager.TransactionImpl.rollback(TransactionImpl.java:480)
at 
org.apache.geronimo.transaction.manager.TransactionManagerImpl.rollback(TransactionManagerImpl.java:265)
at 
org.apache.geronimo.transaction.GeronimoUserTransaction.rollback(GeronimoUserTransaction.java:74)
at org.apache.geronimo.sample.servlet.DoTransfer.doPost(DoTransfer.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)
at 
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:700)
at 
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at 
org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(ProtectedTargetValve.java:53)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:146)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:108)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:402)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:254)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:267)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:245)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:260)
at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
at 
org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.apache.derby.client.am.SqlException: Error executing a 
XAResource.end(), server returned XA_RBROLLBACK.
at org.apache.derby.client.net.NetXAResource.xaRetValErrorAccumSQL(Unknown 
Source)
... 30 more

Thanks!


2010-08-12 



lilisacat 



发件人： David Jencks 
发送时间： 2010-08-12  00:44:04 
收件人： dev 
抄送： 
主题： Re: XA_RBROLLBACK Exception when using Derby in transaction.roolback() 
 
You should be able to use two datasources on one database.  It's a bit odd but 
we should be able to handle it.  It's more plausible to get in this situation 
with a jms provider where you have inbound and outbound messaging, geronimo 
will treat the inbound XAResource and outbound XAResource as different.


It's possible that this is affected by whether what derby returns from 
isSameRM.  



I suspect this is from the second branch, derby is telling the tm that the tx 
has already been rolled back from the first branch.


It would be a lot easier to investigate this if you could provide a complete 
exception stack trace.


thanks!
david jencks


On Aug 11, 2010, at 8:30 AM, lilisacat wrote:


I use
DataSourceDefinition(name=java:app/SHAcc) link to 
url=jdbc:derby://localhost:1527/SHAcc,
DataSourceDefinition(name=java:app/BJAcc)link to another 
url=jdbc:derby://localhost:1527/BJAcc,
so they point to two different databases.
The transaction can commit correctly.

The problem appears when I call the transaction.setRollBackOnly() method, 
transaction will rollback in fact,
but the server say: 
org.apache.derby.client.am.XaException: XA_RBROLLBACK : Error executing a 
XAResource.end(), server returned XA_RBROLLBACK

2010-08-11



lilisacat



发件人： sghayal
发送时间： 2010-08-11  21:03:11
收件人： dev
抄送：
主题： Re: XA_RBROLLBACK Exception when using Derby in transaction.roolback()
U r using wrong url. Both the url point to same database.

This is what seems to be happening. A single transaction has been

[jira] Created: (GERONIMO-5523) Add testsuite for JTA 1.1

2010-08-11 Thread LiWenQin (JIRA)

Add testsuite for JTA 1.1
-

 Key: GERONIMO-5523
 URL: https://issues.apache.org/jira/browse/GERONIMO-5523
 Project: Geronimo
  Issue Type: Task
  Security Level: public (Regular issues)
  Components: testsuite
Affects Versions: 3.0
Reporter: LiWenQin
 Fix For: 3.0


This testsuite create two derby databases , 
and transfer money from one account in DatabaseA to another account in 
DatabaseB under the management of java:comp/UserTransaction.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] maven-plugins 1.1 for Geronimo Eclipse Plugin (2nd try)

2010-08-11 Thread Delos

my own +1 for it

2010/8/11 Delos dait...@gmail.com

 Hi all,

 This is the second try for releasing maven-plugins 1.1 used by GEP. I have
 created the buildable source distribution for it.

 As part of GEP, maven-eclipsepde-plugin helps to convert eclipse plugins to
 maven dependencies and add them into artifact dependency list.But now, we
 have to update the plugin to accommodate new requirements. See more details
 here https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-658

 I will prompt the new plugins once it passes the voting.

 Source distribution:

 https://repository.apache.org/content/repositories/orgapachegeronimo-093/org/apache/geronimo/devtools/maven-plugins/1.1/maven-plugins-1.1-source-release.tar.gz


 https://repository.apache.org/content/repositories/orgapachegeronimo-093/org/apache/geronimo/devtools/maven-plugins/1.1/maven-plugins-1.1-source-release.zip

 Staging repo:
 https://repository.apache.org/content/repositories/orgapachegeronimo-093

 svn tag at:
 http://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/tags/1.1

 [ ] +1 go for it
 [ ] 0
 [ ] -1 whoa, hold on a minute


 --
 Best Regards,

 Delos




-- 
Best Regards,

Delos

[BUILD] trunk: Failed for Revision: 984624

Geronimo Revision: 984624 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811/build-2100.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 46 minutes 32 seconds
[INFO] Finished at: Wed Aug 11 21:50:14 EDT 2010
[INFO] Final Memory: 475M/1000M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811/logs-2100-tomcat/
 
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.469 sec  
FAILURE!
 
Assembly: jetty
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811/logs-2100-jetty/
 
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.447 sec  
FAILURE!
 
Samples: trunk
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100811/samples-2100.log
 
Build status: OK

[jira] Created: (GERONIMO-5524) Security annotation on EJB testsuite:javax.annotation.security.RunAs RolesAllowed PermitAll DenyAll DeclareRoles

Security annotation on EJB testsuite:javax.annotation.security.RunAs 
RolesAllowed PermitAll DenyAll DeclareRoles


 Key: GERONIMO-5524
 URL: https://issues.apache.org/jira/browse/GERONIMO-5524
 Project: Geronimo
  Issue Type: Task
  Security Level: public (Regular issues)
  Components: testsuite
Affects Versions: 3.0
 Environment: OS:Linux 2.6.24-24-generic
JVM:sun 1.6.0_20
Server:Geronimo 3.0
Reporter: janel Zhang
 Fix For: 3.0


The testsuite test for security annotation on EJB.The annotation 
includes:1.javax.annotation.security.RunAs 
2.javax.annotation.security.RolesAllowed 3.javax.annotation.security.PermitAll 
4.javax.annotation.security.DenyAll
5.javax.annotation.security.DeclareRoles


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-5524) Security annotation on EJB testsuite:javax.annotation.security.RunAs RolesAllowed PermitAll DenyAll DeclareRoles


[ 
https://issues.apache.org/jira/browse/GERONIMO-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897586#action_12897586
 ] 

janel Zhang commented on GERONIMO-5524:
---

The testsuite test for security annotation on EJB.The annotation 
includes:1.javax.annotation.security.RunAs 
2.javax.annotation.security.RolesAllowed 3.javax.annotation.security.PermitAll 
4.javax.annotation.security.DenyAll
5.javax.annotation.security.DeclareRoles
The testsuite defines two roles:user and admin.And three user with role 
annonymous,user and admin,access the EJB methods.

 Security annotation on EJB testsuite:javax.annotation.security.RunAs 
 RolesAllowed PermitAll DenyAll DeclareRoles
 

 Key: GERONIMO-5524
 URL: https://issues.apache.org/jira/browse/GERONIMO-5524
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: testsuite
Affects Versions: 3.0
 Environment: OS:Linux 2.6.24-24-generic
 JVM:sun   1.6.0_20
 Server:Geronimo 3.0
Reporter: janel Zhang
 Fix For: 3.0

 Attachments: test-security-annotation-ejb.patch


 The testsuite test for security annotation on EJB.The annotation 
 includes:1.javax.annotation.security.RunAs 
 2.javax.annotation.security.RolesAllowed 
 3.javax.annotation.security.PermitAll 4.javax.annotation.security.DenyAll
 5.javax.annotation.security.DeclareRoles

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-5524) Security annotation on EJB testsuite:javax.annotation.security.RunAs RolesAllowed PermitAll DenyAll DeclareRoles