Re: Release Connector/Transaction components
Hi devs, any news on the availability? Thanks Jean-Louis 2011/7/7 David Jencks david_jen...@yahoo.com I'm still not sure about the instructions, but releasing from the 2.2 branch should be fine. I only want to review the trunk code. also, replying to a different message, if you run release:prepare with -DdryRun=true, then you can't continue since there is no svn tag :-) thanks david jencks On Jul 6, 2011, at 2:24 PM, David Blevins wrote: On Jul 5, 2011, at 11:29 AM, Jacek Laskowski wrote: On Thu, Jun 30, 2011 at 12:26 PM, Jacek Laskowski ja...@laskowski.net.pl wrote: It's been a while since I was more active wrt Geronimo and there's a chance to change it - I may run the release process if no one objects. Hi, No one raised your hand to object or accept my offer, so I'm taking it on. As I understood it's to release https://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/. Doing both would be fine, but it's this one that is needed for OpenEJB 3.2: http://svn.apache.org/repos/asf/geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.2/ -David
Re: buildbot failure in ASF Buildbot on geronimo-server-trunk
failed for me. add dependency groupIdorg.apache.xbean/groupId artifactIdxbean-bundleutils/artifactId /dependency can resolve this. 2011/7/12 David Jencks david_jen...@yahoo.com The build works for me anyone else seeing problems? thanks david jencks On Jul 11, 2011, at 8:25 PM, build...@apache.org wrote: The Buildbot has detected a new failure on builder geronimo-server-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/geronimo-server-trunk/builds/179 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: hemera_ubuntu Build Reason: scheduler Build Source Stamp: [branch geronimo/server/trunk] 1145439 Blamelist: djencks,rwonly BUILD FAILED: failed compile sincerely, -The Buildbot -- Lei Wang (Rex) rwonly AT apache.org
Re: [jira] [Commented] (GERONIMODEVTOOLS-759) Using the new APIs to manage the bundles status both in GEP and Server side
I've reviewed the code, it's better and more concise than I did[?], thank you very much, Jarek. When I test the new feature, I find a problem that when restart the eclipse and modify the bundle's symbolic name or version, then publish the bundle to the server, the server would not remove the previous one! The root cause is when the eclipse restarts, the bundle Map's info is empty, so it could not get the cached bundle id and also the bundle's symbolic name or version has been changed, so it could not find the bundle id from server side by them, the bundle will be an isolated and never used one in server side. Maybe we still need persist the bundle map in GEP side, but just persist the bundle module id, symbolic name,version and the module's state(is removed or something else), the module state can be obtained by a resource changed listener as I patched before. What's your option? On Tue, Jul 12, 2011 at 1:45 AM, Jarek Gawor (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063449#comment-13063449] Jarek Gawor commented on GERONIMODEVTOOLS-759: -- In revision 1145251 I refactored the module handling code. I separated it into two separate classes - one for handling the Java EE modules and EBAs and second one for handling OSGi bundles. I also simplified the OSGi handling code. Please review in case I missed something. Using the new APIs to manage the bundles status both in GEP and Server side Key: GERONIMODEVTOOLS-759 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-759 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 3.0 Environment: WinXP sp3 32bit Win7 64bit, Oracle JDK 1.6, Eclipse3.6SR1SR2 Reporter: Yi Xiao Assignee: Jarek Gawor Labels: OSGI, bundle Fix For: 3.0 Attachments: OSGIBundleDeploy.patch, OSGIBundleDeploy_changeAPI.patch, OSGIBundleDeploy_changeAPI2_759.patch, OSGIBundleDeploy_changePOM_759.patch This improvement depends on the server's modules, so, if the server side does not update timely, it may cause the GEP compile failure! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira -- Best regards! John Xiao 330.gif
[jira] [Assigned] (GERONIMO-5904) Reference bound in JNDI is not dereferenced properly when lookup
[
https://issues.apache.org/jira/browse/GERONIMO-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan reassigned GERONIMO-5904:
--
Assignee: Ivan (was: Shenghao Fang)
Reference bound in JNDI is not dereferenced properly when lookup
Key: GERONIMO-5904
URL: https://issues.apache.org/jira/browse/GERONIMO-5904
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: naming
Affects Versions: 3.0
Reporter: Shenghao Fang
Assignee: Ivan
Attachments: GERONIMO-5904.patch
Get java.lang.ClassCastException:
org.tranql.connector.jdbc.TranqlDataSource$SelfReference cannot be cast to
javax.sql.DataSource on the following code snippet.
{code}
InitialContext ic = new InitialContext();
activeDS =
(DataSource)ic.lookup(jca:/org.apache.geronimo.plugins.monitoring/agent-ds/JCAConnectionManager/jdbc/ActiveDS);
{code}
An instance of org.tranql.connector.jdbc.TranqlDataSource is expected to be
returned, but get an instance of
org.tranql.connector.jdbc.TranqlDataSource$SelfReference.
TranqlDataSource implements javax.naming.Referenceable, so an instance of
javax.naming.Reference is bound on to JNDI, but it is expected to be
dereferenced when lookup.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5904) Reference bound in JNDI is not dereferenced properly when lookup
[
https://issues.apache.org/jira/browse/GERONIMO-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063763#comment-13063763
]
Ivan commented on GERONIMO-5904:
Hi, David, here is some background info for this issue. Geronimo maintains a
jndi tree of namepsace ger, and a listener for gbeans implement ResourceSource
is added. So, once a gbean of this type is started, its value from invoking
$getResource() is bind on the tree. With this tree, users could bind some other
instances on the jndi tree, and use the jndi lookup to get value from their
applications. I know that we have a URLResourceSource sample, which could be
used to bind a URL on the tree.
Move to this jira, once a data source is created, a
GenericConnectionManagerGBean is created, and the return value of
$getResource() will be bind on the jndi tree. The problems is that the return
value is a tranql datasource instance, it implements the Referenceable
interface, so while binding it on our jndi tree, its reference value will be
used as the real value on the tree. The question is, while looking up this
value from the tree, no ObjectFactory could be found by aries jndi
implementation, then bang !
The workaround solution for this is that, a ResourceReference instance is used
to bind on the jndi tree, not the actual instance. With this, the lookup
function could work as usual.
Is it clear for you ? I would go ahead to commit this patch, as some other
JIRAs are depending on this. we could turn to other better solutions if
possible.
Reference bound in JNDI is not dereferenced properly when lookup
Key: GERONIMO-5904
URL: https://issues.apache.org/jira/browse/GERONIMO-5904
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: naming
Affects Versions: 3.0
Reporter: Shenghao Fang
Assignee: Ivan
Attachments: GERONIMO-5904.patch
Get java.lang.ClassCastException:
org.tranql.connector.jdbc.TranqlDataSource$SelfReference cannot be cast to
javax.sql.DataSource on the following code snippet.
{code}
InitialContext ic = new InitialContext();
activeDS =
(DataSource)ic.lookup(jca:/org.apache.geronimo.plugins.monitoring/agent-ds/JCAConnectionManager/jdbc/ActiveDS);
{code}
An instance of org.tranql.connector.jdbc.TranqlDataSource is expected to be
returned, but get an instance of
org.tranql.connector.jdbc.TranqlDataSource$SelfReference.
TranqlDataSource implements javax.naming.Referenceable, so an instance of
javax.naming.Reference is bound on to JNDI, but it is expected to be
dereferenced when lookup.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5904) Reference bound in JNDI is not dereferenced properly when lookup
[
https://issues.apache.org/jira/browse/GERONIMO-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063765#comment-13063765
]
Ivan commented on GERONIMO-5904:
Commit the patch to trunk at rev.1145482. Thanks, Fang Sheng Hao !
Reference bound in JNDI is not dereferenced properly when lookup
Key: GERONIMO-5904
URL: https://issues.apache.org/jira/browse/GERONIMO-5904
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: naming
Affects Versions: 3.0
Reporter: Shenghao Fang
Assignee: Ivan
Attachments: GERONIMO-5904.patch
Get java.lang.ClassCastException:
org.tranql.connector.jdbc.TranqlDataSource$SelfReference cannot be cast to
javax.sql.DataSource on the following code snippet.
{code}
InitialContext ic = new InitialContext();
activeDS =
(DataSource)ic.lookup(jca:/org.apache.geronimo.plugins.monitoring/agent-ds/JCAConnectionManager/jdbc/ActiveDS);
{code}
An instance of org.tranql.connector.jdbc.TranqlDataSource is expected to be
returned, but get an instance of
org.tranql.connector.jdbc.TranqlDataSource$SelfReference.
TranqlDataSource implements javax.naming.Referenceable, so an instance of
javax.naming.Reference is bound on to JNDI, but it is expected to be
dereferenced when lookup.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[BUILD] branches/2.2: Failed for Revision: 1145394
Geronimo Revision: 1145394 built with tests included
See the full build-2000.log file at
http://people.apache.org/builds/geronimo/server/binaries/2.2/20110712/build-2000.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/2.2/20110712
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 430 minutes 4 seconds
[INFO] Finished at: Tue Jul 12 03:12:42 EDT 2011
[INFO] Final Memory: 316M/746M
[INFO]
TESTSUITE RESULTS (Failures only)
=
Assembly: tomcat
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/2.2/20110712/logs-2000-tomcat/
[INFO] Running TestSuite
[INFO] Tests run: 40, Failures: 26, Errors: 0, Skipped: 0, Time elapsed:
215.628 sec FAILURE!
[INFO] Running TestSuite
[INFO] Tests run: 12, Failures: 9, Errors: 0, Skipped: 0, Time elapsed: 59.62
sec FAILURE!
[INFO] [INFO] Copying 3 resources
[INFO] [INFO] [compiler:testCompile {execution: default}]
[INFO] [INFO] Compiling 1 source file to
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/test-classes
[INFO] [INFO] [ear:ear {execution: default-ear}]
[INFO] [INFO] Copying
artifact[war:org.apache.geronimo.testsuite:jca-cms-war:2.2.2-SNAPSHOT]
to[web.war]
[INFO] [INFO] Copying
artifact[rar:org.tranql:tranql-connector-derby-embed-xa:1.7] to[tranql.rar]
[INFO] [INFO] Copy ear resources to
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/jca-cms-ear-2.2.2-SNAPSHOT
[INFO] [INFO] Could not find manifest file:
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/src/main/application/META-INF/MANIFEST.MF
- Generating one
[INFO] [INFO] Building jar:
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/jca-cms-ear-2.2.2-SNAPSHOT.ear
[INFO] [INFO] [selenium:start-server {execution: start}]
[INFO] Launching Selenium Server
[INFO] Waiting for Selenium Server...
[INFO] [INFO] Including display properties from:
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/selenium/display.properties
[INFO] [INFO] Redirecting output to:
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/selenium/server.log
[INFO] [INFO] User extensions:
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/selenium/user-extensions.js
[INFO] Selenium Server started
[INFO] [INFO] [geronimo:deploy-module {execution: deploy-ears}]
[INFO] [INFO] Using non-artifact based module archive:
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/jca-cms-ear-2.2.2-SNAPSHOT.ear
[INFO] [INFO] Distributing module artifact:
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/jca-cms-ear-2.2.2-SNAPSHOT.ear
[INFO] [INFO] Starting modules...
[INFO] [INFO] Starting module:
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] Started module(s):
[INFO] [INFO] [0]
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] [failsafe:integration-test {execution: integration-test}]
[INFO] [INFO] Failsafe report directory:
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/failsafe-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running TestSuite
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.9 sec
[INFO]
[INFO] Results :
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] [WARNING] File encoding has not been set, using platform encoding
ANSI_X3.4-1968, i.e. build is platform dependent!
[INFO] [INFO] [selenium:stop-server {execution: stop}]
[INFO] Stopping Selenium server...
[INFO] Stop request sent
[INFO] [INFO] [geronimo:undeploy-module {execution: undeploy-ear-as-module}]
[INFO] [INFO] Using non-artifact based module id:
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] Stopping module:
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] Stopped module(s):
[INFO] [INFO] [0]
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] [0] web.war; URL: /jca-cms
[INFO] [INFO] [1] tranql.rar
[INFO] [INFO] Undeploying module:
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] Undeployed module(s):
[INFO] [INFO] [0]
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] [failsafe:verify {execution: verify}]
[INFO] [INFO] Failsafe report directory:
/home/geronimo/geronimo/2.2/testsuite
Fwd: EntityManager not closed when a stateful is destroyed
FYI If something fails in Geronimo, please lemme know. Jean-Louis -- Forwarded message -- From: Jean-Louis MONTEIRO jeano...@gmail.com Date: 2011/7/12 Subject: Re: EntityManager not closed when a stateful is destroyed To: d...@openejb.apache.org OK, reverted changes yesterday because of an issue with Inherited Persistence Context. Just committed another version with some more tests. Everything works on my laptop and on the CI. Jean-Louis -- View this message in context: http://openejb.979440.n4.nabble.com/EntityManager-not-closed-when-a-stateful-is-destroyed-tp3658876p3662008.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: buildbot failure in ASF Buildbot on geronimo-server-trunk
On Jul 12, 2011, at 1:23 AM, David Jencks wrote: The build works for me anyone else seeing problems? Builds fine for me, also. --kevan
[jira] [Assigned] (GERONIMO-6063) Yoko 1.2-SNAPSHOT
[ https://issues.apache.org/jira/browse/GERONIMO-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia reassigned GERONIMO-6063: - Assignee: Forrest Xia Yoko 1.2-SNAPSHOT - Key: GERONIMO-6063 URL: https://issues.apache.org/jira/browse/GERONIMO-6063 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Reporter: David Blevins Assignee: Forrest Xia Fix For: 3.0-M2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Release geronimo-el and geronimo-jaxws spec package
I'm going to release geronimo-stax-api_1.2_spec because jaxb bundle and woodstox bundle release also depend on this spec. On Thu, Jun 30, 2011 at 3:38 PM, Ivan xhh...@gmail.com wrote: Another dependent package is also required to release first, geronimo-stax-api_1.2_spec 2011/6/28 Ivan xhh...@gmail.com Hi, we just got some fixes for geronimo-el and geronimo-jaxws-2.2 spec package in the past, I am thinking to do those two package release soon if no objection. -- Ivan -- Ivan -- Shawn
[VOTE] release StAX 1.2 spec version 1.1
[VOTE] release StAX 1.2 spec version 1.1 This is a bug fix release that only includes one fix for GERONIMO-5848 The components up for vote are: https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz The maven staging repository is : https://repository.apache.org/content/repositories/orgapachegeronimo-014/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn
Re: [VOTE] release StAX 1.2 spec version 1.1
1, mvn install build is OK 2, mvn rat:check result is clean. Here is my own +1. On Tue, Jul 12, 2011 at 9:48 PM, Shawn Jiang genspr...@gmail.com wrote: [VOTE] release StAX 1.2 spec version 1.1 This is a bug fix release that only includes one fix for GERONIMO-5848 The components up for vote are: https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz The maven staging repository is : https://repository.apache.org/content/repositories/orgapachegeronimo-014/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn -- Shawn
Re: [VOTE] release StAX 1.2 spec version 1.1 cancelled.
Canceling this vote since the staging repo contains other bundle that I don't want to release now. On Tue, Jul 12, 2011 at 9:48 PM, Shawn Jiang genspr...@gmail.com wrote: [VOTE] release StAX 1.2 spec version 1.1 This is a bug fix release that only includes one fix for GERONIMO-5848 The components up for vote are: https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz The maven staging repository is : https://repository.apache.org/content/repositories/orgapachegeronimo-014/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn -- Shawn
Re: [VOTE] release StAX 1.2 spec version 1.1
cancelled. Will clean up the staging and then init the vote again. On Tue, Jul 12, 2011 at 9:48 PM, Shawn Jiang genspr...@gmail.com wrote: [VOTE] release StAX 1.2 spec version 1.1 This is a bug fix release that only includes one fix for GERONIMO-5848 The components up for vote are: https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz The maven staging repository is : https://repository.apache.org/content/repositories/orgapachegeronimo-014/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn -- Shawn
Class-Path in manifest file of applicationclient module.
Hi, Dev: I met a problem when deploy an ear which packages an ejb, application client, web app. And the EJB is in the class-path of app client module manifest, but Appclientmodulebuilder class doesn't add this class-path of manifest to module's LinkedHashSetString classpath, So it's not in the class path of AppclientDeplomentContext either. Is it correct? -- viola Apache Geronimo
Re: Class-Path in manifest file of applicationclient module.
Yes, it is by design. App client modules should not have access to web modules, ejb modules and other app client modules in the same ear package. 2011/7/12 viola lu viola...@gmail.com Hi, Dev: I met a problem when deploy an ear which packages an ejb, application client, web app. And the EJB is in the class-path of app client module manifest, but Appclientmodulebuilder class doesn't add this class-path of manifest to module's LinkedHashSetString classpath, So it's not in the class path of AppclientDeplomentContext either. Is it correct? -- viola Apache Geronimo -- Ivan
Re: Class-Path in manifest file of applicationclient module.
per java ee 6 spec: EE.8.3.3 Application Client Container Class Loading Requirements Components in the application client container must not have access to the following classes and resources, *unless such classes or resources are covered by one of the rules above.* If the ejb jar is in the class-path of app client module, the module will have the access to ejb jar. On Tue, Jul 12, 2011 at 10:59 PM, Ivan xhh...@gmail.com wrote: Yes, it is by design. App client modules should not have access to web modules, ejb modules and other app client modules in the same ear package. 2011/7/12 viola lu viola...@gmail.com Hi, Dev: I met a problem when deploy an ear which packages an ejb, application client, web app. And the EJB is in the class-path of app client module manifest, but Appclientmodulebuilder class doesn't add this class-path of manifest to module's LinkedHashSetString classpath, So it's not in the class path of AppclientDeplomentContext either. Is it correct? -- viola Apache Geronimo -- Ivan -- Shawn
Re: Class-Path in manifest file of applicationclient module.
Hmm, I double checked the spec, so which rule should cover this request ? --- • The Java EE API classes specified in Table EE.6-1 for the containers other than the application client container. • Any installed libraries available in the application server. • Other classes or resources contained in the application package, and specified by an explicit use of an extension not defined by this specification. • Other classes and resources that are part of the implementation of the applica- tion server. --- 2011/7/12 Shawn Jiang genspr...@gmail.com per java ee 6 spec: EE.8.3.3 Application Client Container Class Loading Requirements Components in the application client container must not have access to the following classes and resources, *unless such classes or resources are covered by one of the rules above.* If the ejb jar is in the class-path of app client module, the module will have the access to ejb jar. On Tue, Jul 12, 2011 at 10:59 PM, Ivan xhh...@gmail.com wrote: Yes, it is by design. App client modules should not have access to web modules, ejb modules and other app client modules in the same ear package. 2011/7/12 viola lu viola...@gmail.com Hi, Dev: I met a problem when deploy an ear which packages an ejb, application client, web app. And the EJB is in the class-path of app client module manifest, but Appclientmodulebuilder class doesn't add this class-path of manifest to module's LinkedHashSetString classpath, So it's not in the class path of AppclientDeplomentContext either. Is it correct? -- viola Apache Geronimo -- Ivan -- Shawn -- Ivan
Re: Is it time to release YOKO 1.2 for G 3.0?
On Jul 12, 2011, at 12:31 AM, Forrest Xia wrote: Hi All, I think we come to a point to determine whether to release YOKO 1.2 for G 3.0 release. Since rest of YOKO related tck failures are due to RI' problem we think, I would think we could release YOKO 1.2 now. If any objection, please speak out, otherwise, I start a vote for that soon. Yesterday, I probably would have said we shouldn't release Yoko, yet. But today, is a different day... ;-) Looks like our test issues have been resolved. So, I think we can release Yoko... --kevan
[VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
[VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt. This is a bug fix release that only includes one bug fix for GERONIMO-5848 The components up for vote are: https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-019/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn
Re: Class-Path in manifest file of applicationclient module.
Components in the application client container must have access to the following classes and resources. • The content of the application client jar file. • The transitive closure of any libraries referenced by the above jar file (as spec- ified in Section EE.8.2, “Library Support”). On Tue, Jul 12, 2011 at 11:10 PM, Ivan xhh...@gmail.com wrote: Hmm, I double checked the spec, so which rule should cover this request ? --- • The Java EE API classes specified in Table EE.6-1 for the containers other than the application client container. • Any installed libraries available in the application server. • Other classes or resources contained in the application package, and specified by an explicit use of an extension not defined by this specification. • Other classes and resources that are part of the implementation of the applica- tion server. --- 2011/7/12 Shawn Jiang genspr...@gmail.com per java ee 6 spec: EE.8.3.3 Application Client Container Class Loading Requirements Components in the application client container must not have access to the following classes and resources, *unless such classes or resources are covered by one of the rules above.* If the ejb jar is in the class-path of app client module, the module will have the access to ejb jar. On Tue, Jul 12, 2011 at 10:59 PM, Ivan xhh...@gmail.com wrote: Yes, it is by design. App client modules should not have access to web modules, ejb modules and other app client modules in the same ear package. 2011/7/12 viola lu viola...@gmail.com Hi, Dev: I met a problem when deploy an ear which packages an ejb, application client, web app. And the EJB is in the class-path of app client module manifest, but Appclientmodulebuilder class doesn't add this class-path of manifest to module's LinkedHashSetString classpath, So it's not in the class path of AppclientDeplomentContext either. Is it correct? -- viola Apache Geronimo -- Ivan -- Shawn -- Ivan -- Shawn
Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
1, mvn install build is OK 2, mvn rat:check result is clean. Again, Here is my own +1. On Tue, Jul 12, 2011 at 11:18 PM, Shawn Jiang genspr...@gmail.com wrote: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt. This is a bug fix release that only includes one bug fix for GERONIMO-5848 The components up for vote are: https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-019/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn -- Shawn
Re: Class-Path in manifest file of applicationclient module.
From the word of 'library', I do not think that ejb module is belong to this scope. 2011/7/12 Shawn Jiang genspr...@gmail.com Components in the application client container must have access to the following classes and resources. • The content of the application client jar file. • The transitive closure of any libraries referenced by the above jar file (as spec- ified in Section EE.8.2, “Library Support”). On Tue, Jul 12, 2011 at 11:10 PM, Ivan xhh...@gmail.com wrote: Hmm, I double checked the spec, so which rule should cover this request ? --- • The Java EE API classes specified in Table EE.6-1 for the containers other than the application client container. • Any installed libraries available in the application server. • Other classes or resources contained in the application package, and specified by an explicit use of an extension not defined by this specification. • Other classes and resources that are part of the implementation of the applica- tion server. --- 2011/7/12 Shawn Jiang genspr...@gmail.com per java ee 6 spec: EE.8.3.3 Application Client Container Class Loading Requirements Components in the application client container must not have access to the following classes and resources, *unless such classes or resources are covered by one of the rules above.* If the ejb jar is in the class-path of app client module, the module will have the access to ejb jar. On Tue, Jul 12, 2011 at 10:59 PM, Ivan xhh...@gmail.com wrote: Yes, it is by design. App client modules should not have access to web modules, ejb modules and other app client modules in the same ear package. 2011/7/12 viola lu viola...@gmail.com Hi, Dev: I met a problem when deploy an ear which packages an ejb, application client, web app. And the EJB is in the class-path of app client module manifest, but Appclientmodulebuilder class doesn't add this class-path of manifest to module's LinkedHashSetString classpath, So it's not in the class path of AppclientDeplomentContext either. Is it correct? -- viola Apache Geronimo -- Ivan -- Shawn -- Ivan -- Shawn -- Ivan
[VOTE] release YOKO 1.2 - 1st attempt.
[VOTE] release YOKO 1.2 - 1st attempt. This is a bug fixes release for Java EE 6 compliance: The fixes in this release are: YOKO-431 Classloader issue when initializing a corba skeleton for EJB object YOKO-433 YOKO chunking logic does not set the the chunk flag to false when the valuetype tag is false on the chunking bit The artifacts up for vote are: 1. https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz 2. https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-019/ https://repository.apache.org/content/repositories/orgapachegeronimo-016 The source tag is: https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn
Re: [VOTE] release YOKO 1.2 - 1st attempt.
1. mvn test, all passed 2. mvn install, all succeed 3. mvn rat:check, except those auto-generated CORBA spec classes and OMG copyright files, all of the other files are passed! So, My +1 Forrest On Tue, Jul 12, 2011 at 11:45 PM, Forrest Xia forres...@gmail.com wrote: [VOTE] release YOKO 1.2 - 1st attempt. This is a bug fixes release for Java EE 6 compliance: The fixes in this release are: YOKO-431 Classloader issue when initializing a corba skeleton for EJB object YOKO-433 YOKO chunking logic does not set the the chunk flag to false when the valuetype tag is false on the chunking bit The artifacts up for vote are: 1. https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz 2. https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-019/ https://repository.apache.org/content/repositories/orgapachegeronimo-016 The source tag is: https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn
[jira] [Created] (GERONIMO-6073) Rotation and appending of console output when Geronimo is run a windows service
Rotation and appending of console output when Geronimo is run a windows service --- Key: GERONIMO-6073 URL: https://issues.apache.org/jira/browse/GERONIMO-6073 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: commands Affects Versions: 2.2.1, 2.1.7 Environment: Windows Reporter: Vamsavardhana Reddy GERONIMO-4394 provided for running Geronimo as windows service. The console output STDOUT is directed to geronimosrv.out and STDERR is directed to geronimosrv.err. If the server is running for long, these files can grow big requiring the server to be stopped. Also, each time the server is started as service, the files from the previous run are overwritten since the output does not get appended to existing file. So, if a user is interested in the console output from the previous runs, it is lost. So, console output rotation and appending to already existing files should be a good improvement for the Run Geronimo as a Windows service feature. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Is there possible for 1.7.0 release ?
Hi, devs, I just uploaded a patch for AXIS2-5023https://issues.apache.org/jira/browse/AXIS2-5023. If possible, please help to review it first, as I am not quite confident for the changes for this jira, although it seems to work now. Thanks. 2011/7/12 Ivan xhh...@gmail.com OK, I forget to reply to Axis2 mail list again ... 2011/7/12 Ivan xhh...@gmail.com 2011/7/12 Andreas Veithen andreas.veit...@gmail.com The changes for Neethi 3.0.x (including the three changes mentioned in your mail) should now be included in the latest 1.6.1-SNAPSHOT build. The release vote for Neethi 3.0.1 has started a couple of hours ago. Once that release is complete, we can switch to the Neethi 3.0.1 release version on the 1.6 branch and Axis2 1.6.1 will be ready for release. Thanks, Andreas, I will try to switch to Axis2 1.6.1-SNAPSHOT soon. Regarding the list of JIRA issues, if I understand this correctly, the Geronimo project has a sort of patching mechanism so that they are not on the critical path for the Geronimo release, which means that we have the time to review them properly and first apply them to the trunk, without delaying any Geronimo release. Can you confirm this? Hmm, I would say that the patching mechanism used now is somewhat a 'temporary' solution, and it is not expected to do that. Geronimo needs to bundle the axis2 components, that gave us a chance to modify codes. We do hope that those patches could be reviewed and included in Axis2 code base. And yes, they work well now, but it is better to have your Axis2 experts' view for them. Also, from other sides, most of them are related to JAX-WS 2.2 support. I guess that they are also important for Axis2 ;-) Anyway, it depends on your schedule, and your guys really helped us a lot in the past. Thanks. Andreas On Sun, Jul 10, 2011 at 15:58, Ivan xhh...@gmail.com wrote: Hi, Axis2 devs, any thought to port those listed changes to 1.6 branch ? Thanks. 2011/7/8 Ivan xhh...@gmail.com Just add the geronimo mail address. 2011/7/8 Ivan xhh...@gmail.com Hi, the initial reason for moving to 1.7.0-SNAPSHOT is for the Policy support, the changes are list below. If they could be ported to 1.6 branch, we are fine to try to turn to 1.6 branch. Also, understand that you guys are busy with some other stuffs, will be very appreciated if those web services patches could be reviewed and included in the 1.6 branch. I pasted the Jira list in the end of the mail. The initial thread could be found http://www.mail-archive.com/java-dev@axis.apache.org/msg06438.html Thanks. --- Revision: 1090457 Author: veithen Date: 5:36:59 AM, Saturday, April 09, 2011 Message: Exclude the transitive Woodstox dependency from Neethi. Otherwise we will end up with two versions of Woodstox. Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml Revision: 1090429 Author: veithen Date: 4:19:38 AM, Saturday, April 09, 2011 Message: Neethi now supports DOM elements. Therefore we don't need to convert DOM elements to stream any more. Alos, DOM2Writer seems to have a bug that causes processing of some policies to fail. Modified : /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java Revision: 1089989 Author: veithen Date: 4:27:37 AM, Friday, April 08, 2011 Message: Updated Neethi dependency and fixed PolicyUtil such that it supports all WS-Policy namespaces supported by Neethi. Modified : /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml --- Jira list: (AXIS2-5062) Connection is not released while using JAXWS client API (AXIS2-5039) Override the SOAPAction from the SOAPMessage MIME header if it is explicitly configured later (AXIS2-5023) Ambigious use of isElementData in the Block interface (AXIS2-5022) Support addressing meta data with policy 1.5 framework (AXIS2-5040) Ignore the methods while no webmethod annotation and no webservice annotation on the declaring class (AXIS2-5034) Incorrect exception name is used for fault message while creating AxisService from WSDL (AXIS2-5001) SOAPMessage.getSOAPHeaders() return null while no headers in the soap envelope (AXIS2-4996) Exclude content-length header while chunked is enabled 2011/7/8 Andreas Veithen andreas.veit...@gmail.com Ivan, There are no plans for a 1.7.0 release, but we can do a 1.6.1 maintenance release. For that you need to let us know which changes you want to see included in that release, so that we can merge them to the 1.6 branch. The goal is to make Geronimo work with 1.6.1-SNAPSHOT. Once that is done, we can create the 1.6.1 release anytime you want. Andreas On Fri, Jul 8, 2011 at 04:31, Ivan xhh...@gmail.com wrote: Hi, Axis2 devs, Geronimo bundles the some Axis2
Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
Build and rat check seems OK for me +1 Forrest On Tue, Jul 12, 2011 at 11:22 PM, Shawn Jiang genspr...@gmail.com wrote: 1, mvn install build is OK 2, mvn rat:check result is clean. Again, Here is my own +1. On Tue, Jul 12, 2011 at 11:18 PM, Shawn Jiang genspr...@gmail.com wrote: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt. This is a bug fix release that only includes one bug fix for GERONIMO-5848 The components up for vote are: https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-019/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn -- Shawn
Re: [VOTE] release YOKO 1.2 - 1st attempt.
build OK for me. + 1 if interop TCK 100% pass On Tue, Jul 12, 2011 at 11:57 PM, Forrest Xia forres...@gmail.com wrote: 1. mvn test, all passed 2. mvn install, all succeed 3. mvn rat:check, except those auto-generated CORBA spec classes and OMG copyright files, all of the other files are passed! So, My +1 Forrest On Tue, Jul 12, 2011 at 11:45 PM, Forrest Xia forres...@gmail.com wrote: [VOTE] release YOKO 1.2 - 1st attempt. This is a bug fixes release for Java EE 6 compliance: The fixes in this release are: YOKO-431 Classloader issue when initializing a corba skeleton for EJB object YOKO-433 YOKO chunking logic does not set the the chunk flag to false when the valuetype tag is false on the chunking bit The artifacts up for vote are: 1. https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz 2. https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-019/ https://repository.apache.org/content/repositories/orgapachegeronimo-016 The source tag is: https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn -- Shawn
Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
+1 2011/7/13 Forrest Xia forres...@gmail.com Build and rat check seems OK for me +1 Forrest On Tue, Jul 12, 2011 at 11:22 PM, Shawn Jiang genspr...@gmail.com wrote: 1, mvn install build is OK 2, mvn rat:check result is clean. Again, Here is my own +1. On Tue, Jul 12, 2011 at 11:18 PM, Shawn Jiang genspr...@gmail.comwrote: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt. This is a bug fix release that only includes one bug fix for GERONIMO-5848 The components up for vote are: https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-019/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn -- Shawn -- Ivan
Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
Looks good with one exception. geronimo-stax-api_1.2_spec-1.1/NOTICE.txt contains: Copyright 2003-2006 The Apache Software Foundation Not a hard requirement, but by our convention the latter date should be 2011. Also, most of our LICENSE/NOTICE files no longer have the .txt suffix. Neither of these are a hard requirement. But given the number of releases that we'll have coming up, may as well cleanup now... Beyond the above, source, signatures/checksums, and build -- all look good to me. With the above minor concerns, I'm +0. --kevan On Jul 12, 2011, at 11:18 AM, Shawn Jiang wrote: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt. This is a bug fix release that only includes one bug fix for GERONIMO-5848 The components up for vote are: https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-019/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn
Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
On Wed, Jul 13, 2011 at 12:01 PM, Kevan Miller kevan.mil...@gmail.comwrote: Looks good with one exception. geronimo-stax-api_1.2_spec-1.1/NOTICE.txt contains: Copyright 2003-2006 The Apache Software Foundation Not a hard requirement, but by our convention the latter date should be 2011. Just updated latter date to 2011 for all notice files in geronimo bundles. Also, most of our LICENSE/NOTICE files no longer have the .txt suffix. Do you mean we need to rename LICENSE/NOTICE to LICENSE.txt/NOTICE.txt ? Neither of these are a hard requirement. But given the number of releases that we'll have coming up, may as well cleanup now... Beyond the above, source, signatures/checksums, and build -- all look good to me. With the above minor concerns, I'm +0. --kevan On Jul 12, 2011, at 11:18 AM, Shawn Jiang wrote: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt. This is a bug fix release that only includes one bug fix for GERONIMO-5848 The components up for vote are: https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-019/ The source repo is: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn -- Shawn
Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
On Jul 13, 2011, at 12:29 AM, Shawn Jiang wrote: On Wed, Jul 13, 2011 at 12:01 PM, Kevan Miller kevan.mil...@gmail.com wrote: Looks good with one exception. geronimo-stax-api_1.2_spec-1.1/NOTICE.txt contains: Copyright 2003-2006 The Apache Software Foundation Not a hard requirement, but by our convention the latter date should be 2011. Just updated latter date to 2011 for all notice files in geronimo bundles. Also, most of our LICENSE/NOTICE files no longer have the .txt suffix. Do you mean we need to rename LICENSE/NOTICE to LICENSE.txt/NOTICE.txt ? Yes. --kevan
Re: [VOTE] release YOKO 1.2 - 1st attempt.
Same about the year in the NOTICE file. So, would like to see that updated. The source, signatures/checksums, LICENSE/NOTICE file looks good. I'm running a build, now. Will let you know if I see any problems. I keep building while a Geronimo server is running. IIRC, the server interferes with the junit tests. Once the NOTICE file is updated, I should be +1 --kevan On Jul 12, 2011, at 11:45 AM, Forrest Xia wrote: [VOTE] release YOKO 1.2 - 1st attempt. This is a bug fixes release for Java EE 6 compliance: The fixes in this release are: YOKO-431 Classloader issue when initializing a corba skeleton for EJB object YOKO-433 YOKO chunking logic does not set the the chunk flag to false when the valuetype tag is false on the chunking bit The artifacts up for vote are: 1. https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz 2. https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip The staging repository is: https://repository.apache.org/content/repositories/orgapachegeronimo-016 The source tag is: https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Shawn
Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
OK, for this spec, let's leave it as is. I'll update the remaining bundles before releasing them. On Wed, Jul 13, 2011 at 12:34 PM, Kevan Miller kevan.mil...@gmail.comwrote: On Jul 13, 2011, at 12:29 AM, Shawn Jiang wrote: On Wed, Jul 13, 2011 at 12:01 PM, Kevan Miller kevan.mil...@gmail.com wrote: Looks good with one exception. geronimo-stax-api_1.2_spec-1.1/NOTICE.txt contains: Copyright 2003-2006 The Apache Software Foundation Not a hard requirement, but by our convention the latter date should be 2011. Just updated latter date to 2011 for all notice files in geronimo bundles. Also, most of our LICENSE/NOTICE files no longer have the .txt suffix. Do you mean we need to rename LICENSE/NOTICE to LICENSE.txt/NOTICE.txt ? Yes. --kevan -- Shawn
