asm4 in xbean
Hi! A small discussion which popped up on IRC regarding asm4: Preclusion: ASM3 and ASM4 are _not_ binary compatible but use the same packages. For preventing some classpath clashes this xbean-asm-shaded package got created. This was ASM3 so far. When moving up to ASM4 we should thus change the package we shade it in, e.g. to org.apache.xbean.asm4.* I think there is common agreement on this point, right? I've added a new module of xbean-asm4-shaded which uses ASM4 and shades to the aforementioned path. But what to do with the asm3 shade? We now have two options: Do we like to 1.) keep both or do we like to 2.) upgrade whole xbean to ASM4 and remove the old xbean-asm-shaded (and only keep xbean-asm4-shaded)? 2.b) keep the xbean-asm-shaded artifactId but otherwise do like 2.). I perso don't like this much as it is not so explicit for users. LieGrue, strub
Re: asm4 in xbean
+1 to remove xbean asm3 shade and upgrade xbean to support asm4 shade (in progress) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/5/27 Mark Struberg strub...@yahoo.de Hi! A small discussion which popped up on IRC regarding asm4: Preclusion: ASM3 and ASM4 are _not_ binary compatible but use the same packages. For preventing some classpath clashes this xbean-asm-shaded package got created. This was ASM3 so far. When moving up to ASM4 we should thus change the package we shade it in, e.g. to org.apache.xbean.asm4.* I think there is common agreement on this point, right? I've added a new module of xbean-asm4-shaded which uses ASM4 and shades to the aforementioned path. But what to do with the asm3 shade? We now have two options: Do we like to 1.) keep both or do we like to 2.) upgrade whole xbean to ASM4 and remove the old xbean-asm-shaded (and only keep xbean-asm4-shaded)? 2.b) keep the xbean-asm-shaded artifactId but otherwise do like 2.). I perso don't like this much as it is not so explicit for users. LieGrue, strub
Re: asm4 in xbean
Out of curiosity, what are the objectives of such a change? I mean, is there any important improvments on ASM4 we cannot miss? Is ASM 3 end of life? Jean-Louis 2013/5/27 Mark Struberg strub...@yahoo.de Hi! A small discussion which popped up on IRC regarding asm4: Preclusion: ASM3 and ASM4 are _not_ binary compatible but use the same packages. For preventing some classpath clashes this xbean-asm-shaded package got created. This was ASM3 so far. When moving up to ASM4 we should thus change the package we shade it in, e.g. to org.apache.xbean.asm4.* I think there is common agreement on this point, right? I've added a new module of xbean-asm4-shaded which uses ASM4 and shades to the aforementioned path. But what to do with the asm3 shade? We now have two options: Do we like to 1.) keep both or do we like to 2.) upgrade whole xbean to ASM4 and remove the old xbean-asm-shaded (and only keep xbean-asm4-shaded)? 2.b) keep the xbean-asm-shaded artifactId but otherwise do like 2.). I perso don't like this much as it is not so explicit for users. LieGrue, strub -- Jean-Louis
Re: asm4 in xbean
The most change I could see is for Java 7 support. 2013/5/27 Jean-Louis MONTEIRO jeano...@gmail.com Out of curiosity, what are the objectives of such a change? I mean, is there any important improvments on ASM4 we cannot miss? Is ASM 3 end of life? Jean-Louis 2013/5/27 Mark Struberg strub...@yahoo.de Hi! A small discussion which popped up on IRC regarding asm4: Preclusion: ASM3 and ASM4 are _not_ binary compatible but use the same packages. For preventing some classpath clashes this xbean-asm-shaded package got created. This was ASM3 so far. When moving up to ASM4 we should thus change the package we shade it in, e.g. to org.apache.xbean.asm4.* I think there is common agreement on this point, right? I've added a new module of xbean-asm4-shaded which uses ASM4 and shades to the aforementioned path. But what to do with the asm3 shade? We now have two options: Do we like to 1.) keep both or do we like to 2.) upgrade whole xbean to ASM4 and remove the old xbean-asm-shaded (and only keep xbean-asm4-shaded)? 2.b) keep the xbean-asm-shaded artifactId but otherwise do like 2.). I perso don't like this much as it is not so explicit for users. LieGrue, strub -- Jean-Louis -- Ivan
Re: asm4 in xbean
Mainly a real complete support of Java 7 IMO *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/5/27 Jean-Louis MONTEIRO jeano...@gmail.com Out of curiosity, what are the objectives of such a change? I mean, is there any important improvments on ASM4 we cannot miss? Is ASM 3 end of life? Jean-Louis 2013/5/27 Mark Struberg strub...@yahoo.de Hi! A small discussion which popped up on IRC regarding asm4: Preclusion: ASM3 and ASM4 are _not_ binary compatible but use the same packages. For preventing some classpath clashes this xbean-asm-shaded package got created. This was ASM3 so far. When moving up to ASM4 we should thus change the package we shade it in, e.g. to org.apache.xbean.asm4.* I think there is common agreement on this point, right? I've added a new module of xbean-asm4-shaded which uses ASM4 and shades to the aforementioned path. But what to do with the asm3 shade? We now have two options: Do we like to 1.) keep both or do we like to 2.) upgrade whole xbean to ASM4 and remove the old xbean-asm-shaded (and only keep xbean-asm4-shaded)? 2.b) keep the xbean-asm-shaded artifactId but otherwise do like 2.). I perso don't like this much as it is not so explicit for users. LieGrue, strub -- Jean-Louis
Re: asm4 in xbean
asm4 has java7++ support - asm3 not. LieGrue, strub From: Jean-Louis MONTEIRO jeano...@gmail.com To: dev@geronimo.apache.org; Mark Struberg strub...@yahoo.de Sent: Monday, 27 May 2013, 9:40 Subject: Re: asm4 in xbean Out of curiosity, what are the objectives of such a change? I mean, is there any important improvments on ASM4 we cannot miss? Is ASM 3 end of life? Jean-Louis 2013/5/27 Mark Struberg strub...@yahoo.de Hi! A small discussion which popped up on IRC regarding asm4: Preclusion: ASM3 and ASM4 are _not_ binary compatible but use the same packages. For preventing some classpath clashes this xbean-asm-shaded package got created. This was ASM3 so far. When moving up to ASM4 we should thus change the package we shade it in, e.g. to org.apache.xbean.asm4.* I think there is common agreement on this point, right? I've added a new module of xbean-asm4-shaded which uses ASM4 and shades to the aforementioned path. But what to do with the asm3 shade? We now have two options: Do we like to 1.) keep both or do we like to 2.) upgrade whole xbean to ASM4 and remove the old xbean-asm-shaded (and only keep xbean-asm4-shaded)? 2.b) keep the xbean-asm-shaded artifactId but otherwise do like 2.). I perso don't like this much as it is not so explicit for users. LieGrue, strub -- Jean-Louis
[VOTE] Release Geronimo eclipse plugin 3.0.1
Hi Devs, Please vote Geronimo eclipse plugin(GEP) 3.0.1 release. This is a release along with Geronimo server runtime release 3.0.1. For details, see http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/geronimo-eclipse-plugin-3.0.1/PLUGIN_RELEASE-NOTES.txt The GEP code up for vote is: https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0.1/geronimo-eclipse-plugin-3.0.1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0.1/geronimo-eclipse-plugin-3.0.1-source-release.zip The GEP staging update site is: http://people.apache.org/builds/geronimo/eclipse/updates/ The release staging site is: https://repository.apache.org/content/repositories/orgapachegeronimo-003 The tag has created at: http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/geronimo-eclipse-plugin-3.0.1/ Vote will be at least open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Thanks! Regards, Forrest
Cancelled [VOTE] Release Geronimo eclipse plugin 3.0.1
On Mon, May 27, 2013 at 5:29 PM, Forrest Xia forres...@gmail.com wrote: Hi Devs, Please vote Geronimo eclipse plugin(GEP) 3.0.1 release. This is a release along with Geronimo server runtime release 3.0.1. For details, see http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/geronimo-eclipse-plugin-3.0.1/PLUGIN_RELEASE-NOTES.txt The GEP code up for vote is: https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0.1/geronimo-eclipse-plugin-3.0.1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0.1/geronimo-eclipse-plugin-3.0.1-source-release.zip The GEP staging update site is: http://people.apache.org/builds/geronimo/eclipse/updates/ The release staging site is: https://repository.apache.org/content/repositories/orgapachegeronimo-003 The tag has created at: http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/geronimo-eclipse-plugin-3.0.1/ Vote will be at least open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Thanks! Regards, Forrest -- Thanks! Regards, Forrest
[VOTE] Release Geronimo eclipse plugin 3.0.1
Hi Devs, Please vote Geronimo eclipse plugin(GEP) 3.0.1 release. This is a release along with Geronimo server runtime release 3.0.1. For details, see http://people.apache.org/builds/geronimo/eclipse/updates/PLUGIN_RELEASE-NOTES-3.0.1.txt The GEP code up for vote is: https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0.1/geronimo-eclipse-plugin-3.0.1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0.1/geronimo-eclipse-plugin-3.0.1-source-release.zip The GEP staging update site is: http://people.apache.org/builds/geronimo/eclipse/updates/ The release staging site is: https://repository.apache.org/content/repositories/orgapachegeronimo-003 The tag has created at: http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/geronimo-eclipse-plugin-3.0.1/ Vote will be at least open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Thanks! Regards, Forrest
Re: [VOTE] Release Geronimo eclipse plugin 3.0.1
+1 myself On Mon, May 27, 2013 at 5:33 PM, Forrest Xia forres...@gmail.com wrote: Hi Devs, Please vote Geronimo eclipse plugin(GEP) 3.0.1 release. This is a release along with Geronimo server runtime release 3.0.1. For details, see http://people.apache.org/builds/geronimo/eclipse/updates/PLUGIN_RELEASE-NOTES-3.0.1.txt The GEP code up for vote is: https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0.1/geronimo-eclipse-plugin-3.0.1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0.1/geronimo-eclipse-plugin-3.0.1-source-release.zip The GEP staging update site is: http://people.apache.org/builds/geronimo/eclipse/updates/ The release staging site is: https://repository.apache.org/content/repositories/orgapachegeronimo-003 The tag has created at: http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/geronimo-eclipse-plugin-3.0.1/ Vote will be at least open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Thanks! Regards, Forrest -- Thanks! Regards, Forrest
[jira] [Updated] (GERONIMO-6467) Make 3.0.1 release
[ https://issues.apache.org/jira/browse/GERONIMO-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6467: -- Description: 3.0.1 is in a good shape to be released 1. Clean up JIRA system to figure out fixed bugs/tasks/improvments, then update release notes file 2. Add a new version for next release, e.g. 3.0.2 3. Make a release tag and open a vote in the dev mailing list 4. Add Geronimo plugin list for 3.0.1 release 5. Add release artifacts to https://dist.apache.org/repos/dist/release/geronimo/ 6. Update download page in geronimo.apache.org, and add a news about it 7. Send announcement emails to mailing list was: 3.0.1 is in a good shape to be released 1. Clean up JIRA system to figure out fixed bugs/tasks/improvments, then update release notes file 2. Add a new version for next release, e.g. 3.0.2 3. Make a release tag and open a vote in the dev mailing list 4. Add Geronimo plugin list for 3.0.1 release 5. TODO Make 3.0.1 release -- Key: GERONIMO-6467 URL: https://issues.apache.org/jira/browse/GERONIMO-6467 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 3.0.1 Reporter: Forrest Xia Assignee: Forrest Xia Labels: release Fix For: 3.0.1 3.0.1 is in a good shape to be released 1. Clean up JIRA system to figure out fixed bugs/tasks/improvments, then update release notes file 2. Add a new version for next release, e.g. 3.0.2 3. Make a release tag and open a vote in the dev mailing list 4. Add Geronimo plugin list for 3.0.1 release 5. Add release artifacts to https://dist.apache.org/repos/dist/release/geronimo/ 6. Update download page in geronimo.apache.org, and add a news about it 7. Send announcement emails to mailing list -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6248) Output a compound WSDL file for the queries from the clients for CXF integration
[ https://issues.apache.org/jira/browse/GERONIMO-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6248: -- Fix Version/s: (was: 3.0.1) 3.0.2 Output a compound WSDL file for the queries from the clients for CXF integration Key: GERONIMO-6248 URL: https://issues.apache.org/jira/browse/GERONIMO-6248 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: webservices Affects Versions: 3.0.0 Reporter: Ivan Assignee: Ivan Fix For: 3.0.2 Sometimes, if multiple SEI shares the same provided WSDL file on the server side, it is better to show a compound WSDL file contains all the available port services while the client sends the ?wsdl request for one single SEI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6252) Fix activemq plan for up to date blueprint jexl evaluator.
[ https://issues.apache.org/jira/browse/GERONIMO-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6252: -- Fix Version/s: (was: 3.0.1) 3.0.2 Fix activemq plan for up to date blueprint jexl evaluator. -- Key: GERONIMO-6252 URL: https://issues.apache.org/jira/browse/GERONIMO-6252 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 3.0.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0.2 Rex says we need to change the ext namespace and add the evaluator=jexl attribute to get the arithmatic evaluations to work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6290) Add explicit import-packages for some module builders
[ https://issues.apache.org/jira/browse/GERONIMO-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6290: -- Fix Version/s: (was: 3.0.1) 3.0.2 Add explicit import-packages for some module builders - Key: GERONIMO-6290 URL: https://issues.apache.org/jira/browse/GERONIMO-6290 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 3.0-beta-1 Reporter: Ivan Assignee: Ivan Fix For: 3.0-beta-2, 3.0.2 Sometimes, while users include some spec API classes in their applications, it will cause some CCE. Considering that, it is always required to use those api classes from server runtime if the application will take advantage of those features from server, it is better to add those packages explicitly in the defaultEnvironment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6247) Put the stax and jaxb api bundles in endorsed and figure out what the karaf-activator idea is so they can work.
[ https://issues.apache.org/jira/browse/GERONIMO-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6247: -- Fix Version/s: (was: 3.0.1) 3.0.2 Put the stax and jaxb api bundles in endorsed and figure out what the karaf-activator idea is so they can work. --- Key: GERONIMO-6247 URL: https://issues.apache.org/jira/browse/GERONIMO-6247 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 3.0.0 Reporter: David Jencks Fix For: 3.0.2 javax.xml.transform (?) seems to need access to either stax or jaxb and we have no good way to deploy xalan as a bundle, so it looks like we need to use the endorsed directory for these spec jars. Guillaume has started working on a karaf-activator concept that I think is supposed to provide a way for karaf startup to call an activator in these jars so they can be hooked up to something like our osgi registry and find the bundle based implementation. Some discussion is here: http://mail-archives.apache.org/mod_mbox/servicemix-dev/20.mbox/%3CCAEQV%2BEH5ca0R6sJvCXEeiLGdTZa6v1H%3DPwLFQ6BdLp27BdwgRw%40mail.gmail.com%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6426) Could not use Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster/ to enable Cluster feature
[
https://issues.apache.org/jira/browse/GERONIMO-6426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Forrest Xia updated GERONIMO-6426:
--
Fix Version/s: (was: 3.0.1)
3.0.2
Could not use Cluster
className=org.apache.catalina.ha.tcp.SimpleTcpCluster/ to enable Cluster
feature
--
Key: GERONIMO-6426
URL: https://issues.apache.org/jira/browse/GERONIMO-6426
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Reporter: xiezhi
Fix For: 3.0-M1, 3.0.0, 3.0.2
I have found uncomment the cluster fragment in server.xml below is OK.
Cluster
className=org.apache.catalina.ha.tcp.SimpleTcpCluster
channelSendOptions=8
Manager
className=org.apache.catalina.ha.session.DeltaManager
expireSessionsOnShutdown=false notifyListenersOnReplication=true
name=${ClusterName} channelSendOptions=6 mapSendOptions=6/
Channel
className=org.apache.catalina.tribes.group.GroupChannel
Membership
className=org.apache.catalina.tribes.membership.McastService
address=228.0.0.4 port=45564 frequency=500 dropTime=3000 /
Receiver
className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=auto port=4000 autoBind=100 selectorTimeout=5000
maxThreads=6 /
Sender
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
Transport
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender /
/Sender
Interceptor
className=org.apache.geronimo.tomcat.interceptor.DisableMcastInterceptor /
Interceptor
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
interval=60/
Interceptor
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member port=5002 securePort=-1
host=${ServerHostname} domain=test-domain
UniqueId={1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0} /
/Interceptor
Interceptor
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor
/
Interceptor
className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor
/
/Channel
Valve
className=org.apache.catalina.ha.tcp.ReplicationValve
filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt; /
Valve
className=org.apache.catalina.ha.session.JvmRouteBinderValve /
ClusterListener
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener /
ClusterListener
className=org.apache.catalina.ha.session.ClusterSessionListener /
/Cluster
But if I add a
Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster/ into
server.xml, the server start failure.
2012-12-20 13:53:47,677 INFO [geronimo-osgi-registry] SPI-Provider Manifest
header found in bundle: org.apache.geronimo.modules.geronimo-webservices
2012-12-20 13:53:47,892 INFO [AprLifecycleListener] The APR based Apache
Tomcat Native library which allows optimal performance in production
environments was not found on the java.library.path:
E:\jdks\IBM\Java60\jre\bin\default;E:\jdks\IBM\Java60\jre\bin;C:\windows\system32;C:\windows;.;E:\jdks\IBM\Java60\\bin;E:\jdks\IBM\Java60\\jre\bin;E:\mavens\apache-maven-2.2.1\bin;E:\Ant\apache-ant-1.7.1/bin;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files\IBM\Infoprint Select;C:\Program Files\ThinkPad\Bluetooth
Software\;C:\Program Files\ThinkPad\Bluetooth Software\syswow64;C:\Program
Files\Intel\WiFi\bin\;C:\Program Files\Common
Files\Intel\WirelessCommon\;C:\Program Files (x86)\Lenovo\Access
Connections\;C:\Program Files (x86)\IBM\Personal Communications\;C:\Program
Files (x86)\IBM\Trace Facility\;C:\Program Files (x86)\ooRexx;C:\Program
Files\TortoiseSVN\bin;C:\Program Files\TortoiseGit\bin;C:\Program Files
(x86)\Git\cmd;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common
Files\Intel\WirelessCommon\;C:\Program Files (x86)\SSH Communications
Security\SSH Secure
Shell;C:\AppServ\Apache2\bin;C:\AppServ\php;C:\AppServ\MySQL\bin;C:\Program
Files (x86)\IDM Computer Solutions\UltraEdit\;C:\Program Files (x86)\IDM
Computer Solutions\UltraCompare\;.
2012-12-20 13:53:47,948 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
[jira] [Updated] (GERONIMO-6391) plugin repository für geronimo 3.0 requires JVM 1.6, 1.5. but JVM 1.7 is used
[ https://issues.apache.org/jira/browse/GERONIMO-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6391: -- Fix Version/s: (was: 3.0.1) 3.0.2 plugin repository für geronimo 3.0 requires JVM 1.6, 1.5. but JVM 1.7 is used - Key: GERONIMO-6391 URL: https://issues.apache.org/jira/browse/GERONIMO-6391 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0.0 Environment: Windows 7, java version 1.7.0_07 Java(TM) SE Runtime Environment (build 1.7.0_07-b10) Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)geronimo-tomcat7-javaee6-3.0.0 Reporter: fpientka Priority: Trivial Fix For: 3.0.2 Hello when I try to download the plugins from the repository http://geronimo.apache.org/plugins/geronimo-3.0.0/ http://geronimo.apache.org/plugins/samples-3.0.0/ http://geronimo.apache.org/plugins/daytrader-3.0.0/ I can't select any because jvm-version1.6/jvm-version is marked in geronimo-plugins.xml, but the server is running with JRE 1.7 and I can't run it with 1.6 The only ERROR i found was ERROR [PluginInstallerGBean] Unable to install plugin org.apache.geronimo.kernel.repository.MissingDependencyException: Plugin is not installable on JVM 1.7.0_07 Missing dependency: org.apache.geronimo.configs/transaction-1_6/3.0.0/car Can anyone fix this? Thank you Frank add jvm-version1.7/jvm-version JVM 1.7 in all geronimo-plugins.xml for G 3.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6467) Make 3.0.1 release
[ https://issues.apache.org/jira/browse/GERONIMO-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6467: -- Fix Version/s: (was: 3.0.1) 3.0.2 Make 3.0.1 release -- Key: GERONIMO-6467 URL: https://issues.apache.org/jira/browse/GERONIMO-6467 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 3.0.1 Reporter: Forrest Xia Assignee: Forrest Xia Labels: release Fix For: 3.0.2 3.0.1 is in a good shape to be released 1. Clean up JIRA system to figure out fixed bugs/tasks/improvments, then update release notes file 2. Add a new version for next release, e.g. 3.0.2 3. Make a release tag and open a vote in the dev mailing list 4. Add Geronimo plugin list for 3.0.1 release 5. Add release artifacts to https://dist.apache.org/repos/dist/release/geronimo/ 6. Update download page in geronimo.apache.org, and add a news about it 7. Send announcement emails to mailing list -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6352) session configuration info is not serialized correctly
[ https://issues.apache.org/jira/browse/GERONIMO-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6352: -- Fix Version/s: (was: 3.0.1) 3.0.2 session configuration info is not serialized correctly -- Key: GERONIMO-6352 URL: https://issues.apache.org/jira/browse/GERONIMO-6352 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 3.0-beta-1 Reporter: Ivan Assignee: Ivan Fix For: 3.0-beta-2, 3.0.2 While creating the WebAppInfo, those information from session config in the web.xml is not serialized correctly, so those configurations will never take effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-4921) Figure out how to handle OSGI cache in Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-4921: -- Fix Version/s: (was: 3.0.1) 3.0.2 Figure out how to handle OSGI cache in Geronimo --- Key: GERONIMO-4921 URL: https://issues.apache.org/jira/browse/GERONIMO-4921 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: osgi Affects Versions: 3.0.0 Reporter: Ivan Fix For: 3.0.2 Some install/uninstall action should be done via OSGI API or Karaf functions more easily. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5554) blueprint deadlock during server start
[ https://issues.apache.org/jira/browse/GERONIMO-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5554: -- Fix Version/s: (was: 3.0.1) 3.0.2 blueprint deadlock during server start -- Key: GERONIMO-5554 URL: https://issues.apache.org/jira/browse/GERONIMO-5554 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Aries Affects Versions: 3.0.0 Reporter: Kevan Miller Fix For: 3.0.2 I stumbled upon a deadlock during server startup. Only seen it once. Was running 'JAVA_OPTS=-verbosegc ./geronimo run --long', but doubt that makes a significant difference. Setting JAVA_OPTS would mean we're running with Java heap/permgen defaults, not the Geronimo defaults. Looked like we were loading rmi-naming. Here's the last console output: Module 2/34 org.apache.geronimo.framework/rmi-naming/3.0-SNAPSHOT/car [GC 49143K-34248K(83008K), 0.0153521 secs] [GC 34257K(83008K), 0.0029171 secs] [GC 34267K(83008K), 0.0015866 secs] Here are the thread dumps from SIGQUIT: Full thread dump Java HotSpot(TM) 64-Bit Server VM (16.3-b01-279 mixed mode): Blueprint Event Dispatcher: 1 daemon prio=5 tid=11ce57800 nid=0x119b19000 waiting on condition [119b18000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 1080c97f8 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:637) JMX OSGi Agent daemon prio=5 tid=101e6 nid=0x11996c000 waiting on condition [11996b000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 1078b00a8 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:637) Timer-2 daemon prio=5 tid=11b82b000 nid=0x117a14000 in Object.wait() [117a13000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 108fcf068 (a java.util.TaskQueue) at java.lang.Object.wait(Object.java:485) at java.util.TimerThread.mainLoop(Timer.java:483) - locked 108fcf068 (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:462) gogo shell pipe thread daemon prio=5 tid=102aca800 nid=0x11961a000 runnable [119619000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:199) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:237) - locked 107e652e0 (a java.io.BufferedInputStream) at jline.Terminal.readCharacter(Terminal.java:99) at org.apache.felix.karaf.shell.console.jline.Console$Pipe.run(Console.java:386) at java.lang.Thread.run(Thread.java:637) Karaf Shell Console Thread daemon prio=5 tid=11ca14800 nid=0x118f55000 waiting on condition [118f54000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 108b6ac38 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) at java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:317) at org.apache.felix.karaf.shell.console.jline.Console$ConsoleInputStream.read(Console.java:324) at org.apache.felix.karaf.shell.console.jline.Console$ConsoleInputStream.read(Console.java:341) at jline.Terminal.readCharacter(Terminal.java:99)
[jira] [Updated] (GERONIMO-5229) PropertyEditors is too willing to pull in editors we don'e necessarly want
[ https://issues.apache.org/jira/browse/GERONIMO-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5229: -- Fix Version/s: (was: 3.0.1) 3.0.2 PropertyEditors is too willing to pull in editors we don'e necessarly want -- Key: GERONIMO-5229 URL: https://issues.apache.org/jira/browse/GERONIMO-5229 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: common Affects Versions: 3.0.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0.2 AMQ just added a StringArrayEditor that uses spring classes so we can't load it. For some reason this is getting pulled in when loading j2ee-deployer. There's something wrong with the visibility rules in PropertyEditors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6117) OpenWebBeansPlugin load optimization
[ https://issues.apache.org/jira/browse/GERONIMO-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6117: -- Fix Version/s: (was: 3.0.1) 3.0.2 OpenWebBeansPlugin load optimization Key: GERONIMO-6117 URL: https://issues.apache.org/jira/browse/GERONIMO-6117 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: OpenEJB, OpenWebBeans Reporter: David Blevins Assignee: David Blevins Fix For: 3.0.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-4908) RMIClassLoader is not compatible with osgi
[ https://issues.apache.org/jira/browse/GERONIMO-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-4908: -- Fix Version/s: (was: 3.0.1) 3.0.2 RMIClassLoader is not compatible with osgi -- Key: GERONIMO-4908 URL: https://issues.apache.org/jira/browse/GERONIMO-4908 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: osgi Affects Versions: 3.0.0 Reporter: David Jencks Fix For: 3.0.2 We have RMIClassLoaderSpiImpl in geronimo-kernel. However, RMIClassLoader loads the spi impl using the system classloader. (http://java.sun.com/javase/6/docs/api/java/rmi/server/RMIClassLoader.html) So we'd have to get our impl into the system classloader unless osgi provides an additional level of delegation in the system classloader. For now I'm going to try not setting java.rmi.server.RMIClassLoaderSpi in RMIRegistryService -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5170) Register connection factories in osgi service registry
[ https://issues.apache.org/jira/browse/GERONIMO-5170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5170: -- Fix Version/s: (was: 3.0.1) 3.0.2 Register connection factories in osgi service registry -- Key: GERONIMO-5170 URL: https://issues.apache.org/jira/browse/GERONIMO-5170 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: connector, osgi, persistence Affects Versions: 3.0.0 Reporter: David Jencks Assignee: Jarek Gawor Fix For: 3.0.2 The aries jpa implementation tries to look up jta-datasource and non-jta-datasource in jndi using the osgi jndi service scheme. If we stuff all our connectio n factories in the service registry this ought to work. We can consider using this for ee jpa too, but this would be a significant change in behavior in terms of visibility. The osgi service registry is global whereas the current lookup is confined to the DAG of ancestors of the jpa module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5086) Apache Aries enhancements
[ https://issues.apache.org/jira/browse/GERONIMO-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5086: -- Fix Version/s: (was: 3.0.1) 3.0.2 Apache Aries enhancements - Key: GERONIMO-5086 URL: https://issues.apache.org/jira/browse/GERONIMO-5086 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Aries, osgi Affects Versions: 3.0.0 Reporter: Rick McGuire Fix For: 3.0.2 Support for hosting Apache Aries applications on Geronimo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5813) add name-value configuration entry for the deployment scope
[ https://issues.apache.org/jira/browse/GERONIMO-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5813: -- Fix Version/s: (was: 3.0.1) 3.0.2 add name-value configuration entry for the deployment scope --- Key: GERONIMO-5813 URL: https://issues.apache.org/jira/browse/GERONIMO-5813 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 3.0-beta-1 Reporter: Ivan Assignee: Ivan Fix For: 3.0-beta-2, 3.0.2 Attachments: Property-preview.patch Please refer to the discussion from dev mail list http://apache-geronimo.328035.n3.nabble.com/Add-name-value-configuration-entry-for-the-deployment-scope-td2485710.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5681) Figure out how urlContextFactory works in Geronimo 3.0
[ https://issues.apache.org/jira/browse/GERONIMO-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5681: -- Fix Version/s: (was: 3.0.1) 3.0.2 Figure out how urlContextFactory works in Geronimo 3.0 -- Key: GERONIMO-5681 URL: https://issues.apache.org/jira/browse/GERONIMO-5681 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: naming Affects Versions: 3.0.0 Reporter: Ivan Fix For: 3.0.2 http://apache-geronimo.328035.n3.nabble.com/Wrap-the-rmiConenctionFactory-and-enable-multiple-remoteDeploymentFactory-in-the-same-vm-with-the-see-td1860729.html#a1860729 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5752) Updates needed to TemporaryClassLoader?
[ https://issues.apache.org/jira/browse/GERONIMO-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5752: -- Fix Version/s: (was: 3.0.1) 3.0.2 Updates needed to TemporaryClassLoader? --- Key: GERONIMO-5752 URL: https://issues.apache.org/jira/browse/GERONIMO-5752 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0.0 Reporter: Kevan Miller Assignee: Forrest Xia Fix For: 3.0.2 OpenJPA's TemporaryClassLoader has had several updates, which are not included in our copy of TemporaryClassLoader. It's likely that the same issues which motivated the OpenJPA issues would cause problems in Geronimo, also. We probably want to merge the changes into Geronimo. See https://issues.apache.org/jira/browse/OPENJPA-646 and https://issues.apache.org/jira/browse/OPENJPA-1121 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6114) Avoid ServiceLoader lookup during OpenWebBeansInitializer
[ https://issues.apache.org/jira/browse/GERONIMO-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6114: -- Fix Version/s: (was: 3.0.1) 3.0.2 Avoid ServiceLoader lookup during OpenWebBeansInitializer - Key: GERONIMO-6114 URL: https://issues.apache.org/jira/browse/GERONIMO-6114 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Affects Versions: 3.0.0 Reporter: Kevan Miller Fix For: 3.0.2 Attachments: getWiredBundle.png OpenWebBeans initialization can represent a major portion of a Geronimo server's startup time. I've seen it take nearly 1/4 of a server's startup time. Nearly all of this time is caused because OpenWebBeans is using ServiceLoader.load(). A search of wired bundles shouldn't be necessary (and we should avoid, if possible). We should be able to replace OpenWebBeans DefaultImplementationLoaderService with our own LoaderService implementation. This LoaderService implementation could in turn avoid the use of XBean's BundleClassLoader (BundleClassLoader.getResource() is what drives the getWiredBundle() processing). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5046) Remove need for system property geronimo.build.cartrue/geronimo.build.car to get car-maven-plugin to work
[ https://issues.apache.org/jira/browse/GERONIMO-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5046: -- Fix Version/s: (was: 3.0.1) 3.0.2 Remove need for system property geronimo.build.cartrue/geronimo.build.car to get car-maven-plugin to work - Key: GERONIMO-5046 URL: https://issues.apache.org/jira/browse/GERONIMO-5046 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem, osgi Affects Versions: 3.0.0 Reporter: David Jencks Fix For: 3.0.2 Right now you need geronimo.build.cartrue/geronimo.build.car configured as a system property in car-maven-plugin configuration to get packaging to work. we should figure out how to use mvn urls everywhere or otherwise eliminate this property. Using mvn urls would probably just mean installing the pax mvn url bundle in the framework as soon as we start it. -or- Probably the car-maven-plugin can just set the system property directly. if the property's missing, the build fails complaining it can't understand mvn urls. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6116) differentiate the two OpenEJB ORB Adapter displayed in Linstening on Ports after server startup.
[
https://issues.apache.org/jira/browse/GERONIMO-6116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Forrest Xia updated GERONIMO-6116:
--
Fix Version/s: (was: 3.0.1)
3.0.2
differentiate the two OpenEJB ORB Adapter displayed in Linstening on
Ports after server startup.
--
Key: GERONIMO-6116
URL: https://issues.apache.org/jira/browse/GERONIMO-6116
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: CORBA, general
Affects Versions: 2.1.8, 2.2.2, 3.0.0
Reporter: Shawn Jiang
Assignee: Han Hong Fang
Fix For: 3.0.2
Listening on Ports:
1050 0.0.0.0 CORBA Naming Service
1099 0.0.0.0 RMI Naming
1527 0.0.0.0 Derby Connector
2001 0.0.0.0 OpenEJB ORB Adapter
4201 0.0.0.0 OpenEJB Daemon
6882 0.0.0.0 OpenEJB ORB Adapter
8009 0.0.0.0 Tomcat Connector AJP TomcatAJPConnector
8080 0.0.0.0 Tomcat Connector HTTP BIO TomcatWebConnector
8443 0.0.0.0 Tomcat Connector HTTPS BIO TomcatWebSSLConnector
0.0.0.0 JMX Remoting Connector
61616 0.0.0.0 ActiveMQ Transport Connector
2001 is normal ORB server while 6882 is secure ORB server, we should
differentiate them in the desciption.
The gbean of orb server is : org.apache.geronimo.corba.CORBAEjbBeanGBean
the plan to defined the 2 server is:
plugins\corba\j2ee-corba-yoko\src\main\plan\plan.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-4956) Tomcat should use Keystore GBean for access to Geronimo keystore
[ https://issues.apache.org/jira/browse/GERONIMO-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-4956: -- Fix Version/s: (was: 3.0.1) 3.0.2 Tomcat should use Keystore GBean for access to Geronimo keystore Key: GERONIMO-4956 URL: https://issues.apache.org/jira/browse/GERONIMO-4956 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.2, 2.2.1, 2.2.2 Reporter: Kevan Miller Fix For: 2.2.2, 3.0.2 Currently, Tomcat is configured to directly access the Geronimo keystore (and thus requires the keystorePass password. Better that it should be configured to use the keystore gbean. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5564) No wait-for-server command in trunk
[ https://issues.apache.org/jira/browse/GERONIMO-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5564: -- Fix Version/s: (was: 3.0.1) 3.0.2 No wait-for-server command in trunk --- Key: GERONIMO-5564 URL: https://issues.apache.org/jira/browse/GERONIMO-5564 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0.0 Reporter: Kevan Miller Fix For: 3.0.2 wait-for-server was a helpful command in 2.1/2.2, but is not available in current commands -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5703) Track:Clustering module fails to start on disabling JMXService gbean
[ https://issues.apache.org/jira/browse/GERONIMO-5703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5703: -- Fix Version/s: (was: 3.0.1) 3.0.2 Track:Clustering module fails to start on disabling JMXService gbean Key: GERONIMO-5703 URL: https://issues.apache.org/jira/browse/GERONIMO-5703 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Ashish Jain Assignee: Ashish Jain Fix For: 2.2.2, 3.0.2 Track for GERONIMO-5690 for 2.2 and 3.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5097) Integrate CXF JAX-RS implementation into Geronimo.
[ https://issues.apache.org/jira/browse/GERONIMO-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5097: -- Fix Version/s: (was: 3.0.1) 3.0.2 Integrate CXF JAX-RS implementation into Geronimo. -- Key: GERONIMO-5097 URL: https://issues.apache.org/jira/browse/GERONIMO-5097 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, webservices Affects Versions: 3.0.0 Reporter: Daniel Kulp Fix For: 3.0.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5743) ServletContext.getRealPath() returns null
[ https://issues.apache.org/jira/browse/GERONIMO-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5743: -- Fix Version/s: (was: 3.0.1) 3.0.2 ServletContext.getRealPath() returns null - Key: GERONIMO-5743 URL: https://issues.apache.org/jira/browse/GERONIMO-5743 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 3.0-M1 Reporter: Jarek Gawor Assignee: Ivan Fix For: 3.0.2 In 3.0 M1 and trunk, ServletContext.getRealPath() returns null. In previous versions of Geronimo a real path was returned. Returning null is ok from specification point of view but it breaks compatibility for applications. It also looks like there are a number of web applications that rely on the getRealPath() to return a non-null value. One such application is Nexus web app. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5565) geronimo.out can grow unbounded
[ https://issues.apache.org/jira/browse/GERONIMO-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5565: -- Fix Version/s: (was: 3.0.1) 3.0.2 geronimo.out can grow unbounded --- Key: GERONIMO-5565 URL: https://issues.apache.org/jira/browse/GERONIMO-5565 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands, Logging Affects Versions: 2.1.6, 2.2, 3.0.0 Reporter: Kevan Miller Fix For: 3.0.2 By default, Geronimo will log WARN (and above) messages to STDOUT. When you start Geronimo in the background, this means that any WARN, ERROR, etc messages will be sent to the file geronimo.out. There is no guard for this file. So, it will grow unbounded. Unlike log files, which are configured with a maximum size. We need procedures and mechanisms to prevent the geronimo.out file from growing too large. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5259) Annoying access denied security exceptions for oenwebbeans while java2 security is enabled.
[ https://issues.apache.org/jira/browse/GERONIMO-5259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5259: -- Fix Version/s: (was: 3.0.1) 3.0.2 Annoying access denied security exceptions for oenwebbeans while java2 security is enabled. - Key: GERONIMO-5259 URL: https://issues.apache.org/jira/browse/GERONIMO-5259 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 3.0.0 Reporter: YING WANG Assignee: Donald Woods Priority: Minor Labels: jcdi Fix For: 3.0.2 Attachments: 5259.patch, AnnotationLiteral.java, AnnotationLiteral.path2 Hello neighbors, I am from the openwebbean project. while I am fixing owb-312 (https://issues.apache.org/jira/browse/OWB-312), I found some of AccessControlExceptions are fired fom javax.enterprise.util.AnnotationLiteral in jcdi api. Fixing the issue in OWB will be nasty since it is referenced all over the owb code. Could we add doPrivileged block around Class.setAccess() and getDeclaredMethods calls in this class? Thanks in advnace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-4974) ee apps or other plugins can't contain gbeans
[ https://issues.apache.org/jira/browse/GERONIMO-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-4974: -- Fix Version/s: (was: 3.0.1) 3.0.2 ee apps or other plugins can't contain gbeans - Key: GERONIMO-4974 URL: https://issues.apache.org/jira/browse/GERONIMO-4974 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: deployment, osgi Affects Versions: 3.0.0 Reporter: David Jencks Fix For: 3.0.2 right now the deployer adds packages it can detect as used in a gbean to the Import-Packages. However it never populares Export-Package. This causes problems if the class is actually in the plugin/bundle we are constructing. If a bundle contains a class, if it lists the package in Import-Package, it won't satisfy the constraint itself unless the package is also listed in Export-Package. So, we need to make the deployer list all the packages contained in the bundle in Export-Package. This might be a challenge in case there are embedded jars and a complicated Bundle-Classpath. For now the workaround appears to be to move any classes used in gbeans to another bundle rather than packing them in a javaee app. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5343) Replace config-substitutions.properties by use of config admin
[ https://issues.apache.org/jira/browse/GERONIMO-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5343: -- Fix Version/s: (was: 3.0.1) 3.0.2 Replace config-substitutions.properties by use of config admin -- Key: GERONIMO-5343 URL: https://issues.apache.org/jira/browse/GERONIMO-5343 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: core Affects Versions: 3.0.0 Reporter: David Jencks Fix For: 3.0.2 OSGI has a fairly sophisticated customization system, config admin. We should look into replacing our homegrown config-substitutions stuff with this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5344) Hook env-entries and servlet init-params up to config admin
[ https://issues.apache.org/jira/browse/GERONIMO-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5344: -- Fix Version/s: (was: 3.0.1) 3.0.2 Hook env-entries and servlet init-params up to config admin --- Key: GERONIMO-5344 URL: https://issues.apache.org/jira/browse/GERONIMO-5344 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming, web Affects Versions: 3.0.0 Reporter: David Jencks Fix For: 3.0.2 Since the osgi approved parameter customization facility is config admin and we're supposed to let people change at least env-entries we ought to use config admin for customizing these values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5187) Isolation for Apache Aries applications
[ https://issues.apache.org/jira/browse/GERONIMO-5187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5187: -- Fix Version/s: (was: 3.0.1) 3.0.2 Isolation for Apache Aries applications --- Key: GERONIMO-5187 URL: https://issues.apache.org/jira/browse/GERONIMO-5187 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: Aries, osgi Affects Versions: 3.0.0 Reporter: Jarek Gawor Fix For: 3.0.2 Equinox framework provides support for composite bundles / nested frameworks which we can use to isolate Aries applications. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5414) Remove references to corba in connector deployer
[ https://issues.apache.org/jira/browse/GERONIMO-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5414: -- Fix Version/s: (was: 3.0.1) 3.0.2 Remove references to corba in connector deployer Key: GERONIMO-5414 URL: https://issues.apache.org/jira/browse/GERONIMO-5414 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0.0 Reporter: Kevan Miller Fix For: 3.0.2 Connector-deployer shouldn't require Yoko. Here's the connector-deployer module section from config.xml for a minimal server: module name=org.apache.geronimo.configs/connector-deployer-1_6/3.0-SNAPSHOT/car gbean name=ResourceRefBuilder attribute name=eeNamespaceshttp://java.sun.com/xml/ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute attribute name=corbaEnvironment propertyEditor=org.apache.geronimo.deployment.service.EnvironmentBuilder environment:environment xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:environment=http://geronimo.apache\ .org/xml/ns/deployment-1.2 dependencies dependency groupIdorg.apache.geronimo.configs/groupId artifactIdj2ee-corba-yoko/artifactId version3.0-SNAPSHOT/version typecar/type /dependency /dependencies /environment:environment /attribute /gbean gbean name=AdminObjectRefBuilder attribute name=eeNamespaceshttp://java.sun.com/xml/ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute /gbean gbean name=ClientResourceRefBuilder attribute name=eeNamespaceshttp://java.sun.com/xml/ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute attribute name=corbaEnvironment propertyEditor=org.apache.geronimo.deployment.service.EnvironmentBuilder environment:environment xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:environment=http://geronimo.apache\ .org/xml/ns/deployment-1.2 dependencies dependency groupIdorg.apache.geronimo.configs/groupId artifactIdclient-corba-yoko/artifactId version3.0-SNAPSHOT/version typecar/type /dependency /dependencies /environment:environment /attribute /gbean /module -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5675) Add role based navigation customization support.
[
https://issues.apache.org/jira/browse/GERONIMO-5675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Forrest Xia updated GERONIMO-5675:
--
Fix Version/s: (was: 3.0.1)
3.0.2
Add role based navigation customization support.
Key: GERONIMO-5675
URL: https://issues.apache.org/jira/browse/GERONIMO-5675
Project: Geronimo
Issue Type: New Feature
Security Level: public(Regular issues)
Components: console
Reporter: Shawn Jiang
Assignee: Shenghao Fang
Fix For: 2.2.2, 3.0.2
the target is that a geronimo user could define role based navigation tree
easily without building geronimo from source code.
User could define an external file with something like this:
{noformat}
role name: role 1
navigation access pages:
0/Welcome,
1-1-1/Application Server/System Information/Server Information,
1-1-2/Application Server/System Information/Java System Info,
1-1-4/Application Server/System Information/Thread Pools,
1-8/Server/Monitoring
role name: role 2
navigation access pages:
0/Welcome,
1-1-1/Application Server/System Information/Server Information,
1-1-2/Application Server/System Information/Java System Info,
1-1-4/Application Server/System Information/Thread Pools,
1-8/Server/Monitoring
{noformat}
The role names must have been defined as group name in current realm. Then,
we could read this file into class[1] and filter the navigation tree
according to current user's roles.
As for the pages that are not in navigation tree, we should use a servlet
filter with the same role/access page mapping to block the address bar direct
access.
[1]https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/console/console-portal-driver/src/main/java/org/apache/geronimo/console/navigation/NavigationJsonGenerator.java
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5644) Share global annotation finder among different components
[ https://issues.apache.org/jira/browse/GERONIMO-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5644: -- Fix Version/s: (was: 3.0.1) 3.0.2 Share global annotation finder among different components - Key: GERONIMO-5644 URL: https://issues.apache.org/jira/browse/GERONIMO-5644 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 3.0.0 Reporter: Ivan Assignee: viola.lu Fix For: 3.0.2 Remember that I mentioned it in the past, while working at JSF integration, I found that the global annoation scanning is required, too. I am thinking that we could create a BundleAnnotationFinder for each application, for web application, servlet, jsf, jaxws, webbeans and jax-rs should be able to share the same finder, for ejb application, ejb and webbeans should be able to share the same finder. But there might be problems for the scan scope, as different components might require different scanning scope. Anothing solution is that we might provide some callback methods for interesting annotation, like equal scenario ( Most scanning requiremetns are in this scenrio), and extend scenario ( guess that webbeans ??? ) Any comment ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5655) switch to tomcat standard taglibs
[ https://issues.apache.org/jira/browse/GERONIMO-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5655: -- Fix Version/s: (was: 3.0.1) 3.0.2 switch to tomcat standard taglibs - Key: GERONIMO-5655 URL: https://issues.apache.org/jira/browse/GERONIMO-5655 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: dependencies Affects Versions: 3.0.0 Reporter: Rex Wang Assignee: Rex Wang Fix For: 3.0.2 1. push tomcat community to release their jstl implementation 2. persuade tomcat community to bundle-ify their jstl implementation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6122) Support Stateless and Singleton EJB as JAX-RS root resource classes, providers and Application subclasses
[ https://issues.apache.org/jira/browse/GERONIMO-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6122: -- Fix Version/s: (was: 3.0.1) 3.0.2 Support Stateless and Singleton EJB as JAX-RS root resource classes, providers and Application subclasses - Key: GERONIMO-6122 URL: https://issues.apache.org/jira/browse/GERONIMO-6122 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: javaee6 Affects Versions: 3.0.0 Reporter: viola.lu Assignee: Ivan Priority: Minor Fix For: 3.0.2 From JAX-RS spec 1.1 In a product that also supports EJB, an implementation MUST support use of stateless and singleton session beans as root resource classes, providers and Application subclasses. JAX-RS annotations MAY be applied to a bean's local interface or directly to a no-interface bean. If an Exception- Mapper for a EJBException or subclass is not included with an application then exceptions thrown by an EJB resource class or provider method MUST be treated as EJB application exceptions: the embedded cause of the EJBException MUST be unwrapped and processed as described in section 3.3.4. Now geronimo recognize javax.ws.rs.URIinfo as EJB resource in a stateless EJB, so failed to get Uriinfo Run Restfulorder samples can give more details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6087) See if we can improve Main not found errors (and other startup issues)
[
https://issues.apache.org/jira/browse/GERONIMO-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Forrest Xia updated GERONIMO-6087:
--
Fix Version/s: (was: 3.0.1)
3.0.2
See if we can improve Main not found errors (and other startup issues)
Key: GERONIMO-6087
URL: https://issues.apache.org/jira/browse/GERONIMO-6087
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Reporter: Kevan Miller
Fix For: 3.0.2
In some cases a startup error will prevent the server from starting. Yet the
only message the user sees is Main not found (or no message at all).
I've seen this happen when trying to profile the server using YourKit. You
must add com.yourkit to org.osgi.framework.bootdelegation in
etc/config.properties in order for the server to start. If you don't the only
error you see is Main not found
Someone also reported that a non-writable java.io.tmpdir directory can lead
to a Main not found error. For me, on Mac OS, looks like my server startup
spins in a hot loop:
{quote}
main prio=5 tid=102801800 nid=0x100501000 runnable [1004ff000]
java.lang.Thread.State: RUNNABLE
at java.io.UnixFileSystem.canonicalize0(Native Method)
at java.io.UnixFileSystem.canonicalize(UnixFileSystem.java:157)
at java.io.File.getCanonicalPath(File.java:559)
at java.io.File.getCanonicalFile(File.java:583)
at java.io.File.mkdirs(File.java:1189)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.prepareTempDir(DirectoryWatcher.java:548)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.init(DirectoryWatcher.java:137)
at
org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:222)
at
org.apache.felix.fileinstall.internal.FileInstall.start(FileInstall.java:124)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389)
at
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1130)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
- locked 7ea24ea68 (a java.lang.Object)
at
org.eclipse.osgi.framework.internal.core.EquinoxLauncher.internalStart(EquinoxLauncher.java:271)
at
org.eclipse.osgi.framework.internal.core.EquinoxLauncher.start(EquinoxLauncher.java:241)
at org.eclipse.osgi.launch.Equinox.start(Equinox.java:258)
at
org.apache.geronimo.main.FrameworkLauncher.launch(FrameworkLauncher.java:179)
at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:47)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:32)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6089) Support for CDI beans in ear lib directory
[ https://issues.apache.org/jira/browse/GERONIMO-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6089: -- Fix Version/s: (was: 3.0.1) 3.0.2 Support for CDI beans in ear lib directory -- Key: GERONIMO-6089 URL: https://issues.apache.org/jira/browse/GERONIMO-6089 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Reporter: David Blevins Assignee: David Blevins Fix For: 3.0.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6246) remove package versions from most spec jars until there's an osgi recommendation on what they should be.
[ https://issues.apache.org/jira/browse/GERONIMO-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6246: -- Fix Version/s: (was: 3.0.1) 3.0.2 remove package versions from most spec jars until there's an osgi recommendation on what they should be. Key: GERONIMO-6246 URL: https://issues.apache.org/jira/browse/GERONIMO-6246 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 3.0.0 Reporter: David Jencks Fix For: 3.0.2 except maybe for servlet, there aren't any osgi recommendations for package versions of spec api packages. We will just cause incompatibility and confusion if we decide on our own what the versions should be. This has already happened with our use of 3.0 for the servlet 3.0 package versions, whereas everyone seems to agree it should be 2.6 (and this should be checked maybe some packages haven't changed from 2.5). This will require recompiling all bundles that have been compiled against our specs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5087) Use OSGi for the Geronimo classloading model.
[ https://issues.apache.org/jira/browse/GERONIMO-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5087: -- Fix Version/s: (was: 3.0.1) 3.0.2 Use OSGi for the Geronimo classloading model. -- Key: GERONIMO-5087 URL: https://issues.apache.org/jira/browse/GERONIMO-5087 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: osgi Affects Versions: 3.0.0 Reporter: Rick McGuire Fix For: 3.0.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5016) Enable cxf in Geronimo 3.0
[ https://issues.apache.org/jira/browse/GERONIMO-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5016: -- Fix Version/s: (was: 3.0.1) 3.0.2 Enable cxf in Geronimo 3.0 -- Key: GERONIMO-5016 URL: https://issues.apache.org/jira/browse/GERONIMO-5016 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, webservices Affects Versions: 3.0.0 Environment: Enable cxf in Geronimo 3.0 Reporter: Rex Wang Assignee: Rex Wang Fix For: 3.0.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5026) Class and resource discovery in OSGi
[ https://issues.apache.org/jira/browse/GERONIMO-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-5026: -- Fix Version/s: (was: 3.0.1) 3.0.2 Class and resource discovery in OSGi Key: GERONIMO-5026 URL: https://issues.apache.org/jira/browse/GERONIMO-5026 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: osgi Affects Versions: 3.0.0 Reporter: Jarek Gawor Assignee: Jarek Gawor Fix For: 3.0.2 For servlets 3.0, EJBs, and web services we need a way to find all classes loadable by the bundle so that we can discover additional servlets, ejbs or web services dynamically (by checking annotations) that are not explicitly referenced in the given deployment descriptor. For resources, we might need a way to discover all resources with a given extension and prefix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-4913) Use pax mvn urls everywhere possible.
[ https://issues.apache.org/jira/browse/GERONIMO-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-4913: -- Fix Version/s: (was: 3.0.1) 3.0.2 Use pax mvn urls everywhere possible. - Key: GERONIMO-4913 URL: https://issues.apache.org/jira/browse/GERONIMO-4913 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: osgi Affects Versions: 3.0.0 Reporter: David Jencks Fix For: 3.0.2 While running the server, we use pax mvn urls for bundle locations, but not always while running tests and otherwise during the build. We should clean this up to use mvn urls except for temporary bundles in the DeploymentContext. The code that creates the non mvn: urls is in locateBundle methods in SimpleConfigurationManager and DeploymentManager. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6137) Support to deploy web applications with other JSF vendors
[ https://issues.apache.org/jira/browse/GERONIMO-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6137: -- Fix Version/s: (was: 3.0.1) 3.0.2 Support to deploy web applications with other JSF vendors - Key: GERONIMO-6137 URL: https://issues.apache.org/jira/browse/GERONIMO-6137 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: myfaces Affects Versions: 3.0-M1 Reporter: Ivan Assignee: Ivan Fix For: 3.0.2 Although Geronimo ships the MyFaces implementation, while still some users would like to use other JSF providers. In the past, users have to configure some classloading options and disable the myfaces deployer. The initial idea for it is to detect whether there is another jsf implementation in the web application by trying to load some vendor class, and once detect, skip the MyFaces builder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-4909) How should we shut down plugin under osgi?
[ https://issues.apache.org/jira/browse/GERONIMO-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-4909: -- Fix Version/s: (was: 3.0.1) 3.0.2 How should we shut down plugin under osgi? -- Key: GERONIMO-4909 URL: https://issues.apache.org/jira/browse/GERONIMO-4909 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: osgi Affects Versions: 3.0.0 Reporter: David Jencks Fix For: 3.0.2 ConfigurationActivator needs it's stop method to shut down the plugin. Calling configurationManager.unload(id) is symmetrical with start and should leave the configuration model in a consistent state, but resets the load attribute in config.xml to false, which prevents restarting the server. Just stopping and unloading the configuration gbean works fine but may leave the configuration model (in the configuration manager) in an inconsistent state. This needs further investigation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6043) module init order doesn't always work due to gbean dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-6043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6043: -- Fix Version/s: (was: 3.0.1) 3.0.2 module init order doesn't always work due to gbean dependencies --- Key: GERONIMO-6043 URL: https://issues.apache.org/jira/browse/GERONIMO-6043 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 3.0.0 Reporter: David Jencks Fix For: 3.0.2 The new start modules in listed order flag in ee 6 doesn't always work because some gbean dependencies conflict with it. The biggest is the owb initialization. We need to always use the openejb owb integration to make this manageable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6467) Make 3.0.1 release
[ https://issues.apache.org/jira/browse/GERONIMO-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated GERONIMO-6467: -- Fix Version/s: (was: 3.0.2) 3.0.1 Make 3.0.1 release -- Key: GERONIMO-6467 URL: https://issues.apache.org/jira/browse/GERONIMO-6467 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 3.0.1 Reporter: Forrest Xia Assignee: Forrest Xia Labels: release Fix For: 3.0.1 3.0.1 is in a good shape to be released 1. Clean up JIRA system to figure out fixed bugs/tasks/improvments, then update release notes file 2. Add a new version for next release, e.g. 3.0.2 3. Make a release tag and open a vote in the dev mailing list 4. Add Geronimo plugin list for 3.0.1 release 5. Add release artifacts to https://dist.apache.org/repos/dist/release/geronimo/ 6. Update download page in geronimo.apache.org, and add a news about it 7. Send announcement emails to mailing list -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6469) EJB annotations are not working in Geronimo 3.0
Nayela Manzoor created GERONIMO-6469: Summary: EJB annotations are not working in Geronimo 3.0 Key: GERONIMO-6469 URL: https://issues.apache.org/jira/browse/GERONIMO-6469 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Nayela Manzoor EJB annotations, for exampe, EJB, Stateless, aroundinvoke are not working in Geronimo 3.0. I have current application running well in Geronimo 2.0.1. I deployed it on Geronimo 3.0 and got many issues due to EJB annotation failures. I had to replace EJB annotations with descriptors in ejb-jar file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6469) EJB annotations are not working in Geronimo 3.0
[ https://issues.apache.org/jira/browse/GERONIMO-6469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13668003#comment-13668003 ] Ivan commented on GERONIMO-6469: You may want to provide the sample for reproducing this issue, or is there any output in the log ? With the current description, it is hard to know what happened. EJB annotations are not working in Geronimo 3.0 --- Key: GERONIMO-6469 URL: https://issues.apache.org/jira/browse/GERONIMO-6469 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Nayela Manzoor EJB annotations, for exampe, EJB, Stateless, aroundinvoke are not working in Geronimo 3.0. I have current application running well in Geronimo 2.0.1. I deployed it on Geronimo 3.0 and got many issues due to EJB annotation failures. I had to replace EJB annotations with descriptors in ejb-jar file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Is there a need to release GEP 3.0.1 for Geronimo 3.0.1?
I port changes on trunk back to eclipse-plugin 3.0 branch for 3.0.1 release, and let's use 3.0 branch for future GEP 3.0.x work. On Sat, May 25, 2013 at 2:31 AM, Jarek Gawor jga...@gmail.com wrote: I'm not entirely sure. Things just got mixed up I guess. I was actually thinking about moving sever/3.0 branch into trunk and moving existing server/trunk into some experimental branch. Jarek On Fri, May 24, 2013 at 11:48 AM, Forrest Xia forres...@gmail.com wrote: Just curious, Is there any reason made changes to trunk, but not 3.0 branches of GEP? I thought we should follow this convention: GEP trunk supports server trunk, GEP 3.0 branch supports server 3.0. branch. On Fri, May 24, 2013 at 11:28 PM, Jarek Gawor jga...@gmail.com wrote: I think you used a wrong branch to compare. The latest updates went into devtools/eclipse-plugin/trunk and not devtools/eclipse-plugin/branches/3.0. There was a definitely lots of changes since 3.0.0 so yes I would vote to release it. Jarek On Fri, May 24, 2013 at 2:01 AM, Forrest Xia forres...@gmail.com wrote: Hi all, I checked GEP 3.0 branch revision history, but not found any new code fixes after its 3.0.0 release back to July of 2012, so my question is, is there a need to make a new GEP release for 3.0.1 server? I did some simple testing, the current GEP 3.0.0 release works well with 3.0.1 server. -- Thanks! Regards, Forrest -- Thanks! Regards, Forrest -- Thanks! Regards, Forrest
[jira] [Closed] (XBEAN-232) No xbean-finder-shaded sources.jar
[ https://issues.apache.org/jira/browse/XBEAN-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed XBEAN-232. --- Resolution: Fixed Fix Version/s: 3.14 The new xbean-asm4-shaded now includes sources.jar For xbean-asm-shaded this is not really possible as the asm3 packages don't ship any sources themselfs. Thus there are just no sources to shade... No xbean-finder-shaded sources.jar -- Key: XBEAN-232 URL: https://issues.apache.org/jira/browse/XBEAN-232 Project: XBean Issue Type: Bug Reporter: David Blevins Assignee: Mark Struberg Fix For: 3.14 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (XBEAN-249) use asm4 shade in xbean-reflect
Romain Manni-Bucau created XBEAN-249: Summary: use asm4 shade in xbean-reflect Key: XBEAN-249 URL: https://issues.apache.org/jira/browse/XBEAN-249 Project: XBean Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.14 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (XBEAN-249) use asm4 shade in xbean-reflect and xbean-finder-shaded
[ https://issues.apache.org/jira/browse/XBEAN-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated XBEAN-249: - Summary: use asm4 shade in xbean-reflect and xbean-finder-shaded (was: use asm4 shade in xbean-reflect and xbean-finder-shade) use asm4 shade in xbean-reflect and xbean-finder-shaded --- Key: XBEAN-249 URL: https://issues.apache.org/jira/browse/XBEAN-249 Project: XBean Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.14 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (XBEAN-249) use asm4 shade in xbean-reflect and xbean-finder-shade
[ https://issues.apache.org/jira/browse/XBEAN-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated XBEAN-249: - Summary: use asm4 shade in xbean-reflect and xbean-finder-shade (was: use asm4 shade in xbean-reflect) use asm4 shade in xbean-reflect and xbean-finder-shade -- Key: XBEAN-249 URL: https://issues.apache.org/jira/browse/XBEAN-249 Project: XBean Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 3.14 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
