[jira] Updated: (GERONIMO-4518) Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties
[ https://issues.apache.org/jira/browse/GERONIMO-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Jiang updated GERONIMO-4518: -- Attachment: G4518_Shawn.patch Patch for this defect. > Can't shutdown the server when host was set to 127.0.0.1 in > config-substitutions.properties > --- > > Key: GERONIMO-4518 > URL: https://issues.apache.org/jira/browse/GERONIMO-4518 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 2.1.4, 2.2 > Environment: Windows XP + Sun JDK 1.5 >Reporter: Shawn Jiang >Priority: Blocker > Fix For: 2.1.4, 2.2 > > Attachments: G4518_Shawn.patch > > > 1, change the host in config-substitutions.properties to 127.0.0.1 > 2, start the server. > 3, shutdown the server. > *expected result*: the server could be shutdown. > *actual result*: the sever can't be shutdown with exception: > java.net.ConnectException: Connection refused: connect > -- > C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\bin>shutdown --host 127.0.0.1 > Using GERONIMO_HOME: C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT > Using GERONIMO_TMPDIR: var\temp > Using JRE_HOME:D:\dev\JDKs\sun_jdk1.5.0_15\jre > log4j:WARN No appenders could be found for logger > (org.apache.geronimo.kernel.basic.BasicKernel). > log4j:WARN Please initialize the log4j system properly. > Username: system > Password: *** > Locating server on 127.0.0.1:1099... > Could not communicate with the server. The server may not be running or the > port number may be inco > rrect (Connection refused to host: 6.153.277.58; nested exception is: > java.net.ConnectException: Connection refused: connect) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4518) Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties
[ https://issues.apache.org/jira/browse/GERONIMO-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Jiang updated GERONIMO-4518: -- Patch Info: [Patch Available] > Can't shutdown the server when host was set to 127.0.0.1 in > config-substitutions.properties > --- > > Key: GERONIMO-4518 > URL: https://issues.apache.org/jira/browse/GERONIMO-4518 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 2.1.4, 2.2 > Environment: Windows XP + Sun JDK 1.5 >Reporter: Shawn Jiang >Priority: Blocker > Fix For: 2.1.4, 2.2 > > Attachments: G4518_Shawn.patch > > > 1, change the host in config-substitutions.properties to 127.0.0.1 > 2, start the server. > 3, shutdown the server. > *expected result*: the server could be shutdown. > *actual result*: the sever can't be shutdown with exception: > java.net.ConnectException: Connection refused: connect > -- > C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\bin>shutdown --host 127.0.0.1 > Using GERONIMO_HOME: C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT > Using GERONIMO_TMPDIR: var\temp > Using JRE_HOME:D:\dev\JDKs\sun_jdk1.5.0_15\jre > log4j:WARN No appenders could be found for logger > (org.apache.geronimo.kernel.basic.BasicKernel). > log4j:WARN Please initialize the log4j system properly. > Username: system > Password: *** > Locating server on 127.0.0.1:1099... > Could not communicate with the server. The server may not be running or the > port number may be inco > rrect (Connection refused to host: 6.153.277.58; nested exception is: > java.net.ConnectException: Connection refused: connect) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4520) Update GBeans documentation
Update GBeans documentation --- Key: GERONIMO-4520 URL: https://issues.apache.org/jira/browse/GERONIMO-4520 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: documentation Affects Versions: 2.1.3 Reporter: Jürgen Weber Fix For: 2.2 Please update the documentatation for GBeans (http://cwiki.apache.org/GMOxDEV/gbeans.html) Right now, the MyGBean sample cannot be deployed (deployment throws java.lang.NoClassDefFoundError: org/apache/geronimo/upgrade/Upgrade1_0To1_1) Please show how the sample can be deployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665390#action_12665390 ] Ivan commented on GERONIMO-4369: I am working on this issue, it seems that the reason is not only that child configurations are not started. In the reloadConfiguration function, I found that there is no invocations of configurationModule.stop()/unload() to sync the configuration status between the configutationManager and configurationModel, which will cause a IllegalStateException threw by ConfigurationStatus.destroy(). Any comment ? Thanks ! > The new attribute values are overwrote while restarting the DB pool connector > - > > Key: GERONIMO-4369 > URL: https://issues.apache.org/jira/browse/GERONIMO-4369 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: Geronimo 2.2 snapshot > JDK 1.5 > Windows XP >Reporter: Ivan >Assignee: Ivan >Priority: Blocker > Fix For: 2.1.4, 2.2 > > Attachments: Geronimo-4369-11.13.patch, Geronimo-4369-11.17.patch, > Geronimo-4369-11.19.patch > > > After editing the values in the db pool, then restart it in the console, the > new values lost. > When saving the new attribute values, such as user name, the gbeandata in > the configurationManager is not updated, so while restarting the connector, > the gbinstance copies those old values from it. So the new persistent values > do not take effect, > Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Security Vulnerability Policy created
I've moved this back to the d...@. This is the danger of cross-posting. The reply-to for your original message (at least the one that I received) was u...@. This DISCUSS belongs on dev@ On Jan 19, 2009, at 5:10 PM, Donald Woods wrote: Sounds good to me. Should step #8 include a post to the private@ list, so other PMC members will have some history behind the fixes being checked into svn in step #9? I like it. 8 is probably a good place to coordinate with the PMC. --kevan
Re: [DISCUSS] Security Vulnerability Policy created
On Jan 19, 2009, at 12:32 PM, Donald Woods wrote: Joe Bohn wrote: Is the omission of any discussion of a JIRA intentional? In other words, is it expected that a JIRA will *not* be created to document or track the code change and that CVE will be the only documentation of the issue (and then only after a server image has already been released by changing the commit log)? Good point. I believe we should create the JIRA as part of step #9. OK. That sounds good. I'm assuming the RELEASE_NOTES will also contain information regarding the vulnerability (including CVE, etc). If we are not creating a JIRA, then this brings up a documentation issue. Not announcing the issue until after a server release also causes some doc issues. - We typically use JIRAs to identify all changes within a release. - We include the list of JIRAs fixed and outstanding within the RELEASE_NOTES for each server release. - The RELEASE_NOTES are included in the server images so that anyone downloading a server image can easily understand what issues are resolved or still outstanding with that release. - So typically JIRAs must be resolved before we create a release candidate. The entire release (including the release notes) is then validated during the vote for the release candidate. Security fixes are important, so it seems that they should be mentioned in the release notes. I also understand the sensitive nature of these issues and the possibility of exploitation. However, it seems that the code check-in itself already has the potential to make the exposure public for those watching carefully. One possible solution would be to announce the vulnerability once we have a work-around available and/or a fix available in a SNAPSHOT image. Agree that we need to be as open as possible. As part of step #9, I'd like to see us add a reference to the fix (but not the complete details) on our Security pages for each release. Step #12 would also be updated, to go back and add the CVE number and more details to the Security pages as each branch is released. OK. Is it necessary to hide the CVE until 12? If so, I guess the RELEASE_NOTES shouldn't include the CVE... --kevan
Re: [DISCUSS] Security Vulnerability Policy created
I think the key question is when we will announce the vulnerability (current #11). My preference would be that we create a JIRA for the issue so that it can be included in the release notes (#9 - either with or without the CVE referenced). But that (along with the code check-in) creates a chicken and egg scenario which exposes some information about the vulnerability prior to the announce (currently step #11). I'm wondering if we should just go ahead and announce as soon as the code is checked-in and we have a SNAPSHOT available for download. In the announcement we could reference any appropriate workarounds and the availability of the fix in the latest SNAPSHOTS so that users can take appropriate action. Updated steps might look something like this (picking up at step #8): 8. Reach an agreement for the fix, announcement and release schedule with the submitter. 9. Create a JIRA and commit the fix in all actively maintained releases. 10. Announce the vulnerability (users, dev, secur...@a.o, bugtraq at securityfocus.com, full-disclosure at lists.grok.org.uk and project security pages) sighting workarounds and latest SNAPSHOT published. 11. Update the JIRA and svn log to include the CVE number. 12. Roll a release for each actively maintained branch (unreleased trunk can wait.) It's not optimal (would be much better to have a release in hand) but perhaps it is an appropriate compromise given that we can't prevent some information from going public when code is checked-in. Joe Kevan Miller wrote: On Jan 19, 2009, at 12:32 PM, Donald Woods wrote: Joe Bohn wrote: Is the omission of any discussion of a JIRA intentional? In other words, is it expected that a JIRA will *not* be created to document or track the code change and that CVE will be the only documentation of the issue (and then only after a server image has already been released by changing the commit log)? Good point. I believe we should create the JIRA as part of step #9. OK. That sounds good. I'm assuming the RELEASE_NOTES will also contain information regarding the vulnerability (including CVE, etc). If we are not creating a JIRA, then this brings up a documentation issue. Not announcing the issue until after a server release also causes some doc issues. - We typically use JIRAs to identify all changes within a release. - We include the list of JIRAs fixed and outstanding within the RELEASE_NOTES for each server release. - The RELEASE_NOTES are included in the server images so that anyone downloading a server image can easily understand what issues are resolved or still outstanding with that release. - So typically JIRAs must be resolved before we create a release candidate. The entire release (including the release notes) is then validated during the vote for the release candidate. Security fixes are important, so it seems that they should be mentioned in the release notes. I also understand the sensitive nature of these issues and the possibility of exploitation. However, it seems that the code check-in itself already has the potential to make the exposure public for those watching carefully. One possible solution would be to announce the vulnerability once we have a work-around available and/or a fix available in a SNAPSHOT image. Agree that we need to be as open as possible. As part of step #9, I'd like to see us add a reference to the fix (but not the complete details) on our Security pages for each release. Step #12 would also be updated, to go back and add the CVE number and more details to the Security pages as each branch is released. OK. Is it necessary to hide the CVE until 12? If so, I guess the RELEASE_NOTES shouldn't include the CVE... --kevan
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665440#action_12665440 ] Bruno César Brito Sant'Anna commented on GERONIMO-4508: --- I'd like to add another comment to this issue: After downgrading my spring to 2.0.5 I've got several errors using spring IoC feature; "org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'accountService': Bean with name 'accountService' has been injected into other beans [accountUtil, nfpUtil, filemanagerUtil, sfzWebServiceUtil] in its raw version as part of a circular reference, but has eventually been wrapped (for example as part of auto-proxy creation). This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example." I've partially solved this by using lazy-init in some beans... but it is not desirable... and it does not work using AOP proxy factory beans... (I need proxy factory beans because i have to work with JPA Interceptor stuff)... I haven't found any solution until now for this problem... > Spring AOP AspectJ conflict when using Apache CXF > - > > Key: GERONIMO-4508 > URL: https://issues.apache.org/jira/browse/GERONIMO-4508 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 >Reporter: Bruno César Brito Sant'Anna > Attachments: jetty_trace.txt, trace.txt > > > I'm trying to create a WebService Bean on Geronimo using Spring IoC container. > Well, I followed this tutorial > http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html > My GERONIMO_OPTS var value is "-Dorg.apache.geronimo.jaxws.provider=cxf > -Dorg.apache.geronimo.saaj.provider=axis2 > -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false" > When server starts, when reading Spring AOC Config my server crashes... > Summary stack trace: > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name > 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': > Instantiation of bean failed; nested exception is > java.lang.AbstractMethodError: > org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; > It took me several hours to discover that cxf environment was messing around > with Spring... > reseting GERONIMO_OPTS and removing cxf webservice stuff from my > applicationContext.xml made my server run again. > Looks like I cannot use CXF with AOP... > I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Security Vulnerability Policy created
Sounds good. I was assuming the SNAPSHOT build in #10 would be handled by Jarek's automated builds and we would just say "mmdd or later SNAPSHOT build" and include the URL to our published snapshot builds. -Donald Joe Bohn wrote: I think the key question is when we will announce the vulnerability (current #11). My preference would be that we create a JIRA for the issue so that it can be included in the release notes (#9 - either with or without the CVE referenced). But that (along with the code check-in) creates a chicken and egg scenario which exposes some information about the vulnerability prior to the announce (currently step #11). I'm wondering if we should just go ahead and announce as soon as the code is checked-in and we have a SNAPSHOT available for download. In the announcement we could reference any appropriate workarounds and the availability of the fix in the latest SNAPSHOTS so that users can take appropriate action. Updated steps might look something like this (picking up at step #8): 8. Reach an agreement for the fix, announcement and release schedule with the submitter. 9. Create a JIRA and commit the fix in all actively maintained releases. 10. Announce the vulnerability (users, dev, secur...@a.o, bugtraq at securityfocus.com, full-disclosure at lists.grok.org.uk and project security pages) sighting workarounds and latest SNAPSHOT published. 11. Update the JIRA and svn log to include the CVE number. 12. Roll a release for each actively maintained branch (unreleased trunk can wait.) It's not optimal (would be much better to have a release in hand) but perhaps it is an appropriate compromise given that we can't prevent some information from going public when code is checked-in. Joe Kevan Miller wrote: On Jan 19, 2009, at 12:32 PM, Donald Woods wrote: Joe Bohn wrote: Is the omission of any discussion of a JIRA intentional? In other words, is it expected that a JIRA will *not* be created to document or track the code change and that CVE will be the only documentation of the issue (and then only after a server image has already been released by changing the commit log)? Good point. I believe we should create the JIRA as part of step #9. OK. That sounds good. I'm assuming the RELEASE_NOTES will also contain information regarding the vulnerability (including CVE, etc). If we are not creating a JIRA, then this brings up a documentation issue. Not announcing the issue until after a server release also causes some doc issues. - We typically use JIRAs to identify all changes within a release. - We include the list of JIRAs fixed and outstanding within the RELEASE_NOTES for each server release. - The RELEASE_NOTES are included in the server images so that anyone downloading a server image can easily understand what issues are resolved or still outstanding with that release. - So typically JIRAs must be resolved before we create a release candidate. The entire release (including the release notes) is then validated during the vote for the release candidate. Security fixes are important, so it seems that they should be mentioned in the release notes. I also understand the sensitive nature of these issues and the possibility of exploitation. However, it seems that the code check-in itself already has the potential to make the exposure public for those watching carefully. One possible solution would be to announce the vulnerability once we have a work-around available and/or a fix available in a SNAPSHOT image. Agree that we need to be as open as possible. As part of step #9, I'd like to see us add a reference to the fix (but not the complete details) on our Security pages for each release. Step #12 would also be updated, to go back and add the CVE number and more details to the Security pages as each branch is released. OK. Is it necessary to hide the CVE until 12? If so, I guess the RELEASE_NOTES shouldn't include the CVE... --kevan
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665451#action_12665451 ] Donald Woods commented on GERONIMO-4508: BTW - The branches/2.1 (2.1.4-SNAPSHOT) code was updated yesterday to use the Spring 2.5.6 binaries, just as trunk (2.2-SNAPSHOT.) But, the 2.1.4 release still uses the older aspectjrt-1.5.3. > Spring AOP AspectJ conflict when using Apache CXF > - > > Key: GERONIMO-4508 > URL: https://issues.apache.org/jira/browse/GERONIMO-4508 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 >Reporter: Bruno César Brito Sant'Anna > Attachments: jetty_trace.txt, trace.txt > > > I'm trying to create a WebService Bean on Geronimo using Spring IoC container. > Well, I followed this tutorial > http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html > My GERONIMO_OPTS var value is "-Dorg.apache.geronimo.jaxws.provider=cxf > -Dorg.apache.geronimo.saaj.provider=axis2 > -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false" > When server starts, when reading Spring AOC Config my server crashes... > Summary stack trace: > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name > 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': > Instantiation of bean failed; nested exception is > java.lang.AbstractMethodError: > org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; > It took me several hours to discover that cxf environment was messing around > with Spring... > reseting GERONIMO_OPTS and removing cxf webservice stuff from my > applicationContext.xml made my server run again. > Looks like I cannot use CXF with AOP... > I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4518) Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties
[ https://issues.apache.org/jira/browse/GERONIMO-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-4518. Resolution: Fixed Verified patch worked on trunk after changing all localhost and 0.0.0.0 references in config-substitutions.properties to 127.0.0.1. Server testsuite passed with Java 1.5. Applied patch to trunk (2.2-SNAPSHOT) as Rev736042. Applied patch to branches/2.1 (2.1.4-SNAPSHOT) as Rev736044. Thanks Shawn. > Can't shutdown the server when host was set to 127.0.0.1 in > config-substitutions.properties > --- > > Key: GERONIMO-4518 > URL: https://issues.apache.org/jira/browse/GERONIMO-4518 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 2.1.4, 2.2 > Environment: Windows XP + Sun JDK 1.5 >Reporter: Shawn Jiang >Assignee: Donald Woods >Priority: Blocker > Fix For: 2.1.4, 2.2 > > Attachments: G4518_Shawn.patch > > > 1, change the host in config-substitutions.properties to 127.0.0.1 > 2, start the server. > 3, shutdown the server. > *expected result*: the server could be shutdown. > *actual result*: the sever can't be shutdown with exception: > java.net.ConnectException: Connection refused: connect > -- > C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\bin>shutdown --host 127.0.0.1 > Using GERONIMO_HOME: C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT > Using GERONIMO_TMPDIR: var\temp > Using JRE_HOME:D:\dev\JDKs\sun_jdk1.5.0_15\jre > log4j:WARN No appenders could be found for logger > (org.apache.geronimo.kernel.basic.BasicKernel). > log4j:WARN Please initialize the log4j system properly. > Username: system > Password: *** > Locating server on 127.0.0.1:1099... > Could not communicate with the server. The server may not be running or the > port number may be inco > rrect (Connection refused to host: 6.153.277.58; nested exception is: > java.net.ConnectException: Connection refused: connect) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4518) Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties
[ https://issues.apache.org/jira/browse/GERONIMO-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-4518: -- Assignee: Donald Woods > Can't shutdown the server when host was set to 127.0.0.1 in > config-substitutions.properties > --- > > Key: GERONIMO-4518 > URL: https://issues.apache.org/jira/browse/GERONIMO-4518 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 2.1.4, 2.2 > Environment: Windows XP + Sun JDK 1.5 >Reporter: Shawn Jiang >Assignee: Donald Woods >Priority: Blocker > Fix For: 2.1.4, 2.2 > > Attachments: G4518_Shawn.patch > > > 1, change the host in config-substitutions.properties to 127.0.0.1 > 2, start the server. > 3, shutdown the server. > *expected result*: the server could be shutdown. > *actual result*: the sever can't be shutdown with exception: > java.net.ConnectException: Connection refused: connect > -- > C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\bin>shutdown --host 127.0.0.1 > Using GERONIMO_HOME: C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT > Using GERONIMO_TMPDIR: var\temp > Using JRE_HOME:D:\dev\JDKs\sun_jdk1.5.0_15\jre > log4j:WARN No appenders could be found for logger > (org.apache.geronimo.kernel.basic.BasicKernel). > log4j:WARN Please initialize the log4j system properly. > Username: system > Password: *** > Locating server on 127.0.0.1:1099... > Could not communicate with the server. The server may not be running or the > port number may be inco > rrect (Connection refused to host: 6.153.277.58; nested exception is: > java.net.ConnectException: Connection refused: connect) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release DayTrader v2.1.3 - Cancelled
Canceling this vote, due to lack of interest. -Donald Donald Woods wrote: All, I've prepared a release candidate of DayTrader 2.1.3 for your review and vote. This release can only be installed on Geronimo 2.1.3 server or later. The source level is Rev723010 from the following svn branch: https://svn.apache.org/repos/asf/geronimo/daytrader/branches/2.1.3/ When the release vote is approved, I will svn mv the code to: https://svn.apache.org/repos/asf/geronimo/daytrader/tags/2.1.3/ The following staging directory contains the maven artifacts to be released: http://people.apache.org/~dwoods/staging-repo/daytrader/ For your convenience, you can add the following as a plugin repo to install DayTrader as a plugin from the staging repo: http://people.apache.org/~dwoods/ The README and source files can be found here: http://people.apache.org/~dwoods/staging-repo/README-daytrader.txt http://people.apache.org/~dwoods/staging-repo/daytrader/org/apache/geronimo/daytrader/daytrader/2.1.3/daytrader-2.1.3-src.zip When the release vote is approved, the maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. [ ] +1 Release DayTrader 2.1.3 [ ] 0 No opinion [ ] -1 Do not release DayTrader 2.1.3 (please provide rationale) The voting will be open for 72 hours or until we have enough votes, whichever is longer. -Donald
Re: svn commit: r736042 - in /geronimo/server/trunk/framework/modules: geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java geronimo-kernel/src/main/java/org/apache/
Donald,
I was looking at this patch but I didn't have a chance to test it and
comment on the bug but I think this fix is not right. It effectively
ignores the host parameter passed in the createSocket() call. So if
you have two running servers one local and one remote and both have
set sub. property hostname=127.0.0.1 and you issue shutdown -h command on the local machine, the local server will be
shutdown!
Jarek
On Tue, Jan 20, 2009 at 12:19 PM, wrote:
> Author: dwoods
> Date: Tue Jan 20 09:19:57 2009
> New Revision: 736042
>
> URL: http://svn.apache.org/viewvc?rev=736042&view=rev
> Log:
> GERONIMO-4518 Can't shutdown the server when host was set to 127.0.0.1 in
> config-substitutions.properties. Applied patch from Shawn Jiang.
>
> Modified:
>
> geronimo/server/trunk/framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java
>
> geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/rmi/GeronimoRMIClientSocketFactory.java
>
> Modified:
> geronimo/server/trunk/framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java
> URL:
> http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java?rev=736042&r1=736041&r2=736042&view=diff
> ==
> ---
> geronimo/server/trunk/framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java
> (original)
> +++
> geronimo/server/trunk/framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java
> Tue Jan 20 09:19:57 2009
> @@ -188,7 +188,7 @@
> } else {
> log.warn("Starting unauthenticating JMXConnector for " +
> jmxServiceURL);
> }
> -RMIClientSocketFactory socketFactory = new
> GeronimoRMIClientSocketFactory(2 * 60 * 1000, 5 * 60 * 1000);
> +RMIClientSocketFactory socketFactory = new
> GeronimoRMIClientSocketFactory(host, 2 * 60 * 1000, 5 * 60 * 1000);
> env.put(RMIConnectorServer.RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE,
> socketFactory);
> RMIServerSocketFactory serverSocketFactory = new
> GeronimoRMIServerSocketFactory(host);
> env.put(RMIConnectorServer.RMI_SERVER_SOCKET_FACTORY_ATTRIBUTE,
> serverSocketFactory);
>
> Modified:
> geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/rmi/GeronimoRMIClientSocketFactory.java
> URL:
> http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/rmi/GeronimoRMIClientSocketFactory.java?rev=736042&r1=736041&r2=736042&view=diff
> ==
> ---
> geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/rmi/GeronimoRMIClientSocketFactory.java
> (original)
> +++
> geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/rmi/GeronimoRMIClientSocketFactory.java
> Tue Jan 20 09:19:57 2009
> @@ -31,15 +31,20 @@
>
> private int connectionTimeout = -1;
> private int readTimeout = -1;
> +private String host=null;
>
> -public GeronimoRMIClientSocketFactory(int connectionTimeout, int
> readTimeout) {
> +public GeronimoRMIClientSocketFactory(String _host,int
> connectionTimeout, int readTimeout) {
> +this.host=_host;
> this.connectionTimeout = connectionTimeout;
> this.readTimeout = readTimeout;
> }
>
> -public Socket createSocket(String host, int port) throws IOException {
> +public Socket createSocket(String _host, int port) throws IOException {
> Socket socket = new Socket();
> -socket.bind(null);
> +socket.bind(null);
> +if(host==null){
> +host=_host;
> +}
> socket.connect(new InetSocketAddress(host, port),
> (this.connectionTimeout > 0) ? this.connectionTimeout : 0);
> if (this.readTimeout >= 0) {
> socket.setSoTimeout(this.readTimeout);
>
>
>
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665503#action_12665503 ] Bruno César Brito Sant'Anna commented on GERONIMO-4508: --- Fine, I was worried by using spring components from different versions. I'll wait until geronimo 2.2 release. Thanks Donald, > Spring AOP AspectJ conflict when using Apache CXF > - > > Key: GERONIMO-4508 > URL: https://issues.apache.org/jira/browse/GERONIMO-4508 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 >Reporter: Bruno César Brito Sant'Anna > Attachments: jetty_trace.txt, trace.txt > > > I'm trying to create a WebService Bean on Geronimo using Spring IoC container. > Well, I followed this tutorial > http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html > My GERONIMO_OPTS var value is "-Dorg.apache.geronimo.jaxws.provider=cxf > -Dorg.apache.geronimo.saaj.provider=axis2 > -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false" > When server starts, when reading Spring AOC Config my server crashes... > Summary stack trace: > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name > 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': > Instantiation of bean failed; nested exception is > java.lang.AbstractMethodError: > org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; > It took me several hours to discover that cxf environment was messing around > with Spring... > reseting GERONIMO_OPTS and removing cxf webservice stuff from my > applicationContext.xml made my server run again. > Looks like I cannot use CXF with AOP... > I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 736192
Geronimo Revision: 736192 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090120/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090120
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 37 minutes 47 seconds
[INFO] Finished at: Tue Jan 20 21:42:21 EST 2009
[INFO] Final Memory: 636M/977M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090120/logs-2100-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:42.844
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:00:59.523)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:29.051)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:33.889)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.724)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:12.104)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:20.105)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:42.608)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:48.000)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:51.712)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:41.893)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:31.153)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:29.375)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:31.396)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:48.737)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:55.417)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:49.310)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.282)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:46.852)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security FAILURE (0:00:36.255) Java
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:28.886)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5
[jira] Updated: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4369: --- Attachment: Geronimo-4369-01.21.patch There should be some issues in the reload function of the configuration manager, if the component which needs to restart has child configurations, the exception will be threw on the 1186th line removeConfigurationFromModel(configurationId); Currently , the solution is first to stop, then start the service, and will try to start all the stopped service, maybe we need to revert to reload function once it works properly. By the way, I found the j2ee-corba-yoko could not be restarted, while we stop the service, it does not release the port 1050. Please help to review the patch, thanks ! > The new attribute values are overwrote while restarting the DB pool connector > - > > Key: GERONIMO-4369 > URL: https://issues.apache.org/jira/browse/GERONIMO-4369 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: Geronimo 2.2 snapshot > JDK 1.5 > Windows XP >Reporter: Ivan >Assignee: Ivan >Priority: Blocker > Fix For: 2.1.4, 2.2 > > Attachments: Geronimo-4369-01.21.patch, Geronimo-4369-11.13.patch, > Geronimo-4369-11.17.patch, Geronimo-4369-11.19.patch > > > After editing the values in the db pool, then restart it in the console, the > new values lost. > When saving the new attribute values, such as user name, the gbeandata in > the configurationManager is not updated, so while restarting the connector, > the gbinstance copies those old values from it. So the new persistent values > do not take effect, > Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4485) Port the GERONIMO-4474 patch for V2.1
[ https://issues.apache.org/jira/browse/GERONIMO-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMO-4485: Summary: Port the GERONIMO-4474 patch for V2.1 (was: Pull out the text in the JSP files to resource bundle files for V2.1) > Port the GERONIMO-4474 patch for V2.1 > - > > Key: GERONIMO-4485 > URL: https://issues.apache.org/jira/browse/GERONIMO-4485 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 >Reporter: Kan Ogawa >Assignee: Kan Ogawa >Priority: Minor > Fix For: 2.1.4 > > Attachments: console-base-portlets.patch, > console-portal-driver.patch, debugviews-portlets.patch, mconsole-jetty.patch, > mconsole-tomcat.patch, mconsole-war.patch, plugin-portlets.patch > > > Target release should be 2.2, if you can attach the patches by Jan. 7th. > If you would like to see this in 2.1.4, then please attach additional patches > created from that branch and we'll try to get them in after we wrap up the > 2.2 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: js-localization-core_v2.patch > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, > js-localization-core_v2.patch, js-localization-openejb.patch, > screenshot-1.jpg, screenshot-2.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: js-localization-sysdb.patch adaption of sysdb portlet > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, > js-localization-core_v2.patch, js-localization-openejb.patch, > js-localization-sysdb.patch, screenshot-1.jpg, screenshot-2.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4475) Improve JMS portlet for Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4475: --- Attachment: (was: G4475-activemq-portlet-update-01.patch) > Improve JMS portlet for Borker configuration > > > Key: GERONIMO-4475 > URL: https://issues.apache.org/jira/browse/GERONIMO-4475 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Ivan >Assignee: Donald Woods > Fix For: 2.2 > > Attachments: G4475-activemq-broker.patch, > G4475-activemq-portlet-update-02.patch, G4475-geronimo-management.patch > > > Currently in the administrator console, the users could not add another embed > broker. Also, they could not edit the broker through administrator console. > I list the features that I could see : > 1. While creating the broker, let the use upload a configuration file. > 2. While editing the broker, show a text area, so that the user could edit > the spring XML file in it. Shall we give the user a more friendly interface, > so that they do not need the edit the XML file directly. I am not sure how it > should look like. > 3. Update the connector port let, so that while creating a new connector, > the user could specify the broker that it belongs to. > Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4475) Improve JMS portlet for Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4475: --- Attachment: (was: G4475-activemq-portlet-update.patch) > Improve JMS portlet for Borker configuration > > > Key: GERONIMO-4475 > URL: https://issues.apache.org/jira/browse/GERONIMO-4475 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Ivan >Assignee: Donald Woods > Fix For: 2.2 > > Attachments: G4475-activemq-broker.patch, > G4475-activemq-portlet-update-02.patch, G4475-geronimo-management.patch > > > Currently in the administrator console, the users could not add another embed > broker. Also, they could not edit the broker through administrator console. > I list the features that I could see : > 1. While creating the broker, let the use upload a configuration file. > 2. While editing the broker, show a text area, so that the user could edit > the spring XML file in it. Shall we give the user a more friendly interface, > so that they do not need the edit the XML file directly. I am not sure how it > should look like. > 3. Update the connector port let, so that while creating a new connector, > the user could specify the broker that it belongs to. > Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
