xfire annotation exception: Service class cannot be abstract for jsr181 proxy
Hi, Does anyone have a complete example of jsr181 proxy for external web service? I have two services, one is inside jbi container and the other one is outside. The inside service consumes the external web service. I followed the jsr181 proxy example, but got org.codehaus.xfire.annotations.AnnotationException as following: It seemed that the ILogger (Interface) actually need to be an implementation class, but this is not how the degelate/proxy is used in the caller. Anyone has any ideas? Sep 16 14:38:56 yingzhaopc [] 5 Error org/codehaus/xfire/handler/DefaultFaultHa ndler Fault occurred! org.codehaus.xfire.annotations.AnnotationException: Servi ce class cannot be abstract: com.ms.im.agile.management.logging.ILogger at org.codehaus.xfire.annotations.AnnotationServiceFactory.assertValidIm plementationClass(AnnotationServiceFactory.java:278) at org.codehaus.xfire.annotations.AnnotationServiceFactory.create(Annota tionServiceFactory.java:172) at org.codehaus.xfire.service.binding.ObjectServiceFactory.create(Object ServiceFactory.java:209) at com.ms.im.agile.se.pojo.impl.helper.JbiProxy.getProxy(Unknown Source) at com.ms.im.agile.se.pojo.impl.helper.JbiProxy.create(Unknown Source) at com.ms.im.agile.se.pojo.impl.helper.JbiProxyFactoryBean.getJBIInvocat ionHandler(Unknown Source) at com.ms.im.agile.se.pojo.impl.helper.JbiProxyFactoryBean.access$000(Un known Source) at com.ms.im.agile.se.pojo.impl.helper.JbiProxyFactoryBean$1.invoke(Unkn own Source) at $Proxy1.trace(Unknown Source) -- View this message in context: http://www.nabble.com/xfire-annotation-exception%3A-Service-class-cannot-be-abstract-for-jsr181-proxy-tf4471381s12049.html#a12749189 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMODEVTOOLS-213) Cannot select Apache Geronimo v1.0 on New Server Runtime dialog.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMODEVTOOLS-213: --- Attachment: GD-213.patch Cannot select Apache Geronimo v1.0 on New Server Runtime dialog. Key: GERONIMODEVTOOLS-213 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Geronimo Eclipse Plugin 2.0.0 RC3 Reporter: Kan Ogawa Priority: Blocker Attachments: GD-213.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-213) Cannot select Apache Geronimo v1.0 on New Server Runtime dialog.
Cannot select Apache Geronimo v1.0 on New Server Runtime dialog. Key: GERONIMODEVTOOLS-213 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Geronimo Eclipse Plugin 2.0.0 RC3 Reporter: Kan Ogawa Priority: Blocker Attachments: GD-213.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-213) Cannot select Apache Geronimo v1.0 on New Server Runtime dialog.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMODEVTOOLS-213: --- Patch Info: [Patch Available] Cannot select Apache Geronimo v1.0 on New Server Runtime dialog. Key: GERONIMODEVTOOLS-213 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Geronimo Eclipse Plugin 2.0.0 RC3 Reporter: Kan Ogawa Priority: Blocker Attachments: GD-213.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-214) Fictional deployment of EJB-JAR
Fictional deployment of EJB-JAR --- Key: GERONIMODEVTOOLS-214 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-214 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Geronimo 2.0.1 Reporter: Tomasz Mazan When I'm deploying my EJB project, Server Views shows it as deployed, but there no any activity trail on Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-213) Cannot select Apache Geronimo v1.0 on New Server Runtime dialog.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMODEVTOOLS-213: --- Attachment: GD-213-ScreenShot-01.jpg Cannot select Apache Geronimo v1.0 on New Server Runtime dialog. Key: GERONIMODEVTOOLS-213 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Geronimo Eclipse Plugin 2.0.0 RC3 Reporter: Kan Ogawa Priority: Blocker Attachments: GD-213-ScreenShot-01.jpg, GD-213.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-213) Cannot select Apache Geronimo v1.0 on New Server Runtime dialog.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMODEVTOOLS-213: --- Attachment: GD-213-ScreenShot-02.jpg This is screen shot after applying my attached patch. Cannot select Apache Geronimo v1.0 on New Server Runtime dialog. Key: GERONIMODEVTOOLS-213 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Geronimo Eclipse Plugin 2.0.0 RC3 Reporter: Kan Ogawa Priority: Blocker Attachments: GD-213-ScreenShot-01.jpg, GD-213-ScreenShot-02.jpg, GD-213.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-213) Cannot select Apache Geronimo v1.0 on New Server Runtime dialog.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527981 ] Kan Ogawa commented on GERONIMODEVTOOLS-213: Sorry, The screen shot in my first comment means GD-213-ScreenShot-02.jpg. Cannot select Apache Geronimo v1.0 on New Server Runtime dialog. Key: GERONIMODEVTOOLS-213 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Geronimo Eclipse Plugin 2.0.0 RC3 Reporter: Kan Ogawa Priority: Blocker Attachments: GD-213-ScreenShot-01.jpg, GD-213-ScreenShot-02.jpg, GD-213.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.0: Failed for Revision: 576296
OpenEJB trunk at 0
Geronimo Revision: 576296 built with tests included
See the full build-0400.log file at
http://people.apache.org/~prasad/binaries/2.0/20070917/build-0400.log
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://download.java.net/maven/1//commons-dbcp/poms/commons-dbcp-1.3-r562808.pom
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:pom:1.3-r562808'
from repository java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.pom
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:pom:1.3-r562808'
from repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.pom
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:pom:1.3-r562808'
from repository central (http://repo1.maven.org/maven2)
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/prasad/geronimo/2.0/modules/geronimo-openejb/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.openejb.GBeanTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.293 sec
Results :
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-openejb-2.0.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/2.0/modules/geronimo-openejb/target/geronimo-openejb-2.0.2-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-openejb/2.0.2-SNAPSHOT/geronimo-openejb-2.0.2-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: Axis
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/poms/openjpa-persistence-1.0.0-r561970.pom
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-persistence:pom:1.0.0-r561970' from repository
java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-persistence/1.0.0-r561970/openjpa-persistence-1.0.0-r561970.pom
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-persistence:pom:1.0.0-r561970' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-persistence/1.0.0-r561970/openjpa-persistence-1.0.0-r561970.pom
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-persistence:pom:1.0.0-r561970' from repository
central (http://repo1.maven.org/maven2)
Downloading: http://download.java.net/maven/1//axis/poms/axis-saaj-1.4.pom
[WARNING] Unable to get resource 'axis:axis-saaj:pom:1.4' from repository
java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//axis/axis-saaj/1.4/axis-saaj-1.4.pom
[WARNING] Unable to get resource 'axis:axis-saaj:pom:1.4' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/axis/axis-saaj/1.4/axis-saaj-1.4.pom
[WARNING] Unable to get resource 'axis:axis-saaj:pom:1.4' from repository
central (http://repo1.maven.org/maven2)
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-jdbc-5-1.0.0-r561970.jar
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-jdbc-5:jar:1.0.0-r561970' from repository java.net
(http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-jdbc-5/1.0.0-r561970/openjpa-jdbc-5-1.0.0-r561970.jar
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-jdbc-5:jar:1.0.0-r561970' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-jdbc-5/1.0.0-r561970/openjpa-jdbc-5-1.0.0-r561970.jar
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-jdbc-5:jar:1.0.0-r561970' from repository central
(http://www.ibiblio.org/maven2)
[INFO
[jira] Commented: (GERONIMO-2925) Key used for encryption same for all server instances
[ https://issues.apache.org/jira/browse/GERONIMO-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528039 ] Donald Woods commented on GERONIMO-2925: +1 Looks good. Are you going to integrate this into branches/2.0 and trunk? Key used for encryption same for all server instances - Key: GERONIMO-2925 URL: https://issues.apache.org/jira/browse/GERONIMO-2925 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1.1, 1.1.2, 1.1.x, 1.2, 2.0-M5 Reporter: Michael Malgeri Assignee: David Jencks Priority: Critical Attachments: GERONIMO-2925.patch We understand that WASCE use AES to encrypt the password. You do javax.crypto.Cipher.getInstance(AES) and init() with a hard-coded key. This key is same for all the WASCE server instances. Anyone getting access to a downloaded version of the software can have the algorithm and decrypt the password. So we need your urgent help on the following: 1. provide a solution with key management that we can control 2. provide a pluggable encryption solution so that we can use our internal algorithms and key management At least, 3. the key should be dynamically generated in each of the installations that would reduce the ability to decrypt to someone who has access to the server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Obscuring passwords in new ways
Vamsavardhana Reddy wrote:
On 9/15/07, *David Jencks* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Sep 15, 2007, at 10:24 AM, Vamsavardhana Reddy wrote:
David,
Thank you for initiating this discussion and also implementing a
quick solution too. Matt asked if I could start a discussion on
this. I said yes and then went in to a long sleep mode :(. Let
me get to business (before I go to sleep again).
More inline...
On 9/15/07, *David Jencks* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Periodically users show up who want their passwords obscured
in new
ways that allow their systems to break by removing the key used to
obscure them :-) (how's that for a biased view of the
situation :-)
I have to accept that I share your PoV.
They don't like SimpleEncryption because the key is hardcoded and
thus the same for all geronimo instances.
See GERONIMO-2925
I've implemented something for this request that allows you to
register encryptors with the EncryptionManager. By default
you get
the current SimpleEncryption which uses AES with a hardcoded key.
There's also a ConfiguredEncryption gbean that will generate
and save
a key if not present or use a saved one.
You can register any number of Encryption instances with
EncrptionManager but only the first one you register will be
used for
encryption. Others might be used for decryption.
If you try to encrypt a string that is already encrypted under a
different registered Encryption instance it will decrypt using
the
old Encryption and re-encrypt using the registered
Encryption. For
instance the properties file login module used to use
{Standard} as
the prefix instead of {Simple} so I registered the
SimpleEncryption
instance under both prefixes: the property files are re-encrypted
with the {Simple} prefix.
Is this supposed to substitute for changing the key?
Not really, more for changing to a new encryption type from the
Simple default. If you start the server up everything gets
encrypted with SimpleEncryption: it would be nice to support at
least installing a new Encryption later, which is pretty much what
is now supported. If you are careful you can change again. One
question I have is whether the current behavior of first explicitly
installed Encryption is the method used or last explicitly
installed Encryption is the method used is a better policy. I lean
towards first because then a user program can't change it as easily.
Which user program are we referring to?
If you want to use the ConfiguredEncryption you can add this to
config.xml under rmi-naming module:
gbean
name=org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car?
name=ConfiguredEncryption,j2eeType=GBean
gbeanInfo=org.apache.geronimo.system.util.ConfiguredEncryption
attribute
name=pathvar/security/ConfiguredSecretKey.ser/attribute
reference name=ServerInfopatternnameServerInfo/name/
pattern/reference
/gbean
Does it have to be a file under the server installation
directory? At the same time, I don't know if it really matters.
No, if you supply an absolute path ServerInfo will resolve it to
itself.
I haven't tried this with app clients yet but I assume that
adding
this gbean to client would work.
I'd appreciate review on this both for the idea of pluggable
Encryption and even more for my use of crypto which I am
definitely
not an expert in.
thanks
david jencks
1. The changed attributes are stored in config.xml. These will
get overwritten when a new encryptor is used, which is as we
wanted. What about the attributes that are in config.ser objects
which are never changed? Do we have to protect these files too?
Any default passwords in our server distributions that live in
these config.sers's may not be of much concern as we expect the
users to change the default passwords anyway (no point encrypting
something that is well-known :o). I am referring to config.ser's
created upon deploying new configurations.
I think we should advise users to override passwords that may be
stored in config.ser in config.xml. We need to figure out how to do
this easily :-)
Sometime ago I had some code locally (not as part of the server code,
but a simple program that searches for config.ser's in the repository
and encrypts) to encrypt all config.ser's based on a password and write
the salt used to a file in the server's directory. When server
starts, it looks for this salt file and asks for the password
Re: automatic builds with tests
+1 Jarek Gawor wrote: I know that at least the 5am build runs with tests on. I would like to change that so that each build always runs with all tests enabled. Some of the tests in testsuite/ directory actaully start the server so if they are successful we should at least know that the server starts up ok and applications can be deployed to it. That should enable us to quickly catch and address problems as people commit their changes. If people agree on this change, I'm willing to spend whatever time is necessary to make this happen. Jarek smime.p7s Description: S/MIME Cryptographic Signature
[jira] Created: (GERONIMO-3473) CA Helper app should support submitting Certificate Requests from Internet Explorer
CA Helper app should support submitting Certificate Requests from Internet Explorer --- Key: GERONIMO-3473 URL: https://issues.apache.org/jira/browse/GERONIMO-3473 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: sample apps, usability Affects Versions: 2.0.1, 1.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 The CA Helper app currently enable submitting Certificate Requests from browsers (e.g. Firefox) that support KEYGEN tag. Since Internet Explorer does not support KEYGEN tag, requests can not be submitted from IE. Though the certificate and key can be exported from Firefox and imported into IE, it will be better if IE can be used to request and download certificates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
What exactly is going into 2.0.2?
I'm starting to wonder what the goal for 2.0.2 is. I kinda thought that a x.y.z where z 0 was a bugfix-only release of x.y.z-1 but I think some new features are going into 2.0.2... IIUC Vamsi is applying an enhancement to allow specifying work directory per-web- app and donald is encouraging me to apply my proposal to GERONIMO-2925 to the branch. Though small these are definitely new features. Personally I would prefer to minimize such feature creep and have more focus on getting 2.1 out in a less than geological time frame, in particular before apachecon atlanta. What do others think? thanks david jencks
[jira] Updated: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-2964: -- Attachment: GERONIMO-2964-2.0-w-cons-change.patch Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.2, 2.0.x, 2.1 Attachments: g2964.war, GERONIMO-2964-2.0-w-cons-change.patch, GERONIMO-2964-2.0.patch, GERONIMO-2964-combined-new.patch, GERONIMO-2964-combined.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: What exactly is going into 2.0.2?
I agree 2.0.2 should be primarily bug fixes but I don't think it must be limited to only bug fixes. If there are small changes that address customer concerns on security (such as GERONIMO-2925) or usability then I think those can be considered for inclusion. Key is to keep the date Kevan proposed (Friday, 9/21) and resolve any TCK issues. Joe David Jencks wrote: I'm starting to wonder what the goal for 2.0.2 is. I kinda thought that a x.y.z where z 0 was a bugfix-only release of x.y.z-1 but I think some new features are going into 2.0.2... IIUC Vamsi is applying an enhancement to allow specifying work directory per-web-app and donald is encouraging me to apply my proposal to GERONIMO-2925 to the branch. Though small these are definitely new features. Personally I would prefer to minimize such feature creep and have more focus on getting 2.1 out in a less than geological time frame, in particular before apachecon atlanta. What do others think? thanks david jencks
[jira] Updated: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-2964: -- Attachment: GERONIMO-2964-2.0.patch Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.2, 2.0.x, 2.1 Attachments: g2964.war, GERONIMO-2964-2.0.patch, GERONIMO-2964-combined-new.patch, GERONIMO-2964-combined.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3474) Use released openjpa 1.0.0
Use released openjpa 1.0.0 -- Key: GERONIMO-3474 URL: https://issues.apache.org/jira/browse/GERONIMO-3474 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: persistence Affects Versions: 2.0.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0.2, 2.1 Use released openjpa 1.0.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-2964: -- Attachment: GERONIMO-2964-trunk.patch Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.2, 2.0.x, 2.1 Attachments: g2964.war, GERONIMO-2964-2.0-w-cons-change.patch, GERONIMO-2964-2.0.patch, GERONIMO-2964-combined-new.patch, GERONIMO-2964-combined.patch, GERONIMO-2964-trunk.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-2964: -- Attachment: suid.patch Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.2, 2.0.x, 2.1 Attachments: g2964.war, GERONIMO-2964-2.0-w-cons-change.patch, GERONIMO-2964-2.0.patch, GERONIMO-2964-combined-new.patch, GERONIMO-2964-combined.patch, GERONIMO-2964-trunk.patch, GERONIMO-2964.patch, suid.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: automatic builds with tests
+1 On Sep 14, 2007, at 4:43 PM, Jarek Gawor wrote: I know that at least the 5am build runs with tests on. I would like to change that so that each build always runs with all tests enabled. Some of the tests in testsuite/ directory actaully start the server so if they are successful we should at least know that the server starts up ok and applications can be deployed to it. That should enable us to quickly catch and address problems as people commit their changes. If people agree on this change, I'm willing to spend whatever time is necessary to make this happen. Jarek
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528065 ] Paul McMahan commented on GERONIMO-2964: Vamsi, that error messages looks related to http://svn.apache.org/viewvc?view=revrevision=568260 Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.2, 2.0.x, 2.1 Attachments: g2964.war, GERONIMO-2964-2.0-w-cons-change.patch, GERONIMO-2964-2.0.patch, GERONIMO-2964-combined-new.patch, GERONIMO-2964-combined.patch, GERONIMO-2964-trunk.patch, GERONIMO-2964.patch, suid.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3475) expose thread pool size in config.xml/config-substitutions.properties
expose thread pool size in config.xml/config-substitutions.properties - Key: GERONIMO-3475 URL: https://issues.apache.org/jira/browse/GERONIMO-3475 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 Make it easier for users to resize the thread pool -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528080 ] Vamsavardhana Reddy commented on GERONIMO-2964: --- Submitted the last comment accidentally and here is the continuation... 2. ... and the changing geronimo-tomcat-config-1.0.xsd is not necessary. Note: The patches do not address renaming the schemas which will be done at commit. If someone is still concerned about backward compatibility of plugins, I will use (1)GERONIMO-2964-2.0.patch on branches\2.0 instead of (2). Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.2, 2.0.x, 2.1 Attachments: g2964.war, GERONIMO-2964-2.0-w-cons-change.patch, GERONIMO-2964-2.0.patch, GERONIMO-2964-combined-new.patch, GERONIMO-2964-combined.patch, GERONIMO-2964-trunk.patch, GERONIMO-2964.patch, suid.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3476) maybe more flexible auto-bind into global jndi?
maybe more flexible auto-bind into global jndi? --- Key: GERONIMO-3476 URL: https://issues.apache.org/jira/browse/GERONIMO-3476 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: naming Affects Versions: 2.0.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 A long time ago dain wrote some auto-bind-into global jndi gbeans for ejbs and resources. I never liked the idea much but with dblevins' idea of a jndi formatter and maybe an abstract name filter the idea is starting to seem more appealing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528088 ] Vamsavardhana Reddy commented on GERONIMO-2964: --- Please see the comments above. If you have a concern with using GERONIMO-2964-2.0-w-cons-change.patch instead of GERONIMO-2964-2.0.patch on branches\2.0, please voice it now. I will commit the patches at or after 20-Sep-07 20:30 IST (GMT+5:30) . Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.2, 2.0.x, 2.1 Attachments: g2964.war, GERONIMO-2964-2.0-w-cons-change.patch, GERONIMO-2964-2.0.patch, GERONIMO-2964-combined-new.patch, GERONIMO-2964-combined.patch, GERONIMO-2964-trunk.patch, GERONIMO-2964.patch, suid.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Default server log level
I'll be the dissenting opinion :) Personally, I don't like INFO as its too verbose and it is not consistent across projects. If we moved it I would prefer WARN rather than INFO but it largely depends on who we feel the largest user population is.. I'm more concerned about people's impression of G from a performance perspective. Although, I'll concede that production and performance related deployments are probably in the minority relative to the number of developers. I would think changing this would make most sense for 2.1 rather in the 2.0.x stream but it probably won't make a big difference. So, my net, is I like it where it is but won't blow a gasket on changing it. On Sep 11, 2007, at 1:27 PM, Kevan Miller wrote: The intent of this thread is to discuss the default log level for the Geronimo server. I'd like to limit the discussion to the near- term (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging code. I'd like to see more structure and consistency in our logging. However, that's not a 2.0.x issue. The current default log level for a Geronimo 2.0.1 server is ERROR. IMO, this is too restrictive. I think we should set the default to INFO. This will make our server logging more verbose. However, I'd rather have too much information, rather than too little. I think our default target audience should be application developers and new users evaluating Geronimo. Currently, these users are forced to configure log levels to INFO, so that they can obtain necessary information for building and deploying applications on Geronimo. This information should be available by default, not requiring configuration... Users who want to limit the logging output can reconfigure the default logging levels, once they are more comfortable with Geronimo. Comments? --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 14, 2007, at 2:55 AM, Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. +1 to Kevan being RM. Thoughts? --kevan
Re: What exactly is going into 2.0.2?
I agree that 2.0.2 should be limited to bug fixes but I think new features are OK as long as they are very low risk and don't cause any backwards compatibility problems. I think when users pick up a x.y.z +1 release they want and expect minimal risk and disruption. Right now GERONIMO-2925 is classified in JIRA as Type: Bug, Priority: Critical. So if we're OK with that classification then sound like it's a good candidate for 2.0.2. Otherwise let's update the JIRA. As for the directory per web-app feature, the JIRA (GERONIMO-2964) contains a lot of discussion about schema changes and version compatibility, which tends to raise an eyebrow about its inclusion in 2.0.2. But the schema changes may be minor and backwards compatible (?), and the reported problems with plugin compatibility might be a false alarm because the plugins in 2.0.1 may not have been working correctly in the first place? I am still a little confused about that. Once the final solution for that item has been committed to trunk I think it would be a good idea to summarize how it might affect 2.0.1 users (especially w.r.t. backwards compatibility) so that the community and release manager can help weigh in on whether or not it should be merged to the 2.0 branch. Joe, you mentioned TCK and our ability to make 2.0.2 available by 9/21. I have a question for the team about that. I would like to bump Geronimo's version of MyFaces from 1.2.0 to 1.2.1 since that new release contains several bug fixes, some of them actually found and reported by Geronimo users. But doing that could affect Geronimo's TCK results and affect the 9/21 delivery date. I would imagine that the same is true for other dependencies.Are we OK with picking up maintenance releases of Geronimo dependencies in 2.0.2 even if we think TCK issues could slow us down? Or should we keep 2.0.2 focused on localized changes and only bump the dependency versions in Geronimo 2.1 so we have more time to deal any resulting TCK issues? Best wishes, Paul On Sep 17, 2007, at 9:25 AM, Joe Bohn wrote: I agree 2.0.2 should be primarily bug fixes but I don't think it must be limited to only bug fixes. If there are small changes that address customer concerns on security (such as GERONIMO-2925) or usability then I think those can be considered for inclusion. Key is to keep the date Kevan proposed (Friday, 9/21) and resolve any TCK issues. Joe David Jencks wrote: I'm starting to wonder what the goal for 2.0.2 is. I kinda thought that a x.y.z where z 0 was a bugfix-only release of x.y.z-1 but I think some new features are going into 2.0.2... IIUC Vamsi is applying an enhancement to allow specifying work directory per-web-app and donald is encouraging me to apply my proposal to GERONIMO-2925 to the branch. Though small these are definitely new features. Personally I would prefer to minimize such feature creep and have more focus on getting 2.1 out in a less than geological time frame, in particular before apachecon atlanta. What do others think? thanks david jencks
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528079 ] Vamsavardhana Reddy commented on GERONIMO-2964: --- I have attached three patches this time: 1. GERONIMO-2964-2.0.patch: Solves the problem without any constructor or method changes that come in the way of backward compatibility of plugins and to be used on branches\2.0 2. GERONIMO-2964-2.0-w-cons-change.patch: Solves the problem without worrying about anything breaking backward compatibility of plugins as something else seem to break it anyways and also servlet-examples, jsp-examples plugins from 2.0.1 won't run because of the default-subject in the plan. What other plugins do I need to worry about? 3. GERONIMO-2964-trunk.patch: It is essentially (2) above but I had to create a new one coz (2) won't apply neatly on trunk. Here is what these patches solve. They provide for a work-dir tag in web app plans. If the tag is omitted, the behaviour is as it currently exists. If the tag is specified (with value 'myworkdir' say), in G/Tomcat, var/catalina/myworkdir will be used as the work dir for the app and in G/Jetty var/jetty/myworkdir will be used. What's new from the previous patches: 1. David Jencks objected to using jetty.home system property. So, it is no longer used. 2. David Jencks suggested changing geronimo-web-2.0.xsd and Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.2, 2.0.x, 2.1 Attachments: g2964.war, GERONIMO-2964-2.0-w-cons-change.patch, GERONIMO-2964-2.0.patch, GERONIMO-2964-combined-new.patch, GERONIMO-2964-combined.patch, GERONIMO-2964-trunk.patch, GERONIMO-2964.patch, suid.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: What exactly is going into 2.0.2?
Speaking of versions I think we should go to openjpa 1.0.0 the trunk build has been broken for a bit since the -r* snapshot openejb was using seems to have disappeared. I'm working on this... david jencks On Sep 17, 2007, at 11:10 AM, Paul McMahan wrote: I agree that 2.0.2 should be limited to bug fixes but I think new features are OK as long as they are very low risk and don't cause any backwards compatibility problems. I think when users pick up a x.y.z+1 release they want and expect minimal risk and disruption. Right now GERONIMO-2925 is classified in JIRA as Type: Bug, Priority: Critical. So if we're OK with that classification then sound like it's a good candidate for 2.0.2. Otherwise let's update the JIRA. As for the directory per web-app feature, the JIRA (GERONIMO-2964) contains a lot of discussion about schema changes and version compatibility, which tends to raise an eyebrow about its inclusion in 2.0.2. But the schema changes may be minor and backwards compatible(?), and the reported problems with plugin compatibility might be a false alarm because the plugins in 2.0.1 may not have been working correctly in the first place? I am still a little confused about that. Once the final solution for that item has been committed to trunk I think it would be a good idea to summarize how it might affect 2.0.1 users (especially w.r.t. backwards compatibility) so that the community and release manager can help weigh in on whether or not it should be merged to the 2.0 branch. Joe, you mentioned TCK and our ability to make 2.0.2 available by 9/21. I have a question for the team about that. I would like to bump Geronimo's version of MyFaces from 1.2.0 to 1.2.1 since that new release contains several bug fixes, some of them actually found and reported by Geronimo users. But doing that could affect Geronimo's TCK results and affect the 9/21 delivery date. I would imagine that the same is true for other dependencies.Are we OK with picking up maintenance releases of Geronimo dependencies in 2.0.2 even if we think TCK issues could slow us down? Or should we keep 2.0.2 focused on localized changes and only bump the dependency versions in Geronimo 2.1 so we have more time to deal any resulting TCK issues? Best wishes, Paul On Sep 17, 2007, at 9:25 AM, Joe Bohn wrote: I agree 2.0.2 should be primarily bug fixes but I don't think it must be limited to only bug fixes. If there are small changes that address customer concerns on security (such as GERONIMO-2925) or usability then I think those can be considered for inclusion. Key is to keep the date Kevan proposed (Friday, 9/21) and resolve any TCK issues. Joe David Jencks wrote: I'm starting to wonder what the goal for 2.0.2 is. I kinda thought that a x.y.z where z 0 was a bugfix-only release of x.y.z-1 but I think some new features are going into 2.0.2... IIUC Vamsi is applying an enhancement to allow specifying work directory per-web-app and donald is encouraging me to apply my proposal to GERONIMO-2925 to the branch. Though small these are definitely new features. Personally I would prefer to minimize such feature creep and have more focus on getting 2.1 out in a less than geological time frame, in particular before apachecon atlanta. What do others think? thanks david jencks
Re: What exactly is going into 2.0.2?
On 9/17/07, Paul McMahan [EMAIL PROTECTED] wrote: I agree that 2.0.2 should be limited to bug fixes but I think new features are OK as long as they are very low risk and don't cause any backwards compatibility problems. I think when users pick up a x.y.z +1 release they want and expect minimal risk and disruption. Right now GERONIMO-2925 is classified in JIRA as Type: Bug, Priority: Critical. So if we're OK with that classification then sound like it's a good candidate for 2.0.2. Otherwise let's update the JIRA. As for the directory per web-app feature, the JIRA (GERONIMO-2964) contains a lot of discussion about schema changes and version compatibility, which tends to raise an eyebrow about its inclusion in 2.0.2. But the schema changes may be minor and backwards compatible (?), and the reported problems with plugin compatibility might be a false alarm because the plugins in 2.0.1 may not have been working correctly in the first place? I am still a little confused about that. Once the final solution for that item has been committed to trunk I think it would be a good idea to summarize how it might affect 2.0.1 users (especially w.r.t. backwards compatibility) so that the community and release manager can help weigh in on whether or not it should be merged to the 2.0 branch. I don't think the schema changes will come in the way of backward compatibility of plugins. I have proposed a patch for branches\2.0 without changing constructors or methods so that it won't come in the way of compatibility. But in the process I noticed that jsp-examples and servlet-examples cars from 2.0.1 won't run on G 2.0.1 due to a default-subject in the plans and won't install on 2.0.2-SNAPSHOT due to a change to Holder class. There may be other plugins that may unearth other changes that have already broken compatibility. If someone is going to take up finding and fixing all those compatibility breaking changes, it may be worth considering the no constructor change patch for trunk too. Also, it may be a good idea to add some tests for the compatibility we want to preserve across versions!! Joe, you mentioned TCK and our ability to make 2.0.2 available by 9/21. I have a question for the team about that. I would like to bump Geronimo's version of MyFaces from 1.2.0 to 1.2.1 since that new release contains several bug fixes, some of them actually found and reported by Geronimo users. But doing that could affect Geronimo's TCK results and affect the 9/21 delivery date. I would imagine that the same is true for other dependencies.Are we OK with picking up maintenance releases of Geronimo dependencies in 2.0.2 even if we think TCK issues could slow us down? Or should we keep 2.0.2 focused on localized changes and only bump the dependency versions in Geronimo 2.1 so we have more time to deal any resulting TCK issues? Best wishes, Paul On Sep 17, 2007, at 9:25 AM, Joe Bohn wrote: I agree 2.0.2 should be primarily bug fixes but I don't think it must be limited to only bug fixes. If there are small changes that address customer concerns on security (such as GERONIMO-2925) or usability then I think those can be considered for inclusion. Key is to keep the date Kevan proposed (Friday, 9/21) and resolve any TCK issues. Joe David Jencks wrote: I'm starting to wonder what the goal for 2.0.2 is. I kinda thought that a x.y.z where z 0 was a bugfix-only release of x.y.z-1 but I think some new features are going into 2.0.2... IIUC Vamsi is applying an enhancement to allow specifying work directory per-web-app and donald is encouraging me to apply my proposal to GERONIMO-2925 to the branch. Though small these are definitely new features. Personally I would prefer to minimize such feature creep and have more focus on getting 2.1 out in a less than geological time frame, in particular before apachecon atlanta. What do others think? thanks david jencks
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/
On Sep 14, 2007, at 7:58 PM, Kevan Miller wrote: Heh. Well, I had hopes for Paul's proposal... Sounds like it's still better than where we are now... I was also thinking that it's a step forward, but now it's not clear to me whether moving the spring filter to cxf-deployer would break cxf's spring-related stuff, or just leave us with some non-critical issues to resolve. If it's the latter case then can we commit as an interim step so the admin console can start working again? I think the right way to address the problem is at the CXF module, itself (which we've talked about on other threads). Basic idea is that the CXF module would declare the classes that it will hide from classloader children. You'd specify something like: child-hidden-classes filterorg.springframework./filter filterMETA-INF/spring/filter /child-hidden-classes The CXF module classloader would hide these classes/resources from child classloaders. We could also consider separating hidden- classes and hidden-resources... I think that the more we can attach the filters to the actual components that need them the better, so I really like your idea. Another variation would be to extend the inverse-classloading element that Geronimo currently supports to include filters that affect whether child components get the parents' or their own versions of certain classes. i.e. something like: inverse-classloading filterorg.springframework./filter /inverse-classloading would tell Geronimo to prefer loading the spring classes from the child's classloader. Other final (?) thing to consider is creating a Spring module. Both cxf and pluto-support could depend on this new module... I thought about this too but couldn't think of a way for apps to share the Spring classes in a classloader without potentially stomping on each other's spring configuration and bean factories. Best wishes, Paul
Re: [VOTE] Release Geronimo Eclipse Plugin 2.0.0 (RC3)
+1 Could successfully execute all steps listed in http://cwiki.apache.org/geronimo/java-ee-50-app-development-on-geronimo-simplified-using-eclipse.html Test results and other observations posted in [Discuss] Release Geronimo Eclipse Plugin 2.0.0 (RC3) thread as per Vamsi's suggestion. - Shiva On 9/15/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi, Please review and vote on the release of the Geronimo Eclipse Plugin 2.0.0 RC3 (to correspond with the Geronimo 2.0.1 Server release). The deployable zip file is here: http://people.apache.org/~mcconne/releases/RC3/geronimo-eclipse-plugin-2.0.0-deployable-RC3.zip The update site zip file is here: http://people.apache.org/~mcconne/releases/RC3/geronimo-eclipse-plugin-2.0.0-updatesite-RC3.zip The current svn location is here (revision number 575886): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.0.0 The future svn location will be here: https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.0.0 Install, ant build, and Staging Site instructions are here: - http://people.apache.org/~mcconne/releases/RC3/Geronimo_Eclipse_Plugin_2.0.0_Instructions-RC3.txt The vote will conclude at 04:00 AM EST on Tuesday, September 18th -- Thanks, Tim McConnell
Re: [DISCUSS] G 2.0.2 Release plan
+1 on the release +1 on Kevan as RM Also, I'd like to help out on TCK testing. I've never done it before but I have sent in my NDA. Matt Hogstrom wrote: On Sep 14, 2007, at 2:55 AM, Kevan Miller wrote: All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. +1 to Kevan being RM. Thoughts? --kevan
[Discuss] Release Geronimo Eclipse Plugin 2.0.0 (RC3)
Tim, The Install prerequisites section of http://people.apache.org/~mcconne/releases/RC3/Geronimo_Eclipse_Plugin_2.0.0_Instructions-RC3.txt needs following updates: 1) 1 -- Europa (also known as Eclipse 3.3), which is platform specific Need to mention package name as Eclipse Classic to avoid confusions as raised in RC2 voting thread. Also, shouldn't the version be changed to 3.3.1? Please see http://www.eclipse.org/eclipse/development/freeze_plan_3_3_1.html So, this could look something like: 1 -- Eclipse 3.3.1 (Eclipse Classic package of Europa distribution), which is platform specific http://www.eclipse.org/eclipse/development/freeze_plan_3_3_1.html 2) 3 -- Data Tools Platform (DTP) 1.5 Should be 3 -- Data Tools Platform (DTP) 1.5.1 3) 4 -- Eclipse Modeling Framework (EMF) 2.3 Should be 4 -- Eclipse Modeling Framework (EMF) 2.3.1 http://www.eclipse.org/modeling/emf/downloads/?project= lists emf-sdo-xsd-SDK-M200709120130.zip under 2.3.1 Maintenance Builds 4) 5 -- Graphical Editing Framework (GEF) 3.3 Should be 5 -- Graphical Editing Framework (GEF) 3.3.1 http://download.eclipse.org/tools/gef/downloads/index.php lists GEF-SDK-M20070814-1555.zip under 3.3.1 Stream Maintenance Builds 5) That is why this ant script downloads and installs the WTP 2.0.1 RC1 artifacts. Should be: That is why this ant script downloads and installs the WTP 2.0.1 RC2 artifacts. - Shiva
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/
Paul, In the new admin console, do the web applications (that provide portlets) need to share Spring version/configuration with the Pluto config module? What if each web application had its own Spring jars? Would that work? Moving the Spring filters to cxf-deployer is better from the modularity point of view (and I'm all for it) but the end results will be the same in this case. I think Kevan's idea might be the best solution here. Jarek On 9/17/07, Paul McMahan [EMAIL PROTECTED] wrote: On Sep 14, 2007, at 7:58 PM, Kevan Miller wrote: Heh. Well, I had hopes for Paul's proposal... Sounds like it's still better than where we are now... I was also thinking that it's a step forward, but now it's not clear to me whether moving the spring filter to cxf-deployer would break cxf's spring-related stuff, or just leave us with some non-critical issues to resolve. If it's the latter case then can we commit as an interim step so the admin console can start working again? I think the right way to address the problem is at the CXF module, itself (which we've talked about on other threads). Basic idea is that the CXF module would declare the classes that it will hide from classloader children. You'd specify something like: child-hidden-classes filterorg.springframework./filter filterMETA-INF/spring/filter /child-hidden-classes The CXF module classloader would hide these classes/resources from child classloaders. We could also consider separating hidden- classes and hidden-resources... I think that the more we can attach the filters to the actual components that need them the better, so I really like your idea. Another variation would be to extend the inverse-classloading element that Geronimo currently supports to include filters that affect whether child components get the parents' or their own versions of certain classes. i.e. something like: inverse-classloading filterorg.springframework./filter /inverse-classloading would tell Geronimo to prefer loading the spring classes from the child's classloader. Other final (?) thing to consider is creating a Spring module. Both cxf and pluto-support could depend on this new module... I thought about this too but couldn't think of a way for apps to share the Spring classes in a classloader without potentially stomping on each other's spring configuration and bean factories. Best wishes, Paul
Re: What exactly is going into 2.0.2?
I'm moving this to the '[DISCUSS] G 2.0.2 Release Plan' mail thread. --kevan
[jira] Updated: (SM-1054) Port JmsMarshaler from lightweight jms component to servicemix-jms component
[ https://issues.apache.org/activemq/browse/SM-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Peterson updated SM-1054: -- Attachment: SM-1054.patch Contributed patch Port JmsMarshaler from lightweight jms component to servicemix-jms component - Key: SM-1054 URL: https://issues.apache.org/activemq/browse/SM-1054 Project: ServiceMix Issue Type: Improvement Components: servicemix-jms Affects Versions: 3.1.1 Reporter: Jeff Peterson Fix For: 3.2 Attachments: SM-1054.patch Many legacy JMS systems have non-xml messages (e.g. ObjectMessage) floating around on their queues and topics. The servicemix-jms component needs a way to marshall those jms messages to normalized messages. The lightweight jms component currently has a marshaller layer to perform these actions. Please port it to the servicemix-jms component. See: http://www.nabble.com/MapMessage-and-or-ObjectMessage-tf2226788s12049.html#a6188688 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build problem on Trunk
I guess I am the only one for now hitting this build error. Anyone else
seeing this error? Output from command window posted below..
I am using Sun JDK 1.5.0_12 on WinXP SP2.
[INFO]
-
---
[INFO] Building Geronimo :: Deploy :: JSR-88
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 25 source files to
C:\G\server\trunk\modules\geronimo-deploy-js
r88\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
Failure executing javac, but could not parse the error:
An exception has occurred in the compiler (1.5.0_12). Please file a bug at
the J
ava Developer Connection (http://java.sun.com/webapps/bugreport) after
checking
the Bug Parade for duplicates. Include your program and the following
diagnosti
c in your report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: file
javax\xml\bind\annotatio
n\XmlAccessorType.class not found
Failure executing javac, but could not parse the error:
An exception has occurred in the compiler (1.5.0_12). Please file a bug at
the J
ava Developer Connection (http://java.sun.com/webapps/bugreport) after
checking
the Bug Parade for duplicates. Include your program and the following
diagnosti
c in your report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: file
javax\xml\bind\annotatio
n\XmlAccessorType.class not found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 4 minutes 9 seconds
[INFO] Finished at: Mon Sep 17 22:57:49 IST 2007
[INFO] Final Memory: 97M/174M
[INFO]
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.0.0 (RC3)
I have successfully deployed and invoked these applications with RC3: -- Daytrader -- calculator-stateless-pojo -- Thanks, Tim McConnell
Re: [VOTE] Release Geronimo Eclipse Plugin 2.0.0 (RC3)
+1 Tim McConnell wrote: Hi, Please review and vote on the release of the Geronimo Eclipse Plugin 2.0.0 RC3 (to correspond with the Geronimo 2.0.1 Server release). The deployable zip file is here: http://people.apache.org/~mcconne/releases/RC3/geronimo-eclipse-plugin-2.0.0-deployable-RC3.zip The update site zip file is here: http://people.apache.org/~mcconne/releases/RC3/geronimo-eclipse-plugin-2.0.0-updatesite-RC3.zip The current svn location is here (revision number 575886): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.0.0 The future svn location will be here: https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.0.0 Install, ant build, and Staging Site instructions are here: - http://people.apache.org/~mcconne/releases/RC3/Geronimo_Eclipse_Plugin_2.0.0_Instructions-RC3.txt The vote will conclude at 04:00 AM EST on Tuesday, September 18th -- Thanks, Tim McConnell
Re: What exactly is going into 2.0.2?
On 9/17/07, Paul McMahan [EMAIL PROTECTED] wrote: snip Joe, you mentioned TCK and our ability to make 2.0.2 available by 9/21. I have a question for the team about that. I would like to bump Geronimo's version of MyFaces from 1.2.0 to 1.2.1 since that new release contains several bug fixes, some of them actually found and reported by Geronimo users. But doing that could affect Geronimo's TCK results and affect the 9/21 delivery date. I would imagine that the same is true for other dependencies.Are we OK with picking up maintenance releases of Geronimo dependencies in 2.0.2 even if we think TCK issues could slow us down? Or should we keep 2.0.2 focused on localized changes and only bump the dependency versions in Geronimo 2.1 so we have more time to deal any resulting TCK issues? In general, I think it's fine to bump dependencies to a later version. Especially, if there are bug fixes we know about. We're also motivated to pick up released versions of projects which we're currently carrying -r* builds in our svn repository... --kevan
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/
On Sep 17, 2007, at 12:48 PM, Jarek Gawor wrote: Paul, In the new admin console, do the web applications (that provide portlets) need to share Spring version/configuration with the Pluto config module? What if each web application had its own Spring jars? Would that work? Actually the portlet webapps don't need to share Spring, they need to share Pluto. Pluto needs to be in a parent configuration for those webapps so that they can know about each other's portlets via the classloader. The tricky part here is that Pluto uses Spring internally for configuration and needs for it to be in the same classloader as the Pluto jars. So this is not a clear cut case of apps needing to share Spring but rather apps needing to share something that depends on Spring. In fact this might be a more common scenario than sharing Spring itself since nowadays many components use Spring for configuration. Moving the Spring filters to cxf-deployer is better from the modularity point of view (and I'm all for it) but the end results will be the same in this case. I think Kevan's idea might be the best solution here. The end results here being that Spring-based webapps that contain web services would inherit cxf's copy of Spring? Or that cxf could not use Spring to configure itself? Or something else? I'm still not clear on what breaks or becomes more difficult if we move the filter to cxf-deployer or remove it altogether. I'm wondering if we can target our solution only at assemblies that contain cxf since the current solution affects the minimal and axis based assemblies where it may not be needed. I guess that's in line with your comment about modularity, and I agree with you and Kevan that a new classloader knob for deployment plans is probably the best way to accomplish this. Best wishes, Paul
Re: What exactly is going into 2.0.2?
Paul McMahan wrote: Joe, you mentioned TCK and our ability to make 2.0.2 available by 9/21. I have a question for the team about that. I would like to bump Geronimo's version of MyFaces from 1.2.0 to 1.2.1 since that new release contains several bug fixes, some of them actually found and reported by Geronimo users. But doing that could affect Geronimo's TCK results and affect the 9/21 delivery date. I would imagine that the same is true for other dependencies.Are we OK with picking up maintenance releases of Geronimo dependencies in 2.0.2 even if we think TCK issues could slow us down? Or should we keep 2.0.2 focused on localized changes and only bump the dependency versions in Geronimo 2.1 so we have more time to deal any resulting TCK issues? I think it makes sense to move to the latest version of the Geronimo dependencies. However, it probably makes sense to validate areas in the TCK that may be impacted prior to the change or soon there-after in case there are issues that need to be resolve which might impact our ability to deliver in a timely manner. Joe
Re: [Discuss] Release Geronimo Eclipse Plugin 2.0.0 (RC3)
Some more observations while testing Geronimo Eclipse Plugin 2.0.0 (RC3): a) When defining a new server, Apache Geronimo v1.2 Server doesn't get listed in the list of available servers. b) Looks like WTP 2.0.1RC2 has solved the problem reported in GERONIMODEVTOOLS-209 if the HelloWorld WAR's geronimo-web.xml uses 1.1Geronimo schemas. However, if geronimo-web.xml is edited to use 2.0 version of Geronimo schemas, then Run As - Run on Server won't open internal browser. c) Another very important thing related to eclipse.ini settings. The default contents of eclipse.ini is shown below: -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m -vmargs -Xms40m -Xmx256m This is *really* messy. With the default provided settings as above, my Eclipse crashed about 7 times! with java.lang.OutOfMemoryError: PermGen space errors and I was not at all able to complete the steps mentioned in http://cwiki.apache.org/geronimo/java-ee-50-app-development-on-geronimo-simplified-using-eclipse.html However, as suggested by Tim, I created a shortcut to eclipse.exe as below E:\IDEs\eclipse3.3.1_WTP2.0.1RC2_gep2.0rc3\eclipse.exe -vmargs -Xms256m -Xmx256m -XX:MaxPermSize=128m And when I use this shortcut, everything worked great and I was able to complete http://cwiki.apache.org/geronimo/java-ee-50-app-development-on-geronimo-simplified-using-eclipse.htmlin one-go in less than 30 minutes. So the key is to correctly set -vmargs -Xms256m -Xmx256m -XX:MaxPermSize=128m arguments. We need to figure out how to set these in eclipse.ini itself and recommend them strongly to users in Release Notes as well as in http://people.apache.org/~mcconne/releases/RC3/Geronimo_Eclipse_Plugin_2.0.0_Instructions-RC3.txt If we can also update http://people.apache.org/~mcconne/releases/RC3/build.xml to automagically edit eclipse.ini with the correct settings, that would just be great! Thanks, Shiva On 9/17/07, Shiva Kumar H R [EMAIL PROTECTED] wrote: Tim, The Install prerequisites section of http://people.apache.org/~mcconne/releases/RC3/Geronimo_Eclipse_Plugin_2.0.0_Instructions-RC3.txt http://people.apache.org/%7Emcconne/releases/RC3/Geronimo_Eclipse_Plugin_2.0.0_Instructions-RC3.txt needs following updates: 1) 1 -- Europa (also known as Eclipse 3.3), which is platform specific Need to mention package name as Eclipse Classic to avoid confusions as raised in RC2 voting thread. Also, shouldn't the version be changed to 3.3.1? Please see http://www.eclipse.org/eclipse/development/freeze_plan_3_3_1.html So, this could look something like: 1 -- Eclipse 3.3.1 (Eclipse Classic package of Europa distribution), which is platform specific http://www.eclipse.org/eclipse/development/freeze_plan_3_3_1.html 2) 3 -- Data Tools Platform (DTP) 1.5 Should be 3 -- Data Tools Platform (DTP) 1.5.1 3) 4 -- Eclipse Modeling Framework (EMF) 2.3 Should be 4 -- Eclipse Modeling Framework (EMF) 2.3.1 http://www.eclipse.org/modeling/emf/downloads/?project= lists emf-sdo-xsd-SDK-M200709120130.zip under 2.3.1 Maintenance Builds 4) 5 -- Graphical Editing Framework (GEF) 3.3 Should be 5 -- Graphical Editing Framework (GEF) 3.3.1 http://download.eclipse.org/tools/gef/downloads/index.php lists GEF-SDK-M20070814-1555.zip under 3.3.1 Stream Maintenance Builds 5) That is why this ant script downloads and installs the WTP 2.0.1 RC1 artifacts. Should be: That is why this ant script downloads and installs the WTP 2.0.1 RC2 artifacts. - Shiva
Re: What exactly is going into 2.0.2?
On 9/17/07, David Jencks [EMAIL PROTECTED] wrote: Speaking of versions I think we should go to openjpa 1.0.0 the trunk build has been broken for a bit since the -r* snapshot openejb was using seems to have disappeared. Hmm. A while back, I moved branches/2.0 and trunk to OpenJPA 1.0.0-SNAPSHOT and deleted the private builds from our repo (or at least thought i did). I moved the version to 1.0.0 earlier today. I confess that I didn't build trunk. But I did build branches/2.0 without a problem. I'm reinstalling the OS on my dev machine. So, I can't really check on this, ATM. --kevan
[jira] Closed: (GERONIMO-3474) Use released openjpa 1.0.0
[ https://issues.apache.org/jira/browse/GERONIMO-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3474. -- Resolution: Fixed kevan did this. Use released openjpa 1.0.0 -- Key: GERONIMO-3474 URL: https://issues.apache.org/jira/browse/GERONIMO-3474 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0.2, 2.1 Use released openjpa 1.0.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] G 2.0.2 Release plan
Moved from another mail thread... On 9/17/07, David Jencks [EMAIL PROTECTED] wrote: I'm starting to wonder what the goal for 2.0.2 is. I kinda thought that a x.y.z where z 0 was a bugfix-only release of x.y.z-1 but I think some new features are going into 2.0.2... IIUC Vamsi is applying an enhancement to allow specifying work directory per-web- app and donald is encouraging me to apply my proposal to GERONIMO-2925 to the branch. Though small these are definitely new features. The goal of 2.0.2 is to get fixes into user's hands. In general, I agree with you. 2.0.x releases are bug-fix releases. You're raising two questions: 1) what is a bug fix? and 2) how dogmatic do we want to be in our bug-fix release management? Regarding 1), I think we'd agree that there isn't necessarily an objective measure for determining what is or isn't a bug fix. Re: 2), we could be pretty conservative on our interpretation of bug fix or we can be a bit more permissive on what we interpret as a bug fix. Personally, I probably fall into a more permissive side of that decision (at least at this point in time of our 2.x lifetime -- I expect I'll have a different answer when 2.4 rolls around...). In the meantime, if users are encountering issues or experiencing pain because of missing features (perhaps features that were overlooked), then I'm not averse to alleviating this pain in a 2.0.x release. More important metric, IMO, is are we helping our users? I haven't looked closely at either of the issues that you highlight. If you'd like me to, I'll evaluate and give my opinion with a release manager hat on -- barring objections...) Personally I would prefer to minimize such feature creep and have more focus on getting 2.1 out in a less than geological time frame, in particular before apachecon atlanta. I haven't seen a discussion or proposal for a 2.1 release. So, it's hard for me to evaluate if ApacheCon is a reasonable date for 2.1. I don't think that a 2.1 schedule is, by itself, a reason to not do work in 2.0.x -- especially at this point. When we have a target 2.1 release date and are getting closer to that date, then I'm sure I'd feel differently... --kevan
Re: Build problem on Trunk
On Sep 17, 2007, at 1:35 PM, Vamsavardhana Reddy wrote: I guess I am the only one for now hitting this build error. Anyone else seeing this error? Output from command window posted below.. I just rebuilt trunk and didn't see an error using sun javac 1.5.0_07 on osx. Best wishes, Paul
Re: Build problem on Trunk
This is the error I got from today's trunk on win xp and java
1.5.0_08-b03 -
[INFO] [compiler:testCompile]
Compiling 16 source files to
C:\anita\geronimo\g2.0\modules\geronimo-system\targ
et\test-classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
C:\anita\geronimo\g2.0\modules\geronimo-system\src\test\java\org\apache\geronimo
\system\plugin\CopyConfigTest.java:[258,69] incompatible types
found : java.util.Listjava.io.Serializable
required: java.util.Listjava.lang.Object
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I guess I am the only one for now hitting this build error. Anyone
else
seeing this error? Output from command window posted below..
I am using Sun JDK 1.5.0_12 on WinXP SP2.
[INFO]
-
---
[INFO] Building Geronimo :: Deploy :: JSR-88
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 25 source files to
C:\G\server\trunk\modules\geronimo-deploy-js
r88\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
Failure executing javac, but could not parse the error:
An exception has occurred in the compiler (1.5.0_12). Please file a
bug at
the J
ava Developer Connection (http://java.sun.com/webapps/bugreport)
after
checking
the Bug Parade for duplicates. Include your program and the
following
diagnosti
c in your report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: file
javax\xml\bind\annotatio
n\XmlAccessorType.class not found
Failure executing javac, but could not parse the error:
An exception has occurred in the compiler (1.5.0_12). Please file a
bug at
the J
ava Developer Connection (http://java.sun.com/webapps/bugreport)
after
checking
the Bug Parade for duplicates. Include your program and the
following
diagnosti
c in your report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: file
javax\xml\bind\annotatio
n\XmlAccessorType.class not found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 4 minutes 9 seconds
[INFO] Finished at: Mon Sep 17 22:57:49 IST 2007
[INFO] Final Memory: 97M/174M
[INFO]
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/
Re: What exactly is going into 2.0.2?
FYI - for 2.0.2, We are looking at moving to newer versions of tranql artifacts which contains a fix for G2188. Hopefully this won't impact tck. Thanks, Lin Kevan Miller wrote: On 9/17/07, Paul McMahan [EMAIL PROTECTED] wrote: snip Joe, you mentioned TCK and our ability to make 2.0.2 available by 9/21. I have a question for the team about that. I would like to bump Geronimo's version of MyFaces from 1.2.0 to 1.2.1 since that new release contains several bug fixes, some of them actually found and reported by Geronimo users. But doing that could affect Geronimo's TCK results and affect the 9/21 delivery date. I would imagine that the same is true for other dependencies.Are we OK with picking up maintenance releases of Geronimo dependencies in 2.0.2 even if we think TCK issues could slow us down? Or should we keep 2.0.2 focused on localized changes and only bump the dependency versions in Geronimo 2.1 so we have more time to deal any resulting TCK issues? In general, I think it's fine to bump dependencies to a later version. Especially, if there are bug fixes we know about. We're also motivated to pick up released versions of projects which we're currently carrying -r* builds in our svn repository... --kevan
[BUILD] 2.0: Failed for Revision: 576555
OpenEJB trunk at 0
Geronimo Revision: 576555 built with tests skipped
See the full build-1400.log file at
http://people.apache.org/~prasad/binaries/2.0/20070917/build-1400.log
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-transformer-2.0.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/2.0/modules/geronimo-transformer/target/geronimo-transformer-2.0.2-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-transformer/2.0.2-SNAPSHOT/geronimo-transformer-2.0.2-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: Persistence 3.0
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-persistence-jpa10-2.0.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/2.0/modules/geronimo-persistence-jpa10/target/geronimo-persistence-jpa10-2.0.2-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-persistence-jpa10/2.0.2-SNAPSHOT/geronimo-persistence-jpa10-2.0.2-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: OpenEJB
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://download.java.net/maven/1//commons-dbcp/poms/commons-dbcp-1.3-r562808.pom
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:pom:1.3-r562808'
from repository java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.pom
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:pom:1.3-r562808'
from repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.pom
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:pom:1.3-r562808'
from repository central (http://repo1.maven.org/maven2)
Downloading:
http://download.java.net/maven/1//commons-dbcp/jars/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository/commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository apache-incubating-repository
(http://people.apache.org/repo/m2-incubating-repository)
Downloading:
http://tomcat.apache.org/dev/dist/m2-repository/commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository tomcat-private-repository
(http://tomcat.apache.org/dev/dist/m2-repository)
Downloading:
http://svn.apache.org/repos/asf/openejb/repo//commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository openejb-3rdparty-builds
(http://svn.apache.org/repos/asf/openejb/repo/)
Downloading:
http://repo1.maven.org/maven2/commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository central (http://repo1.maven.org/maven2)
[INFO
[jira] Commented: (GERONIMO-2188) When oracle wrapper is used, commits are not immediately committed to oracle database
[ https://issues.apache.org/jira/browse/GERONIMO-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528121 ] Lin Sun commented on GERONIMO-2188: --- Verified this is fixed in tranql connector trunk and oracle vendor wrapper trunk. This defect should be closed whenever we release a newer version of tranql vendor wrappers and the connector jar and the generic wrapper and we change geronimo to use them. Assign back to David for his help on releasing newer versions of tranql artifacts. Thanks! When oracle wrapper is used, commits are not immediately committed to oracle database - Key: GERONIMO-2188 URL: https://issues.apache.org/jira/browse/GERONIMO-2188 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1.1 Reporter: Krishnakumar B Assignee: Lin Sun Attachments: G2188-2.patch, G2188-latest.patch, G2188.patch We have to configure CommitBeforeAutCommit=true property exclusively in the database connection pool plan, to have the ejb -based transactions immediately committed for oracle database. Otherwise it only commits transaction when the server shuts-down. This problem is not faces with Derby database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2188) When oracle wrapper is used, commits are not immediately committed to oracle database
[ https://issues.apache.org/jira/browse/GERONIMO-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun reassigned GERONIMO-2188: - Assignee: David Jencks (was: Lin Sun) When oracle wrapper is used, commits are not immediately committed to oracle database - Key: GERONIMO-2188 URL: https://issues.apache.org/jira/browse/GERONIMO-2188 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1.1 Reporter: Krishnakumar B Assignee: David Jencks Attachments: G2188-2.patch, G2188-latest.patch, G2188.patch We have to configure CommitBeforeAutCommit=true property exclusively in the database connection pool plan, to have the ejb -based transactions immediately committed for oracle database. Otherwise it only commits transaction when the server shuts-down. This problem is not faces with Derby database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/
On 9/17/07, Paul McMahan [EMAIL PROTECTED] wrote: Moving the Spring filters to cxf-deployer is better from the modularity point of view (and I'm all for it) but the end results will be the same in this case. I think Kevan's idea might be the best solution here. The end results here being that Spring-based webapps that contain web services would inherit cxf's copy of Spring? Or that cxf could not use Spring to configure itself? Or something else? I'm still not clear on what breaks or becomes more difficult if we move the filter to cxf-deployer or remove it altogether. Moving the filter from web deployer to cxf deployer will have no effect on your app. The application will always end up with the same filter in either setup. It will only work ok, if the filter is in cxf-deployer *and* if you use Tomcat or configure Axis2 as the JAX-WS engine. So moving the filter is better but it's definitely not a fool proof solution. Maybe for now we should remove the filtering from web deployers and let each application configure the Spring filtering if necessary. Jarek
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/
On Sep 17, 2007, at 4:15 PM, Jarek Gawor wrote: Moving the filter from web deployer to cxf deployer will have no effect on your app. The application will always end up with the same filter in either setup. It will only work ok, if the filter is in cxf-deployer *and* if you use Tomcat or configure Axis2 as the JAX-WS engine. So moving the filter is better but it's definitely not a fool proof solution. OK thanks for the clarification. Maybe for now we should remove the filtering from web deployers and let each application configure the Spring filtering if necessary. Agreed and the idea about using a configuration for spring could be promising too. Best wishes, Paul
[BUILD] Trunk: Failed for Revision: 576583
OpenEJB trunk at 0
Geronimo Revision: 576555 built with tests skipped
See the full build-1400.log file at
http://people.apache.org/~prasad/binaries/2.0/20070917/build-1400.log
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-transformer-2.0.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/2.0/modules/geronimo-transformer/target/geronimo-transformer-2.0.2-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-transformer/2.0.2-SNAPSHOT/geronimo-transformer-2.0.2-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: Persistence 3.0
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-persistence-jpa10-2.0.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/2.0/modules/geronimo-persistence-jpa10/target/geronimo-persistence-jpa10-2.0.2-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-persistence-jpa10/2.0.2-SNAPSHOT/geronimo-persistence-jpa10-2.0.2-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: OpenEJB
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://download.java.net/maven/1//commons-dbcp/poms/commons-dbcp-1.3-r562808.pom
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:pom:1.3-r562808'
from repository java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.pom
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:pom:1.3-r562808'
from repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.pom
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:pom:1.3-r562808'
from repository central (http://repo1.maven.org/maven2)
Downloading:
http://download.java.net/maven/1//commons-dbcp/jars/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository/commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository apache-incubating-repository
(http://people.apache.org/repo/m2-incubating-repository)
Downloading:
http://tomcat.apache.org/dev/dist/m2-repository/commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository tomcat-private-repository
(http://tomcat.apache.org/dev/dist/m2-repository)
Downloading:
http://svn.apache.org/repos/asf/openejb/repo//commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository openejb-3rdparty-builds
(http://svn.apache.org/repos/asf/openejb/repo/)
Downloading:
http://repo1.maven.org/maven2/commons-dbcp/commons-dbcp/1.3-r562808/commons-dbcp-1.3-r562808.jar
[WARNING] Unable to get resource 'commons-dbcp:commons-dbcp:jar:1.3-r562808'
from repository central (http://repo1.maven.org/maven2)
[INFO
Re: Build problem on Trunk
I updated and built earlier today without any problems. I built rev.
576541 with Sun JDK 1.5.0_11 on OSX 10.4.10
Joe
Vamsavardhana Reddy wrote:
I guess I am the only one for now hitting this build error. Anyone else
seeing this error? Output from command window posted below..
I am using Sun JDK 1.5.0_12 on WinXP SP2.
[INFO]
-
---
[INFO] Building Geronimo :: Deploy :: JSR-88
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 25 source files to
C:\G\server\trunk\modules\geronimo-deploy-js
r88\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
Failure executing javac, but could not parse the error:
An exception has occurred in the compiler (1.5.0_12). Please file a bug
at the J
ava Developer Connection ( http://java.sun.com/webapps/bugreport) after
checking
the Bug Parade for duplicates. Include your program and the following
diagnosti
c in your report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: file
javax\xml\bind\annotatio
n\XmlAccessorType.class not found
Failure executing javac, but could not parse the error:
An exception has occurred in the compiler (1.5.0_12). Please file a bug
at the J
ava Developer Connection (http://java.sun.com/webapps/bugreport) after
checking
the Bug Parade for duplicates. Include your program and the following
diagnosti
c in your report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: file
javax\xml\bind\annotatio
n\XmlAccessorType.class not found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 4 minutes 9 seconds
[INFO] Finished at: Mon Sep 17 22:57:49 IST 2007
[INFO] Final Memory: 97M/174M
[INFO]
[BUILD] Trunk: Failed for Revision: 576584
OpenEJB trunk at 576572
Geronimo Revision: 576584 built with tests included
See the full build-1600.log file at
http://people.apache.org/~prasad/binaries/trunk/20070917/build-1600.log
[INFO] Surefire report directory:
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.cli.deployer.ListModulesCommandArgsTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec
Running org.apache.geronimo.cli.deployer.CommandFileCommandMetaDataTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running org.apache.geronimo.cli.BaseCLParserTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.geronimo.cli.client.ClientCLParserTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec
Running org.apache.geronimo.cli.deployer.DeployerCLParserTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 sec
Running org.apache.geronimo.cli.daemon.DaemonCLParserTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.geronimo.cli.deployer.DistributeCommandArgsTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Results :
Tests run: 33, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/geronimo-cli-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-cli-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/geronimo-cli-2.1-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-cli/2.1-SNAPSHOT/geronimo-cli-2.1-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: System
[INFO]task-segment: [install]
[INFO]
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
central (http://repo1.maven.org/maven2)
[INFO] [enforcer:enforce {execution: default}]
[INFO] [jaxb2:xjc {execution: default}]
[INFO] Generating source...
[INFO] parsing a schema...
[INFO] compiling a schema...
[INFO] org/apache/geronimo/system/plugin/model/ArtifactType.java
[INFO] org/apache/geronimo/system/plugin/model/AttributeType.java
[INFO] org/apache/geronimo/system/plugin/model/AttributesType.java
[INFO] org/apache/geronimo/system/plugin/model/CopyFileType.java
[INFO] org/apache/geronimo/system/plugin/model/DependencyType.java
[INFO] org/apache/geronimo/system/plugin/model/GbeanType.java
[INFO] org/apache/geronimo/system/plugin/model/HashType.java
[INFO] org/apache/geronimo/system/plugin/model/LicenseType.java
[INFO] org/apache/geronimo/system/plugin/model/ModuleType.java
[INFO] org/apache/geronimo/system/plugin/model/ObjectFactory.java
[INFO] org/apache/geronimo/system/plugin/model/PluginArtifactType.java
[INFO] org/apache/geronimo/system/plugin/model/PluginListType.java
[INFO] org/apache/geronimo/system/plugin/model/PluginType.java
[INFO] org/apache/geronimo/system/plugin/model/PrerequisiteType.java
[INFO] org/apache/geronimo/system/plugin/model/PropertyType.java
[INFO] org/apache/geronimo/system/plugin/model/ReferenceType.java
[INFO] org/apache/geronimo/system/plugin/model/package-info.java
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/modules/geronimo-system/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/modules/geronimo-system/target/classes/META-INF
[INFO] [antrun:run {execution: generate-dynamic-properties}]
[INFO] Executing tasks
[mkdir] Created dir:
/home/prasad/geronimo/trunk/modules/geronimo-system/target/classes/org/apache/geronimo/system/serverinfo
[propertyfile] Creating new property file:
/home/prasad/geronimo/trunk/modules/geronimo-system/target/classes/org/apache/geronimo/system/serverinfo/geronimo-version.properties
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 108 source files to
/home/prasad/geronimo/trunk
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.0.0 (RC3)
Hi Ted, yes I shall do that now--it never occurred to me that anyone would want to use 1.0 and 1.1 Ted Kirby wrote: From the staging update site, I downloaded and installed a 2.0 tomcat server, started it, brought up the console, and stopped it, with WTP 2.0.1 RC2. I could not download a 1.1 server. Tim, can you put the 1.0 and 1.1 runtimes on the staging site? I presume they'll also be on the production site. With that change, +1 Ted Kirby -- Thanks, Tim McConnell
Re: XML Schemas on the site
The 2.0 page isn't quite right -- the preferred J2EE schemas on the top right should name and point to the Java EE 5 ones, I should think. Thanks, Aaron On 9/17/07, Hernan Cunico [EMAIL PROTECTED] wrote: I've updated the XML Schemas info on the web site for reflect 1.0, 1.1 and 2.0 You can take a quick look at the new organization here http://cwiki.apache.org/GMOxSITE/xml-schemas.html Changes will get reflected on the live site within the next hour. Cheers! Hernan Hernan Cunico wrote: Folks, This is what we have so far for the schemas, note that openEJB is still pending http://cwiki.apache.org/GMOxSBOX/schemas-20.html Thanks Jarek for consolidating the schemas on svn Pls take a look and send in your comments. Cheers! Hernan Hernan Cunico wrote: YES. I think Jarek already moved all the schemas (https://svn.apache.org/repos/asf/geronimo/site/trunk/docs/schemas-2.0/) so I'll be updating the web site soon. Cheers! Hernan Anita Kulshreshtha wrote: Are there any plans to put the schemas for 2.0.1 here: http://geronimo.apache.org/xml-schemas.html Thanks Anita Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
where is the Web application security sample svn repo?
Hi Folks, I'm playing around with application security in Geronimo and found the Web application security sample[1]. It's helpful, thanks! I needed to make a few changes to get it to work with 2.0, so I'm curious if I can check it out of subversion somewhere and use svn to make a patch for you guys. If looks as if the zip file is just a wiki attachment so I imagine there's a subversion repo somewhere but I can't find it. Pointers appreciated. Thanks, Toby [1] http://cwiki.apache.org/GMOxDOC20/web-application-security-sample.html
[jira] Created: (SM-1057) SoapWriter use default suboptimal Content-Transfer-Encoding
SoapWriter use default suboptimal Content-Transfer-Encoding --- Key: SM-1057 URL: https://issues.apache.org/activemq/browse/SM-1057 Project: ServiceMix Issue Type: Improvement Components: servicemix-soap Affects Versions: 3.1.1 Reporter: Tomasz Wysocki Currently SoapWriter class does not enforce in any way Content-Transfer-Encoding for attachments. This causes to choose base64 for binary content. Suggestion for change: part.setDataHandler(dh); part.setContentID( + id + ); // optimization - attachments will use binary encoding part.setHeader(Content-Transfer-Encoding, binary); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.0.0 (RC3)
From the staging update site, I downloaded and installed a 2.0 tomcat server, started it, brought up the console, and stopped it, with WTP 2.0.1 RC2. I could not download a 1.1 server. Tim, can you put the 1.0 and 1.1 runtimes on the staging site? I presume they'll also be on the production site. With that change, +1 Ted Kirby
Re: What exactly is going into 2.0.2?
On Sep 17, 2007, at 1:49 PM, Joe Bohn wrote: Paul McMahan wrote: Joe, you mentioned TCK and our ability to make 2.0.2 available by 9/21. I have a question for the team about that. I would like to bump Geronimo's version of MyFaces from 1.2.0 to 1.2.1 since that new release contains several bug fixes, some of them actually found and reported by Geronimo users. But doing that could affect Geronimo's TCK results and affect the 9/21 delivery date. I would imagine that the same is true for other dependencies.Are we OK with picking up maintenance releases of Geronimo dependencies in 2.0.2 even if we think TCK issues could slow us down? Or should we keep 2.0.2 focused on localized changes and only bump the dependency versions in Geronimo 2.1 so we have more time to deal any resulting TCK issues? I think it makes sense to move to the latest version of the Geronimo dependencies. However, it probably makes sense to validate areas in the TCK that may be impacted prior to the change or soon there-after in case there are issues that need to be resolve which might impact our ability to deliver in a timely manner. OK thanks Joe (and Kevan). Just wanted to make sure that overall as a team we agree that it's OK to introduce changes that could affect the proposed 9/21 date due to TCK issues. We can always back those changes out if we decide to, of course. Best wishes, Paul
[jira] Commented: (GERONIMODEVTOOLS-213) Cannot select Apache Geronimo v1.0 on New Server Runtime dialog.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528196 ] Kan Ogawa commented on GERONIMODEVTOOLS-213: I'm very sorry, On other pc environment, this is not reproduced. Would you close this issue immediately? Cannot select Apache Geronimo v1.0 on New Server Runtime dialog. Key: GERONIMODEVTOOLS-213 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Geronimo Eclipse Plugin 2.0.0 RC3 Reporter: Kan Ogawa Priority: Blocker Attachments: GD-213-ScreenShot-01.jpg, GD-213-ScreenShot-02.jpg, GD-213.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3439) geronimo-openejb-2.0.xsd not packaged under schema directory!
[ https://issues.apache.org/jira/browse/GERONIMO-3439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3439: - Assignee: Jarek Gawor geronimo-openejb-2.0.xsd not packaged under schema directory! - Key: GERONIMO-3439 URL: https://issues.apache.org/jira/browse/GERONIMO-3439 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0.x, 2.1 Reporter: Shiva Kumar H R Assignee: Jarek Gawor Fix For: 2.0.x, 2.1 geronimo-openejb-2.0.xsd is currently hidden inside repository\org\apache\geronimo\modules\geronimo-security-builder\2.0.1\geronimo-security-builder-2.0.1.jar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: XML Schemas on the site
Yes, that's right. I updated the schema files to point to Java EE ones. Jarek On 9/17/07, Aaron Mulder [EMAIL PROTECTED] wrote: The 2.0 page isn't quite right -- the preferred J2EE schemas on the top right should name and point to the Java EE 5 ones, I should think. Thanks, Aaron On 9/17/07, Hernan Cunico [EMAIL PROTECTED] wrote: I've updated the XML Schemas info on the web site for reflect 1.0, 1.1 and 2.0 You can take a quick look at the new organization here http://cwiki.apache.org/GMOxSITE/xml-schemas.html Changes will get reflected on the live site within the next hour. Cheers! Hernan Hernan Cunico wrote: Folks, This is what we have so far for the schemas, note that openEJB is still pending http://cwiki.apache.org/GMOxSBOX/schemas-20.html Thanks Jarek for consolidating the schemas on svn Pls take a look and send in your comments. Cheers! Hernan Hernan Cunico wrote: YES. I think Jarek already moved all the schemas (https://svn.apache.org/repos/asf/geronimo/site/trunk/docs/schemas-2.0/) so I'll be updating the web site soon. Cheers! Hernan Anita Kulshreshtha wrote: Are there any plans to put the schemas for 2.0.1 here: http://geronimo.apache.org/xml-schemas.html Thanks Anita Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
[jira] Closed: (GERONIMODEVTOOLS-213) Cannot select Apache Geronimo v1.0 on New Server Runtime dialog.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-213. -- Resolution: Fixed Closed per Kan's instructions Cannot select Apache Geronimo v1.0 on New Server Runtime dialog. Key: GERONIMODEVTOOLS-213 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-213 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Geronimo Eclipse Plugin 2.0.0 RC3 Reporter: Kan Ogawa Priority: Blocker Attachments: GD-213-ScreenShot-01.jpg, GD-213-ScreenShot-02.jpg, GD-213.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3439) geronimo-openejb-2.0.xsd not packaged under schema directory!
[ https://issues.apache.org/jira/browse/GERONIMO-3439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3439. --- Resolution: Fixed Fix Version/s: 2.0.2 Fix committed to trunk (r. 576663) and branches/2.0 (r. 576662). geronimo-openejb-2.0.xsd not packaged under schema directory! - Key: GERONIMO-3439 URL: https://issues.apache.org/jira/browse/GERONIMO-3439 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0.x, 2.1 Reporter: Shiva Kumar H R Assignee: Jarek Gawor Fix For: 2.0.2, 2.0.x, 2.1 geronimo-openejb-2.0.xsd is currently hidden inside repository\org\apache\geronimo\modules\geronimo-security-builder\2.0.1\geronimo-security-builder-2.0.1.jar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Move J2G from sandbox to devtools
Donald, It seems no one is opposed to this idea. We're you going to make this change soon? Thanks, Jason Warner On 9/13/07, Matt Hogstrom [EMAIL PROTECTED] wrote: +1 to move it ... I agree with the other comments on lazy consensus. On Sep 12, 2007, at 10:21 AM, Donald Woods wrote: Given all of the work and interest in the J2G tool, I would like to move the current J2G files from sandbox/j2g to devtools/trunk/j2g, so we can start working towards an official release of the tool. Does this require a Vote first or does the CTR process apply here, as the code is already in our svn repo? -Donald
[jira] Closed: (GERONIMO-2925) Key used for encryption same for all server instances
[ https://issues.apache.org/jira/browse/GERONIMO-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2925. -- Resolution: Fixed Fix Version/s: 2.1 2.0.2 Patch (with cleanup and more comments) applied to trunk in rev 576651 and branches/2.0 in rev 576668 Key used for encryption same for all server instances - Key: GERONIMO-2925 URL: https://issues.apache.org/jira/browse/GERONIMO-2925 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1.1, 1.1.2, 1.1.x, 1.2, 2.0-M5 Reporter: Michael Malgeri Assignee: David Jencks Priority: Critical Fix For: 2.0.2, 2.1 Attachments: GERONIMO-2925.patch We understand that WASCE use AES to encrypt the password. You do javax.crypto.Cipher.getInstance(AES) and init() with a hard-coded key. This key is same for all the WASCE server instances. Anyone getting access to a downloaded version of the software can have the algorithm and decrypt the password. So we need your urgent help on the following: 1. provide a solution with key management that we can control 2. provide a pluggable encryption solution so that we can use our internal algorithms and key management At least, 3. the key should be dynamically generated in each of the installations that would reduce the ability to decrypt to someone who has access to the server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] Trunk: Failed for Revision: 576668
OpenEJB trunk at 0
Geronimo Revision: 576668 built with tests included
See the full build-2200.log file at
http://people.apache.org/~prasad/binaries/trunk/20070917/build-2200.log
[WARNING] Unable to get resource 'ognl:ognl:jar:2.6.9' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/ognl/ognl/2.6.9/ognl-2.6.9.jar
164K downloaded
Downloading: http://download.java.net/maven/1//woodstox/jars/wstx-asl-3.2.1.jar
[WARNING] Unable to get resource 'woodstox:wstx-asl:jar:3.2.1' from repository
java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.jar
[WARNING] Unable to get resource 'woodstox:wstx-asl:jar:3.2.1' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.jar
493K downloaded
[INFO] snapshot org.apache.geronimo.modules:geronimo-kernel:2.1-SNAPSHOT:
checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-kernel:2.1-SNAPSHOT:
checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-kernel:2.1-SNAPSHOT:
checking for updates from apache.snapshots
Downloading:
http://download.java.net/maven/1//javax.xml.bind/jars/jaxb-api-2.0.jar
72K downloaded
Downloading:
http://download.java.net/maven/1//com.sun.xml.bind/jars/jaxb-impl-2.0.5.jar
769K downloaded
[INFO] [enforcer:enforce {execution: default}]
Downloading:
http://repository.codehaus.org/com/sun/xml/bind/jaxb-impl/2.0.3/jaxb-impl-2.0.3.pom
[WARNING] Unable to get resource 'com.sun.xml.bind:jaxb-impl:pom:2.0.3' from
repository codehaus.org (http://repository.codehaus.org)
Downloading:
http://repo1.maven.org/maven2/com/sun/xml/bind/jaxb-impl/2.0.3/jaxb-impl-2.0.3.pom
656b downloaded
Downloading:
http://repository.codehaus.org/javax/xml/bind/jsr173_api/1.0/jsr173_api-1.0.pom
[WARNING] Unable to get resource 'javax.xml.bind:jsr173_api:pom:1.0' from
repository codehaus.org (http://repository.codehaus.org)
Downloading:
http://repo1.maven.org/maven2/javax/xml/bind/jsr173_api/1.0/jsr173_api-1.0.pom
157b downloaded
Downloading:
http://repository.codehaus.org/com/sun/xml/bind/jaxb-xjc/2.0.3/jaxb-xjc-2.0.3.pom
[WARNING] Unable to get resource 'com.sun.xml.bind:jaxb-xjc:pom:2.0.3' from
repository codehaus.org (http://repository.codehaus.org)
Downloading:
http://repo1.maven.org/maven2/com/sun/xml/bind/jaxb-xjc/2.0.3/jaxb-xjc-2.0.3.pom
165b downloaded
Downloading:
http://repository.codehaus.org/javax/xml/bind/jsr173_api/1.0/jsr173_api-1.0.jar
[WARNING] Unable to get resource 'javax.xml.bind:jsr173_api:jar:1.0' from
repository codehaus.org (http://repository.codehaus.org)
Downloading:
http://download.java.net/maven/1//javax.xml.bind/jars/jsr173_api-1.0.jar
48K downloaded
Downloading:
http://repository.codehaus.org/com/sun/xml/bind/jaxb-impl/2.0.3/jaxb-impl-2.0.3.jar
[WARNING] Unable to get resource 'com.sun.xml.bind:jaxb-impl:jar:2.0.3' from
repository codehaus.org (http://repository.codehaus.org)
Downloading:
http://repo1.maven.org/maven2/com/sun/xml/bind/jaxb-impl/2.0.3/jaxb-impl-2.0.3.jar
765K downloaded
Downloading:
http://repository.codehaus.org/com/sun/xml/bind/jaxb-xjc/2.0.3/jaxb-xjc-2.0.3.jar
[WARNING] Unable to get resource 'com.sun.xml.bind:jaxb-xjc:jar:2.0.3' from
repository codehaus.org (http://repository.codehaus.org)
Downloading:
http://repo1.maven.org/maven2/com/sun/xml/bind/jaxb-xjc/2.0.3/jaxb-xjc-2.0.3.jar
2918K downloaded
[INFO] [jaxb2:xjc {execution: default}]
[INFO] Generating source...
[INFO] parsing a schema...
[INFO] compiling a schema...
[INFO] org/apache/geronimo/system/plugin/model/ArtifactType.java
[INFO] org/apache/geronimo/system/plugin/model/AttributeType.java
[INFO] org/apache/geronimo/system/plugin/model/AttributesType.java
[INFO] org/apache/geronimo/system/plugin/model/CopyFileType.java
[INFO] org/apache/geronimo/system/plugin/model/DependencyType.java
[INFO] org/apache/geronimo/system/plugin/model/GbeanType.java
[INFO] org/apache/geronimo/system/plugin/model/HashType.java
[INFO] org/apache/geronimo/system/plugin/model/LicenseType.java
[INFO] org/apache/geronimo/system/plugin/model/ModuleType.java
[INFO] org/apache/geronimo/system/plugin/model/ObjectFactory.java
[INFO] org/apache/geronimo/system/plugin/model/PluginArtifactType.java
[INFO] org/apache/geronimo/system/plugin/model/PluginListType.java
[INFO] org/apache/geronimo/system/plugin/model/PluginType.java
[INFO] org/apache/geronimo/system/plugin/model/PrerequisiteType.java
[INFO] org/apache/geronimo/system/plugin/model/PropertyType.java
[INFO] org/apache/geronimo/system/plugin/model/ReferenceType.java
[INFO] org/apache/geronimo/system/plugin/model/package-info.java
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk
[BUILD] 2.0: Failed for Revision: 576667
OpenEJB trunk at 0
Geronimo Revision: 576667 built with tests included
See the full build-2200.log file at
http://people.apache.org/~prasad/binaries/2.0/20070917/build-2200.log
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/prasad/geronimo/2.0/configs/webservices-common/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration:
/home/prasad/geronimo/2.0/configs/webservices-common/target/plan/plan.xml
[INFO] snapshot org.apache.geronimo.modules:geronimo-jaxws:2.0.2-SNAPSHOT:
checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-jaxws:2.0.2-SNAPSHOT:
checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-jaxws:2.0.2-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] Building jar:
/home/prasad/geronimo/2.0/configs/webservices-common/target/webservices-common-2.0.2-SNAPSHOT.car
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: webservices-common-2.0.2-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/2.0/configs/webservices-common/target/webservices-common-2.0.2-SNAPSHOT.car
to
/home/prasad/.m2/repository/org/apache/geronimo/configs/webservices-common/2.0.2-SNAPSHOT/webservices-common-2.0.2-SNAPSHOT.car
[INFO]
[INFO] Building Geronimo Configs :: OpenJPA with dependencies
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/2.0/configs/openjpa/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/2.0/configs/openjpa/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /home/prasad/geronimo/2.0/configs/openjpa/target/plan/plan.xml
Downloading:
http://download.java.net/maven/1//commons-lang/poms/commons-lang-2.0.pom
[WARNING] Unable to get resource 'commons-lang:commons-lang:pom:2.0' from
repository java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//commons-lang/commons-lang/2.0/commons-lang-2.0.pom
[WARNING] Unable to get resource 'commons-lang:commons-lang:pom:2.0' from
repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.pom
2K downloaded
Downloading:
http://download.java.net/maven/1//commons-lang/jars/commons-lang-2.0.jar
[WARNING] Unable to get resource 'commons-lang:commons-lang:jar:2.0' from
repository java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//commons-lang/commons-lang/2.0/commons-lang-2.0.jar
[WARNING] Unable to get resource 'commons-lang:commons-lang:jar:2.0' from
repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.jar
165K downloaded
[INFO] [car:package]
[INFO] Packaging module configuration:
/home/prasad/geronimo/2.0/configs/openjpa/target/plan/plan.xml
[INFO] snapshot org.apache.geronimo.modules:geronimo-openjpa:2.0.2-SNAPSHOT:
checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-openjpa:2.0.2-SNAPSHOT:
checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-openjpa:2.0.2-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] Building jar:
/home/prasad/geronimo/2.0/configs/openjpa/target/openjpa-2.0.2-SNAPSHOT.car
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: openjpa-2.0.2-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/2.0/configs/openjpa/target/openjpa-2.0.2-SNAPSHOT.car to
/home/prasad/.m2/repository/org/apache/geronimo/configs/openjpa/2.0.2-SNAPSHOT/openjpa-2.0.2-SNAPSHOT.car
[INFO]
[INFO] Building Geronimo Configs :: OpenEJB
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/2.0/configs/openejb/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/2.0/configs/openejb/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /home/prasad/geronimo/2.0
