[jira] Closed: (GERONIMO-2973) Bind JDBC DataSource to Global JNDI

2009-03-26 Thread David Jencks (JIRA)

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

David Jencks closed GERONIMO-2973.
--

   Resolution: Fixed
Fix Version/s: 2.1.3

This was implemented a long time ago certainly before 2.1.3

 Bind JDBC DataSource  to Global JNDI
 

 Key: GERONIMO-2973
 URL: https://issues.apache.org/jira/browse/GERONIMO-2973
 Project: Geronimo
  Issue Type: Sub-task
  Security Level: public(Regular issues) 
  Components: naming
Affects Versions: 2.0-M5
Reporter: Christopher M. Cardona
 Fix For: 2.1.3


 Auto bind JDBC DataSource objects to Global JNDI.

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



[jira] Closed: (GERONIMO-2014) Geronimo uses outdated version of ApacheDS

2009-03-26 Thread David Jencks (JIRA)

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

David Jencks closed GERONIMO-2014.
--

Resolution: Fixed

Directory now is a geronimo plugin that is not included in the main 
distributions.  We are also using a much more recent directory release.

 Geronimo uses outdated version of ApacheDS
 --

 Key: GERONIMO-2014
 URL: https://issues.apache.org/jira/browse/GERONIMO-2014
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: naming
Affects Versions: 1.2
 Environment: P4 3.0Ghz 2Gb WinXP
Reporter: Alexei Zakharov
 Attachments: geronimo-1.2_to_apacheds-1.0-RC2.patch, 
 geronimo-1.2_to_apacheds-1.0-RC2_modules_directory_pom_xml.patch


 Outdated version of Apache Directory Server is currently used by Geronimo. 
 This is a cause of GERONIMO-1805 bug and probably some other issues. Attached 
 patches port  Geronimo directory module to ApachedDS 1.0 RC2. It is 
 applicable to maven2 version of config files since ADS 1.0 RCx jars available 
 for m2 repo only.

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



[jira] Closed: (GERONIMO-2698) DirectoryGBean not referenceable as a GBean

2009-03-26 Thread David Jencks (JIRA)

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

David Jencks closed GERONIMO-2698.
--

   Resolution: Fixed
Fix Version/s: 2.1

We don't use proxies any more for gbean references, so you wouldn't run into a 
problem like this in a current geronimo release.

 DirectoryGBean not referenceable as a GBean
 ---

 Key: GERONIMO-2698
 URL: https://issues.apache.org/jira/browse/GERONIMO-2698
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: naming
Affects Versions: 1.1.1
Reporter: Chris Curtis
Priority: Minor
 Fix For: 2.1


 Specifying a reference to DirectoryGBean.class fails because DirectoryGBean 
 doesn't have a no-arg constructor. Example:
 {{...}}
 {{infoFactory.addReference(DirectoryGBean, DirectoryGBean.class);}}
 {{...}}
 At load time, this throws:
 {{java.lang.IllegalArgumentException: Cannot find matching 
 method/constructor}}
   {{at 
 org.apache.geronimo.directory.DirectoryGBean$$EnhancerByCGLIB$$f37d2ade$$FastClassByCGLIB$$dc9cb3c5.newInstance(generated)}}
 The cleanest way to resolve this seems like it would be to pull up the 
 relevant attributes/operations to an interface, which would be usable as a 
 reference classspec.

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



[jira] Assigned: (GERONIMO-3954) Allow overriding the value of an env-entry/ from within deployment plans

2009-03-26 Thread David Jencks (JIRA)

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

David Jencks reassigned GERONIMO-3954:
--

Assignee: David Jencks

 Allow overriding the value of an env-entry/ from within deployment plans
 --

 Key: GERONIMO-3954
 URL: https://issues.apache.org/jira/browse/GERONIMO-3954
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Reporter: Janko Heilgeist
Assignee: David Jencks

 The provider or assembler of an JavaEE application can define environment 
 entries inside the standard deployment descriptor files like ejb-jar.xml or 
 web.xml with
 {code:xml}
 env-entry
 descriptionSome crucial variable!/description
 env-entry-namesomeVariable/env-entry-name
 env-entry-typejava.lang.String/env-entry-type
 !--env-entry-valuecontent of string/env-entry-value--
 /env-entry
 {code}
 Currently, the deployer of this application needs to modify the standard 
 deployment descriptor to set the environment entry to a value. This is a 
 problem, if e.g. the archive containing the descriptor file was signed by the 
 provider and is supposed to be used unmodified. It would be a major 
 improvement, if the Geronimo deployment plans would allow setting or 
 overriding the values of these entries.
 This seems to have been the case in previous versions of Geronimo. On August 
 24th, 2003 the schema 
 incubator-geronimo/modules/core/src/schema/geronimo-ejb-jar.xsd contained the 
 following elements:
 {code:xml}
 [...]
 xsd:element name=env-entry
   xsd:annotation
 xsd:documentation
   Configuration for an environment entry.  Normally an env-entry
   is fully configured by the assembler in the standard ejb-jar.xml
   deployment descriptor.  However, the deployer can specify a
   value here if there was no value specified in ejb-jar.xml, or
   if the deployer wants to override the value specified there.
 /xsd:documentation
   /xsd:annotation
   xsd:complexType
 xsd:sequence
   xsd:element ref=env-entry-name minOccurs=1 maxOccurs=1/
   xsd:element ref=env-entry-value minOccurs=1 maxOccurs=1/
 /xsd:sequence
   /xsd:complexType
 /xsd:element
 [...]
 {code}

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



[jira] Commented: (GERONIMO-3954) Allow overriding the value of an env-entry/ from within deployment plans

2009-03-26 Thread David Jencks (JIRA)

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

David Jencks commented on GERONIMO-3954:


Fixed in trunk rev 758570, branches/2.1 rev 758581

I did not change the naming schema version since this change is backward 
compatible.  We need to agree on the dev list whether this is the correct 
approach before closing this issue.

 Allow overriding the value of an env-entry/ from within deployment plans
 --

 Key: GERONIMO-3954
 URL: https://issues.apache.org/jira/browse/GERONIMO-3954
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Reporter: Janko Heilgeist
Assignee: David Jencks

 The provider or assembler of an JavaEE application can define environment 
 entries inside the standard deployment descriptor files like ejb-jar.xml or 
 web.xml with
 {code:xml}
 env-entry
 descriptionSome crucial variable!/description
 env-entry-namesomeVariable/env-entry-name
 env-entry-typejava.lang.String/env-entry-type
 !--env-entry-valuecontent of string/env-entry-value--
 /env-entry
 {code}
 Currently, the deployer of this application needs to modify the standard 
 deployment descriptor to set the environment entry to a value. This is a 
 problem, if e.g. the archive containing the descriptor file was signed by the 
 provider and is supposed to be used unmodified. It would be a major 
 improvement, if the Geronimo deployment plans would allow setting or 
 overriding the values of these entries.
 This seems to have been the case in previous versions of Geronimo. On August 
 24th, 2003 the schema 
 incubator-geronimo/modules/core/src/schema/geronimo-ejb-jar.xsd contained the 
 following elements:
 {code:xml}
 [...]
 xsd:element name=env-entry
   xsd:annotation
 xsd:documentation
   Configuration for an environment entry.  Normally an env-entry
   is fully configured by the assembler in the standard ejb-jar.xml
   deployment descriptor.  However, the deployer can specify a
   value here if there was no value specified in ejb-jar.xml, or
   if the deployer wants to override the value specified there.
 /xsd:documentation
   /xsd:annotation
   xsd:complexType
 xsd:sequence
   xsd:element ref=env-entry-name minOccurs=1 maxOccurs=1/
   xsd:element ref=env-entry-value minOccurs=1 maxOccurs=1/
 /xsd:sequence
   /xsd:complexType
 /xsd:element
 [...]
 {code}

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



[jira] Commented: (GERONIMO-3954) Allow overriding the value of an env-entry/ from within deployment plans

2009-03-26 Thread David Jencks (JIRA)

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

David Jencks commented on GERONIMO-3954:


Also I'm not sure if openejb is using the geronimo env-entry builder -- this 
change may not affect openejb.

 Allow overriding the value of an env-entry/ from within deployment plans
 --

 Key: GERONIMO-3954
 URL: https://issues.apache.org/jira/browse/GERONIMO-3954
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Reporter: Janko Heilgeist
Assignee: David Jencks

 The provider or assembler of an JavaEE application can define environment 
 entries inside the standard deployment descriptor files like ejb-jar.xml or 
 web.xml with
 {code:xml}
 env-entry
 descriptionSome crucial variable!/description
 env-entry-namesomeVariable/env-entry-name
 env-entry-typejava.lang.String/env-entry-type
 !--env-entry-valuecontent of string/env-entry-value--
 /env-entry
 {code}
 Currently, the deployer of this application needs to modify the standard 
 deployment descriptor to set the environment entry to a value. This is a 
 problem, if e.g. the archive containing the descriptor file was signed by the 
 provider and is supposed to be used unmodified. It would be a major 
 improvement, if the Geronimo deployment plans would allow setting or 
 overriding the values of these entries.
 This seems to have been the case in previous versions of Geronimo. On August 
 24th, 2003 the schema 
 incubator-geronimo/modules/core/src/schema/geronimo-ejb-jar.xsd contained the 
 following elements:
 {code:xml}
 [...]
 xsd:element name=env-entry
   xsd:annotation
 xsd:documentation
   Configuration for an environment entry.  Normally an env-entry
   is fully configured by the assembler in the standard ejb-jar.xml
   deployment descriptor.  However, the deployer can specify a
   value here if there was no value specified in ejb-jar.xml, or
   if the deployer wants to override the value specified there.
 /xsd:documentation
   /xsd:annotation
   xsd:complexType
 xsd:sequence
   xsd:element ref=env-entry-name minOccurs=1 maxOccurs=1/
   xsd:element ref=env-entry-value minOccurs=1 maxOccurs=1/
 /xsd:sequence
   /xsd:complexType
 /xsd:element
 [...]
 {code}

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



Re: Deploying ear file with ldap realm - geronimo 2.1.x

2009-03-26 Thread David Jencks
I don't see anything obviously wrong with your xml.  Is  there any  
more information with the error such as a stack trace or the name of  
the class that can't be loaded?


thanks
david jencks

On Mar 25, 2009, at 10:05 PM, govinda wrote:



I tried to deploy ear file that has single war file and I receive the
following error, my geronimo-application.xml has ldap realm.
I have server-wide ldap realm created, deployed war and tested ldap
security, its working but I could not deploy ear file. Am I missing  
any

security mapping?

server001:/global/WebSphereCE/bin # ./deploy.sh deploy SuperSnoop.ear
geronimo-application.xml
Using GERONIMO_BASE: /global/WebSphereCE
Using GERONIMO_HOME: /global/WebSphereCE
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME: /opt/ibm/java2-i386-50/jre
Username: system
Password: ***
Error: Operation failed: load of SuperSnoop/SuperSnoopEAR/1.0/car
failed

Error starting configuration gbean SuperSnoop/SuperSnoopEAR/1.0/car

Configuration gbean failed to start
SuperSnoop/SuperSnoopEAR/1.0/car

reason: Class not loadable in classloader:
[org.apache.geronimo.kernel.config.MultiParentClassLoader
id=SuperSnoop/SuperSnoopEAR/1.0/car]

geronimo-application.xml:

?xml version=1.0 encoding=UTF-8?
application xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-2.0 


xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.2;
application-name=SuperSnoop
sys:environment
sys:moduleId
sys:groupIdSuperSnoop/sys:groupId
sys:artifactIdSuperSnoopEAR/sys:artifactId
sys:version1.0/sys:version
sys:typecar/sys:type
/sys:moduleId
/sys:environment

module
webSuperSnoopWeb.war/web
web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1; 
sys:environment
sys:moduleId
sys:groupIdSuperSnoop/sys:groupId
sys:artifactIdSuperSnoopWEB/sys:artifactId
sys:version1.0/sys:version
sys:typewar/sys:type
/sys:moduleId
/sys:environment
context-root/SuperSnoopWeb/context-root
security-realm-namecorp-ldap/security-realm-name
/web-app
/module
security
default-principal realm-name=corp-ldap
principal name=nobody
class 
= 
org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal/

/default-principal
role-mappings
role role-name=admin
realm realm-name=corp-ldap
principal name=adminstrators
class 
= 
org 
.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal/

principal name=admin
class 
= 
org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal/

/realm
/role
/role-mappings
/security
/application

META-INF/application.xml:

?xml version=1.0 encoding=UTF-8?
!DOCTYPE application PUBLIC -//Sun Microsystems, Inc.//DTD J2EE
Application 1.2//EN http://java.sun.com/j2ee/dtds/application_1_2.dtd 


application id=Application_ID
display-nameSuperSnoop/display-name
module id=WebModule_1049985603917
web
web-uriSuperSnoopWeb.war/web-uri
context-rootSuperSnoopWeb/context-root
/web
/module
security-role
role-nameadmin/role-name
/security-role
/application
--
View this message in context: 
http://www.nabble.com/Deploying-ear-file-with-ldap-realm---geronimo-2.1.x-tp22711096s134p22711096.html
Sent from the Apache Geronimo - Dev mailing list archive at  
Nabble.com.






should we update schema namespace for backwards compatible changes?

2009-03-26 Thread David Jencks
Following a user request here at apachecon eu I finally implemented  
the ability to override env-entry elements in geronimo plans  
(GERONIMO-3954) (also, I'm not sure if this works for ejbs -- is  
openejb using our env-entry builder?)


This requires a backwards compatible change to the geronimo naming  
schema.


In the past we've tended to update the schema namespace by increasing  
the version with every change although this has resulted in a lot of  
nuisance and does not appear to be a recommended practice.


So far I haven't updated the namespace. I'm very tempted to suggest  
that we change our policy a bit and not change the namespace so often.


Thoughts?

thanks
david jencks


Re: Deploying ear file with ldap realm - geronimo 2.1.x

2009-03-26 Thread govinda


Thanks David. I'm able to deploy the ear file by adding dependency in
geronimo-application.xml, how do I protect resource (/SuperSnoopWeb)?
deployer does not accept security-constraint element in application.xml

Dependency:

sys:environment
sys:moduleId
sys:groupIdSuperSnoop/sys:groupId
sys:artifactIdSuperSnoopEAR/sys:artifactId
sys:version1.0/sys:version
sys:typecar/sys:type
/sys:moduleId
dependencies
dependency
groupIdconsole.realm/groupId
artifactIdcorp-ldap/artifactId
version1.0/version
typecar/type
/dependency
/dependencies
/sys:environment



djencks wrote:
 
 I don't see anything obviously wrong with your xml.  Is  there any  
 more information with the error such as a stack trace or the name of  
 the class that can't be loaded?
 
 thanks
 david jencks
 
 On Mar 25, 2009, at 10:05 PM, govinda wrote:
 

 I tried to deploy ear file that has single war file and I receive the
 following error, my geronimo-application.xml has ldap realm.
 I have server-wide ldap realm created, deployed war and tested ldap
 security, its working but I could not deploy ear file. Am I missing  
 any
 security mapping?

 server001:/global/WebSphereCE/bin # ./deploy.sh deploy SuperSnoop.ear
 geronimo-application.xml
 Using GERONIMO_BASE: /global/WebSphereCE
 Using GERONIMO_HOME: /global/WebSphereCE
 Using GERONIMO_TMPDIR: var/temp
 Using JRE_HOME: /opt/ibm/java2-i386-50/jre
 Username: system
 Password: ***
 Error: Operation failed: load of SuperSnoop/SuperSnoopEAR/1.0/car
 failed

 Error starting configuration gbean SuperSnoop/SuperSnoopEAR/1.0/car

 Configuration gbean failed to start
 SuperSnoop/SuperSnoopEAR/1.0/car

 reason: Class not loadable in classloader:
 [org.apache.geronimo.kernel.config.MultiParentClassLoader
 id=SuperSnoop/SuperSnoopEAR/1.0/car]

 geronimo-application.xml:

 ?xml version=1.0 encoding=UTF-8?
 application
 xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-2.0 
 
 xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.2;
 application-name=SuperSnoop
 sys:environment
 sys:moduleId
 sys:groupIdSuperSnoop/sys:groupId
 sys:artifactIdSuperSnoopEAR/sys:artifactId
 sys:version1.0/sys:version
 sys:typecar/sys:type
 /sys:moduleId
 /sys:environment

 module
 webSuperSnoopWeb.war/web
 web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1; 
 sys:environment
 sys:moduleId
 sys:groupIdSuperSnoop/sys:groupId
 sys:artifactIdSuperSnoopWEB/sys:artifactId
 sys:version1.0/sys:version
 sys:typewar/sys:type
 /sys:moduleId
 /sys:environment
 context-root/SuperSnoopWeb/context-root
 security-realm-namecorp-ldap/security-realm-name
 /web-app
 /module
 security
 default-principal realm-name=corp-ldap
 principal name=nobody
 class 
 = 
 org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal/
 /default-principal
 role-mappings
 role role-name=admin
 realm realm-name=corp-ldap
 principal name=adminstrators
 class 
 = 
 org 
 .apache.geronimo.security.realm.providers.GeronimoGroupPrincipal/
 principal name=admin
 class 
 = 
 org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal/
 /realm
 /role
 /role-mappings
 /security
 /application

 META-INF/application.xml:

 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE application PUBLIC -//Sun Microsystems, Inc.//DTD J2EE
 Application 1.2//EN http://java.sun.com/j2ee/dtds/application_1_2.dtd 
 
 application id=Application_ID
 display-nameSuperSnoop/display-name
 module id=WebModule_1049985603917
 web
 web-uriSuperSnoopWeb.war/web-uri
 context-rootSuperSnoopWeb/context-root
 /web
 /module
 security-role
 role-nameadmin/role-name
 /security-role
 /application
 -- 
 View this message in context:
 http://www.nabble.com/Deploying-ear-file-with-ldap-realm---geronimo-2.1.x-tp22711096s134p22711096.html
 Sent from the Apache Geronimo - Dev mailing list archive at  
 Nabble.com.

 
 
 

-- 
View this message in context: 
http://www.nabble.com/Deploying-ear-file-with-ldap-realm---geronimo-2.1.x-tp22711096s134p22723363.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.



Re: should we update schema namespace for backwards compatible changes?

2009-03-26 Thread Juergen Weber


djencks wrote:
 
 Following a user request here at apachecon eu I finally implemented  
 the ability to override env-entry elements in geronimo plans  
 (GERONIMO-3954) (also, I'm not sure if this works for ejbs -- is  
 openejb using our env-entry builder?)
 

Great, but please see also
http://www.nabble.com/Re%3A-Google-Summer-of-Code-p22599207.html
(every single web.xml or ejb-jar.xml entry should be overridable).

Also, concerning EJB3, can you override an injected property with a geronimo
plan, even if the injected property is not overridden by an entry in
ejb-jar.xml ?

geronimo-plan - ejb-jar.xml - injected property

Thanks,
Juergen
-- 
View this message in context: 
http://www.nabble.com/should-we-update-schema-namespace-for-backwards-compatible-changes--tp22721031s134p22724942.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.



Re: should we update schema namespace for backwards compatible changes?

2009-03-26 Thread David Blevins


On Mar 26, 2009, at 5:28 AM, David Jencks wrote:

Following a user request here at apachecon eu I finally implemented  
the ability to override env-entry elements in geronimo plans  
(GERONIMO-3954) (also, I'm not sure if this works for ejbs -- is  
openejb using our env-entry builder?)


I don't think so, but there likely is a place in the G ejb deployer  
where we can grab the env entries and update them with the overrided  
values.  I seem to recall we're doing some manipulation of the jaxb  
ejb-jar.xml tree already.


-David



Re: [VOTE] Release Geronimo Server 2.1.4 RC1

2009-03-26 Thread Kevan Miller

Joe,
Everything looks good, with one exception -- plugins/console/console- 
filter/src/main/resources/XSRF.js is missing a license header. Once  
that is fixed, I'll be +1.


I built from source, reviewed source, started servers, and looked at  
generated artifacts.


--kevan

On Mar 25, 2009, at 5:17 PM, Joe Bohn wrote:


All,

I've prepared a release candidate (RC1) of Geronimo Server 2.1.4 for  
your review and vote.


The source for rc1 is Rev758299 from the following svn branch:
 https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.4/

When the release vote is approved, I will svn mv the code to:
 https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.4

An archive of this source code can be found here:
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-2.1.4-src.tar.gz
OR
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-2.1.4-src.zip

http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/ contains  
the 10 server binary distributions to be released (framework, tomcat/ 
jetty, Java EE/Minimal, tar/zip) as well as the RELEASE_NOTES,  
README, NOTICE, LICENSE, DISCLAIMER, and source code archives for  
the release.  These extra txt files were included so that they could  
be leveraged by GEP if necessary (they are also included in the  
assembly images).


For your convenience, here are pointers to the urls for the
distributions in zip format:
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-jetty6-javaee5-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-jetty6-minimal-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-tomcat6-javaee5-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-tomcat6-minimal-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-framework-2.1.4-bin.zip


The maven artifacts for the release can be found here:
 http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.4-rc1/

When the release vote is approved, these maven artifacts will be moved
to the m2-ibiblio-rsync-repository at Apache.


[ ] +1 Release Geronimo Server 2.1.4
[ ] 0 No opinion
[ ] -1 Do not release Geronimo Server 2.1.4 (please provide rationale)


The voting will be open for 72 hours or until sufficient input has  
been received and the tck results have been verified.


Thanks,
Joe





Re: [VOTE] Release Geronimo Server 2.1.4 RC1 - CANCELLED

2009-03-26 Thread Joe Bohn


Thanks Kevan.  I should have caught that.  I'll fix the file and spin a 
new rc.


Joe


Kevan Miller wrote:

Joe,
Everything looks good, with one exception 
-- plugins/console/console-filter/src/main/resources/XSRF.js is missing 
a license header. Once that is fixed, I'll be +1.


I built from source, reviewed source, started servers, and looked at 
generated artifacts.


--kevan

On Mar 25, 2009, at 5:17 PM, Joe Bohn wrote:


All,

I've prepared a release candidate (RC1) of Geronimo Server 2.1.4 for 
your review and vote.


The source for rc1 is Rev758299 from the following svn branch:
 https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.4/

When the release vote is approved, I will svn mv the code to:
 https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.4

An archive of this source code can be found here:
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-2.1.4-src.tar.gz
OR
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-2.1.4-src.zip

http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/ contains the 
10 server binary distributions to be released (framework, 
tomcat/jetty, Java EE/Minimal, tar/zip) as well as the RELEASE_NOTES, 
README, NOTICE, LICENSE, DISCLAIMER, and source code archives for the 
release.  These extra txt files were included so that they could be 
leveraged by GEP if necessary (they are also included in the assembly 
images).


For your convenience, here are pointers to the urls for the
distributions in zip format:
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-jetty6-javaee5-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-jetty6-minimal-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-tomcat6-javaee5-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-tomcat6-minimal-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc1/geronimo-framework-2.1.4-bin.zip


The maven artifacts for the release can be found here:
 http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.4-rc1/

When the release vote is approved, these maven artifacts will be moved
to the m2-ibiblio-rsync-repository at Apache.


[ ] +1 Release Geronimo Server 2.1.4
[ ] 0 No opinion
[ ] -1 Do not release Geronimo Server 2.1.4 (please provide rationale)


The voting will be open for 72 hours or until sufficient input has 
been received and the tck results have been verified.


Thanks,
Joe







Re: should we update schema namespace for backwards compatible changes?

2009-03-26 Thread Jarek Gawor
We've had similar conversations before and I think we pretty much
decided that backwards compatible changes without updating the
namespace were ok.

(Although, from my understanding the recommended practice is to change
the namespace each time a change is made)

Jarek

On Thu, Mar 26, 2009 at 8:28 AM, David Jencks david_jen...@yahoo.com wrote:
 Following a user request here at apachecon eu I finally implemented the
 ability to override env-entry elements in geronimo plans (GERONIMO-3954)
 (also, I'm not sure if this works for ejbs -- is openejb using our env-entry
 builder?)

 This requires a backwards compatible change to the geronimo naming schema.

 In the past we've tended to update the schema namespace by increasing the
 version with every change although this has resulted in a lot of nuisance
 and does not appear to be a recommended practice.

 So far I haven't updated the namespace. I'm very tempted to suggest that we
 change our policy a bit and not change the namespace so often.

 Thoughts?

 thanks
 david jencks



Re: Should the CXF JAX-WS command line tools be a part of Web Services Axis2 group ?

2009-03-26 Thread Jarek Gawor
Shawn,

In Geronimo 2.2, WSDL and other artifacts used by JAX-WS web services
can be either generated by Sun or CXF tools. So, the CXF tools are
part of Axis2 group to let users choose which set of tools they want
to use. Before they were forced to use Sun's tools. I think Sun's
tools are still used by default though.

Jarek

On Mon, Mar 23, 2009 at 1:40 AM, Shawn Jiang genspr...@gmail.com wrote:
 http://cwiki.apache.org/GMOxDOC22/plugins-group.html
 Should the CXF JAX-WS command line tools be a part of Web Services Axis2
 group ?  please advice ,thanks.

 Geronimo Plugin Group :: Web Services Axis2

 Description: This plugin group provides Web Services Axis2 functionality.
 Plugins included:
 Plugin name ModuleId description
 Geronimo Plugins, AXIS :: Deployer
 org.apache.geronimo.configs/axis-deployer//car Provides the web Services
 Deployer for Geronimo Axis 1 integration.
 Geronimo Plugins, AXIS2 :: Deployer
 org.apache.geronimo.configs/axis2-deployer//car Provides the web Services
 Deployer for Geronimo Axis 2 integration.
 Geronimo Plugins, AXIS2 :: EJB Deployer
 org.apache.geronimo.configs/axis2-ejb-deployer//car Provides the Geronimo
 JAX-WS EJB deployer for Apache Axis2.
 Geronimo Plugins, JAXWS :: Tools
 org.apache.geronimo.configs/jaxws-tools//car Provides JAX-WS command line
 tools.
 Geronimo Plugins, CXF :: Tools CLI
 org.apache.geronimo.configs/cxf-tools//car Provides CXF JAX-WS command line
 tools.

 Geronimo Plugin Group :: Web Services CXF

 Description: This plugin group provides Web Services CXF functionality.
 Plugins included:
 Plugin name ModuleId description
 Geronimo Plugins, AXIS :: Deployer
 org.apache.geronimo.configs/axis-deployer//car Provides web Services
 Deployer for Geronimo Axis 1 integration.
 Geronimo Plugins, CXF :: Deployer
 org.apache.geronimo.configs/cxf-deployer//car Provides Geronimo JAX-WS
 deployer for Apache CXF.
 Geronimo Plugins, CXF :: EJB Deployer
 org.apache.geronimo.configs/cxf-ejb-deployer//car Provides Geronimo JAX-WS
 EJB deployer for Apache CXF.
 Geronimo Plugins, JAXWS :: Tools
 org.apache.geronimo.configs/jaxws-tools//car Provides JAX-WS command line
 tools.
 Geronimo Plugins, CXF :: Tools CLI
 org.apache.geronimo.configs/cxf-tools//car Provides CXF JAX-WS command line
 tools.


 --
 Shawn



Re: [DISCUSS] Release Geronimo Server 2.1.4 RC1

2009-03-26 Thread Jay D. McHugh
Hey all,

I know that this vote is cancelled, but I tried my real app on 2.1.4 RC1
and some JPA entities are not working the way they used to on 2.1.3.

I am trying to figure out if I have been taking advantage of a bug that
has since been corrected - or if a problem snuck into JPA.

I will let you all know as soon as I figure out which is the case.

Jay

Joe Bohn wrote:
 Message created for any discussion of the pending Geronimo 2.1.4 RC1
 currently up for vote.
 
 Thanks,
 Joe


Re: [DISCUSS] Release Geronimo Server 2.1.4 RC1

2009-03-26 Thread Joe Bohn

Hi Jay,

Yes, please do let us know.

I'm nearly done generating a new set of images and will start the vote 
again shortly.


However, as the previous comments indicate, the images themselves are 
not functionally different than what you are using ... just adding in a 
missing license header and removing some unnecessary text in the 
README.txt file.


Thanks,
Joe

Jay D. McHugh wrote:

Hey all,

I know that this vote is cancelled, but I tried my real app on 2.1.4 RC1
and some JPA entities are not working the way they used to on 2.1.3.

I am trying to figure out if I have been taking advantage of a bug that
has since been corrected - or if a problem snuck into JPA.

I will let you all know as soon as I figure out which is the case.

Jay

Joe Bohn wrote:

Message created for any discussion of the pending Geronimo 2.1.4 RC1
currently up for vote.

Thanks,
Joe






[VOTE] Release Geronimo Server 2.1.4 RC2

2009-03-26 Thread Joe Bohn

All,

I've prepared a second release candidate (RC2) of Geronimo Server 2.1.4 
for your review and vote.


The only differences from rc1 are:
- addition of a missing license header in 
plugins/console/console-filter/src/main/resources/XSRF.js

- removal of an extraneous (TBD) in README.txt


The source for rc2 is Rev758842 from the following svn branch:
  https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.4/

When the release vote is approved, I will svn mv the code to:
  https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.4/

An archive of this source code can be found here:
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-2.1.4-src.tar.gz
OR
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-2.1.4-src.zip

http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/ contains the 10 
server binary distributions to be released (framework, tomcat/jetty, 
Java EE/Minimal, tar/zip) as well as the RELEASE_NOTES, README, NOTICE, 
LICENSE, DISCLAIMER, and source code archives for the release.  These 
extra txt files were included so that they could be leveraged by GEP if 
necessary (they are also included in the assembly images).


For your convenience, here are pointers to the urls for the
distributions in zip format:
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-jetty6-javaee5-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-jetty6-minimal-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-tomcat6-javaee5-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-tomcat6-minimal-2.1.4-bin.zip
http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-framework-2.1.4-bin.zip


The maven artifacts for the release can be found here:
  http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.4-rc2/

When the release vote is approved, these maven artifacts will be moved
to the m2-ibiblio-rsync-repository at Apache.


[ ] +1 Release Geronimo Server 2.1.4
[ ] 0 No opinion
[ ] -1 Do not release Geronimo Server 2.1.4 (please provide rationale)


The voting will be open for 72 hours or until sufficient input has been 
received and the tck results have been verified.


Thanks,
Joe


[DISCUSS] Release Geronimo Server 2.1.4 RC2

2009-03-26 Thread Joe Bohn
Message created for any discussion of the pending Geronimo 2.1.4 RC2 
currently up for vote.


Thanks,
Joe


Re: [DISCUSS] Release Geronimo Server 2.1.4 RC1

2009-03-26 Thread Jay D. McHugh
Hey again all,

I think that this may caused by my rather extreme entity relationships
and the use of OpenJPA's proprietary @ElementJoinColumn annotation.

I have the following relationship structure:

project
- projectDetail (project 1-M projectDetail using @EJC)
  - component (projectDetail 1-1 component)
- componentAttribute (component 1-M componentAttribute using @EJC)
  - attribute (componentAttribute 1-1 attribute)
- compAttribValue (componentAttribute 1-1 compAttribValue)
- componentClass (component 1-1 componentClass)
  - classAttrib (componentClass 1-M classAttrib using @EJC)
  - attribute (classAttrib 1- attribute)

And I am basically trying to clone a project entity.  I have debugging
code that says it is creating and attaching all of the necessary details
(which it is) containing the appropriate components (which it is not).

I am only getting the first projectDetail persisted to the database
fully.  All subsequent are not getting their components created.

I will try to create a test that has a similarly complicated entity
relationship but uses only JPA standard links.

If that works - how should we handle it?  If the assembly passes TCK,
and the problem is only related to the use of an OpenJPA proprietary
annotation, should we just issue a note that the use of that annotation
may cause problems?

Jay
Joe Bohn wrote:
 Hi Jay,
 
 Yes, please do let us know.
 
 I'm nearly done generating a new set of images and will start the vote
 again shortly.
 
 However, as the previous comments indicate, the images themselves are
 not functionally different than what you are using ... just adding in a
 missing license header and removing some unnecessary text in the
 README.txt file.
 
 Thanks,
 Joe
 
 Jay D. McHugh wrote:
 Hey all,

 I know that this vote is cancelled, but I tried my real app on 2.1.4 RC1
 and some JPA entities are not working the way they used to on 2.1.3.

 I am trying to figure out if I have been taking advantage of a bug that
 has since been corrected - or if a problem snuck into JPA.

 I will let you all know as soon as I figure out which is the case.

 Jay

 Joe Bohn wrote:
 Message created for any discussion of the pending Geronimo 2.1.4 RC1
 currently up for vote.

 Thanks,
 Joe

 


Re: Should the CXF JAX-WS command line tools be a part of Web Services Axis2 group ?

2009-03-26 Thread Shawn Jiang
I see.Thanks Jarek !

On Fri, Mar 27, 2009 at 4:08 AM, Jarek Gawor jga...@gmail.com wrote:

 Shawn,

 In Geronimo 2.2, WSDL and other artifacts used by JAX-WS web services
 can be either generated by Sun or CXF tools. So, the CXF tools are
 part of Axis2 group to let users choose which set of tools they want
 to use. Before they were forced to use Sun's tools. I think Sun's
 tools are still used by default though.

 Jarek

 On Mon, Mar 23, 2009 at 1:40 AM, Shawn Jiang genspr...@gmail.com wrote:
  http://cwiki.apache.org/GMOxDOC22/plugins-group.html
  Should the CXF JAX-WS command line tools be a part of Web Services Axis2
  group ?  please advice ,thanks.
 
  Geronimo Plugin Group :: Web Services Axis2
 
  Description: This plugin group provides Web Services Axis2 functionality.
  Plugins included:
  Plugin name ModuleId description
  Geronimo Plugins, AXIS :: Deployer
  org.apache.geronimo.configs/axis-deployer//car Provides the web Services
  Deployer for Geronimo Axis 1 integration.
  Geronimo Plugins, AXIS2 :: Deployer
  org.apache.geronimo.configs/axis2-deployer//car Provides the web Services
  Deployer for Geronimo Axis 2 integration.
  Geronimo Plugins, AXIS2 :: EJB Deployer
  org.apache.geronimo.configs/axis2-ejb-deployer//car Provides the Geronimo
  JAX-WS EJB deployer for Apache Axis2.
  Geronimo Plugins, JAXWS :: Tools
  org.apache.geronimo.configs/jaxws-tools//car Provides JAX-WS command line
  tools.
  Geronimo Plugins, CXF :: Tools CLI
  org.apache.geronimo.configs/cxf-tools//car Provides CXF JAX-WS command
 line
  tools.
 
  Geronimo Plugin Group :: Web Services CXF
 
  Description: This plugin group provides Web Services CXF functionality.
  Plugins included:
  Plugin name ModuleId description
  Geronimo Plugins, AXIS :: Deployer
  org.apache.geronimo.configs/axis-deployer//car Provides web Services
  Deployer for Geronimo Axis 1 integration.
  Geronimo Plugins, CXF :: Deployer
  org.apache.geronimo.configs/cxf-deployer//car Provides Geronimo JAX-WS
  deployer for Apache CXF.
  Geronimo Plugins, CXF :: EJB Deployer
  org.apache.geronimo.configs/cxf-ejb-deployer//car Provides Geronimo
 JAX-WS
  EJB deployer for Apache CXF.
  Geronimo Plugins, JAXWS :: Tools
  org.apache.geronimo.configs/jaxws-tools//car Provides JAX-WS command line
  tools.
  Geronimo Plugins, CXF :: Tools CLI
  org.apache.geronimo.configs/cxf-tools//car Provides CXF JAX-WS command
 line
  tools.
 
 
  --
  Shawn
 




-- 
Shawn


[BUILD] trunk: Failed for Revision: 758936

2009-03-26 Thread gawor
Geronimo Revision: 758936 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090326/build-2100.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090326
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 36 minutes 5 seconds
[INFO] Finished at: Thu Mar 26 21:39:19 EDT 2009
[INFO] Final Memory: 650M/1016M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090326/logs-2100-tomcat/test.log
 
 
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from codehaus-snapshots
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:41.583
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO] 
[INFO] 
---
[INFO] 
[INFO] commands-testsuite/deploy  RUNNING
[INFO] commands-testsuite/deploy  SUCCESS (0:01:00.565) 
[INFO] commands-testsuite/gshell  RUNNING
[INFO] commands-testsuite/gshell  SUCCESS (0:00:28.170) 
[INFO] commands-testsuite/jaxws   RUNNING
[INFO] commands-testsuite/jaxws   SUCCESS (0:00:32.821) 
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:15.861) 
[INFO] concurrent-testsuite/concurrent-basic  RUNNING
[INFO] concurrent-testsuite/concurrent-basic  SUCCESS (0:06:29.102) 
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:28.849) 
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:54.819) 
[INFO] corba-testsuite/corba-helloworld   RUNNING
[INFO] corba-testsuite/corba-helloworld   SUCCESS (0:00:47.150) 
[INFO] corba-testsuite/corba-marshal  RUNNING
[INFO] corba-testsuite/corba-marshal  SUCCESS (0:00:49.198) 
[INFO] corba-testsuite/corba-mytime   RUNNING
[INFO] corba-testsuite/corba-mytime   SUCCESS (0:00:41.433) 
[INFO] deployment-testsuite/deployment-tests  RUNNING
[INFO] deployment-testsuite/deployment-tests  SUCCESS (0:00:29.780) 
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:32.711) 
[INFO] deployment-testsuite/manifestcp-tests  RUNNING
[INFO] deployment-testsuite/manifestcp-tests  SUCCESS (0:00:33.035) 
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:47.681) 
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:55.130) 
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:47.954) 
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:25.790) 
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:49.273) 
[INFO] security-testsuite/test-security   RUNNING
[INFO] security-testsuite/test-security   FAILURE (0:00:38.246) Java 
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:31.203) 
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5