Re: How many bean validation tck tests are there?
Using the 1.0.3GA TCK level stand-alone = 244 incontainer = 258 (these are required for certification) -Donald On 11/20/10 3:03 AM, David Jencks wrote: I'm seeing a strange problem in geronimo when I run the bean validation tck where trying to determine the annotations on some test classes throws an exception and no annotations can be discovered. So at least in the server the testng annotations announcing that it's a test won't be discovered. So I wonder if we're actually running all the tests. Then I tried running the bval-tck tests and got fewer than when I run in geronimo. bval-tck: 244 geronimo: 258 actual expected test count. priceless thanks david jencks
Re: [VOTE] release EJB 3.1 spec version 1.0.2
+1 Donald On 11/9/10 6:50 AM, Rick McGuire wrote: This is a bug fix release to fix a small spec compliance issue The components up for vote are: org/apache/geronimo/specs/geronimo-ejb_3.1_spec/1.0.2/geronimo-ejb_3.1_spec-1.0.2-source-release.zip org/apache/geronimo/specs/geronimo-ejb_3.1_spec/1.0.2/geronimo-ejb_3.1_spec-1.0.2-source-release.tar.gz from the staging repository at: https://repository.apache.org/content/repositories/orgapachegeronimo-047/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-ejb_3.1_spec-1.0.2 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Rick
Re: [VOTE] release EL 2.2 spec version 1.0.1
+1 Donald On 11/9/10 7:13 AM, Rick McGuire wrote: This is a bug fix release to fix a couple of problems EL spec implementation. The components up for vote are: org/apache/geronimo/specs/geronimo-el_2.2_spec/1.0.1/geronimo-el_2.2_spec-1.0.1-source-release.zip org/apache/geronimo/specs/geronimo-el_2.2_spec/1.0.1/geronimo-el_2.2_spec-1.0.1-source-release.tar.gz from the staging repository at: https://repository.apache.org/content/repositories/orgapachegeronimo-048/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-el_2.2_spec-1.0.1 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Rick
Re: [VOTE] release JASPI component 1.1.1
+1 Donald On 11/9/10 7:31 AM, Rick McGuire wrote: This is a bug fix release to fix a problem with the JASPI OSGi integration: https://issues.apache.org/jira/browse/GERONIMO-5656 The components up for vote are: org/apache/geronimo/components/geronimo-jaspi/1.1.1/geronimo-jaspi-1.1.1-source-release.zip org/apache/geronimo/components/geronimo-jaspi/1.1.1/geronimo-jaspi-1.1.1-source-release.tar.gz from the staging repository at: https://repository.apache.org/content/repositories/orgapachegeronimo-049/ The source repo is: https://svn.apache.org/repos/asf/geronimo/components/jaspi/tags/geronimo-jaspi-1.1.1 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Rick
Re: [VOTE] Release geronimo txmanager 2.2.1 - 3rd attempt.
+1 Donald On 11/11/10 2:04 PM, Rick McGuire wrote: This is a bug-fix release that will be used for the Geronimo server 2.2.1 and 2.1.7 releases. The following Jiras included in this update. GERONIMO-5649 txmanager could try to replace dead XAResources in commit and rollback tasks GERONIMO-5684 Some txmanager Timers are not being created as daemon threads The components up for vote are: org/apache/geronimo/components/geronimo-txmanager-parent/2.2.1/geronimo-txmanager-parent-2.2.1-source-release.tar.gz org/apache/geronimo/components/geronimo-txmanager-parent/2.2.1/geronimo-txmanager-parent-2.2.1-source-release.zip from the staging repository at: https://repository.apache.org/content/repositories/orgapachegeronimo-061/ The source repo is: https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.2.1 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Rick
[jira] Commented: (GERONIMO-5617) Timestamp precision (scale) openjpa - Oracle
[ https://issues.apache.org/jira/browse/GERONIMO-5617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12912997#action_12912997 ] Donald Woods commented on GERONIMO-5617: Do you have precision settings set for this field as annotations or in a orm.xml? Can you post your persistence.xml, entity and orm.xml (if using one)? Timestamp precision (scale) openjpa - Oracle - Key: GERONIMO-5617 URL: https://issues.apache.org/jira/browse/GERONIMO-5617 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases, persistence Affects Versions: 2.1.4 Environment: Geronimo 2.14 with JDK 1.5 update 20, on Window / Linux, Database Oracle 10g or 11 Reporter: Ralf Baumhof Original Estimate: 504h Remaining Estimate: 504h Timestamp precision should be up to 10 up -12 (nano second) with Datatype java.sql.Timestamp. On inserts to database only 10 up -3 is inserted. This is done with rounding at position 10 up -3. Example - the log lines beginning with a # the value of 5551110 is rounded to 12:16:06.006: 2010-09-21 12:16:06,646 INFO - $$vor update, timestamp.toString=2010-09-21 12:16:06.646 $$ nanos vor update=64600 2010-09-21 12:16:06,646 INFO - (addition Millisekunden): 1 * 1110222 = 1110222 2010-09-21 12:16:06,646 INFO - $$nach update, timestamp.toString=2010-09-21 12:16:06.001110222 $$ nanos nach update=1110222 2010-09-21 12:16:06,662 INFO - $$vor update, timestamp.toString=2010-09-21 12:16:06.662 $$ nanos vor update=66200 2010-09-21 12:16:06,662 INFO - (addition Millisekunden): 2 * 1110222 = 2220444 2010-09-21 12:16:06,662 INFO - $$nach update, timestamp.toString=2010-09-21 12:16:06.002220444 $$ nanos nach update=2220444 2010-09-21 12:16:06,662 INFO - $$vor update, timestamp.toString=2010-09-21 12:16:06.662 $$ nanos vor update=66200 2010-09-21 12:16:06,662 INFO - (addition Millisekunden): 3 * 1110222 = 3330666 2010-09-21 12:16:06,662 INFO - $$nach update, timestamp.toString=2010-09-21 12:16:06.003330666 $$ nanos nach update=3330666 2010-09-21 12:16:06,677 INFO - $$vor update, timestamp.toString=2010-09-21 12:16:06.677 $$ nanos vor update=67700 2010-09-21 12:16:06,677 INFO - (addition Millisekunden): 4 * 1110222 = 4440888 2010-09-21 12:16:06,677 INFO - $$nach update, timestamp.toString=2010-09-21 12:16:06.004440888 $$ nanos nach update=4440888 2010-09-21 12:16:06,693 INFO - $$vor update, timestamp.toString=2010-09-21 12:16:06.693 $$ nanos vor update=69300 2010-09-21 12:16:06,693 INFO - (addition Millisekunden): 5 * 1110222 = 5551110 ###2010-09-21 12:16:06,693 INFO - $$nach update, timestamp.toString=2010-09-21 12:16:06.00555111 $$ nanos nach update=5551110 ###2010-09-21 12:16:36,583 INFO - $$ personAnschrift=4425 54852010-09-21 12:16:06.006 2010-09-21 12:16:36,583 INFO - $$ personAnschrift=4425 54842010-09-21 12:16:06.004 2010-09-21 12:16:36,583 INFO - $$ personAnschrift=4425 54832010-09-21 12:16:06.003 2010-09-21 12:16:36,583 INFO - $$ personAnschrift=4425 54822010-09-21 12:16:06.002 2010-09-21 12:16:36,583 INFO - $$ personAnschrift=4425 54812010-09-21 12:16:06.001 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release EJB 3.1 spec version 1.0.1
+1 Built from source and staged artifacts look good. -Donald On 9/13/10 8:34 AM, Rick McGuire wrote: This is a bug fix release to fix a couple of problems with the EJB embedded container support. The components up for vote are: org/apache/geronimo/specs/geronimo-ejb_3.1_spec/1.0.1/geronimo-ejb_3.1_spec-1.0.1-source-release.zip org/apache/geronimo/specs/geronimo-ejb_3.1_spec/1.0.1/geronimo-ejb_3.1_spec-1.0.1-source-release.tar.gz from the staging repository at: https://repository.apache.org/content/repositories/orgapachegeronimo-015/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-ejb_3.1_spec-1.0.1 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Rick
Re: svn commit: r997288 [1/2] - in /geronimo/sandbox/rick/serviceloader
Is the below really needed in the NOTICE file? +This product includes software developed by +The Object Management Group. + +Copyright (c) 1999-2000 Object Management Group. Unlimited rights to +duplicate and use this code are hereby granted provided that this +copyright notice is included. + +This product includes software developed by +The W3C Consortium (http://www.w3.org/). + +Copyright © 1994-2002 World Wide Web Consortium, +(Massachusetts Institute of Technology, Institut National +de Recherche en Informatique et en Automatique, Keio +University). All Rights Reserved. +http://www.w3.org/Consortium/Legal/ On 9/15/10 7:34 AM, rickmcgu...@apache.org wrote: +This product includes software developed by +The Object Management Group. + +Copyright (c) 1999-2000 Object Management Group. Unlimited rights to +duplicate and use this code are hereby granted provided that this +copyright notice is included. + +This product includes software developed by +The W3C Consortium (http://www.w3.org/). + +Copyright © 1994-2002 World Wide Web Consortium, +(Massachusetts Institute of Technology, Institut National +de Recherche en Informatique et en Automatique, Keio +University). All Rights Reserved. +http://www.w3.org/Consortium/Legal/
Re: [VOTE] release javamail 1.8.2 provider and mail components. (second attempt)
+1 Could build from source and staged jars look good. -Donald On 9/14/10 7:43 AM, Rick McGuire wrote: This is a bug fix release to fix a problem with the javamail smtp provider including the BCC recipients as a header in sent messages. The JIRA in question is https://issues.apache.org/jira/browse/GERONIMO-5587 This is a vote for the javamail providers and combined mail jar. This fix did not require an update to the javamail specs. . The 2 components up for vote are: org/apache/geronimo/javamail/geronimo-javamail_1.4/1.8.2/geronimo-javamail_1.4-1.8.2-source-release.tar.gz org/apache/geronimo/javamail/geronimo-javamail_1.4/1.8.2/geronimo-javamail_1.4-1.8.2-source-release.zip from the staging repository at: https://repository.apache.org/content/repositories/orgapachegeronimo-020/ The source repo is: https://svn.apache.org/repos/asf/geronimo/javamail/tags/geronimo-javamail_1.4-1.8.2/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Rick
Re: bad things that are happening when we perform a release using windows
Or is it simply that not everyone has updated their .subversion/config
with suggested values (to handle eol-style and autoprops) or that we're
missing svn props from some of our files?
-Donald
On 9/10/10 5:11 PM, Kevan Miller wrote:
In addition to the bad shell scripts in 2.1.6, I ran across the following
difference between branches/2.1 and tags/geronimo-2.1.6 (I ran across a
number of pom's with the same basic issue).
Would like to see release processes put in place that prevent these things
from happening in the future. In some instances, we probably force some of
our files to have Unix line endings (so people can build from a Windows svn
checkout). I'm also would be ok with requiring releases be run from
unix-style machines. I assume this would avoid issues like the following
pom.xml file...
Thoughts?
$ svn diff
https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.6/plugins/monitoring/mconsole-jetty/pom.xml
https://svn.apache.org/repos/asf/geronimo/server/branches/2.1/plugins/monitoring/mconsole-jetty/pom.xml
svn diff
https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.6/plugins/monitoring/mconsole-jetty/pom.xml
https://svn.apache.org/repos/asf/geronimo/server/branches/2.1/plugins/monitoring/mconsole-jetty/pom.xml
Index: pom.xml
===
--- pom.xml
(.../tags/geronimo-2.1.6/plugins/monitoring/mconsole-jetty/pom.xml)
(revision 995984)
+++ pom.xml (.../branches/2.1/plugins/monitoring/mconsole-jetty/pom.xml)
(revision 995984)
@@ -1,123 +1,123 @@
-?xml version=1.0 encoding=UTF-8?
-!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the License); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an AS IS BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
---
-
-!-- $Rev: 605412 $ $Date: 2007-12-18 19:58:03 -0800 (Tue, 18 Dec 2007) $ --
-
-project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
-
-modelVersion4.0.0/modelVersion
-
-parent
-groupIdorg.apache.geronimo.plugins.monitoring/groupId
-artifactIdmonitoring/artifactId
-version2.1.6/version
-/parent
-
-groupIdorg.apache.geronimo.plugins/groupId
-artifactIdmconsole-jetty/artifactId
-nameGeronimo Plugins, Monitoring :: Console (Jetty)/name
-packagingcar/packaging
-
-dependencies
-dependency
-groupIdorg.apache.geronimo.configs/groupId
-artifactIdjetty6-deployer/artifactId
-version${version}/version
-typecar/type
-scopeprovided/scope
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.configs/groupId
-artifactIdjasper-deployer/artifactId
-version${version}/version
-typecar/type
-scopeprovided/scope
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.configs/groupId
-artifactIdconnector-deployer/artifactId
-version${version}/version
-typecar/type
-scopeprovided/scope
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.plugins/groupId
-artifactIdmconsole-ds/artifactId
-version${version}/version
-typecar/type
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.plugins/groupId
-artifactIdconsole-jetty/artifactId
-version${version}/version
-typecar/type
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.plugins.monitoring/groupId
-artifactIdmconsole-war/artifactId
-version${version}/version
-typewar/type
-scopeprovided/scope
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.configs/groupId
-artifactIddojo-legacy-jetty6/artifactId
-version${version}/version
-typecar/type
-/dependency
-
-dependency
-
[jira] Commented: (GERONIMO-5228) Add classes for parsing a validation.xml descriptor
[ https://issues.apache.org/jira/browse/GERONIMO-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908877#action_12908877 ] Donald Woods commented on GERONIMO-5228: Do we just need to update our Spec API to be bundle aware and use the bundle context if we have one? Add classes for parsing a validation.xml descriptor --- Key: GERONIMO-5228 URL: https://issues.apache.org/jira/browse/GERONIMO-5228 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Affects Versions: 3.0 Reporter: Rick McGuire Assignee: David Jencks Fix For: 3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[ANNOUNCE] Welcome Xuan Dai Delos as a new Geronimo PMC member
Please join us in congratulating Delos as a new member of the Geronimo PMC. In addition to all his work on GEP and Samples, Delos also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratulation Delos !!! The Apache Geronimo PMC
[ANNOUNCE] Welcome Ming Xai Forrest as a new Geronimo PMC member
Please join us in congratulating Forrest as a new member of the Geronimo PMC. In addition to all his work on Samples, Forrest also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratulation Forrest !!! The Apache Geronimo PMC
Re: [ANNOUNCE] Welcome Rex Wang as a new member of the Geronimo PMC
Congrats Rex! -Donald On 9/7/10 9:00 AM, Rick McGuire wrote: Please join us in congratulating as a new member of the Geronimo PMC. In addition to serving as a release manager for the Geronimo 2.1.5 server release, Rex also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratuatlons Rex !!! The Apache Geronimo PMC
Re: Where is ValidatorFactoryBuilder interface?
Right, one area in the doc that needs updating... For Apache BVal, take a look at - bval-jsr303/src/main/java/org/apache/bval/jsr303/ConfigurationImpl.java Which can hold the constraint mappings as InputStreams and has public ValidatorFactory buildValidatorFactory() You can get a Validator with something like - javax.validation.Configuration configuration = Validation.byProvider( ApacheValidationProvider.class).configure(); Validator validator = configuration.buildValidatorFactory().getValidator(); Are you trying to build a Validator with a Configuration that uses a custom validation.xml? -Donald On 9/7/10 5:57 AM, Rick McGuire wrote: On 9/2/2010 5:33 PM, Vamsavardhana Reddy wrote: Section EE.5.16.2 of Java EE 6 specification says, For the benefit of implementors, we note that the Bean Validation API includes a ValidatorFactoryBuilder interface that can be used to create a ValidatorFactory configured according to the contents of a validation deployment descriptor in the form of a java.io.InputStream.. I don't see it in geronimo-validation_1.0_spec-1.1.jar. Where can I find this ValidatorFactoryBuilder? -- Vamsi The Bean Validation spec does not include ValidatorFactoryBuilder and it is also not part of the TCK. I suspect the mention on the Java EE 6 is obsolete. Rick
[jira] Commented: (GERONIMO-5553) Fail to enchance entities on Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905625#action_12905625 ] Donald Woods commented on GERONIMO-5553: Reply to the 8/30 questions about enhancer, which dup my 8/27 comments When a list of classes is handed to the javaagent, then it will only enhance those classes, but when no class list is given it will discover all classes to enhance. When the 1.6 JVM's Attach API is used (new in OpenJPA 2.0) to dynamically load the OpenJPA enhancer agent, then the class list is used AND any other classes to enhance are discovered unless exclude-unlisted-classes is specified in the PU. So, I'll opened OPENJPA-1780 to request that the javaagent behave the same as the dynamic loader Fail to enchance entities on Geronimo - Key: GERONIMO-5553 URL: https://issues.apache.org/jira/browse/GERONIMO-5553 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 3.0 Environment: OS:win xp Geronimo :3.0 20100824 build Reporter: Lu Jiang Assignee: Rick McGuire Fix For: 3.0 Attachments: booknew.war I tried to deploy a simple jpa sample on geronimo.But when persist data into database. Following exception will occur. openjpa-2.0.0-r422266:935683 nonfatal user error org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance org.apache.sample.entities.b...@97781f to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: org.apache.sample.entities.b...@97781f -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5553) Fail to enchance entities on Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903393#action_12903393 ] Donald Woods commented on GERONIMO-5553: I checked with Jeremy on the OpenJPA team yesterday and he agreed that the openjpa.RuntimeUnenhancedClasses property is ignored for the javaagent code and only used for dynamic runtime enhancement (subclassing), so setting that value in the EMF Map should not be required and is discouraged, as we tell OpenJPA users all the time NOT to use dynamic runtime enhancement. For the javaagent, classLoadEnhancement=true is the default, which controls whether OpenJPA load-time class enhancement should be available in this JVM execution. Starting in OpenJPA 2.0 - If a javaagent is not provided via the command line and OpenJPA is running on the Sun 1.6 SDK or IBM 1.6 JDK (SR8+), OpenJPA will attempt to dynamically load the runtime Enhancer. This support is provided as an ease of use feature and it is not recommended for use in a production system. Setting the property openjpa.DynamicEnhancementAgent to false will disable this function. When then dynamic enhancer is loaded, the following informational message is logged: [java] jpa.enhancement INFO [main] openjpa.Runtime - OpenJPA dynamically loaded the class enhancer. Any classes that were not enhanced at build time will be enhanced when they are loaded by the JVM. So, is another module (like a deployer, annotation scanner or Tomcat) possibly loading the classes before the OpenJPA GBean is being loaded and having a chance to register the TransformerAgent? Fail to enchance entities on Geronimo - Key: GERONIMO-5553 URL: https://issues.apache.org/jira/browse/GERONIMO-5553 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 3.0 Environment: OS:win xp Geronimo :3.0 20100824 build Reporter: Lu Jiang Assignee: Rick McGuire Fix For: 3.0 Attachments: booknew.war I tried to deploy a simple jpa sample on geronimo.But when persist data into database. Following exception will occur. openjpa-2.0.0-r422266:935683 nonfatal user error org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance org.apache.sample.entities.b...@97781f to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: org.apache.sample.entities.b...@97781f -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5553) Fail to enchance entities on Geronimo
[
https://issues.apache.org/jira/browse/GERONIMO-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903400#action_12903400
]
Donald Woods commented on GERONIMO-5553:
In geronimo-transformer, the TransformerWrapper class is commented out and no
longer used, but geronimo-persistence-jpa20 and geronimo-aries-jpa contains its
own implementation of TransformerWrapper, which only calls the transformer if
the provided classloader is an instance of BundleReference? Is that the right
behavior for geronimo-persistence-jpa20 for a WAR case, where it is not a
Bundle? Seems okay for the Aries case...
public byte[] transform(ClassLoader loader, String className, Class?
classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer)
throws IllegalClassFormatException {
if (loader instanceof BundleReference ((BundleReference)
loader).getBundle() == bundle) {
try {
return classTransformer.transform(loader, className,
classBeingRedefined, protectionDomain, classfileBuffer);
} catch (IllegalClassFormatException e) {
throw e;
} catch (RuntimeException e) {
return null;
}
}
return null;
}
Fail to enchance entities on Geronimo
-
Key: GERONIMO-5553
URL: https://issues.apache.org/jira/browse/GERONIMO-5553
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: persistence
Affects Versions: 3.0
Environment: OS:win xp
Geronimo :3.0 20100824 build
Reporter: Lu Jiang
Assignee: Rick McGuire
Fix For: 3.0
Attachments: booknew.war
I tried to deploy a simple jpa sample on geronimo.But when persist data into
database.
Following exception will occur.
openjpa-2.0.0-r422266:935683 nonfatal user error
org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance
org.apache.sample.entities.b...@97781f to PersistenceCapable failed.
Ensure that it has been enhanced.
FailedObject: org.apache.sample.entities.b...@97781f
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5553) Fail to enchance entities on Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903442#action_12903442 ] Donald Woods commented on GERONIMO-5553: OK, so this dual personality is really confusing... Looking back at ARIES-320, you added and them removed code to enable the javaagent support and instead in geronimo-aries-jpa created GeronimoManagedPersistenceUnitInfoFactory extends ManagedPersistenceUnitInfoFactoryImpl. How did this enable the javaagent for Aries apps??? Guess I'm wondering, if the app is being loaded as a bundle, is OpenJPA being loaded as a bundle? We have tons of places in OpenJPA where we're looking up classloaders, but only one place (broker factory creation) that we try to use the bundle context if available (which was OPENJPA-1491 for Aries.) So, if the OpenJPA transformer uses the bundle context, what is the runtime using and are we seeing two copies of the class, one enhanced and one not? Fail to enchance entities on Geronimo - Key: GERONIMO-5553 URL: https://issues.apache.org/jira/browse/GERONIMO-5553 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 3.0 Environment: OS:win xp Geronimo :3.0 20100824 build Reporter: Lu Jiang Assignee: Rick McGuire Fix For: 3.0 Attachments: booknew.war I tried to deploy a simple jpa sample on geronimo.But when persist data into database. Following exception will occur. openjpa-2.0.0-r422266:935683 nonfatal user error org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance org.apache.sample.entities.b...@97781f to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: org.apache.sample.entities.b...@97781f -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5553) Fail to enchance entities on Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903635#action_12903635 ] Donald Woods commented on GERONIMO-5553: Thanks Lin. I missed that. But, this was unexpected behavior for OpenJPA due to Geronimo using the javaagent, which only enhances the classes listed in the persistence.xml whereas the dynamic enhancer will find other classes to enhance unless exclude-unlisted-classes is specified. If no classes are specified, then all of the classes will get enhanced whether the dynamic or javaagent methods are used. So, we have a difference in enhancement behavior here Fail to enchance entities on Geronimo - Key: GERONIMO-5553 URL: https://issues.apache.org/jira/browse/GERONIMO-5553 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 3.0 Environment: OS:win xp Geronimo :3.0 20100824 build Reporter: Lu Jiang Assignee: Rick McGuire Fix For: 3.0 Attachments: booknew.war I tried to deploy a simple jpa sample on geronimo.But when persist data into database. Following exception will occur. openjpa-2.0.0-r422266:935683 nonfatal user error org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance org.apache.sample.entities.b...@97781f to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: org.apache.sample.entities.b...@97781f -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-5553) Fail to enchance entities on Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-5553: -- Assignee: Donald Woods Fail to enchance entities on Geronimo - Key: GERONIMO-5553 URL: https://issues.apache.org/jira/browse/GERONIMO-5553 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 3.0 Environment: OS:win xp Geronimo :3.0 20100824 build Reporter: Lu Jiang Assignee: Donald Woods Fix For: 3.0 Attachments: booknew.war I tried to deploy a simple jpa sample on geronimo.But when persist data into database. Following exception will occur. openjpa-2.0.0-r422266:935683 nonfatal user error org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance org.apache.sample.entities.b...@97781f to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: org.apache.sample.entities.b...@97781f -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5553) Fail to enchance entities on Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902980#action_12902980 ] Donald Woods commented on GERONIMO-5553: I decompiled your org.apache.sample.entities.Book.class and did not see that it had been enhanced. In OpenJPA 2.0, we have turned RuntimeUnenhancedClasses off/unsupported by default (it was enabled in 1.0 and 1.2) - http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/manual.html#openjpa.RuntimeUnenhancedClasses To enable runtime enhancement (which we strongly discourage for production applications), you need to update your persistence.xml to set the following property - properties property name=openjpa.RuntimeUnenhancedClasses value=supported/ . . . /properties The better solution, is to use build time enhancement, which can be done via ANT, Maven plugin or Eclipse plugin - http://openjpa.apache.org/entity-enhancement.html Fail to enchance entities on Geronimo - Key: GERONIMO-5553 URL: https://issues.apache.org/jira/browse/GERONIMO-5553 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 3.0 Environment: OS:win xp Geronimo :3.0 20100824 build Reporter: Lu Jiang Fix For: 3.0 Attachments: booknew.war I tried to deploy a simple jpa sample on geronimo.But when persist data into database. Following exception will occur. openjpa-2.0.0-r422266:935683 nonfatal user error org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance org.apache.sample.entities.b...@97781f to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: org.apache.sample.entities.b...@97781f -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5553) Fail to enchance entities on Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903001#action_12903001 ] Donald Woods commented on GERONIMO-5553: Agree, the Javaagent code should work no matter what RuntimeUnenhancedClasses is set to. After more digging, in 2.1.5 we used - JAVA_AGENT_JAR=$GERONIMO_HOME/bin/jpa.jar but in 3.0, we are using - JAVA_AGENT_JAR=$GERONIMO_HOME/lib/agent/transformer.jar and there is no jpa.jar anywhere to be found. So, the real question is, where did jpa.jar go and how do we register OpenJPA with framework/modules/geronimo-transformer/src/main/java/org/apache/geronimo/transformer/TransformerAgent.java ? Fail to enchance entities on Geronimo - Key: GERONIMO-5553 URL: https://issues.apache.org/jira/browse/GERONIMO-5553 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 3.0 Environment: OS:win xp Geronimo :3.0 20100824 build Reporter: Lu Jiang Assignee: Donald Woods Fix For: 3.0 Attachments: booknew.war I tried to deploy a simple jpa sample on geronimo.But when persist data into database. Following exception will occur. openjpa-2.0.0-r422266:935683 nonfatal user error org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance org.apache.sample.entities.b...@97781f to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: org.apache.sample.entities.b...@97781f -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-5553) Fail to enchance entities on Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-5553: -- Assignee: Rick McGuire (was: Donald Woods) Both of these are registering transformers - openjpa2/geronimo-aries-jpa/src/main/java/org/apache/geronimo/aries/jpa/GeronimoPersistenceUnitInfo.java openjpa2/geronimo-persistence-jpa20/src/main/java/org/apache/geronimo/persistence/PersistenceUnitGBean.java So, are all WAR files being turned into WAB files and run as OSGi bundles in 3.0? If so, then using JPA in WAR files is going to require Aries and the geronimo-aries-jpa code, which knows about bundle context, while the normal geronimo-persistence-jpa20 code has no knowledge of bundles and how to access their classloaders??? Fail to enchance entities on Geronimo - Key: GERONIMO-5553 URL: https://issues.apache.org/jira/browse/GERONIMO-5553 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 3.0 Environment: OS:win xp Geronimo :3.0 20100824 build Reporter: Lu Jiang Assignee: Rick McGuire Fix For: 3.0 Attachments: booknew.war I tried to deploy a simple jpa sample on geronimo.But when persist data into database. Following exception will occur. openjpa-2.0.0-r422266:935683 nonfatal user error org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance org.apache.sample.entities.b...@97781f to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: org.apache.sample.entities.b...@97781f -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [discuss]Web profile assemblies
Sounds right. Thanks for looking at this. -Donald On 8/23/10 2:37 PM, Lin Sun wrote: Ok, thanks, I'll take your recommendation and keep both. :) I just removed the webservices-common and webservices-builder. We still need geronimo-webservices module since it is used by geronimo-tomcat whenever user requests to retrieve to see the wsdl via http and the work is delegated to the geronimo-webservices. So in additional to the base web profile, I think we added the following support: javamail connector javaee management/deployment jaspic (currently in) jacc Did the above sound right to people? Lin On Mon, Aug 23, 2010 at 6:10 AM, Rick McGuire rick...@gmail.com wrote: On 8/20/2010 4:36 PM, Lin Sun wrote: It seems hard to remove javamail given openejb depends on it. At least for the javamail schema for JNDI, which is used by the openejb-client. Also, I don't quite understand this comment in G roomt pom.xml - !-- Use org.apache.geronimo.javamail/geronimo-javamail_1.4_mail uber jar containing both the spec and the providers in order that users can actually use mail without advanced degrees in geronimo classloading. DO NOT add or replace this with org.apache.geronimo.specs/geronimo-javamail_1.4_spec -- dependency groupIdorg.apache.geronimo.javamail/groupId artifactIdgeronimo-javamail_1.4_mail/artifactId version1.8.1/version /dependency This seems to indicate that it is recommended to have java mail spec and impl together as dependency, instead of just using the spec jar. The uber jar is required in order for the Geronimo mail component to work correctly, since it configures the various transport implementations. If that is removed, it might be possible to revert to just the spec jar, but I think I'd recommend against it because it makes it more difficult to incrementally add the full javamail support back in. Rick Lin 1. whether we keep jaspi and javamail in web profile assembly? I personally would say no, but open to opinions.
Re: [discuss]Web profile assemblies
We need connector, TranQL and RAs for OpenJPA -Donald On 8/20/10 2:29 PM, Lin Sun wrote: Ok, regarding tranql RAs, the derby ones are pulled in by system-database. The other RAs are pulled in as part of the db-connectors plugin which is part of the eba-tomcat plugin group. I think we are fine to keep these RAs in, if we want to support these different dbs like db2, oracle, sql server, etc in our web profile assembly. Lin 2. tranql: i cannot think of a reason why these resource adapters are needed for web profile... I can see geronimo-connector are needed but not the RAs. Maybe people who knows more about tranql could comment on this? Anything else I missed on this topic? Thanks Lin On Fri, Aug 20, 2010 at 11:30 AM, Jarek Gawor jga...@gmail.com wrote: On Fri, Aug 20, 2010 at 10:09 AM, Lin Sun linsun@gmail.com wrote: Hi I am checking at our web profile assemblies to ensure it met the requirements for Java EE 6 web profile and prune the unnecessary artifacts. I've been mainly look at the tomcat7-javaee6-web and I have some comments/questions: felix core: i assume we'll always ship 2 osgi runtime? Yep, that's the plan. connector (geronimo-connector, geronimo-connector-builder, connector spec): I think openejb uses connector, so we may have to keep it in. java ee management 1.1: Unchanged from Java EE 5. I assume this is provided by geronimo-management. Not sure if we could remove this? java ee deployment 1.2 related: Unchanged from Java EE 5. we may have to keep it in, to keep existing deployment work. geronimo-javamail: can we get rid of it? think the answer is yes. Maybe. Might be nicer to include it. geronimo-jaspi: can we get rid of it? think the answer is yes. Maybe. Might be nicer to include it. geronimo-webservices, geronimo-webservices-builder: think we could remove these. Yes, i think so. geronimo-yoko, yoko: think we could remove these. spec jars: we seems to include all specs in web profile assembly. things that can be removed: aspic, jaxr, jaxrpc, jaxws, dims, saaj, ccpp? I don't think this is very important. A lot of specs have dependencies on each other. So this might be a mess to sort it all out. I think we should be able to include them all even though we don't provide all of that functionality. At runtime an user should see an error that a given provider is not found. mina: think we could remove it... not sure which web profile function it related to. It's not related to web profile. It used so one can remotely login to Karaf/Geronimo shell. So this should be totally ok. ops4j, pax-loggin-api, pax-url-mvn, pax-url-wrap: think these are just test dependencies that were put into the assembly incorrectly. Again, not related to web profile. And these are used at runtime. We need them. Expect maybe pax-url-wrap. tranql: think we could remove it. openejb: anything we could do so that we can just have the ejb-lite function? pluto/portal: I assume these are needed for admin console so we need it. Right. Shouldn't matter for web profile. Jarek
Re: [VOTE] Release new geronimo-annotation_1.1 1.0.1 and geronimo-jaxb_2.2 1.0.1 spec versions
+1 Both artifact source passed rat:check, built from source, contain LICENSE/NOTICE files in the jars and have signatures. -Donald On 8/18/10 7:08 AM, Rick McGuire wrote: These are bug fix releases to fix problems in the common annotation and jaxb spec bundles. The common annotations bundle included a package (javax.annotation.processing) that is not part of the common annotations specification. This package is part of the base Java SE 6 support, so this has been removed from the common annotations jar. https://issues.apache.org/jira/browse/GERONIMO-5529 The jaxb update has a workaround for a problem in the Sun jaxb impl. Details can be found here: https://issues.apache.org/jira/browse/GERONIMO-5500 This is a single vote for both spec updates. Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-123/ The source repos are: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-annotation_1.1_spec-1.0.1 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jaxb_2.2_spec-1.0.1 Rick
Re: Setup instructions for the standalone tcks?
Moving to dev@ list since we're discussing the public ASL 2.0 licensed TCKS Yep, but nothing in the wiki yet for the public TCKs Just build the top level projects first, which builds some integration artifacts: cd geronimo/tck/branches/3.0/ mvn clean install Then run either BVAL or JCDI TCKs - cd validator-tck-runner mvn test -Pincontainer,geronimo-assembly -DassemblyId=tomcat7-javaee6 or mvn test -Pincontainer -Dgeronimo.home=/Users/x/geronimo/trunk/assemblies/. -Donald On 8/18/10 10:21 AM, Jarek Gawor wrote: For the standalone tcks, in each 'runner' directory I put a README.TXT file that describes how to the given tck. I hope it was kept it up-to-date. Jarek On Wed, Aug 18, 2010 at 8:53 AM, Rick McGuire rick...@gmail.com wrote: Are there any setup instructions for configuring/running the different standalone tcks? Rick
Re: Setup instructions for the standalone tcks?
There is only one failing test when the BVAL TCK is run inside the Tomcat7-JavaEE6 assembly, which I'll get back to looking at once I get a OpenJPA 2.0.1 release candidate out... -Donald On 8/18/10 3:40 PM, Lin Sun wrote: Hi Does anyone know the latest test status of these standalone TCKs? I am building my G 3.0 server and intend to run these TCKs one by one, except the at-inject-tck and the jcdi-tck. The at-inject tck doesn't need a full G server and it all pass now. From what I heard, the jcdi-tck isn't ready to run yet. Thanks, Lin On Wed, Aug 18, 2010 at 12:35 PM, Donald Woods dwo...@apache.org wrote: Moving to dev@ list since we're discussing the public ASL 2.0 licensed TCKS Yep, but nothing in the wiki yet for the public TCKs Just build the top level projects first, which builds some integration artifacts: cd geronimo/tck/branches/3.0/ mvn clean install Then run either BVAL or JCDI TCKs - cd validator-tck-runner mvn test -Pincontainer,geronimo-assembly -DassemblyId=tomcat7-javaee6 or mvn test -Pincontainer -Dgeronimo.home=/Users/x/geronimo/trunk/assemblies/. -Donald On 8/18/10 10:21 AM, Jarek Gawor wrote: For the standalone tcks, in each 'runner' directory I put a README.TXT file that describes how to the given tck. I hope it was kept it up-to-date. Jarek On Wed, Aug 18, 2010 at 8:53 AM, Rick McGuire rick...@gmail.com wrote: Are there any setup instructions for configuring/running the different standalone tcks? Rick
Re: [DISCUSSION] How to detect status of server instance?
Will file locking work across all OS and filesystem combinations reliably? Wondering about Windows/exFAT and Unix/NFS shares Another way is to use *.pid files to hold the server process id or something like *.rmi or *.jmx files to denote the ports that servers are listening on. Maybe building something into the Felix shell to track instances would be another solution? -Donald On 8/17/10 9:37 PM, Delos wrote: 2010/8/17 Delos dait...@gmail.com mailto:dait...@gmail.com For some reasons, we often need to know if there is a running server instance. By establishing a connection to a specific port such as 1099, we may get the status of server. However, the method doesn't work if default port number is changed, especially in multi-instances scenario. In multi-instances scenario, we hope to know if any instance is running. Below is my thoughts about the solution. Any comments or suggestions, please feel free to tell me. It will be appreciated if any better solution could be provided. Possible solution: We may create flag file for each instance and lock the file with FileChannel.lock() when a server instance is starting up. It will be unlocked and deleted when the server is stopped. Unlocking will be automatically done when JVM exits; deleting the file can be done in shutdown hook in FrameworkLauncher.launch(). In this way, if any flag file has been locked, we may deduce that there is at least one running server instance; if no locked files found, we may think all server instances are stopped. We can put all the flag files in a same directory for us to track. -- Best Regards, Delos -- Best Regards, Delos
Re: [VOTE] maven-plugins 1.1 for Geronimo Eclipse Plugin (2nd try)
+1 source-release passed rat:check and was able to build it on Mac with Maven 2.2.1 and 1.6.0_20. -Donald On 8/10/10 10:42 PM, Delos wrote: 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
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 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: 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]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: [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: 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
Re: svn commit: r983551 - Possible NPE in MergeHelper now?
Seeing a deployment failure on Tomcat assemblies when trying to run the stand-alone BVAL TCK and was wondering if it was related to the below changes, since a NPE is occurring in MergeHelper.java now? 2010-08-10 17:19:09,565 WARN [TomcatModuleBuilder] Web application . does not c ontain a WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, depending on whether you have things like resource references that need to be resolved. You can also give the deployer a separate deployment plan file on the command line. 2010-08-10 17:19:10,849 ERROR [Deployer] Deployment failed due tojava.lang.NullPointerException at org.apache.geronimo.web25.deployment.merge.MergeHelper.saveOrderedLibAttribute(MergeHelper.java:563) at org.apache.geronimo.web25.deployment.merge.MergeHelper.relativeOrderWebFragments(MergeHelper.java:479) at org.apache.geronimo.web25.deployment.merge.MergeHelper.sortWebFragments(MergeHelper.java:555) at org.apache.geronimo.web25.deployment.merge.MergeHelper.processWebFragmentsAndAnnotations(MergeHelper.java:378) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.basicInitContext(AbstractWebModuleBuilder.java:464) . . . Deployer operation failed: java.lang.NullPointerException org.apache.geronimo.common.DeploymentException: java.lang.NullPointerExceptionat org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:284) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:138) at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source) 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(Refl ectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.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) . . . On 8/9/10 4:18 AM, xuhaih...@apache.org wrote: Author: xuhaihong Date: Mon Aug 9 08:18:04 2010 New Revision: 983551 URL: http://svn.apache.org/viewvc?rev=983551view=rev Log: Ignore the mapping configurations from web-fragment.xml and annotations while they are configured in web.xml. Modified: geronimo/server/trunk/plugins/j2ee/geronimo-web-2.5-builder/src/main/java/org/apache/geronimo/web25/deployment/AbstractWebModuleBuilder.java geronimo/server/trunk/plugins/j2ee/geronimo-web-2.5-builder/src/main/java/org/apache/geronimo/web25/deployment/merge/webfragment/FilterMappingMergeHandler.java geronimo/server/trunk/plugins/j2ee/geronimo-web-2.5-builder/src/main/java/org/apache/geronimo/web25/deployment/merge/webfragment/FilterMergeHandler.java geronimo/server/trunk/plugins/j2ee/geronimo-web-2.5-builder/src/main/java/org/apache/geronimo/web25/deployment/merge/webfragment/ServletMappingMergeHandler.java geronimo/server/trunk/plugins/j2ee/geronimo-web-2.5-builder/src/main/java/org/apache/geronimo/web25/deployment/merge/webfragment/ServletMergeHandler.java Modified: geronimo/server/trunk/plugins/j2ee/geronimo-web-2.5-builder/src/main/java/org/apache/geronimo/web25/deployment/AbstractWebModuleBuilder.java URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/j2ee/geronimo-web-2.5-builder/src/main/java/org/apache/geronimo/web25/deployment/AbstractWebModuleBuilder.java?rev=983551r1=983550r2=983551view=diff == --- geronimo/server/trunk/plugins/j2ee/geronimo-web-2.5-builder/src/main/java/org/apache/geronimo/web25/deployment/AbstractWebModuleBuilder.java (original) +++ geronimo/server/trunk/plugins/j2ee/geronimo-web-2.5-builder/src/main/java/org/apache/geronimo/web25/deployment/AbstractWebModuleBuilder.java Mon Aug 9 08:18:04 2010 @@ -51,7 +51,6 @@ import org.apache.geronimo.components.ja import org.apache.geronimo.components.jaspi.model.JaspiXmlUtil; import org.apache.geronimo.components.jaspi.model.ServerAuthConfigType; import org.apache.geronimo.components.jaspi.model.ServerAuthContextType; -import org.apache.geronimo.deployment.ClassPathUtils; import org.apache.geronimo.deployment.ModuleIDBuilder; import org.apache.geronimo.deployment.NamespaceDrivenBuilder; import org.apache.geronimo.deployment.NamespaceDrivenBuilderCollection; Modified: geronimo/server/trunk/plugins/j2ee/geronimo-web-2.5-builder/src/main/java/org/apache/geronimo/web25/deployment/merge/webfragment/FilterMappingMergeHandler.java URL:
Re: Apache Tuscany Logo in Geronimo Wiki
Just noticed the following autoexport logging when trying to run an autoexport of the OpenJPA space - [Fri Aug 06 14:51:10 EDT 2010] Exporting: - null [key=OPENEJBGMOxSITEOPENEJBx30=GMOxDEV] where when exporting a single space you would expect to see - [Fri Aug 06 14:51:54 EDT 2010] Exporting: - OpenJPA [key=openjpa] Wonder if that explains some of our earlier problems, where there are multiple auto exports trying to run simultaneously due to space updates -Donald On 7/7/10 3:08 PM, Joe Bohn wrote: OK, it looks like doing a manual export fixed all of the links again for now. But since we still don't really understand what is causing this or how to fix it (as I mentioned earlier manual export didn't fix it a few weeks ago) ... then I don't know when it will happen again or for certain how we can resolve it. This is just strange. Joe On 7/7/10 2:54 PM, Joe Bohn wrote: Actually, I think all of the GMOxDOC30 and GMOxDOC21 doc has/had the Tuscany logo (not just the clustering page). It seems that most of the GMOxDOC22 doc is clean with the exception of the clustering-and-farming link that you mention and perhaps some others (I didn't look at all the pages ;-) ). I did spend some time looking into this a few weeks back for 3.0 but didn't find a cause or solution at the time. Here's what I tried: - Validating the the export template for the space hadn't been corrupted. It looked OK to me and matched what we have in svn. - Forced an update of the template with what we saved in svn (even though they looked the same) - didn't help. - Forced a minor change to the template in confluence - also didn't help. - Moved the license header below the macros - Donald mentioned that this may have fixed it when he looked into it earlier - but it didn't fix anything when I tried it. - I also posted a question on infra@ about it but didn't get any responses. I ran out of ideas and gave up. However, after seeing this I thought I'd try to force an export again and see if anything changed. I tried it for 3.0 and to my surprise it seems to have fixed that one. I'll try on the others as well. This leads me to think that it is somehow timing related based upon Tuscany exports ... but I really don't have a clue. Does anybody else have any ideas? Joe On 7/7/10 12:59 PM, Kevan Miller wrote: On Jun 2, 2010, at 5:44 AM, chi runhua wrote: G2.2 don't have the problem and I think we could just apply the changes we made to G2.2 for G2.1 doc space . There are still parts of our Wiki documentation that still have the Tuscany logo. See: https://cwiki.apache.org/GMOxDOC30/clustering-and-farming.html https://cwiki.apache.org/GMOxDOC22/clustering-and-farming.html https://cwiki.apache.org/GMOxDOC21/clustering.html If somebody can help get these cleaned up, that would be great. --kevan
Re: [VOTE] maven-plugins 1.1 for Geronimo Eclipse Plugins
+1 Passed rat:check, built tag with 1.6.0_20, jar contains required License/Notice files. -Donald On 7/27/10 10:15 AM, Delos wrote: Hi all, Hope you're not surprised at this voting. Actually, I have discussed it with Kevan and Donald. 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. https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-658 Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-030/ 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
Re: [VOTE] External tomcat-parent-6.0.29.0
+1 Was able to build the tag and the jars looked like they have the required License/Notice files. -Donald On 7/23/10 7:28 AM, Delos wrote: This voting is for mavenized tomcat 6.0.29. Following what we did to tomcat 6.0.20, we are using a forked copy of tomcat derived from the tomcat 6.0.29 release, built with maven, with maven dependencies, etc etc. Besides, we also applied some patches which haven't been included in tomcat 6.0.29. Based on tomcat 6.0.29 tag, I also applied another couple of patches: GERONIMO-3451 'Restricted listeners property file not found' error logged during Tomcat server startup GERONIMO-4685 Include patches for revision #790742 Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-028/ svn tag at: http://svn.apache.org/repos/asf/geronimo/external/tags/tomcat-parent-6.0.29.0/ [ ] +1 go for it [ ] 0 [ ] -1 whoa, hold on a minute Vote open 72 hours thanks a lot! -- Best Regards, Delos
Re: JCDI and Bean Validation TCKs
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. Sounds good. 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? I'd mirror the current layout with branches/3.0/ -Donald 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
Latest OpenJPA trunk updates
As of r966020, the OpenJPA trunk (2.1.0-SNAPSHOT) now has the following long sought after improvements - OPENJPA-1732 LogFactory adapter for SLF4J Now, the SLF4J API can be used by setting openjpa.Log=slf4j and including the required slf4-api and backend adapter on the classpath. OPENJPA-1735 Mark commons-logging as provided in the build to remove transient maven dependency Now, users of openjpa-2.1.0-SNAPSHOT.jar no longer need to include a dependency exclusion for commons-logging. Enjoy! Donald
Re: svn commit: r964521 - /geronimo/server/trunk/plugins/jetty8/pom.xml
Note - this will cause a build failure until someone has a chance to look at the geronimo-jetty code - [INFO] Compilation failure /Users/drwoods/geronimo/server-trunk/plugins/jetty8/geronimo-jetty8/src/main/java/org/apache/geronimo/jetty8/WebAppContextWrapper.java:[229,21] cannot find symbol symbol : method setInitParams(java.util.Mapjava.lang.String,java.lang.String) location: class org.apache.geronimo.jetty8.handler.GeronimoWebAppContext On 7/15/10 2:22 PM, dwo...@apache.org wrote: Author: dwoods Date: Thu Jul 15 18:22:35 2010 New Revision: 964521 URL: http://svn.apache.org/viewvc?rev=964521view=rev Log: upgrade to released Jetty 8.0.0.M1 until M2-SNAPSHOT is available Modified: geronimo/server/trunk/plugins/jetty8/pom.xml Modified: geronimo/server/trunk/plugins/jetty8/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/jetty8/pom.xml?rev=964521r1=964520r2=964521view=diff == --- geronimo/server/trunk/plugins/jetty8/pom.xml (original) +++ geronimo/server/trunk/plugins/jetty8/pom.xml Thu Jul 15 18:22:35 2010 @@ -34,7 +34,7 @@ /description properties -jettyVersion8.0.0.M1-SNAPSHOT/jettyVersion +jettyVersion8.0.0.M1/jettyVersion /properties dependencyManagement @@ -135,4 +135,4 @@ /profile /profiles -/project \ No newline at end of file +/project
Re: ${project.version} is a problem..
That's the expected behavior, in that ${project.version} is the current
module's version and not that of it's parent. If you need the parent's
version, then yes, we need a property like geronimoVersion.
-Donald
On 7/13/10 10:56 PM, Rex Wang wrote:
Hi,
I suggest we stop using ${project.version} in 3.0's pom.
This maven variable will magicly change when I create a new sub-project
which has it own version.
For example,
When I create a new server assembly abc under the assemblies project,
and the abc's pom has it own version 3.0.0.0 http://3.0.0.0:
parent
groupIdorg.apache.geronimo.assemblies/groupId
artifactIdassemblies/artifactId
version3.0-M1/version
/parent
groupIdc.i.w.assemblies/groupId
artifactIdabc/artifactId
version3.0.0.0/version
packagingserver-assembly/packaging
Then, in its effective pom, maven will replace all the
${project.version} defined in parent pom with 3.0.0.0
I think we use ${geronimoVersion} instead and specify geronimoVersion
explicitly in root pom.
Thoughts?
--
Lei Wang (Rex)
rwonly AT apache.org http://apache.org
Re: Question about geronimoHome configuration in geronimo-maven-plugin
You could also set it as a property in the pom, like -
properties
geronimoHome${project.build.outputDirectory}/geronimoHome
/properties
which allows users to override it either in settings.xml or on the
command line. In your case, you could define a profile in settings.xml
that sets geronimoHome for your specific machine and then enable it when
building, like -
mvn clean install -Pg30home
Including hard-coded paths in poms is not a best practice, unless you
allow users to override it. Otherwise, we are adding profiles that are
specific to each user's machine and making the pom harder to maintain...
-Donald
On 7/14/10 12:54 AM, Shawn Jiang wrote:
You could use optionSets to add your customized properties.
1, add optionSets to your geronimo-maven-plugin configuration
plugin
groupIdorg.apache.geronimo.buildsupport/groupId
artifactIdgeronimo-maven-plugin/artifactId
configuration
optionSets
optionSet
idmoreMemory/id
options
option-XX:MaxPermSize=256m/option
option-XX:+HeapDumpOnOutOfMemoryError/option
option-enableassertions/option
/options
/optionSet
optionSet
idghome/id
options
option-DgeronimoHome=/home/genspring/geronimo222-SNAPSHOT
/option
option-DXXX=XXX
/option
/options
/optionSet
/optionSets
/configuration
/plugin
2, add -Doptions=xxx when do the mvn build to active the option set.
mvn clean install -Doptions=ghome
On Wed, Jul 14, 2010 at 11:20 AM, viola lu viola.lu
http://viola.lu@gmail.com http://gmail.com wrote:
From geronimo-maven-plugin site doc, it described that if i want to
run a customized geornimo server, i can run command:
mvn geronimo:start-server -DgeronimoHome=[$dir_geronimo-server]
but i want to define geronimoHome in pom.xml not in command, how to
configure geronimo-maven-plugin?
The way below is possible?thanks in advance!
plugin
groupIdorg.apache.geronimo.plugins/groupId
artifactIdgeronimo-maven-plugin/artifactId
configuration
geronimoHomec:\server1\/geroninomHome
/configuration
/plugin
--
viola
--
Shawn
Re: [VOTE] Release new versions of the Geronimo bundle components
+1 Was able to build all 6 from their tags and each passed rat:check. Note: The version on woodstox has an extra _1 and should be listed as woodstox-4.0.6_1. -Donald On 7/13/10 10:43 AM, Rick McGuire wrote: To allow the Geronimo trunk release to upgrade the some of the components used by the server, I'd like release new versions of some of the Geronimo bundle components. This components are versions of external Geronimo dependencies that have been converted into OSGi jars. This is a single vote for multiple upgraded bundles used by the Geronimo 3.0 trunk branch. The RAT and IANAL plugins have been run against of the projects. All tag svn versions have been successfully built. Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-056/ All source repos are relative to location https://svn.apache.org/repos/asf/geronimo/bundles/tags and have the same final element as the artifact name. The following components are being voted on (the bundles-parent has already been promoted): aspectjrt-1.6.8_1 aspectjweaver-1.6.8_1 derby-all-10.6.1.0_1 sxc-jaxb-0.7.3_1 sxc-runtime-0.7.3_1 woodstox-4.0.6_1_1
Re: ${project.version} is a problem..
I see this as a common use case, where users want to build their own
assemblies, but want ONE place to change the Geronimo version they are
using (as using scopeimport/scope doesn't resolve this for every
case anymore.) Heck, we even use this method for our TCK builds.
-Donald
On 7/14/10 12:31 PM, David Jencks wrote:
On Jul 13, 2010, at 7:56 PM, Rex Wang wrote:
Hi,
I suggest we stop using ${project.version} in 3.0's pom.
This maven variable will magicly change when I create a new
sub-project which has it own version.
For example,
When I create a new server assembly abc under the assemblies
project, and the abc's pom has it own version 3.0.0.0 http://3.0.0.0/:
parent
groupIdorg.apache.geronimo.assemblies/groupId
artifactIdassemblies/artifactId
version3.0-M1/version
/parent
groupIdc.i.w.assemblies/groupId
artifactIdabc/artifactId
version3.0.0.0/version
packagingserver-assembly/packaging
Then, in its effective pom, maven will replace all the
${project.version} defined in parent pom with 3.0.0.0
I think we use ${geronimoVersion} instead and specify geronimoVersion
explicitly in root pom.
Thoughts?
I think this is a really bad idea. In your example above, you should
not have the explicit version version3.0.0.0/version
Generally, if you want a different version for a particular project, put
the project in a different tree without a file system parent pom. There
are a few special cases like the bundles even those probably
shouldn't have a file system parent pom (not actually sure if they do
right now).
thanks
david jencks
--
Lei Wang (Rex)
rwonly AT apache.org http://apache.org/
Re: [VOTE] Geronimo Eclipse Plugin 2.1.6 RC1
+1 Was able to build the tag on Win7 (but not Mac as with GEP 3.0.0) and rat:check returned some hits that can be ignored (can we backport the excludes list from trunk to ignore all of the .* Eclipse files?) -Donald On 7/8/10 10:12 AM, Delos wrote: Hi all, Please review and vote on the release of the Geronimo Eclipse Plugin 2.1.6 *RC1*. GEP 2.1.6 supports Geronimo server 2.1.6 and Eclipse 3.6. *Note*: Now, GEP 2.1.6 can only build on Windows and Linux, but fail to build on Mac. Because eclipse 3.6 no longer support carbon and maven-eclipsepde-plugin doesn't support new cocoa package, GEP can't build successfully on Mac until a new maven-eclipsepde-plugin is released. It's not a problem of GEP itself, so I think it's not a big issue blocking the release. Please see GERONIMODEVTOOLS-649 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-649 for details. The source code zip is here: _https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/devtools/geronimo-eclipse-plugin/2.1.6/geronimo-eclipse-plugin-2.1.6-source-release.tar.gz_ _https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/devtools/geronimo-eclipse-plugin/2.1.6/geronimo-eclipse-plugin-2.1.6-source-release.zip_ The deployable zip file is here: _http://people.apache.org/builds/geronimo/eclipse/2.1.6/geronimo-eclipse-plugin-2.1.6-deployable.zip_ The update site zip file is here: _http://people.apache.org/builds/geronimo/eclipse/2.1.6/geronimo-eclipse-plugin-2.1.6-updatesite.zip_ http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC2/staging_site/geronimo-eclipse-plugin-2.2.0-updatesite.zip The tag is here: http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/geronimo-eclipse-plugin-2.1.6/ If you would like to review and/or comment on the release notes, they are here: http://people.apache.org/builds/geronimo/eclipse/updates/PLUGIN_RELEASE-NOTES-2.1.6.txt Finally, I've created a Staging Site that can be used to test the update manager functions (i.e., p2 in Halios or Galileo) of Eclipse for downloading the GEP itself. http://people.apache.org/builds/geronimo/eclipse/updates/ Please let me know if there are any questions and/or problems. -- Best Regards, Delos
Re: [VOTE] Geronimo Eclipse Plugin 3.0M1 - second try
+1 Was able to build the tag on Win7, use the built update site to install GEP into a clean Eclipse 3.5.2 using Java 1.6.0 and start/stop a Geronimo 3.0-M1 Tomcat assembly. Some thoughts - I don't like how we add a new Download menu in the Eclipse IDE, considering the Download Servers option is available when creating a new Server runtime and the link to the OSGi tools is only applicable to 3.6 users. -Donald On 7/6/10 12:18 PM, Delos wrote: Hi everyone, Please review and vote on the release of the Geronimo Eclipse Plugin 3.0M1 *RC2*. *Note*: Now, GEP 3.0M1 can only build on Windows and Linux, but fail to build on Mac. Because eclipse 3.6 no longer support carbon and maven-eclipsepde-plugin doesn't support new cocoa package, GEP can't build successfully on Mac until a new maven-eclipsepde-plugin is released. It's not a problem of GEP itself, so I think it's not a big issue blocking the release. Please see GERONIMODEVTOOLS-649 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-649 for details. The source code zip is here: https://repository.apache.org/content/repositories/orgapachegeronimo-039/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0_M1/geronimo-eclipse-plugin-3.0_M1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-039/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0_M1/geronimo-eclipse-plugin-3.0_M1-source-release.zip The deployable zip file is here: http://people.apache.org/builds/geronimo/eclipse/3.0M1/geronimo-eclipse-plugin-3.0_M1-deployable.zip The update site zip file is here: http://people.apache.org/builds/geronimo/eclipse/3.0M1/geronimo-eclipse-plugin-3.0_M1-updatesite.zip http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC2/staging_site/geronimo-eclipse-plugin-2.2.0-updatesite.zip The tag is here: http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/geronimo-eclipse-plugin-3.0_M1/ If you would like to review and/or comment on the release notes, they are here: http://people.apache.org/builds/geronimo/eclipse/3.0M1/PLUGIN_RELEASE-NOTES-3.0_M1.txt Finally, I've created a Staging Site that can be used to test the update manager functions (i.e., p2 in Halios or Galileo) of Eclipse for downloading the GEP itself. http://people.apache.org/builds/geronimo/eclipse/updates/ Please let me know if there are any questions and/or problems. -- Best Regards, Delos
Re: [VOTE] Release Geronimo Samples 3.0-M1 -- Third Attempt
+1 Was able to build the tag on my Mac w/ 1.6.0_20 and it passed mvn rat:check. -Donald On 7/1/10 1:29 PM, Forrest Xia wrote: Hi All, A release candidate for Geronimo Samples 3.0-M1 has been created and staged. This release includes these samples which works with Geronimo 3.0-M1: 1. Java EE 5 samples * dbtester * inventory * ldap-sample-app * timereport * jsp-examples * servlet-examples 2. Java EE 6 samples * cviewer-javaee6 * converter-javaee6 * jarresource-javaee6 * fileupload-javaee6 3. OSGi samples * aries-datasource 4. Daytrader * daytrader-web-jdbc * daytrader-web-jpa The tag has been created here: https://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-3.0-M1/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-025/ https://repository.apache.org/content/repositories/orgapachegeronimo-029/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-029/org/apache/geronimo/samples/samples-parent/3.0-M1/samples-parent-3.0-M1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-029/org/apache/geronimo/samples/samples-parent/3.0-M1/samples-parent-3.0-M1-source-release.zip A sample plugin catalog file is prepared for your convenience: http://geronimo.apache.org/plugins/samples-3.0-M1/ The vote will be last for 72 hours. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Forrest
Re: [Discussion] Time to release an updated maven-eclipsepde-plugin?
+1 Sounds like needed updates. -Donald On 7/9/10 4:37 AM, Delos wrote: As part of GEP, maven-eclipsepde-plugin helps to convert eclipse plugins to maven dependencies and add them into artifact dependency list. So without it, GEP can't be compiled successfully. The plugin is in version 1.0. But now, some new requirements come out that the plugin didn't take into account before. I'm afraid we have to update the plugin to accommodate new requirements. 1) Eclipse on Mac There are two edition of eclipse on Mac, carbon and cocoa. From Eclipse 3.6, only cocoa is supported. But maven-eclipsepde-plugin can only recognize carbon eclipse on Mac, so we have to fix it to make GEP build successfully on Mac. You may see details in 2)Optional bundles There are some optional required bundles in MANIFEST.MF for some extended functions, such as TPTP and Free Aires Tools. They're not mandatory for GEP and actually GEP don't need these bundles in build process. They're marked as optional because user may get these extra plugins by themselves for some advanced functions. So these optional bundles shouldn't block the build process of GEP. Unfortunately, current maven-eclipsepde-plugin does block GEP build process because of these optional bundles. Because of these new requirements, I suggest we release an updated maven-eclipsepde-plugin with version 1.1. Any objection? -- Best Regards, Delos
Re: [VOTE] Release Geronimo 2.1.6 - second attempt.
Has the voting finished? I didn't see a [RESULTS] reply yet... -Donald On 6/23/10 5:24 AM, Rick McGuire wrote: A release candidate for Geronimo 2.1.6 has been created and staged. This version is the same as the previous release candidate except for an upgrade to the spring framework dependency. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.6 The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-008 The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.zip The distribution artifacts have been copied to a second staging repository for your convenience: http://people.apache.org/~rickmcguire/staging-repo/2.1.6/ We have to verify the binaries pass the tck, so the vote may be open for longer than the 72-hour minimum. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Rick
Re: [VOTE] Release Geronimo Samples 3.0-M1
One file failed the mvn rat:check - geronimo-samples-archetype/src/main/resources/archetype-resources/sample-war/src/main/webapp/WEB-INF/geronimo-web.xml which is missing the ASL header -Donald On 6/30/10 3:05 AM, Forrest Xia wrote: Hi All, A release candidate for Geronimo Samples 3.0-M1 has been created and staged. This release includes these samples which works with Geronimo 3.0-M1: 1. Java EE 5 samples * dbtester * inventory * ldap-sample-app * timereport * jsp-examples * servlet-examples 2. Java EE 6 samples * cviewer-javaee6 * converter-javaee6 * jarresource-javaee6 * fileupload-javaee6 3. OSGi samples * aries-datasource 4. Daytrader * daytrader-web-jdbc * daytrader-web-jpa The tag has been created here: https://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-3.0-M1/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-025/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-022/org/apache/geronimo/samples/samples-parent/3.0-M1/samples-parent-3.0-M1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-025/org/apache/geronimo/samples/samples-parent/3.0-M1/samples-parent-3.0-M1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-025/org/apache/geronimo/samples/samples-parent/3.0-M1/samples-parent-3.0-M1-source-release.zip A sample plugin catalog file is prepared for your convenience: http://geronimo.apache.org/plugins/samples-3.0-M1/ The vote will be last for 72 hours. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Forrest
Re: [VOTE] Geronimo Eclipse Plugin 3.0M1 RC1
-1 Could not build on MacOSX, as the referenced file no longer exists - file=/technology/epp/downloads/release/helios/R/eclipse-jee-helios-macosx-carbon.tar.gz Looks like we need to use the following 32bit Mac download instead in eclipse/build.xml - property name=helios_jee_macos value=eclipse-jee-helios-macosx-cocoa.tar/ property name=helios_jee_macos-x86_64 value=eclipse-jee-helios-macosx-cocoa-x86_64.tar/ Also, I had to specify specific mirrors to use (like AWS) as the local mirror didn't have the Helios files on it yet -Donald On 7/1/10 8:26 AM, Delos wrote: Hi everyone, Please review and vote on the release of the Geronimo Eclipse Plugin 3.0M1 *RC1*. The source code zip is here: https://repository.apache.org/content/repositories/orgapachegeronimo-027/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0_M1/geronimo-eclipse-plugin-3.0_M1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-027/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0_M1/geronimo-eclipse-plugin-3.0_M1-source-release.zip The deployable zip file is here: http://people.apache.org/builds/geronimo/eclipse/3.0M1/geronimo-eclipse-plugin-3.0M1-deployable.zip The update site zip file is here: http://people.apache.org/builds/geronimo/eclipse/3.0M1/geronimo-eclipse-plugin-3.0M1-updatesite.zip http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC2/staging_site/geronimo-eclipse-plugin-2.2.0-updatesite.zip The tag is here: http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/geronimo-eclipse-plugin-3.0_M1/ If you would like to review and/or comment on the release notes, they are here: http://people.apache.org/builds/geronimo/eclipse/3.0M1/PLUGIN_RELEASE-NOTES-3.0M1.txt Finally, I've created a Staging Site that can be used to test the update manager functions (i.e., p2 in Halios or Galileo) of Eclipse for downloading the GEP itself. http://people.apache.org/builds/geronimo/eclipse/updates/ Please let me know if there are any questions and/or problems. -- Best Regards, Delos
Re: [VOTE] Geronimo Eclipse Plugin 3.0M1 RC1
Also, the build ended up failing after I patched my local
eclipse/build.xml -
[INFO]
[INFO] Building org.apache.geronimo.st.ui
[INFO]task-segment: [clean, install]
[INFO]
. . .
[INFO] Installing
/Users/drwoods/.m2/repository/eclipse/eclipse/plugins/org.eclipse.wst.server.ui_1.1.203.v20100601.jar
to
/Users/drwoods/.m2/repository/org/eclipse/plugins/org.eclipse.wst.server.ui/1.1.203-v20100601/org.eclipse.wst.server.ui-1.1.203-v20100601.jar
[INFO] SWTFragment: Dependency {groupId=org.eclipse.plugins,
artifactId=org.eclipse.swt.carbon.macosx, version=null, type=jar}
[ERROR] Bundle for dependency not found: org.eclipse.swt.carbon.macosx
. . .
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] An invalid artifact was detected.
This artifact might be in your project's POM, or it might have been
included transitively during the resolution process. Here is the
information we do have for this artifact:
o GroupID: org.eclipse.plugins
o ArtifactID: org.eclipse.swt.carbon.macosx
o Version: MISSING
o Type:jar
[INFO]
[INFO] Trace
org.apache.maven.artifact.InvalidArtifactRTException: For artifact
{org.eclipse.plugins:org.eclipse.swt.carbon.macosx:null:jar}: The
version cannot be empty.
at
org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147)
at
org.apache.maven.artifact.DefaultArtifact.init(DefaultArtifact.java:122)
On 7/1/10 10:39 AM, Donald Woods wrote:
-1
Could not build on MacOSX, as the referenced file no longer exists -
file=/technology/epp/downloads/release/helios/R/eclipse-jee-helios-macosx-carbon.tar.gz
Looks like we need to use the following 32bit Mac download instead in
eclipse/build.xml -
property name=helios_jee_macos
value=eclipse-jee-helios-macosx-cocoa.tar/
property name=helios_jee_macos-x86_64
value=eclipse-jee-helios-macosx-cocoa-x86_64.tar/
Also, I had to specify specific mirrors to use (like AWS) as the local
mirror didn't have the Helios files on it yet
-Donald
On 7/1/10 8:26 AM, Delos wrote:
Hi everyone, Please review and vote on the release of
the Geronimo Eclipse Plugin 3.0M1 *RC1*.
The source code zip is here:
https://repository.apache.org/content/repositories/orgapachegeronimo-027/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0_M1/geronimo-eclipse-plugin-3.0_M1-source-release.tar.gz
https://repository.apache.org/content/repositories/orgapachegeronimo-027/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0_M1/geronimo-eclipse-plugin-3.0_M1-source-release.zip
The deployable zip file is here:
http://people.apache.org/builds/geronimo/eclipse/3.0M1/geronimo-eclipse-plugin-3.0M1-deployable.zip
The update site zip file is here:
http://people.apache.org/builds/geronimo/eclipse/3.0M1/geronimo-eclipse-plugin-3.0M1-updatesite.zip
http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC2/staging_site/geronimo-eclipse-plugin-2.2.0-updatesite.zip
The tag is here:
http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/geronimo-eclipse-plugin-3.0_M1/
If you would like to review and/or comment on the release notes, they
are here:
http://people.apache.org/builds/geronimo/eclipse/3.0M1/PLUGIN_RELEASE-NOTES-3.0M1.txt
Finally, I've created a Staging Site that can be used to test the update
manager functions (i.e., p2 in Halios or Galileo) of Eclipse for
downloading the GEP itself.
http://people.apache.org/builds/geronimo/eclipse/updates/
Please let me know if there are any questions and/or problems.
--
Best Regards,
Delos
Re: [VOTE] Release Geronimo Samples 3.0-M1
No vote, just a discussion point - Since this was created from a 3.0-M1 branch, I don't agree with keeping all of the sample source in the release, when only a subset is being built and released. Seems that this will only confuse users who want to build the Samples from source. -Donald On 6/29/10 4:58 AM, Forrest Xia wrote: Hi All, A release candidate for Geronimo Samples 3.0-M1 has been created and staged. This version includes these samples which works with Geronimo 3.0-M1: 1. Java EE 5 samples * dbtester * inventory * ldap-sample-app * timereport * jsp-examples * servlet-examples 2. Java EE 6 samples * cviewer-javaee6 * converter-javaee6 * jarresource-javaee6 * fileupload-javaee6 3. OSGi samples * aries-datasource Note that I do not remove those unreleased samples from the svn tree, and want to keep it there for future updates. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-3.0-M1/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-022/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.tar.gzhttps://repository.apache.org/content/repositories/orgapachegeronimo-022/org/apache/geronimo/samples/samples-parent/3.0-M1/samples-parent-3.0-M1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-022/org/apache/geronimo/samples/samples-parent/3.0-M1/samples-parent-3.0-M1-source-release.zip A sample plugin catalog file is prepared for your convenience: http://geronimo.apache.org/plugins/samples-3.0-M1/ The vote will be last for 72 hours. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Forrest
Re: Anyone could help add me access to Apache Geronimo confluence?
Done. I added both ids to the geronimo-committers group in Confluence. -Donald On 6/29/10 4:34 AM, Forrest Xia wrote: Hi, I am doing samples release and will need to update the Apache Geronimo confluence project to add some news. But my two confluence IDs(xiaming and forres...@gmail.com mailto:forres...@gmail.com) do not have write access to the project? So anyone could help to add? Request write access to https://cwiki.apache.org/confluence/display/GMOxSITE My confluence ID: xiaming Thanks! Forrest
Re: [VOTE] Release Geronimo 2.1.6 - second attempt.
+1 Was able to build the tag and start the Tomcat JEE5 server. -Donald On 6/23/10 5:24 AM, Rick McGuire wrote: A release candidate for Geronimo 2.1.6 has been created and staged. This version is the same as the previous release candidate except for an upgrade to the spring framework dependency. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.6 The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-008 The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.zip The distribution artifacts have been copied to a second staging repository for your convenience: http://people.apache.org/~rickmcguire/staging-repo/2.1.6/ We have to verify the binaries pass the tck, so the vote may be open for longer than the 72-hour minimum. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Rick
Re: About G Samples 3.0-M1 release
OK, then we should create a 3.0-M1 branch for the Samples and start removing ones that will not work. -Donald On 6/23/10 9:08 AM, Forrest Xia wrote: On Tue, Jun 22, 2010 at 10:01 PM, Donald Woods dwo...@apache.org mailto:dwo...@apache.org wrote: We should create the required datasource plugins for the Aries Blog, along with plugin wrappers for Blog and AriesTrade to make it easier to install. I will try that, but not so confident if the 3.0-M1 car-maven-plugin allows to do that. We also have some patches over in OpenJPA for Daytrader to use the new JPA 2.0 Criteria API, but not sure how we want to integrate those yet... Can we have a patch against the daytrader in samples trunk? and I will try to merge it into the samples. As far as removing unsupported Samples, we are releasing the full JavaEE6 assemblies in M1 (web profile assemblies were added to trunk after the M1 branch was created), so as long as the samples work on that assembly, I don't see why we should only provide Web Profile samples. Unfortunately, G 3.0-M1 is lack of EAR support, most of Java EE 5 samples won't work on it. Even for the javaee6 category, only 4 of 9 samples works so far. I know there are lot of other features that G 3.0-M1 implemented but not demod via the current samples set. It let us know there are more work to do on the samples and testsuite aspect. I will try keep working on them. Forrest
Re: About G Samples 3.0-M1 release
We should create the required datasource plugins for the Aries Blog, along with plugin wrappers for Blog and AriesTrade to make it easier to install. We also have some patches over in OpenJPA for Daytrader to use the new JPA 2.0 Criteria API, but not sure how we want to integrate those yet... As far as removing unsupported Samples, we are releasing the full JavaEE6 assemblies in M1 (web profile assemblies were added to trunk after the M1 branch was created), so as long as the samples work on that assembly, I don't see why we should only provide Web Profile samples. -Donald On 6/21/10 10:17 PM, Forrest Xia wrote: Hi all, Since G 3.0-M1 is released, I will do a release for samples. When I am doing this, I have these things to discuss here: 1. For the current samples in the trunk, we've have some Java EE 6 samples ready, but no OSGi samples yet. My thought is to use available Aries samples directly, including AriesTrader and Blog, and I will update the samples document about how to run the Aries samples on the 3.0-M1 release. 2. Since 3.0-M1 is a web profile only release, some of old java ee 5 and java ee 6 samples won't work, do we release the ones which now does not work? Any thoughts? Forrest
Re: [RESULT][VOTE] Geronimo 3.0-M1 release - 3rd attempt
Believe you meant Kevan Miller and Donald Woods... :-) -Donald On 6/18/10 7:57 AM, Rick McGuire wrote: The Vote passes with 4.5 +1 votes and no 0 or -1 votes. Voting for the release were Rick McGuire Jarek Gawor Kevan Woods Donald Wood Joe Bohn Thank you for the time spent reviewing this. The release artifacts will be promoted and made available for download ASAP. Rick On 6/9/2010 4:13 PM, Rick McGuire wrote: A new 3.0-M1 release candidate is ready for review. The LICENSE problem has been corrected and the missed testsuite updates that Jarek noticed have been included. See the JIRA issues here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315090styleName=TextprojectId=10220 Staged to https://repository.apache.org/content/repositories/orgapachegeronimo-046/ The main artifacts up for vote are the source release archives https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.tar.gz If you vote you should at least examine these and make sure something plausible builds from them. The voting will be open a minimum of 72 hours. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Rick
Re: [VOTE] Release Geronimo 2.1.6
+1 Was able to build the tag and start the JEE5 Tomcat assembly. A few minor issues, but nothing requiring another release: - Copyright dates in Welcome app and Console not updated to 2010 - Welcome App shows an Embedded Tomcat @VERSION@ - RELEASE_NOTES.txt was the only RAT failure -Donald On 6/18/10 12:31 PM, Rick McGuire wrote: A release candidate for Geronimo 2.1.6 has been created and staged. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.6/ https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.5/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-001/ https://repository.apache.org/content/repositories/orgapachegeronimo-005/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-001/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/geronimo/2.1.5/geronimo-2.1.5-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-001/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/geronimo/2.1.5/geronimo-2.1.5-source-release.zip The distribution artifacts have been copied to a second staging repository for your convenience: http://people.apache.org/~rickmcguire/staging-repo/2.1.6/ We have to verify the binaries pass the tck, so the vote may be open for longer than the 72-hour minimum. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Rick
Re: [DISCUSSION] change 2.2 branch build JDK from 6 to 5
I'd be fine with requiring Java SE 6 for 2.2.1 and follow-on releases. -Donald On 6/16/10 10:40 PM, Shawn Jiang wrote: We should change the 2.2 build JDK from 6 to 5 because we can't start the server with jdk 5 if we build 2.2 branch with jdk 6. See [1] for more background. Jarek, I remember that you are owner of the geronimo build system. Can you help do that ? [1]https://issues.apache.org/jira/browse/GERONIMO-5369 -- Shawn
Re: [Discussion] How to display help informations on the Console
Another choice for #7 would be to include/reuse index tags in the Docs (like #CreateDataSource) which the console could then launch a browser to a Google search of our geronimo.a.o domain, along with including the release tag (GMOxDoc22), so maybe the 2.2 doc search results would be first in the results You'd probably want to write some script/code that could examine the console source and cross-check against the wiki to validate all the expected tags are there. -Donald On 6/16/10 10:49 PM, chi runhua wrote: Thanks for the comments, please find my input inlines. On Mon, Jun 14, 2010 at 10:29 PM, Bill Stoddard wgstodd...@gmail.com mailto:wgstodd...@gmail.com wrote: On 6/14/10 10:01 AM, Donald Woods wrote: #1-3 are good usability improvements. Can we use Dojo for #4-6? Seems hover help would be the best option, as adding an example beside/below every field could require a lot of screen area and doesn't cover the cases for links (like Start/Stop/Restart/Delete). Also, the portlet help page should include the same text as the hoover help (which should be the same resource strings), plus additional help text if needed. Agree~! #7 requires us to stop reorganizing the User Docs and would mean we couldn't rename pages. If we go this route, we should include a hidden comment on each doc page with a reference back to the portlet that has a link to it, so we know not to rename the page unless the portlet link is updated too. Connecting the documentation and console will be expensive to maintain. As a general principle, I would suggest carefully weighing the 'opportunity cost' of adding new features to the server that require on-going maintenance. Each added feature that requires on-going maintenance takes time away from other potentially more important work. Over time as more 'on-going' maintenance requirements accumulate, the development team spends more and more effort to just tending to the maintenance; less time is spent on innovation and keeping current with technology trends. Bill Agree~!. An alternative of #7 is to provide the linkage to doc index page instead of matching the exact page on the top panel of doc. But in the code level, we could define different keys for different portlets for future improvements. All those keys use the same value for each release, for example: For 2.2, use https://cwiki.apache.org/GMOxDOC22/ For 3.0, use https://cwiki.apache.org/GMOxDOC30/ The alternative provides the users a short-cut to Geronimo doc site from console and possibilities to implement #7 for exact match. Jeff
Re: [DISCUSSION] change 2.2 branch build JDK from 6 to 5
I thought there was an earlier discussion about some component using new security features of Java SE 6, but can't find that thread now Maybe Shawn can give more details as to why we should consider the move. -Donald On 6/17/10 12:26 PM, Kevan Miller wrote: On Jun 17, 2010, at 11:33 AM, Rick McGuire wrote: On 6/17/2010 11:20 AM, Donald Woods wrote: I'd be fine with requiring Java SE 6 for 2.2.1 and follow-on releases. Is that even allowed by the Java EE 5 certification rules? Yes, but I don't think it really matters. I don't think we have any real motivation to move to Java 6 -- there aren't Java 6 features that we're planning on taking advantage of... It's simply someone built on Java 6 and found that they had problems subsequently running on Java 5. IMO, we should be building on Java 5 (maintaining support for Java 5), if users want to run on Java 6, that's fine... --kevan
Re: [DISCUSSION] change 2.2 branch build JDK from 6 to 5
OK, just found GERONIMO-5369 and it turns out not to be an issue, so lets stay with SE 5 for 2.2. -Donald On 6/17/10 12:26 PM, Kevan Miller wrote: On Jun 17, 2010, at 11:33 AM, Rick McGuire wrote: On 6/17/2010 11:20 AM, Donald Woods wrote: I'd be fine with requiring Java SE 6 for 2.2.1 and follow-on releases. Is that even allowed by the Java EE 5 certification rules? Yes, but I don't think it really matters. I don't think we have any real motivation to move to Java 6 -- there aren't Java 6 features that we're planning on taking advantage of... It's simply someone built on Java 6 and found that they had problems subsequently running on Java 5. IMO, we should be building on Java 5 (maintaining support for Java 5), if users want to run on Java 6, that's fine... --kevan
Re: [VOTE] Geronimo 3.0-M1 release - 3rd attempt
On 6/15/10 11:33 PM, Joe Bohn wrote: Here's my +1 as well ... but I did notice a few strange things that I don't think have been pointed out yet: Perhaps the most annoying thing is that we aren't including the tranql connector rars in server images as with previous releases. I guess this isn't a big concern because they should be available via other means - just a bit annoying. Yep, I fixed that in trunk. I also noticed a dependency management entry in the root pom for a geronimo bundle of axiom (at a SNAPSHOT version). This doesn't actually exist but it seems that it isn't causing any build issues either. I was able to build fine and I ran one of the EBA samples in the tomcat assembly. Joe On 6/9/10 4:13 PM, Rick McGuire wrote: A new 3.0-M1 release candidate is ready for review. The LICENSE problem has been corrected and the missed testsuite updates that Jarek noticed have been included. See the JIRA issues here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315090styleName=TextprojectId=10220 Staged to https://repository.apache.org/content/repositories/orgapachegeronimo-046/ The main artifacts up for vote are the source release archives https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.tar.gz If you vote you should at least examine these and make sure something plausible builds from them. The voting will be open a minimum of 72 hours. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Rick
Re: [Discussion] How to display help informations on the Console
#1-3 are good usability improvements. Can we use Dojo for #4-6? Seems hover help would be the best option, as adding an example beside/below every field could require a lot of screen area and doesn't cover the cases for links (like Start/Stop/Restart/Delete). Also, the portlet help page should include the same text as the hoover help (which should be the same resource strings), plus additional help text if needed. #7 requires us to stop reorganizing the User Docs and would mean we couldn't rename pages. If we go this route, we should include a hidden comment on each doc page with a reference back to the portlet that has a link to it, so we know not to rename the page unless the portlet link is updated too. -Donald On 6/13/10 4:53 AM, chi runhua wrote: Hi devs, I noticed that there are 2 different styles to display help information on the Admin Console: a. Using help.jsp when coding and you can only see it after clicking the question mark on the top-right corner of the portlet, meanwhile, you lose the focus but can come back after another click -; for example EJB Server portlet b. Put the help message on the portlet together with those fields, users can refer to the description and input the correct value at the same time, which is more clear and efficient, such as database pool wizard. But if there are lots of fields on the panel, the UI could be a mess and overwhelming. What about we try to unify the style of help infos and improving it in the coming CE 3.0? Here are a few of thoughts for discussion: 1. For the fields requires user selection, they should have a default value ready; 2. Labels must be consistent across the console; 3. For each portlet, we should have a description directly on the top to summarize its major features; 4. For the fields requires user input, an example should be provided right below instead of its detailed description; 5. For checkboxes, we should use hover help to introduce its usage; 6. For the description of each field, use help.jsp when coding, but we should use pop-up panel; 7. Document should be connected with the console more closely, for example, users can refer to document about tasks related to the current portlet instantly instead of googling by themselves. Any comments? Jeff C
Re: svn commit: r954158 - in /geronimo/server/trunk: framework/configs/karaf-framework/pom.xml pom.xml
Is this on the public repos yet? The 3.0 server build just failed for a web profile TCK run. -Donald On 6/12/10 11:40 PM, ga...@apache.org wrote: Author: gawor Date: Sun Jun 13 03:40:04 2010 New Revision: 954158 URL: http://svn.apache.org/viewvc?rev=954158view=rev Log: use bundlerepository 1.6.4 under vote Modified: geronimo/server/trunk/framework/configs/karaf-framework/pom.xml geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/framework/configs/karaf-framework/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/framework/configs/karaf-framework/pom.xml?rev=954158r1=954157r2=954158view=diff == --- geronimo/server/trunk/framework/configs/karaf-framework/pom.xml (original) +++ geronimo/server/trunk/framework/configs/karaf-framework/pom.xml Sun Jun 13 03:40:04 2010 @@ -41,7 +41,7 @@ depends.maven.plugin.version1.0/depends.maven.plugin.version easymock.version2.4/easymock.version equinox.version3.5.1.v20090827/equinox.version - felix.bundlerepository.version1.6.3-SNAPSHOT/felix.bundlerepository.version + felix.bundlerepository.version1.6.4/felix.bundlerepository.version felix.compendium.version1.2.0/felix.compendium.version felix.configadmin.version1.2.4/felix.configadmin.version felix.fileinstall.version3.0.0/felix.fileinstall.version Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=954158r1=954157r2=954158view=diff == --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Sun Jun 13 03:40:04 2010 @@ -1838,7 +1838,7 @@ only found in cxf dependency groupIdorg.apache.felix/groupId artifactIdorg.apache.felix.bundlerepository/artifactId -version1.6.3-SNAPSHOT/version +version1.6.4/version exclusions exclusion groupIdorg.apache.felix/groupId @@ -2363,6 +2363,19 @@ only found in cxf repositories repository +idbundlerepo/id +namebundlerepo/name +layoutdefault/layout + urlhttps://repository.apache.org/content/repositories/orgapachefelix-049/url +snapshots +enabledfalse/enabled +/snapshots +releases +enabledtrue/enabled +/releases +/repository + +repository !-- org.eclipse.jetty routing -- idjetty.oss.sonatype.org/id nameJetty Repository/name
Re: Release new javamail components -- second attempt
+1 Built both artifacts from source. Jars contained correct looking License/Notice files. RAT returned some hits, but they were not new files and were mostly for provider and test files. Can we get some excludes added for future releases? -Donald On 6/11/10 6:57 AM, Rick McGuire wrote: This is a bug fix release to fix a major problem with using the javamail code on EBCDIC-based platforms. The JIRA in question is https://issues.apache.org/jira/browse/GERONIMO-5326 The second attempt version also corrects the Java 5 compilation errors encountered with the first attempt. This is a single vote for new versions of the javamail spec, providers, and mail uber-jar. The 3 components up for vote are: geronimo-javamail_1.4_spec-1.7.1 geronimo-javamail_1.4_provider-1.8.1 geronimo-javamail_1.4_mail-1.8.1 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-048/ The source repos are: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.4_spec-1.7.1 https://svn.apache.org/repos/asf/geronimo/javamail/tags/geronimo-javamail_1.4-1.8.1 Rick
Re: [VOTE] Geronimo 3.0-M1 release - 3rd attempt
+1 as I think the below issues are acceptable for a milestone release.
Was able to build the tag and start the Tomcat Java EE 6 server.
-Donald
On 6/10/10 4:29 PM, Jarek Gawor wrote:
+0.5
M1 is affected by GERONIMO-5336. All services will most likely bind to
the local loopback device instead of all network devices so you won't
be able to access the console, etc. remotely. That can be fixed by
setting the ServerHostname property to 0.0.0.0 in
var/config/config-substitutions.properties file and also changing the
following in var/config/config.xml:
attribute name=ServerUrltcp://${ServerHostname}:${ActiveMQPort +
PortOffset}/attribute
to
attribute name=ServerUrltcp://localhost:${ActiveMQPort +
PortOffset}/attribute
Otherwise, without the second change an exception will be generated at
server startup by the activemq plugin.
M1 also seems to be affected by GERONIMO-5334. But I only see that
error from time to time.
Jarek
On Wed, Jun 9, 2010 at 4:13 PM, Rick McGuire rick...@gmail.com wrote:
A new 3.0-M1 release candidate is ready for review. The LICENSE problem has
been corrected and the missed testsuite updates that Jarek noticed have been
included.
See the JIRA issues here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315090styleName=TextprojectId=10220
Staged to
https://repository.apache.org/content/repositories/orgapachegeronimo-046/
The main artifacts up for vote are the source release archives
https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.zip
https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.tar.gz
If you vote you should at least examine these and make sure something
plausible builds from them.
The voting will be open a minimum of 72 hours.
[ ] +1 about time to push this out the door
[ ] 0 no opinion
[ ] -1 not this one (please explain why)
Rick
Re: [VOTE] Geronimo 3.0-M1 release - 3rd attempt
Those versions on Mac
What problem did you encounter? Did you run the bootstrap build first?
mvn install -Dstage=bootstrap
mvn install
-Donald
On 6/11/10 12:33 PM, Vamsavardhana Reddy wrote:
Donald,
I am unable to build the tag starting with an empty maven repo. I tried
with Maven-2.2.1 as well as Maven-3.0-beta1. I am using Sun JDK
1.6.0_20. Which version of Sun JDK and Maven have you used to build the
tag?
On Fri, Jun 11, 2010 at 5:43 PM, Donald Woods dwo...@apache.org
mailto:dwo...@apache.org wrote:
+1 as I think the below issues are acceptable for a milestone release.
Was able to build the tag and start the Tomcat Java EE 6 server.
-Donald
On 6/10/10 4:29 PM, Jarek Gawor wrote:
+0.5
M1 is affected by GERONIMO-5336. All services will most likely bind to
the local loopback device instead of all network devices so you won't
be able to access the console, etc. remotely. That can be fixed by
setting the ServerHostname property to 0.0.0.0 in
var/config/config-substitutions.properties file and also changing the
following in var/config/config.xml:
attribute name=ServerUrltcp://${ServerHostname}:${ActiveMQPort +
PortOffset}/attribute
to
attribute name=ServerUrltcp://localhost:${ActiveMQPort +
PortOffset}/attribute
Otherwise, without the second change an exception will be generated at
server startup by the activemq plugin.
M1 also seems to be affected by GERONIMO-5334. But I only see that
error from time to time.
Jarek
On Wed, Jun 9, 2010 at 4:13 PM, Rick McGuire rick...@gmail.com
mailto:rick...@gmail.com wrote:
A new 3.0-M1 release candidate is ready for review. The LICENSE
problem has
been corrected and the missed testsuite updates that Jarek
noticed have been
included.
See the JIRA issues here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315090styleName=TextprojectId=10220
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315090styleName=TextprojectId=10220
Staged to
https://repository.apache.org/content/repositories/orgapachegeronimo-046/
The main artifacts up for vote are the source release archives
https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.zip
https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.tar.gz
If you vote you should at least examine these and make sure something
plausible builds from them.
The voting will be open a minimum of 72 hours.
[ ] +1 about time to push this out the door
[ ] 0 no opinion
[ ] -1 not this one (please explain why)
Rick
--
Vamsi
Re: svn commit: r953208 - in /geronimo/server/branches/2.2: framework/configs/ framework/configs/client-system/ plugins/ plugins/client/ plugins/client/client-security/ plugins/client/client/ plugin
It can go either way. Most of the time, we expect plugin providers to
update their CAR builds to add in the new server releases (see
geronimo/plugins/openjpa2/). Ideally, the Samples would be released
with every server release, but we have never done that in the past, but
it is something we need to start doing.
If you add artifact-alias entries so the server can support older
Samples, then I'm afraid this will become a maintenance problem, as you
may also need to add in mappings to handle upgraded levels of Jetty,
Tomcat, OpenEJB, OpenJPA, Then the question becomes, how many
intra-release levels do you support? Only 2.2 plugins working on 2.2.1
or any 2.2.x plugins working on all future levels of 2.2.x forever. I'm
really against this scenario, as it greatly complicates creating new
maintenance releases, as you have to go in and find/add new alias
entries after every release.
-Donald
On 6/9/10 11:42 PM, Ivan wrote:
I am not sure whether we really need to keep the old plugins work in the
new Geronimo release. Do we have corresponding samples for the new release ?
e.g. between different releases, there maybe GBean signatures changes,
so the serialized data will not work correctly.
2010/6/10 xiam...@apache.org mailto:xiam...@apache.org
Author: xiaming
Date: Thu Jun 10 03:22:19 2010
New Revision: 953208
URL: http://svn.apache.org/viewvc?rev=953208view=rev
http://svn.apache.org/viewvc?rev=953208view=rev
Log:
GERONIMO-5373 Make 2.2 samples plugins work on G 2.2.1, though only
part of samples plugins works after this change.
Modified:
geronimo/server/branches/2.2/framework/configs/client-system/pom.xml
geronimo/server/branches/2.2/framework/configs/pom.xml
geronimo/server/branches/2.2/plugins/client/client-security/pom.xml
geronimo/server/branches/2.2/plugins/client/client/pom.xml
geronimo/server/branches/2.2/plugins/client/pom.xml
geronimo/server/branches/2.2/plugins/connector/client-transaction/pom.xml
geronimo/server/branches/2.2/plugins/corba/client-corba-yoko/pom.xml
geronimo/server/branches/2.2/plugins/pom.xml
Modified:
geronimo/server/branches/2.2/framework/configs/client-system/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/branches/2.2/framework/configs/client-system/pom.xml?rev=953208r1=953207r2=953208view=diff
http://svn.apache.org/viewvc/geronimo/server/branches/2.2/framework/configs/client-system/pom.xml?rev=953208r1=953207r2=953208view=diff
==
---
geronimo/server/branches/2.2/framework/configs/client-system/pom.xml
(original)
+++
geronimo/server/branches/2.2/framework/configs/client-system/pom.xml
Thu Jun 10 03:22:19 2010
@@ -207,6 +207,7 @@
config-xml-content load=false /
artifact-alias server=client
key=org.apache.geronimo.framework/j2ee-system//carorg.apache.geronimo.framework/client-system/${version}/car/artifact-alias
artifact-alias server=client
key=org.apache.geronimo.framework/j2ee-system/${version}/carorg.apache.geronimo.framework/client-system/${version}/car/artifact-alias
+artifact-alias server=client
key=org.apache.geronimo.framework/j2ee-system/2.2/carorg.apache.geronimo.framework/client-system/${version}/car/artifact-alias
/plugin-artifact
/instance
Modified: geronimo/server/branches/2.2/framework/configs/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/branches/2.2/framework/configs/pom.xml?rev=953208r1=953207r2=953208view=diff
http://svn.apache.org/viewvc/geronimo/server/branches/2.2/framework/configs/pom.xml?rev=953208r1=953207r2=953208view=diff
==
--- geronimo/server/branches/2.2/framework/configs/pom.xml (original)
+++ geronimo/server/branches/2.2/framework/configs/pom.xml Thu Jun
10 03:22:19 2010
@@ -85,6 +85,7 @@
source-repository${PluginSrcRepoCentral}/source-repository
source-repository${PluginSrcRepoApacheSnapshots}/source-repository
artifact-alias
key=${groupId}/${artifactId}//car${groupId}/${artifactId}/${version}/car/artifact-alias
+artifact-alias
key=${groupId}/${artifactId}/2.2/car${groupId}/${artifactId}/${version}/car/artifact-alias
/plugin-artifact
/commonInstance
/configuration
Modified:
geronimo/server/branches/2.2/plugins/client/client-security/pom.xml
URL:
Re: svn commit: r953250 - in /geronimo/server/branches/2.1/repository/org/apache: axis2/ axis2/axis2-kernel/1.3-G20090406/ ws/ ws/commons/ ws/commons/axiom/ ws/commons/axiom/axiom-api/ ws/commons/axio
But we're going to instruct existing 2.1.x users to copy it over the
existing jars in the server repository, right? Or are we going to
instruct them to create an artifact-alias entry to map all usage to the
new one (which may not work in all cases)?
-Donald
On 6/10/10 9:10 AM, Rick McGuire wrote:
Ashish,
I think there are a couple of changes that need to be made for this update:
1) Since we're likely going to be making the Axis2 jar available for
download before we have the release complete, the timestamp in the jar
name should be updated so the different versions can be easily
distinguished.
2) The checked in axiom jar should also carry a timestamp modifier
(e.g., axiom-api-1.2.5-20100610).
Rick
On 6/10/2010 4:45 AM, ashishj...@apache.org wrote:
Author: ashishjain
Date: Thu Jun 10 08:45:57 2010
New Revision: 953250
URL: http://svn.apache.org/viewvc?rev=953250view=rev
Log:
GERONIMO-5379 Fixes for geronimo custom AXIS2 for 2.1 branch
Added:
geronimo/server/branches/2.1/repository/org/apache/axis2/builder.patch
geronimo/server/branches/2.1/repository/org/apache/ws/
geronimo/server/branches/2.1/repository/org/apache/ws/axiom_api.patch
geronimo/server/branches/2.1/repository/org/apache/ws/commons/
geronimo/server/branches/2.1/repository/org/apache/ws/commons/axiom/
geronimo/server/branches/2.1/repository/org/apache/ws/commons/axiom/axiom-api/
geronimo/server/branches/2.1/repository/org/apache/ws/commons/axiom/axiom-api/1.2.5/
geronimo/server/branches/2.1/repository/org/apache/ws/commons/axiom/axiom-api/1.2.5/axiom-api-1.2.5.jar
(with props)
geronimo/server/branches/2.1/repository/org/apache/ws/readme.txt
(with props)
Modified:
geronimo/server/branches/2.1/repository/org/apache/axis2/README.TXT
geronimo/server/branches/2.1/repository/org/apache/axis2/axis2-kernel/1.3-G20090406/axis2-kernel-1.3-G20090406.jar
Modified:
geronimo/server/branches/2.1/repository/org/apache/axis2/README.TXT
URL:
http://svn.apache.org/viewvc/geronimo/server/branches/2.1/repository/org/apache/axis2/README.TXT?rev=953250r1=953249r2=953250view=diff
==
---
geronimo/server/branches/2.1/repository/org/apache/axis2/README.TXT
(original)
+++
geronimo/server/branches/2.1/repository/org/apache/axis2/README.TXT
Thu Jun 10 08:45:57 2010
@@ -3,7 +3,7 @@ Private Build of Axis2 1.3 for Geronimo.
How to build Axis2 1.3-G20090406:
-
Checkout the Axis2 1.3 tag
- svn co
http://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.3/
axis2-1.3
+ svn co
http://svn.apache.org/repos/asf/axis/axis2/java/core/tags/java/v1.3
Apply the patches
@@ -14,6 +14,7 @@ Apply the patches
patch -p0 -i metadata.patch
patch -p0 -i jaxws.patch
patch -p0 -i kernel.patch
+ patch -p0 -i builder.patch
Build Axis2 1.3
---
@@ -32,6 +33,7 @@ Patch Information
metadata.patch - contains fixes for SEI with overloaded methods
jaxws.patch- contains fixes for AXIS2-3343 and RESTful invocations
kernel.patch - contains fixes for AXIS2-4279
+ builder.patch - contains fixes for AXIS2-4450
Copy patched jar files to appropriate locations
---
Modified:
geronimo/server/branches/2.1/repository/org/apache/axis2/axis2-kernel/1.3-G20090406/axis2-kernel-1.3-G20090406.jar
URL:
http://svn.apache.org/viewvc/geronimo/server/branches/2.1/repository/org/apache/axis2/axis2-kernel/1.3-G20090406/axis2-kernel-1.3-G20090406.jar?rev=953250r1=953249r2=953250view=diff
==
Binary files - no diff available.
Added:
geronimo/server/branches/2.1/repository/org/apache/axis2/builder.patch
URL:
http://svn.apache.org/viewvc/geronimo/server/branches/2.1/repository/org/apache/axis2/builder.patch?rev=953250view=auto
==
---
geronimo/server/branches/2.1/repository/org/apache/axis2/builder.patch
(added)
+++
geronimo/server/branches/2.1/repository/org/apache/axis2/builder.patch
Thu Jun 10 08:45:57 2010
@@ -0,0 +1,132 @@
+Index: modules/kernel/src/org/apache/axis2/builder/BuilderUtil.java
+===
+--- modules/kernel/src/org/apache/axis2/builder/BuilderUtil.java
(revision 952555)
modules/kernel/src/org/apache/axis2/builder/BuilderUtil.java
(working copy)
+@@ -192,9 +192,9 @@
+ public static StAXBuilder getPOXBuilder(InputStream inStream,
String charSetEnc)
+ throws XMLStreamException {
+ StAXBuilder builder;
+-XMLStreamReader xmlreader =
+-StAXUtils.createXMLStreamReader(inStream, charSetEnc);
+-builder = new StAXOMBuilder(xmlreader);
++
Re: [DISCUSS] Time to upgrade or drop Minimal assemblies from 3.0 builds?
On 6/10/10 11:22 AM, Kevan Miller wrote: On Jun 9, 2010, at 7:48 PM, Donald Woods wrote: Now that I have the initial web profile assemblies created and hooked into our TCK harness, I'd like to circle back around on this. Personally, I like Option #1 - Upgrade and rename minimal assemblies to EBA based assemblies. This way, all of the assemblies we build and release will support the Aries EBA programming model. Users can choose to build their own custom assemblies if they choose and leave out the EBA and WAB support if they do not require it. Also, it looks like we will have to add a few more modules into the web profile assemblies to handle some of the TCK tests, along with missing console, monitoring agent, clustering, which will probably make those assemblies grow from the current 65MB to more like 80MB. The last time I checked (over a month ago), I seem to recall that an EBA assembly was pulling in components that I didn't think belonged in an EBA assembly (e.g. ActiveMQ). Was that fixed/changed? No ActiveMQ in the current EBA assembly. On that note, I recall the OSGi EEG is looking at adding Message Driven Services. So, EBA is going to be a moving target overtime... And may not always be a minimal environment. Well, that could become a problem for our Web profile assembly which includes EBA, as the TCK docs mention that if a web profile server includes additional/optional Java EE technologies (aka. JMS or web services from the Full profile) then the corresponding TCK buckets or stand-alone tests must also be run. I can imagine users being interested in WAB, EBA, Java EE Web, and Java EE Full functionality. I'm not sure that a multitude of assemblies is where we want to end up, however. I'm sure we don't want to be building 8 separate assemblies. True, but you still end up with a download that includes everything, including the admin console. Still think we need a smaller download option for 3.0 that doesn't include the console I've mentioned this before, but I would like to consider packaging multiple configs (or allowing an assembly to easily run a subset of the installed functionality). Something like: geronimo run -c wab-config.xml geronimo run -c eba-config.xml etc. --kevan
Re: [DISCUSS] Time to upgrade or drop Minimal assemblies from 3.0 builds?
Now that I have the initial web profile assemblies created and hooked into our TCK harness, I'd like to circle back around on this. Personally, I like Option #1 - Upgrade and rename minimal assemblies to EBA based assemblies. This way, all of the assemblies we build and release will support the Aries EBA programming model. Users can choose to build their own custom assemblies if they choose and leave out the EBA and WAB support if they do not require it. Also, it looks like we will have to add a few more modules into the web profile assemblies to handle some of the TCK tests, along with missing console, monitoring agent, clustering, which will probably make those assemblies grow from the current 65MB to more like 80MB. -Donald On 6/8/10 3:17 PM, Donald Woods wrote: I remember we had some discussion about dropping the minimal assemblies from the 3.0 builds awhile back, but can't find where a decision was made, so here goes... Option 1 - We upgrade the minimal assemblies to support EBA apps by using the eba-* instead of wab-* plugingroups, so all of our base assemblies supports the EBA programming environment, while still producing an assembly which is a subset of the Java EE 6 Web Profile. The wab-* plugingroups pull in deployers and runtime for: Servlet 3.0, JSP 2.2 and EL 1.2, JSF 2.0, JSTL 1.2, WAB (OSGi RFC66), and remote/offline deploy. Which creates a zip assembly of ~42MB. The eba-* plugingroups pull in the wab-* plugins along with deployers and runtime for: Aries, JPA2, JTA 1.6, JCA 1.6, system db and TranQL connectors. Which creates a zip assembly of ~52MB. Option 2 - We drop the minimal assemblies and only produce the Java EE 6 full and web profiles. Both would still support EBA apps, but instead of being able to download a ~52MB assembly, they would either have to build a custom assembly or go with a larger web profile assembly that also pulls in console, monitoring, clustering, EJB, ... Either option, would require users wanting a minimal server to create their own custom assembly which uses either the wab-* plugins or their own subset. For comparison data, currently the framework assembly is ~26MB, the new javaee6-web assemblies ~65MB, and the full javaee6 assemblies ~75MB (but both are still lacking full console, hot deploy, monitoring, ... and the web profile is pulling in all of the EJB support instead of a subset.) -Donald
[DISCUSS] Time to upgrade or drop Minimal assemblies from 3.0 builds?
I remember we had some discussion about dropping the minimal assemblies from the 3.0 builds awhile back, but can't find where a decision was made, so here goes... Option 1 - We upgrade the minimal assemblies to support EBA apps by using the eba-* instead of wab-* plugingroups, so all of our base assemblies supports the EBA programming environment, while still producing an assembly which is a subset of the Java EE 6 Web Profile. The wab-* plugingroups pull in deployers and runtime for: Servlet 3.0, JSP 2.2 and EL 1.2, JSF 2.0, JSTL 1.2, WAB (OSGi RFC66), and remote/offline deploy. Which creates a zip assembly of ~42MB. The eba-* plugingroups pull in the wab-* plugins along with deployers and runtime for: Aries, JPA2, JTA 1.6, JCA 1.6, system db and TranQL connectors. Which creates a zip assembly of ~52MB. Option 2 - We drop the minimal assemblies and only produce the Java EE 6 full and web profiles. Both would still support EBA apps, but instead of being able to download a ~52MB assembly, they would either have to build a custom assembly or go with a larger web profile assembly that also pulls in console, monitoring, clustering, EJB, ... Either option, would require users wanting a minimal server to create their own custom assembly which uses either the wab-* plugins or their own subset. For comparison data, currently the framework assembly is ~26MB, the new javaee6-web assemblies ~65MB, and the full javaee6 assemblies ~75MB (but both are still lacking full console, hot deploy, monitoring, ... and the web profile is pulling in all of the EJB support instead of a subset.) -Donald
Re: svn commit: r952721 - in /geronimo/server/trunk/plugins: connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ j2ee/geronimo-naming-builder/src/main/
I'm seeing compile failures after pulling in the below changes
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[232,58]
cannot find symbol
symbol : method isSetReferenceClass()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[233,44]
cannot find symbol
symbol : method getReferenceClass()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-bulocation:
interface org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[236,69]
cannot find symbol
symbol : method getStringAddrType()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[237,65]
cannot find symbol
symbol : method getStringAddr()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[240,67]
cannot find symbol
symbol : method getObjectFactory()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[241,75]
cannot find symbol
symbol : method getObjectFactoryLocation()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
On 6/8/10 12:20 PM, djen...@apache.org wrote:
Author: djencks
Date: Tue Jun 8 16:20:48 2010
New Revision: 952721
URL: http://svn.apache.org/viewvc?rev=952721view=rev
Log:
GERONIMO-5360 support binding References in jndi
Modified:
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ResourceRefBuilder.java
geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/src/main/xsd/geronimo-naming-1.2.xsd
Modified:
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java?rev=952721r1=952720r2=952721view=diff
==
---
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java
(original)
+++
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java
Tue Jun 8 16:20:48 2010
@@ -25,7 +25,9 @@ import java.util.List;
import java.util.Map;
import javax.annotation.Resource;
+import javax.naming.RefAddr;
import javax.naming.Reference;
+import javax.naming.StringRefAddr;
import javax.xml.namespace.QName;
import org.apache.geronimo.gbean.annotation.GBean;
@@ -227,6 +229,18 @@ public class AdminObjectRefBuilder exten
} catch (ClassNotFoundException e) {
throw new DeploymentException(Could not load resource-env-ref
entry class + type, e);
}
+if (gerResourceEnvRef != null
gerResourceEnvRef.isSetReferenceClass()) {
+String clazz = gerResourceEnvRef.getReferenceClass();
+RefAddr addr = null;
+if (gerResourceEnvRef.isSetStringAddrType()) {
+String refAddrType =
getStringValue(gerResourceEnvRef.getStringAddrType());
+String refAddr =
getStringValue(gerResourceEnvRef.getStringAddr());
+addr = new StringRefAddr(refAddrType, refAddr);
+}
+String objectFactory =
getStringValue(gerResourceEnvRef.getObjectFactory());
+String objectFactoryLocation =
getStringValue(gerResourceEnvRef.getObjectFactoryLocation());
+return new Reference(clazz, addr,
Re: svn commit: r952721 - in /geronimo/server/trunk/plugins: connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ j2ee/geronimo-naming-builder/src/main/
Yep, I got past those errors after a couple retries, but am now hitting
an error trying to download a osgi-openejb artifact. Guess I need to
build openejb locally for now
-Donald
On 6/8/10 3:44 PM, David Jencks wrote:
It looks to me like the schema changes to support this got into the same
commit, are you sure that plugins/j2ee/geronimo-naming-builder got recompiled
before these errors?
thanks
david jencks
On Jun 8, 2010, at 12:30 PM, Donald Woods wrote:
I'm seeing compile failures after pulling in the below changes
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[232,58]
cannot find symbol
symbol : method isSetReferenceClass()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[233,44]
cannot find symbol
symbol : method getReferenceClass()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-bulocation:
interface org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[236,69]
cannot find symbol
symbol : method getStringAddrType()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[237,65]
cannot find symbol
symbol : method getStringAddr()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[240,67]
cannot find symbol
symbol : method getObjectFactory()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
/Users/drwoods/geronimo/server-trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java:[241,75]
cannot find symbol
symbol : method getObjectFactoryLocation()
location: interface
org.apache.geronimo.xbeans.geronimo.naming.GerResourceEnvRefType
On 6/8/10 12:20 PM, djen...@apache.org wrote:
Author: djencks
Date: Tue Jun 8 16:20:48 2010
New Revision: 952721
URL: http://svn.apache.org/viewvc?rev=952721view=rev
Log:
GERONIMO-5360 support binding References in jndi
Modified:
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ResourceRefBuilder.java
geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/src/main/xsd/geronimo-naming-1.2.xsd
Modified:
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java?rev=952721r1=952720r2=952721view=diff
==
---
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java
(original)
+++
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/AdminObjectRefBuilder.java
Tue Jun 8 16:20:48 2010
@@ -25,7 +25,9 @@ import java.util.List;
import java.util.Map;
import javax.annotation.Resource;
+import javax.naming.RefAddr;
import javax.naming.Reference;
+import javax.naming.StringRefAddr;
import javax.xml.namespace.QName;
import org.apache.geronimo.gbean.annotation.GBean;
@@ -227,6 +229,18 @@ public class AdminObjectRefBuilder exten
} catch (ClassNotFoundException e) {
throw new DeploymentException(Could not load resource-env-ref
entry class + type, e);
}
+if (gerResourceEnvRef != null
gerResourceEnvRef.isSetReferenceClass()) {
+String clazz = gerResourceEnvRef.getReferenceClass();
+RefAddr addr = null;
+if (gerResourceEnvRef.isSetStringAddrType()) {
+String
Re: Apache Tuscany Logo in Geronimo Wiki
I'm not sure what's up. I replaced the autoexport template with the one from the 3.0 docs and it's still showing the wrong topNav content -Donald On 5/31/10 1:19 PM, Kevan Miller wrote: When I load our 2.1 or 2.2 Wiki information, I'm getting a Tuscany logo (e.g. https://cwiki.apache.org/GMOxDOC21/documentation.html). Anybody else seeing this? Anybody willing to fix? --kevan
Re: [VOTE] Release Geronimo Customized Tomcat 7.0.0.1
+1 Build worked. Only rat failure was for an empty file - catalina/src/main/resources/org/apache/ServerInfo.properties -Donald On 5/24/10 2:21 AM, Ivan wrote: Please vote for Geronimo Customized Tomcat 7.0.0.1 a. Recently, Tomcat community has begun their vote for Tomcat 7 RC 3, so current version should be a more stable one. b. About the license issues found in the vote for Geronimo Tomcat 7.0.0.0, as those files have been donated, so they are properly under ASL 2.0. At this time, no files are removed explictly. c. If the vote could be passed on time, I would like use this version in M1 branch. Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-007/ Source repo: https://svn.apache.org/repos/asf/geronimo/external/tags/tomcat-parent-7.0.0.1/ -- I have run the servlet/JSP TCK, at least, the failed cases should not caused by Tomcat codes itself. The codes until rev 947397 are merged from Tomcat 7.0 trunk. -- Ivan
Re: The 3.0-M1 release notes need some attention.
On 5/26/10 11:32 AM, Rick McGuire wrote:
I've done a quick pass through the 3.0-M1 release notes, but I need a
little help to get this updated for creating a release candidate. This
is the first time I've done of these, so I have a few questions on how
this gets pulled together.
1) The version in here is listed as @vers...@. Is that something the
release plugin updates automatically when the release is prepared or
does this require a manual search-and-replace operation? I notice that
the 2.2 version of this still says @vers...@. Was that just an
oversite, or is that convention.
The Eclipse plugin build does something like this, but with
${pom.version} instead -
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-505
http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.st.v20.core/pom.xml?p2=/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.st.v20.core/pom.xmlp1=/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.st.v20.core/pom.xmlr1=689987r2=689986view=diffpathrev=689987
2) Are there tools (or standard Jira searches) available for generating
the various lists of issues included in the release notes?
https://issues.apache.org/jira/browse/GERONIMO
Release Notes
version=3.0
style=text
cut-n-paste section is at the bottom -
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314206styleName=TextprojectId=10220Create=Create
For OpenJPA, we created releases for each milestone and beta, so we
could correctly group the jiras per release. If you wanted to do that
for Geronimo, you'd have to create a 3.0-M1 and then bulk edit all
issues that have a Fix Version of 3.0 (and resolved or closed) and
change it to 3.0-M1.
3) What enhancements should we be listing here? I took a quick first
pass, but please make additions/corrections to the list I've put
together. I know there are some things missing like the Global JNDI
enhancements and the Datasource resource bindings and I suspect the
Aries feature list is incomplete. Please help me fill this out.
Well, I wouldn't say the following until we pass the TCKs -
All programming elements of the Java EE 6.0 Specification are available.
I know the BVAL plugin that David J. was working on is not in the M1
branch. Also, not sure if we've updated our JSF 2.2 support to include
the BVAL support
4) What should we list for supported features? The wording currently
there is definitely wrong. How should we phrase this?
I would only list what we want users to focus on and try -
web apps - servlet 3.0, jsf 2.2, jsp
wab - rfc66 apps
eba - osgi/aries based apps (blueprint, jpa, transaction, jndi, ...)
Secondary focus - traditional Java EE apps -
jpa 2.0?
how much of EJB 3.1?
activemq 5.3.2
connector 1.6?
5) There are obviously lots of limitations here. What should we be
listing?
Just a big disclaimer that this is a milestone release and should only
be used for learning about the upcoming Geronimo 3.0 release with Java
EE 6 and OSGi/Aries support and not for any type of production usage...
Rick
[jira] Commented: (GERONIMO-5337) ServerHostName does not control the bind ip address for Tomcat Connectors
[ https://issues.apache.org/jira/browse/GERONIMO-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12870756#action_12870756 ] Donald Woods commented on GERONIMO-5337: How would we preserve plugin overrides in car-maven-plugin then? Or would switching to osgi version ranges allow us to finally remove all of the hard coded version info in CARs? ServerHostName does not control the bind ip address for Tomcat Connectors - Key: GERONIMO-5337 URL: https://issues.apache.org/jira/browse/GERONIMO-5337 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 ServerHostName in config-substitutions.properties does not control the bind address for Tomcat Connectors. They are always 0.0.0.0 Note I didn't test Jetty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5343) Replace config-substitutions.properties by use of config admin
[ https://issues.apache.org/jira/browse/GERONIMO-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12870757#action_12870757 ] Donald Woods commented on GERONIMO-5343: How would we preserve plugin overrides in car-maven-plugin then? Or would switching to osgi version ranges allow us to finally remove all of the hard coded version info in CARs? Replace config-substitutions.properties by use of config admin -- Key: GERONIMO-5343 URL: https://issues.apache.org/jira/browse/GERONIMO-5343 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: core Affects Versions: 3.0 Reporter: David Jencks Fix For: 3.0 OSGI has a fairly sophisticated customization system, config admin. We should look into replacing our homegrown config-substitutions stuff with this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Web services in G 3.0-M1
+1 Focusing on Aries and Web Profile sound like the right priorities. -Donald On 5/21/10 6:07 AM, Rick McGuire wrote: Jarek Gawor brought to my attention that the web services support in 3.0 has not yet gotten any testing or attention. While it builds, it is in a state where it doesn't really work. Since the focus of the M1 release is on the new Aries support and the Java EE 6 Web Profile, I think it makes sense to remove the web services components from the M1 release. Web services are not part of the Web Profile, so including them in the 3.0 Web Profile release was a bit of a stretch goal to begin with. Since this support might not be in the 3.0 final release and isn't really functional at this point anyway, I'm going to be removing the web services support from the M1 branch. Rick
Fwd: [ANNOUNCE] Apache Derby 10.6.1.0 released
Original Message Subject: [ANNOUNCE] Apache Derby 10.6.1.0 released Date: 19 May 2010 15:53:28 - From: rhille...@apache.org To: annou...@apache.org The Apache Derby project is pleased to announce release 10.6.1.0. In addition to introducing many new features, this release fixes a security flaw. Please see below for more details. Apache Derby is a subproject of the Apache DB project. Derby is a pure Java relational database engine which conforms to the ISO/ANSI SQL and JDBC standards. Derby aims to be easy for developers and end-users to work with. Derby 10.6.1.0 can be obtained from the Derby download site: http://db.apache.org/derby/derby_downloads.html. Derby 10.6.1.0 contains the following new features: * Sequence Generators - Named generators for allocating successive, evenly spaced numbers. See feature T176 of the SQL Standard. * User-defined types - Named types bound to serializable Java objects. * Restricted table functions - Limits on the columns and rows returned by table functions. * XPLAIN statistics collection - Query plan statistics stored in tables for later analysis. * GROUP BY ROLLUP - A subset of the SQL Standard ROLLUP functionality on the GROUP BY clause. See feature T431 of the SQL Standard. * CROSS JOIN - CROSS JOIN syntax. See feature F401-04 of the SQL Standard. * Named columns join - USING clauses in joins. * SHOW FUNCTIONS - IJ command that lists stored functions. * In-memory back end enhancements - Numerous improvements, including the ability to delete in-memory databases. * ORDER BY in subqueries - Syntax for explicitly ordering rows returned by subqueries. See features F851, F852, and F855 of the SQL Standard. * OFFSET, FETCH FIRST/NEXT in subqueries - Generalized syntax for retrieving row subsets. See features F856, F857, F858, F859, F861, F862, F863, and F864 of the SQL Standard. * NATURAL JOIN - Support for NATURAL JOIN. See feature T431 of the SQL Standard. * Qualified identifers in ij - Ability to reference cursors and prepared statements in other connections. * Configurable hash algorithm - Ability to customize the hash algorithm used by BUILTIN authentication. * Context-sniffing scripts - Ability of shipped scripts to locate Derby jars when DERBY_HOME isn't set. * Case-insensitive strings - Ability to ignore case in string comparisons and sorts. In addition, Derby 10.6.1.0 contains many bug and documentation fixes. Please try out this new release. -- IMPORTANT SECURITY NOTE -- IMPORTANT SECURITY NOTE -- IMPORTANT SECURITY NOTE -- Derby 10.6.1.0 also fixes a security flaw tracked by the Apache Common Vulnerabilities and Exposures id CVE-2009-4269. This flaw made it easy to crack passwords managed by Derby's BUILTIN authentication logic. Originally, the BUILTIN logic was intended only for testing purposes. However, Derby's user documentation suggested that this scheme was production-ready and it appears that many users rely on BUILTIN authentication in production. Tracked by DERBY-4483, the flaw is addressed as follows: 1) The bug itself is corrected for newly created 10.6 databases. 2) Password substitution is not allowed when logging into a database where the bug is corrected and BUILTIN passwords are stored in the database. See the release note for DERBY-4483. 3) Derby's default password-hashing scheme is changed from SHA-1 to SHA-256, which is harder to crack. 4) The user guides are glossed with warnings against production use of the BUILTIN authentication mechanism. Users are urged to i) Migrate production systems off the BUILTIN mechanism onto Derby's LDAP and user-customized authentication schemes. ii) Or hard-upgrade to 10.6.1.0 immediately and perform the following additional steps: a) Set derby.authentication.builtin.algorithm to a stronger authentication scheme like SHA-256 or SHA-512. b) Reset all passwords stored in the database. c) Stop using strong password substitution. Instead, encrypt all network traffic using SSL/TLS. -- IMPORTANT SECURITY NOTE -- IMPORTANT SECURITY NOTE -- IMPORTANT SECURITY NOTE --
Re: Runtime entity enhancement for OSGi applications
Good summary Lin. In the OpenJPA community, we've been telling users for awhile now not to use the runtime enhancement, as it has known deficiencies, and should only be used for quick prototyping and never in production. If we need to continue supporting this in Geronimo (for the developer scenarios), then I'd go with #3 for now. -Donald On 5/19/10 11:19 AM, Lin Sun wrote: Seems No. 3 is the right approach, given that there is no overhead on the user side and it gives the ability to add the imports at the last minute, before the PU is resolved. No. 2 gives some extra work on the user side which can make the PU not portable. Np. 4 has to be done when PU is installed, and it is possible the provider is not even there yet. No. 5 can be confusing to the user as a fragment is attached to their PU. Lin On Tue, May 18, 2010 at 10:41 PM, Jarek Gawor jga...@gmail.com wrote: Hi all, I was looking into getting the runtime JPA entity enhancement for OSGi applications working in Geronimo. With some modifications to the Aries JPA code and some to Geronimo I was able to get runtime enhancement working (using the java agent approach) but with one major issue: The bundle that contains the persistence unit must be able to load some persistence provider specific (in our case openjpa) classes. That's because during the bytecode weaving, openjpa adds some openjpa specific interfaces to the entity classes. So how should we deal with this issue in Geronimo? 1) We could do nothing and just say we don't support runtime enhancement. 2) We could support runtime enhancement and require that bundles with PU have DynamicImport-Package: * header. 3) Use framework classloader hooks to dynamically add imports for the persistence provider specific packages to the bundles with PU . That of course, would rely on framework specific extensions. I know Equinox has such hooks and I think recently something similar was added to Felix. 4) Provide some url handler, e.g. jpa which would enhance the entity classes and add right imports during the install. Something similar to the webbundle url handler for web application archives. Of course, we would have to make sure the bundles with PU get installed via the url handler. 5) Have some kind of an extender that would generate a fragment bundle (with right persistence provider imports) and attach it to the bundle with PU. Or something similar that would require manifest modification or generation of additional bundle. Thoughts? Jarek
Re: [VOTE] special Geronimo OpenEJB 3.1.3.0 release (second attempt)
Do we need to publish everything? I was able to build the source, but there were some rat:check failures in some modules (like container)... -Donald On 5/17/10 9:30 AM, Rick McGuire wrote: Please vote for the geronimo openejb 3.1.3.0 release This is a version of openejb based on revision r942249. This is a special release to be used on the Geronimo 3.0-M1 release and is being released under the org.apache.geronimo.ext.openejb groupid. Differences from the first attempt: Copyright headers added to container/openejb-osgi/src/main/resources/default.openejb.conf container/openejb-activemq4/src/main/resources/login.config container/openejb-core/src/main/resources/login.config container/openejb-osgi/src/main/resources/login.config container/openejb-core/src/main/resources/schema/ejb-jar_1_1.xsd LICENSE file updated to include the W3C license for the following files: container/openejb-jee/src/main/resources/META-INF/schema/xml.xsd server/openejb-axis/src/main/resources/META-INF/schema/soap_encoding_1_1.xsd This is the working version of openejb that works with Geronimo 3.0. This component is dependent upon the XBean release that is also currently up for a vote. You may need to build XBean yourself to build openejb from the tag file at: https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.7 Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-037/ tag is here: https://svn.apache.org/repos/asf/geronimo/external/tags/openejb-3.1.3.0 Vote open 72 hours. Note also that this is contingent upon the XBean vote also passing. [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) Rick
Re: [VOTE] special Geronimo OpenEJB 3.1.3.0 release (second attempt)
Looks like there were really only 4 services files that had rat:check failures, even though it gave a count of 867. So, here's my +1. -Donald On 5/19/10 4:28 PM, Donald Woods wrote: Do we need to publish everything? I was able to build the source, but there were some rat:check failures in some modules (like container)... -Donald On 5/17/10 9:30 AM, Rick McGuire wrote: Please vote for the geronimo openejb 3.1.3.0 release This is a version of openejb based on revision r942249. This is a special release to be used on the Geronimo 3.0-M1 release and is being released under the org.apache.geronimo.ext.openejb groupid. Differences from the first attempt: Copyright headers added to container/openejb-osgi/src/main/resources/default.openejb.conf container/openejb-activemq4/src/main/resources/login.config container/openejb-core/src/main/resources/login.config container/openejb-osgi/src/main/resources/login.config container/openejb-core/src/main/resources/schema/ejb-jar_1_1.xsd LICENSE file updated to include the W3C license for the following files: container/openejb-jee/src/main/resources/META-INF/schema/xml.xsd server/openejb-axis/src/main/resources/META-INF/schema/soap_encoding_1_1.xsd This is the working version of openejb that works with Geronimo 3.0. This component is dependent upon the XBean release that is also currently up for a vote. You may need to build XBean yourself to build openejb from the tag file at: https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.7 Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-037/ tag is here: https://svn.apache.org/repos/asf/geronimo/external/tags/openejb-3.1.3.0 Vote open 72 hours. Note also that this is contingent upon the XBean vote also passing. [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) Rick
Re: Runtime entity enhancement for OSGi applications
On 5/19/10 4:28 PM, David Jencks wrote: On May 19, 2010, at 1:16 PM, Donald Woods wrote: Good summary Lin. In the OpenJPA community, we've been telling users for awhile now not to use the runtime enhancement, as it has known deficiencies, and should only be used for quick prototyping and never in production. What are these deficiencies? I thought you got the same bytecode whether you ran the enhancer using maven or as the classes are loaded using a class transformer. I know the subclassing approach doesn't work well but that is not being discussed here AFAIK. Javaagent - yes, it should be the same. Subclassing - no, that is what we tell people not to use. BTW - Geronimo is the only App Server that we know of that uses the -javaagent method for enhancing -Donald Is this stuff documented clearly somewhere in the openjpa docs? I've never found a comprehensible explanation when I've looked in the past. thanks david jencks If we need to continue supporting this in Geronimo (for the developer scenarios), then I'd go with #3 for now. -Donald On 5/19/10 11:19 AM, Lin Sun wrote: Seems No. 3 is the right approach, given that there is no overhead on the user side and it gives the ability to add the imports at the last minute, before the PU is resolved. No. 2 gives some extra work on the user side which can make the PU not portable. Np. 4 has to be done when PU is installed, and it is possible the provider is not even there yet. No. 5 can be confusing to the user as a fragment is attached to their PU. Lin On Tue, May 18, 2010 at 10:41 PM, Jarek Gawor jga...@gmail.com wrote: Hi all, I was looking into getting the runtime JPA entity enhancement for OSGi applications working in Geronimo. With some modifications to the Aries JPA code and some to Geronimo I was able to get runtime enhancement working (using the java agent approach) but with one major issue: The bundle that contains the persistence unit must be able to load some persistence provider specific (in our case openjpa) classes. That's because during the bytecode weaving, openjpa adds some openjpa specific interfaces to the entity classes. So how should we deal with this issue in Geronimo? 1) We could do nothing and just say we don't support runtime enhancement. 2) We could support runtime enhancement and require that bundles with PU have DynamicImport-Package: * header. 3) Use framework classloader hooks to dynamically add imports for the persistence provider specific packages to the bundles with PU . That of course, would rely on framework specific extensions. I know Equinox has such hooks and I think recently something similar was added to Felix. 4) Provide some url handler, e.g. jpa which would enhance the entity classes and add right imports during the install. Something similar to the webbundle url handler for web application archives. Of course, we would have to make sure the bundles with PU get installed via the url handler. 5) Have some kind of an extender that would generate a fragment bundle (with right persistence provider imports) and attach it to the bundle with PU. Or something similar that would require manifest modification or generation of additional bundle. Thoughts? Jarek
Re: [VOTE] Release XBean 3.7 - second attempt
+1 Was able to build. -Donald On 5/14/10 10:36 AM, Rick McGuire wrote: Please vote for the geronimo xbean 3.7 release The major changes to this release are: - xbean-blueprint subproject to provide support for Aries blueprint component assembly - xbean-bundleutils subproject to provide useful common utilities for dealing with OSGi bundles. Differences from the 1st attempt: 1) KEYS file has been deleted 2) copyright date in NOTICE file has been updated 3) test properties files have had ASL license headers added. The xbean-finder-shaded license issue that Kevan raised turned out to not be an issue, so no changes were required for that. Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-031/ tag is here: https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.7 Vote open 72 hours [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) Rick
Re: [VOTE] Geronimo jaspi component 1.1
+1 -Donald On 5/5/10 7:31 PM, David Jencks wrote: Please vote for the geronimo-jaspi 1.1 component. The major changes to this release are: - packaged as an osgi bundle - fairly non-functional classloading in 1.0 replaced by Rick's ProviderLocator that actually works in osgi. - dependencies upgraded to use bundleized dependencies. I spent some time trying to get the manifest entries to look reasonable to me. Since this is the first osgi release I put the package-version at 1.0. The import version ranges are _versionpolicy[$(version;==;$(@)),$(version;+;$(@)))/_versionpolicy for everything except the self-imports which are [1.0,1.1). I suppose it would have been better to use this version range for the jaspic spec as well, but I didn't. There's always something. Maybe next time the maven-bundle-plugin will do this for us. Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-012/ tag is here: https://svn.apache.org/repos/asf/geronimo/components/jaspi/tags/geronimo-jaspi-1.1/ Vote open 72 hours [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) thanks david jencks
Re: Creating Geronimo 3.0 wiki space
Do you want an empty space or one that is based on a copy of the 2.2 docs? -Donald On 5/10/10 11:43 PM, chi runhua wrote: Hi devs, I believe we could start creating document plan for Geronimo 3.0. First of all, we might need to create a new wiki space for G3.0. According to instructions on ASF CWIKI site, only a project PMC member can file the request. Refer to [1]. Any PMC member would like to help with this? Thanks in advance. [1] https://cwiki.apache.org/confluence/display/CWIKI/Index Jeff
Re: bean validation
Cool. We've noticed some problems with using BV in JEE app servers, in that OpenJPA needs to discover the entities to enhance before a BV provider loads them, otherwise we don't have a change to do our Serp byte code enhancing. Don't remember the exact details right now, but Albert on the OpenJPA team looked into it a few months back. The Apache Bean Validation podling [1] is moving along and we're knocking off TCK failures. Also, I've got OpenJPA trunk (2.1.0-SNAPSHOT) updated to use the BVAL artifacts for our bean validation tests, instead of the Hibernate implementation. Ping me if you need help and feel free to post to the BVAL lists [2]. [1] https://cwiki.apache.org/BeanValidation/ [2] https://cwiki.apache.org/BeanValidation/mailing-lists.html -Donald On 5/8/10 3:15 AM, David Jencks wrote: I'm going to look next at a bit of bean validation support. So far my plans are just to have a naming builder to stuff validator/factory references into jndi and an appropriate ref object. It looks like there are some requirements to stuff this into various contexts as well, hopefully that will be pretty easy... thanks david jencks
Re: Creating Geronimo 3.0 wiki space
Yep, that was my thoughts too. Just kicked of a Copy Space of GMOxDOC22 to GMOxDOC30. -Donald On 5/11/10 3:46 PM, David Jencks wrote: I hope we copy the 2.2 space, even though there will be a lot of changes. I think we wasted an enormous amount of time copying the 2.1 docs to 2.2 by hand. thanks david jencks On May 11, 2010, at 12:11 PM, Donald Woods wrote: Do you want an empty space or one that is based on a copy of the 2.2 docs? -Donald On 5/10/10 11:43 PM, chi runhua wrote: Hi devs, I believe we could start creating document plan for Geronimo 3.0. First of all, we might need to create a new wiki space for G3.0. According to instructions on ASF CWIKI site, only a project PMC member can file the request. Refer to [1]. Any PMC member would like to help with this? Thanks in advance. [1] https://cwiki.apache.org/confluence/display/CWIKI/Index Jeff
Re: Creating Geronimo 3.0 wiki space
Space is created and the autoexport template updated - https://cwiki.apache.org/GMOxDOC30/ -Donald On 5/11/10 4:51 PM, Donald Woods wrote: Yep, that was my thoughts too. Just kicked of a Copy Space of GMOxDOC22 to GMOxDOC30. -Donald On 5/11/10 3:46 PM, David Jencks wrote: I hope we copy the 2.2 space, even though there will be a lot of changes. I think we wasted an enormous amount of time copying the 2.1 docs to 2.2 by hand. thanks david jencks On May 11, 2010, at 12:11 PM, Donald Woods wrote: Do you want an empty space or one that is based on a copy of the 2.2 docs? -Donald On 5/10/10 11:43 PM, chi runhua wrote: Hi devs, I believe we could start creating document plan for Geronimo 3.0. First of all, we might need to create a new wiki space for G3.0. According to instructions on ASF CWIKI site, only a project PMC member can file the request. Refer to [1]. Any PMC member would like to help with this? Thanks in advance. [1] https://cwiki.apache.org/confluence/display/CWIKI/Index Jeff
[jira] Updated: (GERONIMO-4946) Add optional OpenJPA2 plugin to server builds, but not the assemblies
[ https://issues.apache.org/jira/browse/GERONIMO-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-4946: --- Fix Version/s: Wish List (was: 2.2.1) Please do not associate to a specific release Add optional OpenJPA2 plugin to server builds, but not the assemblies - Key: GERONIMO-4946 URL: https://issues.apache.org/jira/browse/GERONIMO-4946 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.3, 2.1.4, 2.1.5, 2.2, 2.2.1 Reporter: Donald Woods Assignee: Donald Woods Fix For: Wish List I'm trying to build a openjpa 2.0 plugin for 2.2, which would replace the existing openjpa 1.2 plugin when installed. https://svn.apache.org/repos/asf/geronimo/server/branches/2.2/plugins/openjpa2 The following works as expected: 1) when the new openjpa2 plugin and deployer are installed they replace the existing ones via the obsoletes directive in config.xml 2) the artifact-alias.properties and client-artifact-alias.properties are updated with: org.apache.geronimo.configs/openjpa//car=org.apache.geronimo.configs/openjpa2/2.2-SNAPSHOT/car org.apache.geronimo.configs/persistence-jpa10-deployer//car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-SNAPSHOT/car Issues: 1) the offline-deployer-config.xml contains entries for the old openjpa and jpa10-deployer modules and the new openjpa2 and jpa20-deployer modules. I would have expected the old ones to be removed, as was done for the server config.xml 2) the openjeb module fails to load (even after server restart) using the new plugins, even though entries were added to artifact-alias.properties - aused by: org.apache.geronimo.gbean.InvalidConfigurationException: Configuration gbean failed to start org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car reason: Missing dependency: org.apache.geronimo.configs/openjpa/2.2-SNAPSHOT/car at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:166) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4946) Create stand-alone OpenJPA2 plugins for 2.1.3+ and 2.2+ servers
[ https://issues.apache.org/jira/browse/GERONIMO-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-4946: --- Summary: Create stand-alone OpenJPA2 plugins for 2.1.3+ and 2.2+ servers (was: Add optional OpenJPA2 plugin to server builds, but not the assemblies) Create stand-alone OpenJPA2 plugins for 2.1.3+ and 2.2+ servers --- Key: GERONIMO-4946 URL: https://issues.apache.org/jira/browse/GERONIMO-4946 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.3, 2.1.4, 2.1.5, 2.2, 2.2.1 Reporter: Donald Woods Assignee: Donald Woods Fix For: Wish List I'm trying to build a openjpa 2.0 plugin for 2.2, which would replace the existing openjpa 1.2 plugin when installed. https://svn.apache.org/repos/asf/geronimo/server/branches/2.2/plugins/openjpa2 The following works as expected: 1) when the new openjpa2 plugin and deployer are installed they replace the existing ones via the obsoletes directive in config.xml 2) the artifact-alias.properties and client-artifact-alias.properties are updated with: org.apache.geronimo.configs/openjpa//car=org.apache.geronimo.configs/openjpa2/2.2-SNAPSHOT/car org.apache.geronimo.configs/persistence-jpa10-deployer//car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-SNAPSHOT/car Issues: 1) the offline-deployer-config.xml contains entries for the old openjpa and jpa10-deployer modules and the new openjpa2 and jpa20-deployer modules. I would have expected the old ones to be removed, as was done for the server config.xml 2) the openjeb module fails to load (even after server restart) using the new plugins, even though entries were added to artifact-alias.properties - aused by: org.apache.geronimo.gbean.InvalidConfigurationException: Configuration gbean failed to start org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car reason: Missing dependency: org.apache.geronimo.configs/openjpa/2.2-SNAPSHOT/car at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:166) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5274) Deploy New/Install New Application portlet needs some love to help out newbies
[ https://issues.apache.org/jira/browse/GERONIMO-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865771#action_12865771 ] Donald Woods commented on GERONIMO-5274: Looks good. Thanks. Deploy New/Install New Application portlet needs some love to help out newbies -- Key: GERONIMO-5274 URL: https://issues.apache.org/jira/browse/GERONIMO-5274 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Reporter: Donald Woods Assignee: Chi Runhua Priority: Minor Fix For: 2.2.1 Attachments: 5274_2.2_en.patch Got feedback from a new Geronimo user (one of our OpenJPA committers) when she tried to setup Geronimo 2.1.5 + OpenJPA2 + Daytrader 2.1.3. 1) Title of Deploy New item in the navigation tree should be more generic, like Deploy Applications or Deployer, as it can be used to redeploy apps 2) The Portlet title of Install New Applications should be more generic just like the menu title, like Deploy Applications, as it can also be used to redeploy apps 3) The Plan field needs to be relabeled as Plan (optional): as the deployment plan is optional. 4) The Help for the portlet needs some updating: 4a) The Archive field can be WAR/EAR/RAR and not just the mentioned WAR type. 4b) The Plan field needs more description, like mentioning it is optional. Also it should mention archive instead of war as multiple file types are supported as stated in 4a. Need to also reword that it can be a deployment plan not included in the archive or a stand-alone deployment plan when a RAR is being used or for providing environment specific settings like the DB plans used with Daytrader. 4c) the Redeploy application option in the portlet is not mentioned in the Help and needs to be added 5) we shouldn't use app as an abbreviation for application for the checkbox Start app after install -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
