[jira] Closed: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3754. -- Resolution: Fixed Fix Version/s: 2.1 Assignee: David Jencks I applied the patch in rev 612745 after fixing up the problems with trying to install already-present plugins. The downloadPoller now shows info about plugins that weren't installed: we should show it in the gshell output at least. > Username/password is ignored in PluginInstallerGBean > > > Key: GERONIMO-3754 > URL: https://issues.apache.org/jira/browse/GERONIMO-3754 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: general >Affects Versions: 2.1 >Reporter: Jarek Gawor >Assignee: David Jencks > Fix For: 2.1 > > Attachments: GERONIMO-3754.patch > > > The username/password is ignored in PluginInstallerGBean in listPlugins() > function. That means, for example, that with plugin installer portlet I'm > unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo > as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[YOKO] premature tools deletion?
I was wondering if we prematurely deleted tools. It would be nice to have our own IDL compiler. I was thinking that we could move tools to a dir in the sandbox for someone to pick up. Thoughts? Regards, Alan
Re: svn commit: r612439 [1/2] - in /geronimo/server/trunk: assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-tomcat6-javaee5/ plugins/clustering/ plugins/clustering/clustering/ plugins/clusterin
On 17/01/2008, at 9:01 AM, Kevan Miller wrote: I am now integration testing the OpenEJB clustering support and it appears I will need to do some minor adjustments. As part of the change, four sub-projects/dependencies are added: geronimo-openejb- clustering-wadi, geronimo-openejb-clustering-builder-wadi, openejb- clustering-wadi and openejb-clustering-builder-wadi. This structure mirrors the Jetty and Tomcat ones. I also think 2.1 is belated and should be cut as soon as possible. I will hold-on the OpenEJB commit till the creation of a 2.1 branch. Cool. If this branch isn't for another week or two, is that going to ok for you? I think we want to avoid creating branches/2.1 and then merging a bunch of fit-and-finish fixes between the branch and trunk... No worries. Also I agree it is quite a pain to port change sets from branches to trunk. Thanks, Gianny
Re: [YOKO] Yoko web site
They use confluence and auto-export. --jason -Original Message- From: "Alan D. Cabrera" <[EMAIL PROTECTED]> Date: Wed, 16 Jan 2008 21:39:43 To:dev@geronimo.apache.org Subject: Re: [YOKO] Yoko web site :) What does XBean and GShell do? Regards, Alan On Jan 16, 2008, at 5:18 PM, Jason Dillon wrote: > Well there is this thing called HTML and you use it to make things > called "pages" and then put them on a "web server"... > > :-P > > What do you want... Something backed up by confluence? Or static > via svn? > > --jason > > > -Original Message- > From: "Alan D. Cabrera" <[EMAIL PROTECTED]> > > Date: Wed, 16 Jan 2008 16:41:30 > To:Developers Geronimo > Subject: [YOKO] Yoko web site > > > I want to start creating the new Yoko website and wiki. How do I do > this? > > > Regards, > Alan > > > >
[jira] Commented: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559824#action_12559824 ] Jarek Gawor commented on GERONIMO-3754: --- Ok, but except that change, the patch looks good to you (wasn't sure about the api changes)? Also, I just committed a basic console test that should check the plugin portlet for listing the plugins (revision 612725). > Username/password is ignored in PluginInstallerGBean > > > Key: GERONIMO-3754 > URL: https://issues.apache.org/jira/browse/GERONIMO-3754 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: general >Affects Versions: 2.1 >Reporter: Jarek Gawor > Attachments: GERONIMO-3754.patch > > > The username/password is ignored in PluginInstallerGBean in listPlugins() > function. That means, for example, that with plugin installer portlet I'm > unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo > as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559818#action_12559818 ] David Jencks commented on GERONIMO-3754: the change to validatePlugin causes problems in assembly if a plugin is mentioned in an assembly but is already in whatever was unpacked (e.g. framework). I'm thinking about how to fix this, leaning towards ignoring requests to install plugins that are already installed. > Username/password is ignored in PluginInstallerGBean > > > Key: GERONIMO-3754 > URL: https://issues.apache.org/jira/browse/GERONIMO-3754 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: general >Affects Versions: 2.1 >Reporter: Jarek Gawor > Attachments: GERONIMO-3754.patch > > > The username/password is ignored in PluginInstallerGBean in listPlugins() > function. That means, for example, that with plugin installer portlet I'm > unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo > as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [YOKO] Yoko web site
Hi there Alan, In terms of starting a Wiki, there are several options out there... just to name a few popular ones: Confluence http://www.atlassian.com/software/confluence/ Media Wiki http://www.mediawiki.org/wiki/MediaWiki Doku Wiki http://wiki.splitbrain.org/wiki:dokuwiki PmWiki http://www.pmwiki.org/ If you're looking to build something pretty big I've heard Confluence and Media Wiki work pretty well. The Media Wiki was the original package written for Wikipedia, so it's pretty robust. Smaller, simpler and cleaner solutions would be the Doku Wiki and PmWiki. Hopes this helps. the best, Joseph Leong On Jan 17, 2008 12:39 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > :) > > > What does XBean and GShell do? > > > Regards, > Alan > > On Jan 16, 2008, at 5:18 PM, Jason Dillon wrote: > > > Well there is this thing called HTML and you use it to make things > > called "pages" and then put them on a "web server"... > > > > :-P > > > > What do you want... Something backed up by confluence? Or static > > via svn? > > > > --jason > > > > > > -Original Message- > > From: "Alan D. Cabrera" <[EMAIL PROTECTED]> > > > > Date: Wed, 16 Jan 2008 16:41:30 > > To:Developers Geronimo > > Subject: [YOKO] Yoko web site > > > > > > I want to start creating the new Yoko website and wiki. How do I do > > this? > > > > > > Regards, > > Alan > > > > > > > > > >
Re: Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
I got the similar error using the latest trunk build on Windows XP. I searched the org.apache.geronimo.configs/j2ee-system/2.1-SNAPSHOT/car ,org.apache.geronimo.configs/jee-specs/2.1-SNAPSHOT/car and org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car configurations ( they are the parents of org.apache.geronimo.configs/plugin/2.1-SNAPSHOT/car), but didn't find they loaded org.apache.xbean/xbean-reflect/3.3-SNAPSHOT/jar which includes the class org.apache.xbean.propertyeditor.LinkedListEditor. Now I added org.apache.xbean/xbean-reflect/3.3-SNAPSHOT/jar to org.apache.geronimo.configs/j2ee-system/2.1-SNAPSHOT/car, the server can start up correctly. But I don't know if I'm missing anything, if not, I'll open a jira for this. Thanks a lot. -- Yun Feng Peter Petersson wrote: > Yes thank you Jarek! > > As mentioned by Jarek the second attribute below is the offending one. > It is added to the config by adding a repository. > The question is where is my > org.apache.xbean.propertyeditor.LinkedListEditor :) maybe it is fixed > in newer builds I haven't got around checking it yet. > thanks > Peter P > > config.xml > : > > > name="repositoryList">http://geronimo.apache.org/plugins/plugin-repository-list-2.1.txt > > propertyEditor="org.apache.xbean.propertyeditor.LinkedListEditor" > name="userRepositories">[~/.m2/repository,file:/home/ppe/.m2/repository/] > > > > > > Jarek Gawor wrote: >> Peter, >> >> I also see the same problem on XP on second start up. But I was able >> to work around it by removing >> 'propertyEditor="org.apache.xbean.propertyeditor.LinkedListEditor"' >> attribute from element of DownloadedPluginRepos gbean. >> >> Hope this helps, >> Jarek >> >> On Jan 14, 2008 7:21 PM, Peter Petersson <[EMAIL PROTECTED]> wrote: >> >>> In the men time I resorted to the assembly I pulled together yesterday >>> and just doing a ./startup.sh; ./shutdown.sh; ../startup.sh fails on the >>> second startup with the error indicated bellow. Its getting late >>> here so >>> I will look in to this again tomorrow hopefully with a fresh build. >>> regards >>> Peter Petersson >>> >>> >>> >>> Peter Petersson wrote: >>> Things seems to be in a flux right now as I get a parse exception on 'geronimo-plugin-list' so I guess I have to wait with testing out plugins on a fresh build. I get back to you when this is out of the way. regards Peter P 23:44:02,710 INFO [PluginInstallerGBean] Attempting to download file:/home/ppe/.m2/repository/geronimo-plugins.xml 23:44:02,860 ERROR [PluginInstallerGBean] Unable to load repository configuration data org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'geronimo-plugin-list'. at org.apache.geronimo.system.plugin.PluginInstallerGBean$3.error(PluginInstallerGBean.java:1440) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) Peter Petersson wrote: > David Jencks wrote: > >> I finally got around to applying your roller plugin patch but I >> can't reproduce this either on jetty or tomcat. I'm on osx I >> wonder if its due to the different os >> > Nice :) > hmmm well I am on Linux and Hernan got this on a Windows XP box and > maybe osx is spared but there is clearly something wrong with my > environment or else the server is getting into a faulty state due to > the plugin modules I install (roller-tomcat, roller-themes) although > I doubt the later is the case ;), I will try investigate this a bit > more, will post my findings (if any) here but If you or anyone else > have some suggestions or hints on what may cause this let me know. > > I will do a svn update; mvn clean install; and go make some coffee > and try out the new build with different setups. > > regards > Peter P > >> thanks >> david jencks >> >> On Jan 14, 2008, at 2:28 AM, Peter Petersson wrote: >> >> >>> Anyone still getting this? >>> >>> On the first startup the server starts fine but every following >>> startup after a shutdown (or even reboot of comp) fails. >>> I have had this problem for some time now (2 weeks I think) and to >>> get around it I keep reinstalling the server but that's getting a >>> bit boring :). This is happening for me on new builds of 2.1. >>> The only thing I have done in between is installing the roller >>> plugin. >>> I have also tried startup with load="false" in config.xml on the >>> roller modules before startup (just in case the plugin would be >>> causing
[jira] Created: (GERONIMO-3755) application-1.2 schema does not exist
application-1.2 schema does not exist - Key: GERONIMO-3755 URL: https://issues.apache.org/jira/browse/GERONIMO-3755 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0.2 Environment: Mac OS X Tiger, Java 1.5 Reporter: Aurimas Valionis Priority: Blocker I want to create a plan for ear application and I follow the samples, there should be application-1.2 schema available on "http://geronimo.apache.org/xml/ns/j2ee/application-1.2"; but it is not there. Would you upload the schema? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [YOKO] Yoko web site
:) What does XBean and GShell do? Regards, Alan On Jan 16, 2008, at 5:18 PM, Jason Dillon wrote: Well there is this thing called HTML and you use it to make things called "pages" and then put them on a "web server"... :-P What do you want... Something backed up by confluence? Or static via svn? --jason -Original Message- From: "Alan D. Cabrera" <[EMAIL PROTECTED]> Date: Wed, 16 Jan 2008 16:41:30 To:Developers Geronimo Subject: [YOKO] Yoko web site I want to start creating the new Yoko website and wiki. How do I do this? Regards, Alan
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Thanks Matt. And congratulations Kevan. ++Vamsi On Jan 17, 2008 1:40 AM, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > Recently I have had several things change personally and I have found > it increasingly difficult to keep up with the Geronimo mailing lists > on a daily basis. As a result, I did some soul searching and decided > that my intentions to stay on top of Geronimo were good but my follow > through wasn't This was specifically in regard to being able to > respond to people on issues that I needed to do as PMC chair. > > I tendered my resignation to the Board earlier this week. There was > some discussion on the PMC list about a replacement and the PMC > unanimously approved Kevan Miller as my successor. The board just > approved this request so Kevan now has the mantle for Geronimo as the > PMC chair. > > It is with great pleasure that I announce that Kevan has accepted this > responsibility of PMC chair. The beauty is that Kevan has already > been doing most of the work of the PMC chair anyway and is the right > person going forward. Please give it up for Kevan Miller, VP, Apache > Geronimo! > > I'm still noodling with some performance work as time allows so I'm > not gone. I'll prolly continue to nag in my own unique way. > > Matt >
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Congrats Kevan & Thanks Matt. On Jan 17, 2008 1:40 AM, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > Recently I have had several things change personally and I have found > it increasingly difficult to keep up with the Geronimo mailing lists > on a daily basis. As a result, I did some soul searching and decided > that my intentions to stay on top of Geronimo were good but my follow > through wasn't This was specifically in regard to being able to > respond to people on issues that I needed to do as PMC chair. > > I tendered my resignation to the Board earlier this week. There was > some discussion on the PMC list about a replacement and the PMC > unanimously approved Kevan Miller as my successor. The board just > approved this request so Kevan now has the mantle for Geronimo as the > PMC chair. > > It is with great pleasure that I announce that Kevan has accepted this > responsibility of PMC chair. The beauty is that Kevan has already > been doing most of the work of the PMC chair anyway and is the right > person going forward. Please give it up for Kevan Miller, VP, Apache > Geronimo! > > I'm still noodling with some performance work as time allows so I'm > not gone. I'll prolly continue to nag in my own unique way. > > Matt > -- Thanks, Shiva
[jira] Resolved: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen resolved GERONIMO-3753. Resolution: Fixed > monitoring portlet is not up to date with dojo 1.0 > -- > > Key: GERONIMO-3753 > URL: https://issues.apache.org/jira/browse/GERONIMO-3753 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: monitoring >Affects Versions: 2.1 > Environment: windows >Reporter: Viet Hung Nguyen >Assignee: Viet Hung Nguyen >Priority: Trivial > Attachments: geronimo-3753.patch > > > I noticed that when a user clicks on a Graph's name, the graph does not > render correctly. I'm pretty sure it has something to do with the new version > of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new > version of dojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig reopened GERONIMO-3753: - > monitoring portlet is not up to date with dojo 1.0 > -- > > Key: GERONIMO-3753 > URL: https://issues.apache.org/jira/browse/GERONIMO-3753 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: monitoring >Affects Versions: 2.1 > Environment: windows >Reporter: Viet Hung Nguyen >Assignee: Viet Hung Nguyen >Priority: Trivial > Attachments: geronimo-3753.patch > > > I noticed that when a user clicks on a Graph's name, the graph does not > render correctly. I'm pretty sure it has something to do with the new version > of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new > version of dojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig resolved GERONIMO-3753. - Resolution: Fixed Patch Committed revision 612698. Great joerb viet. > monitoring portlet is not up to date with dojo 1.0 > -- > > Key: GERONIMO-3753 > URL: https://issues.apache.org/jira/browse/GERONIMO-3753 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: monitoring >Affects Versions: 2.1 > Environment: windows >Reporter: Viet Hung Nguyen >Assignee: Viet Hung Nguyen >Priority: Trivial > Attachments: geronimo-3753.patch > > > I noticed that when a user clicks on a Graph's name, the graph does not > render correctly. I'm pretty sure it has something to do with the new version > of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new > version of dojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[AsyncHttpClient] data collection & instrumentation
I'd like to propose changes to enable some basic stat collection and/or instrumentation to have visibility into performance of AHC. For a given AsyncHttpClient, one might want to know metrics like - total request count - total success count - total exception count - total timeout count - connection attempt count - connection failure count - connect time average - connection close count - average response time (as measured from the invocation time to having the response ready) - and others? Collecting these metrics should have little effect on the overall performance. There would be an API to access these stats. I was initially thinking of an IoFilter to consolidate these hooks, but I realize some of these metrics are not readily available to an IoFilter (e.g. connect-related numbers). It might be unavoidable to spread the instrumentation in a couple of places (IoHandler, ConnectFutureListener, etc.). Taking this one step further, one might think of callbacks or listeners for various key events such as connect complete, request sent, etc., so callers can provide instrumenting/logging code via event notification. However, I think this should be used judiciously as such injected code may cause havoc. Thoughts? Suggestions? Thanks, Sangjin
Re: [YOKO] Yoko web site
Well there is this thing called HTML and you use it to make things called "pages" and then put them on a "web server"... :-P What do you want... Something backed up by confluence? Or static via svn? --jason -Original Message- From: "Alan D. Cabrera" <[EMAIL PROTECTED]> Date: Wed, 16 Jan 2008 16:41:30 To:Developers Geronimo Subject: [YOKO] Yoko web site I want to start creating the new Yoko website and wiki. How do I do this? Regards, Alan
[YOKO] KEYS
I have removed all the keys but Rick's from the KEYS file since I do not recognize who they belong to. Yoko committers, please feel free to add your keys to this file. Regards, Alan
[YOKO] Yoko web site
I want to start creating the new Yoko website and wiki. How do I do this? Regards, Alan
Re: svn commit: r612439 [1/2] - in /geronimo/server/trunk: assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-tomcat6-javaee5/ plugins/clustering/ plugins/clustering/clustering/ plugins/clusterin
Thanks Gianny. More below... On Jan 16, 2008, at 3:42 PM, Gianny Damour wrote: On 17/01/2008, at 1:30 AM, Kevan Miller wrote: On Jan 16, 2008, at 7:48 AM, [EMAIL PROTECTED] wrote: Author: gdamour Date: Wed Jan 16 04:48:37 2008 New Revision: 612439 URL: http://svn.apache.org/viewvc?rev=612439&view=rev Log: Move farm related classes to new sub-project geronimo-farm. Add a new configuration "farming" and move farming related GBeans from the clustering config. to this new one. Also, by default this configuration is not started. Cool. Gianny, can you give us a bit of status about where you are with this? Looks like you're laying some groundwork for OpenEJB dependencies... Hi, David J. proposed a while back two clustering code/module rearrangements he was keen to have implemented before 2.1. With this commit, both of these rearrangements are now in. Right. Although I haven't looked at the specifics, I think this split is a really good one. I am now integration testing the OpenEJB clustering support and it appears I will need to do some minor adjustments. As part of the change, four sub-projects/dependencies are added: geronimo-openejb- clustering-wadi, geronimo-openejb-clustering-builder-wadi, openejb- clustering-wadi and openejb-clustering-builder-wadi. This structure mirrors the Jetty and Tomcat ones. I also think 2.1 is belated and should be cut as soon as possible. I will hold-on the OpenEJB commit till the creation of a 2.1 branch. Cool. If this branch isn't for another week or two, is that going to ok for you? I think we want to avoid creating branches/2.1 and then merging a bunch of fit-and-finish fixes between the branch and trunk... --kevan Thanks, Gianny Enhanced clustering support is really great to have. Want to understand what additional dependencies this is going to require. I think we're overdue for a 2.1 release. We have polish and a number of usability issues to work out in current trunk, prior to this. However, worried about also pushing in a bunch of new function is going to make this difficult... --kevan
[jira] Updated: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3754: -- Attachment: GERONIMO-3754.patch Updated patch with a fix to validatePlugin() code that checks if a plugin is already installed. Before, the validatePlugin() was checking if a plugin was running and therefore, plugins that were not running but installed were considered installable. > Username/password is ignored in PluginInstallerGBean > > > Key: GERONIMO-3754 > URL: https://issues.apache.org/jira/browse/GERONIMO-3754 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: general >Affects Versions: 2.1 >Reporter: Jarek Gawor > Attachments: GERONIMO-3754.patch > > > The username/password is ignored in PluginInstallerGBean in listPlugins() > function. That means, for example, that with plugin installer portlet I'm > unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo > as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3754: -- Attachment: (was: GERONIMO-3754.patch) > Username/password is ignored in PluginInstallerGBean > > > Key: GERONIMO-3754 > URL: https://issues.apache.org/jira/browse/GERONIMO-3754 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: general >Affects Versions: 2.1 >Reporter: Jarek Gawor > Attachments: GERONIMO-3754.patch > > > The username/password is ignored in PluginInstallerGBean in listPlugins() > function. That means, for example, that with plugin installer portlet I'm > unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo > as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3752) JACC principal-role mapping installation is too tied to our policy implementation.
[ https://issues.apache.org/jira/browse/GERONIMO-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3752. -- Resolution: Fixed The patch needed some tweaks, a better version committed in rev 612602. > JACC principal-role mapping installation is too tied to our policy > implementation. > -- > > Key: GERONIMO-3752 > URL: https://issues.apache.org/jira/browse/GERONIMO-3752 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.1 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1 > > Attachments: GERONIMO-3752.patch > > > We need a couple interfaces to avoid tying the installation of principal-role > mapping to our specific jacc implementation. Someone else might want to use > it with their jacc implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Thanx Matt. Congrats Kevan ! (the band is now playing *Hail to the Chief* ) Cheers Prasad On Jan 16, 2008 3:10 PM, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > Recently I have had several things change personally and I have found > it increasingly difficult to keep up with the Geronimo mailing lists > on a daily basis. As a result, I did some soul searching and decided > that my intentions to stay on top of Geronimo were good but my follow > through wasn't This was specifically in regard to being able to > respond to people on issues that I needed to do as PMC chair. > > I tendered my resignation to the Board earlier this week. There was > some discussion on the PMC list about a replacement and the PMC > unanimously approved Kevan Miller as my successor. The board just > approved this request so Kevan now has the mantle for Geronimo as the > PMC chair. > > It is with great pleasure that I announce that Kevan has accepted this > responsibility of PMC chair. The beauty is that Kevan has already > been doing most of the work of the PMC chair anyway and is the right > person going forward. Please give it up for Kevan Miller, VP, Apache > Geronimo! > > I'm still noodling with some performance work as time allows so I'm > not gone. I'll prolly continue to nag in my own unique way. > > Matt >
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Matt, Thanks for the great work you've done as the PMC Chair! Kevan, Congratulations on the new assignment! Cheers! Hernan Matt Hogstrom wrote: Recently I have had several things change personally and I have found it increasingly difficult to keep up with the Geronimo mailing lists on a daily basis. As a result, I did some soul searching and decided that my intentions to stay on top of Geronimo were good but my follow through wasn't This was specifically in regard to being able to respond to people on issues that I needed to do as PMC chair. I tendered my resignation to the Board earlier this week. There was some discussion on the PMC list about a replacement and the PMC unanimously approved Kevan Miller as my successor. The board just approved this request so Kevan now has the mantle for Geronimo as the PMC chair. It is with great pleasure that I announce that Kevan has accepted this responsibility of PMC chair. The beauty is that Kevan has already been doing most of the work of the PMC chair anyway and is the right person going forward. Please give it up for Kevan Miller, VP, Apache Geronimo! I'm still noodling with some performance work as time allows so I'm not gone. I'll prolly continue to nag in my own unique way. Matt
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Congratulations Kevan. :) Sangjin On 1/16/08, Kevan Miller <[EMAIL PROTECTED]> wrote: > > > On Jan 16, 2008, at 3:10 PM, Matt Hogstrom wrote: > > > Recently I have had several things change personally and I have > > found it increasingly difficult to keep up with the Geronimo mailing > > lists on a daily basis. As a result, I did some soul searching and > > decided that my intentions to stay on top of Geronimo were good but > > my follow through wasn't This was specifically in regard to being > > able to respond to people on issues that I needed to do as PMC chair. > > > > I tendered my resignation to the Board earlier this week. There was > > some discussion on the PMC list about a replacement and the PMC > > unanimously approved Kevan Miller as my successor. The board just > > approved this request so Kevan now has the mantle for Geronimo as > > the PMC chair. > > > > It is with great pleasure that I announce that Kevan has accepted > > this responsibility of PMC chair. The beauty is that Kevan has > > already been doing most of the work of the PMC chair anyway and is > > the right person going forward. Please give it up for Kevan Miller, > > VP, Apache Geronimo! > > > > I'm still noodling with some performance work as time allows so I'm > > not gone. I'll prolly continue to nag in my own unique way. > > Matt, > You're leaving some big shoes to fill. You've done a great job the > past 14 months. Thanks! > > Now about those performance numbers... ;-) > > --kevan >
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
On Jan 16, 2008, at 12:10 PM, Matt Hogstrom wrote: Recently I have had several things change personally and I have found it increasingly difficult to keep up with the Geronimo mailing lists on a daily basis. As a result, I did some soul searching and decided that my intentions to stay on top of Geronimo were good but my follow through wasn't This was specifically in regard to being able to respond to people on issues that I needed to do as PMC chair. I tendered my resignation to the Board earlier this week. There was some discussion on the PMC list about a replacement and the PMC unanimously approved Kevan Miller as my successor. The board just approved this request so Kevan now has the mantle for Geronimo as the PMC chair. It is with great pleasure that I announce that Kevan has accepted this responsibility of PMC chair. The beauty is that Kevan has already been doing most of the work of the PMC chair anyway and is the right person going forward. Please give it up for Kevan Miller, VP, Apache Geronimo! I'm still noodling with some performance work as time allows so I'm not gone. I'll prolly continue to nag in my own unique way. Thanks Matt for all the great work. Congrats Kevan! I know that you're going to make a great chair! Regards, Alan
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Thanks for your terrific service in this position Matt! Congratulations and thank you for stepping up to the plate Kevan! Joe Matt Hogstrom wrote: Recently I have had several things change personally and I have found it increasingly difficult to keep up with the Geronimo mailing lists on a daily basis. As a result, I did some soul searching and decided that my intentions to stay on top of Geronimo were good but my follow through wasn't This was specifically in regard to being able to respond to people on issues that I needed to do as PMC chair. I tendered my resignation to the Board earlier this week. There was some discussion on the PMC list about a replacement and the PMC unanimously approved Kevan Miller as my successor. The board just approved this request so Kevan now has the mantle for Geronimo as the PMC chair. It is with great pleasure that I announce that Kevan has accepted this responsibility of PMC chair. The beauty is that Kevan has already been doing most of the work of the PMC chair anyway and is the right person going forward. Please give it up for Kevan Miller, VP, Apache Geronimo! I'm still noodling with some performance work as time allows so I'm not gone. I'll prolly continue to nag in my own unique way. Matt
[jira] Updated: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3753: --- Patch Info: [Patch Available] > monitoring portlet is not up to date with dojo 1.0 > -- > > Key: GERONIMO-3753 > URL: https://issues.apache.org/jira/browse/GERONIMO-3753 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: monitoring >Affects Versions: 2.1 > Environment: windows >Reporter: Viet Hung Nguyen >Assignee: Viet Hung Nguyen >Priority: Trivial > Attachments: geronimo-3753.patch > > > I noticed that when a user clicks on a Graph's name, the graph does not > render correctly. I'm pretty sure it has something to do with the new version > of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new > version of dojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3753: --- Attachment: geronimo-3753.patch > monitoring portlet is not up to date with dojo 1.0 > -- > > Key: GERONIMO-3753 > URL: https://issues.apache.org/jira/browse/GERONIMO-3753 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: monitoring >Affects Versions: 2.1 > Environment: windows >Reporter: Viet Hung Nguyen >Assignee: Viet Hung Nguyen >Priority: Trivial > Attachments: geronimo-3753.patch > > > I noticed that when a user clicks on a Graph's name, the graph does not > render correctly. I'm pretty sure it has something to do with the new version > of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new > version of dojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3754: -- Attachment: GERONIMO-3754.patch Proposed patch for this issue. > Username/password is ignored in PluginInstallerGBean > > > Key: GERONIMO-3754 > URL: https://issues.apache.org/jira/browse/GERONIMO-3754 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: general >Affects Versions: 2.1 >Reporter: Jarek Gawor > Attachments: GERONIMO-3754.patch > > > The username/password is ignored in PluginInstallerGBean in listPlugins() > function. That means, for example, that with plugin installer portlet I'm > unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo > as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
Username/password is ignored in PluginInstallerGBean Key: GERONIMO-3754 URL: https://issues.apache.org/jira/browse/GERONIMO-3754 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: general Affects Versions: 2.1 Reporter: Jarek Gawor The username/password is ignored in PluginInstallerGBean in listPlugins() function. That means, for example, that with plugin installer portlet I'm unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
On Jan 16, 2008, at 3:10 PM, Matt Hogstrom wrote: Recently I have had several things change personally and I have found it increasingly difficult to keep up with the Geronimo mailing lists on a daily basis. As a result, I did some soul searching and decided that my intentions to stay on top of Geronimo were good but my follow through wasn't This was specifically in regard to being able to respond to people on issues that I needed to do as PMC chair. I tendered my resignation to the Board earlier this week. There was some discussion on the PMC list about a replacement and the PMC unanimously approved Kevan Miller as my successor. The board just approved this request so Kevan now has the mantle for Geronimo as the PMC chair. It is with great pleasure that I announce that Kevan has accepted this responsibility of PMC chair. The beauty is that Kevan has already been doing most of the work of the PMC chair anyway and is the right person going forward. Please give it up for Kevan Miller, VP, Apache Geronimo! I'm still noodling with some performance work as time allows so I'm not gone. I'll prolly continue to nag in my own unique way. Matt, You're leaving some big shoes to fill. You've done a great job the past 14 months. Thanks! Now about those performance numbers... ;-) --kevan
Re: svn commit: r612439 [1/2] - in /geronimo/server/trunk: assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-tomcat6-javaee5/ plugins/clustering/ plugins/clustering/clustering/ plugins/clusterin
On 17/01/2008, at 1:30 AM, Kevan Miller wrote: On Jan 16, 2008, at 7:48 AM, [EMAIL PROTECTED] wrote: Author: gdamour Date: Wed Jan 16 04:48:37 2008 New Revision: 612439 URL: http://svn.apache.org/viewvc?rev=612439&view=rev Log: Move farm related classes to new sub-project geronimo-farm. Add a new configuration "farming" and move farming related GBeans from the clustering config. to this new one. Also, by default this configuration is not started. Cool. Gianny, can you give us a bit of status about where you are with this? Looks like you're laying some groundwork for OpenEJB dependencies... Hi, David J. proposed a while back two clustering code/module rearrangements he was keen to have implemented before 2.1. With this commit, both of these rearrangements are now in. I am now integration testing the OpenEJB clustering support and it appears I will need to do some minor adjustments. As part of the change, four sub-projects/dependencies are added: geronimo-openejb- clustering-wadi, geronimo-openejb-clustering-builder-wadi, openejb- clustering-wadi and openejb-clustering-builder-wadi. This structure mirrors the Jetty and Tomcat ones. I also think 2.1 is belated and should be cut as soon as possible. I will hold-on the OpenEJB commit till the creation of a 2.1 branch. Thanks, Gianny Enhanced clustering support is really great to have. Want to understand what additional dependencies this is going to require. I think we're overdue for a 2.1 release. We have polish and a number of usability issues to work out in current trunk, prior to this. However, worried about also pushing in a bunch of new function is going to make this difficult... --kevan
[ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Recently I have had several things change personally and I have found it increasingly difficult to keep up with the Geronimo mailing lists on a daily basis. As a result, I did some soul searching and decided that my intentions to stay on top of Geronimo were good but my follow through wasn't This was specifically in regard to being able to respond to people on issues that I needed to do as PMC chair. I tendered my resignation to the Board earlier this week. There was some discussion on the PMC list about a replacement and the PMC unanimously approved Kevan Miller as my successor. The board just approved this request so Kevan now has the mantle for Geronimo as the PMC chair. It is with great pleasure that I announce that Kevan has accepted this responsibility of PMC chair. The beauty is that Kevan has already been doing most of the work of the PMC chair anyway and is the right person going forward. Please give it up for Kevan Miller, VP, Apache Geronimo! I'm still noodling with some performance work as time allows so I'm not gone. I'll prolly continue to nag in my own unique way. Matt
[jira] Commented: (GERONIMO-3581) Default security relam name in ContextManager
[
https://issues.apache.org/jira/browse/GERONIMO-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559648#action_12559648
]
Jarek Gawor commented on GERONIMO-3581:
---
There are two (related) issues here.
1) Forgetting about OpenEJB for a moment, ContextManager.login() creates
LoginContext. And LoginContext will throw NPE if the security realm is null. So
we could either add a null check to ContextManager.login() or pass a default
security realm name.
2) With OpenEJB, OpenEJB uses GeronimoSecurityService to login. That class has
two login functions. First, the one without security realm parameter passes
"OpenEJB" as a security realm. That security realm is not configured anywhere
(as far as I can tell) and therefore if that method is called the
authentication will always fail. The second GeronimoSecurityService.login()
function just calls ContextManager.login(). And it also does not perform null
check of the security realm. I guess we could add the default security realm
there but it won't address 1) if there is another path to
ContextManager.login().
> Default security relam name in ContextManager
> -
>
> Key: GERONIMO-3581
> URL: https://issues.apache.org/jira/browse/GERONIMO-3581
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: security
>Affects Versions: 2.0.x, 2.1
>Reporter: Jarek Gawor
>
> ContextManager.login() should use a default security realm name if user did
> not pass a security realm. Null security realm will cause an exception in
> LoginContext. Right now becuase of this issue, a standalone ejb client must
> set a custom property ("openejb.authentication.realmName") in order for
> authentication to succeed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [SECURITY] Potential vulnerability in Jetty servlet container
I've updated this notice with a better location from which to obtain the jetty-6.1.7.jar (see below). Joe Bohn wrote: The Geronimo project has learned of a security vulnerability in the Jetty servlet container (6.1.5) included in Geronimo. If you use a Jetty configuration of Geronimo you may be affected by the vulnerability. This vulnerability impacts Jetty configurations of Geronimo 2.0.1 and 2.0.2. For specific information regarding the Jetty vulnerability, see http://www.kb.cert.org/vuls/id/553235 The problem is related to the processing of URLs which contain multiple consecutive forward slash (/) characters that are handled incorrectly (for example . http://foo//../bar). If your system is susceptible to attacks using such URLs we recommend that you filter these URLs using an application firewall or reverse proxy server. Alternatively, you can upgrade your Geronimo Jetty server image to utilize the corrected Jetty 6.1.7 jar: - Obtain a jetty-6.1.7.jar from http://repo1.maven.org/maven2/org/mortbay/jetty/jetty/6.1.7/jetty-6.1.7.jar - Stop your Geronimo Jetty server image - copy jetty-6.1.7.jar to /repository/org/mortbay/jetty/jetty/6.1.7/jetty-6.1.7.jar - remove the jetty 6.1.5 jar: /repository/org/mortbay/jetty/jetty/6.1.5/jetty-6.1.5.jar - start the Geronimo Jetty server. The server will now be using the 6.1.7 Jetty jar. This vulnerability will be fixed in the next release of Geronimo (2.0.3 and/or 2.1) which will include Jetty 6.1.7 correcting the vulnerability.
[jira] Closed: (GERONIMODEVTOOLS-258) GEP by default can no longer deploy to all targets returned from the deployment manager
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-258. -- Resolution: Fixed Fixed in revision 612208 and verified by Tomasz > GEP by default can no longer deploy to all targets returned from the > deployment manager > --- > > Key: GERONIMODEVTOOLS-258 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-258 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.0 >Reporter: Tim McConnell >Assignee: Tim McConnell > Fix For: 2.1.0 > > > Now that the Geronimo 2.1 server supports clustering multiple targets will > likely be returned from any getTargets() method invoked on the deployment > manager. The GEP should use only the first target, which is the default > configuration store and which is explicitly configured by users. Otherwise, > the artifacts will get deployed to the master-repository, the > cluster-repository, and the local repository which is obviously incorrect and > will result in deployment errors. > Thanks to Gianny for this very useful bit of information -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: MailGBean/JNDI problem on Harmony
Sorry for disturbing, I've just found out the cause for this issue - I
had one extra property in config.xml. If namingFactoryInitial
specification is removed, and namingFactoryUrlPkgs specification is
retained, the problem is resolved, and Geronimo starts fine on Harmony.
Vasily
-Original Message-
From: Zakharov, Vasily M [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 16, 2008 8:53 PM
To: dev@geronimo.apache.org
Subject: MailGBean/JNDI problem on Harmony
Hi, all,
I'm found a problem with MailGBean on Harmony due to of JNDI
configuration, and I'm asking for help to understand how to deal with
that problem. The problem would occur on any JDK lacking Sun
implementation of JNDI RMI Registry provider
(com.sun.jndi.rmi.registry.RegistryContext). The problem occurs at
startup and looks as follows:
java.lang.IllegalArgumentException: Cannot bind to RMI Registry object
that is neither Remote nor Reference nor Referenceable
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.getStateTo
Bind(RegistryContext.java:618)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:266)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:280)
at javax.naming.InitialContext.bind(InitialContext.java:411)
at
org.apache.geronimo.mail.MailGBean.doStart(MailGBean.java:385)
The investigation shows the following difference of MailGBean code
operation on Sun and Harmony:
On Sun, the InitialContext.getEnvironment() is empty, and
InitialContext.lookup("") returns
org.apache.geronimo.gjndi.GlobalContextGBean, and
InitialContext.getNameParser("") returns
org.apache.xbean.naming.context.ContextUtil$SimpleNameParser.
On Harmony, this works much differently -
InitialContext.getEnvironment() contains the JNDI properties specified
in config.xml, and InitialContext.lookup("") returns
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext, and
InitialContext.getNameParser("") returns
org.apache.harmony.jndi.provider.rmi.registry.AtomicNameParser.
This causes the error above.
I had to specify the respective JNDI properties in config.xml for
JMXConnector to start normally, as follows:
org.apache.harmony.jndi.provider.rmi.registr
y.RegistryContextFactory
org.apache.harmony.jndi.provider
rmi://${ServerHostname}:${NamingPort
+ PortOffset}
Probably this is wrong to configure JNDI this way, as it overrides
Geronimo internal naming mechanisms?
Maybe org.apache.geronimo.gjndi.GlobalContextGBean needs to be tweaked
to find the proper JNDI RMI Registry provider by other means than
standard JNDI properties?
I'd be happy to hear any ideas, considerations or suggestions on this
issue.
Thank you very much!
Vasily Zakharov
Intel ESSD
---
[jira] Assigned: (GERONIMO-3725) The progress bar shown during Geronimo start up needs to be updated
[ https://issues.apache.org/jira/browse/GERONIMO-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3725: - Assignee: Jarek Gawor > The progress bar shown during Geronimo start up needs to be updated > --- > > Key: GERONIMO-3725 > URL: https://issues.apache.org/jira/browse/GERONIMO-3725 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 2.1 >Reporter: Jarek Gawor >Assignee: Jarek Gawor > Attachments: GERONIMO-3725.patch > > > The progress bar shown during Geronimo start up (when executing 'geronimo > run') needs to be updated. Currently, the size of the bar depends on the > number of modules installed. That is, if N number of modules are installed > the bar is of size N. So if lots of modules are installed, the bar might wrap > around the screen. > I think we should replace this bar with a bar based on the percentage of > total Geronimo startup (what is currently displayed just as a number). The > new bar would not display the detailed information as the existing bar (i.e. > which modules successfully started up or failed) but would not suffer from > the problem explained above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
progress bar at Geronimo startup
Folks, A few times before I've ran into some problems with the progress bar displayed at Geronimo startup as I had a lot of modules installed. I described the problem in https://issues.apache.org/jira/browse/GERONIMO-3725. I also just attached to the bug report a patch with a new and simpler progress bar hat does not suffer from the same problem as the existing bar but at the same time it does not it display the same detail info as the existing bar. I tired to explain this difference in the bug report. So, any thoughts/objections on replacing the existing progress bar with the one I attached to the bug report? Thanks, Jarek
[jira] Commented: (GERONIMO-3725) The progress bar shown during Geronimo start up needs to be updated
[ https://issues.apache.org/jira/browse/GERONIMO-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559624#action_12559624 ] Jarek Gawor commented on GERONIMO-3725: --- To clarify, the existing bar can visually indicate (by displaying different characters) if a given module is starting, started or failed as the server starts up. But the new bar (in the patch) is just displays the percentage of the total server startup (no per-module info). > The progress bar shown during Geronimo start up needs to be updated > --- > > Key: GERONIMO-3725 > URL: https://issues.apache.org/jira/browse/GERONIMO-3725 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 2.1 >Reporter: Jarek Gawor > Attachments: GERONIMO-3725.patch > > > The progress bar shown during Geronimo start up (when executing 'geronimo > run') needs to be updated. Currently, the size of the bar depends on the > number of modules installed. That is, if N number of modules are installed > the bar is of size N. So if lots of modules are installed, the bar might wrap > around the screen. > I think we should replace this bar with a bar based on the percentage of > total Geronimo startup (what is currently displayed just as a number). The > new bar would not display the detailed information as the existing bar (i.e. > which modules successfully started up or failed) but would not suffer from > the problem explained above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-257) Errors when publishing to the Geronimo 2.1 server using the 2.1 version of the GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-257. -- Resolution: Fixed Fix provided in revision 611355 and verified by Tomasz. > Errors when publishing to the Geronimo 2.1 server using the 2.1 version of > the GEP > -- > > Key: GERONIMODEVTOOLS-257 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-257 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.0 >Reporter: Tim McConnell >Assignee: Tim McConnell > Fix For: 2.1.0 > > > As reported by Tomasz Manaz, the following error occurs when publishing to > the Geronimo 2.1 server using the 2.1 version of the GEP > http://www.nabble.com/file/p14730930/gep-deploy-error.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3725) The progress bar shown during Geronimo start up needs to be updated
[ https://issues.apache.org/jira/browse/GERONIMO-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3725: -- Attachment: GERONIMO-3725.patch Attached a patch with a new progress bar. > The progress bar shown during Geronimo start up needs to be updated > --- > > Key: GERONIMO-3725 > URL: https://issues.apache.org/jira/browse/GERONIMO-3725 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 2.1 >Reporter: Jarek Gawor > Attachments: GERONIMO-3725.patch > > > The progress bar shown during Geronimo start up (when executing 'geronimo > run') needs to be updated. Currently, the size of the bar depends on the > number of modules installed. That is, if N number of modules are installed > the bar is of size N. So if lots of modules are installed, the bar might wrap > around the screen. > I think we should replace this bar with a bar based on the percentage of > total Geronimo startup (what is currently displayed just as a number). The > new bar would not display the detailed information as the existing bar (i.e. > which modules successfully started up or failed) but would not suffer from > the problem explained above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[YOKO] Heads up
I'm going to remove the WS that went to CXF tonight. Regards, Alan
MailGBean/JNDI problem on Harmony
Hi, all,
I'm found a problem with MailGBean on Harmony due to of JNDI
configuration, and I'm asking for help to understand how to deal with
that problem. The problem would occur on any JDK lacking Sun
implementation of JNDI RMI Registry provider
(com.sun.jndi.rmi.registry.RegistryContext). The problem occurs at
startup and looks as follows:
java.lang.IllegalArgumentException: Cannot bind to RMI Registry object
that is neither Remote nor Reference nor Referenceable
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.getStateTo
Bind(RegistryContext.java:618)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:266)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:280)
at javax.naming.InitialContext.bind(InitialContext.java:411)
at
org.apache.geronimo.mail.MailGBean.doStart(MailGBean.java:385)
The investigation shows the following difference of MailGBean code
operation on Sun and Harmony:
On Sun, the InitialContext.getEnvironment() is empty, and
InitialContext.lookup("") returns
org.apache.geronimo.gjndi.GlobalContextGBean, and
InitialContext.getNameParser("") returns
org.apache.xbean.naming.context.ContextUtil$SimpleNameParser.
On Harmony, this works much differently -
InitialContext.getEnvironment() contains the JNDI properties specified
in config.xml, and InitialContext.lookup("") returns
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext, and
InitialContext.getNameParser("") returns
org.apache.harmony.jndi.provider.rmi.registry.AtomicNameParser.
This causes the error above.
I had to specify the respective JNDI properties in config.xml for
JMXConnector to start normally, as follows:
org.apache.harmony.jndi.provider.rmi.registr
y.RegistryContextFactory
org.apache.harmony.jndi.provider
rmi://${ServerHostname}:${NamingPort
+ PortOffset}
Probably this is wrong to configure JNDI this way, as it overrides
Geronimo internal naming mechanisms?
Maybe org.apache.geronimo.gjndi.GlobalContextGBean needs to be tweaked
to find the proper JNDI RMI Registry provider by other means than
standard JNDI properties?
I'd be happy to hear any ideas, considerations or suggestions on this
issue.
Thank you very much!
Vasily Zakharov
Intel ESSD
---
[jira] Updated: (GERONIMODEVTOOLS-206) Error while deploying EAR to running server Geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gennadibereshnoi updated GERONIMODEVTOOLS-206: -- Priority: Critical (was: Major) > Error while deploying EAR to running server Geronimo 2.0.1 > -- > > Key: GERONIMODEVTOOLS-206 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-206 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0.0 > Environment: Geronimo 2.0.1 > WTP 2.0 + GEP 2.0 >Reporter: Tomasz Mazan >Assignee: Tim McConnell >Priority: Critical > Fix For: 2.1.0 > > > Exception on deploy > Distribution of configuration failed. See log for details. > java.io.FileNotFoundException: > C:\DEV\IDE\eclipse-wtp-2.0\workspace\.metadata\.plugins\org.apache.geronimo.st.core\server_13.09.07_14_454\FonBsaCore.zip > (File not found) > org.apache.geronimo.common.DeploymentException: > java.io.FileNotFoundException: > C:\DEV\IDE\eclipse-wtp-2.0\workspace\.metadata\.plugins\org.apache.geronimo.st.core\server_13.09.07_14_454\FonBsaCore.zip > (File not found) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:121) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) > at > org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at > org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) > at > com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) > at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) > at > javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1408) > at > javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) > at > javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1245) > at java.security.AccessController.doPrivileged(Native Method) > at > javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1348) > at > javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:782) > at sun.reflect.GeneratedMethodAccessor223.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) > at sun.rmi.transport.Transport$1.run(Transport.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:149) > at > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) > at java.lang.Thread.run(Thread.java:595) > Caused by: java.io.FileNotFoundException: > C:\DEV\IDE\eclipse-wtp-2.0\workspace\.metadata\.plugins\org.apache.geronimo.st.core\server_13.09.07_14_454\FonBsaCore.zip > (File not found) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at > org.apache.geronimo.deployment.util.DeploymentUtil.copyFile(DeploymentUtil.java:92) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:118) > ... 34 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issu
[jira] Commented: (GERONIMODEVTOOLS-206) Error while deploying EAR to running server Geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559577#action_12559577 ] gennadibereshnoi commented on GERONIMODEVTOOLS-206: --- same by using "geronimo-maven-plugin" >@WIN@>>mvn -e geronimo:deploy [INFO] [geronimo:deploy] [INFO] Using artifact based module archive(s)... [INFO] Distributing module artifact: ... log4j:WARN No appenders could be found for logger (org.apache.geronimo.deployment.plugin.factories.BaseDep log4j:WARN Please initialize the log4j system properly. Deployer operation failed: Cound not open module file: c:\TMP\GERONIMO.###\2001\geronimo-deployer4332.tmpd org.apache.geronimo.common.DeploymentException: Cound not open module file: c:\TMP\GERONIMO.###\2001\geron at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:223) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:126) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$100(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.(Unknown Source) at java.util.jar.JarFile.(Unknown Source) at java.util.jar.JarFile.(Unknown Source) at org.apache.geronimo.deployment.util.DeploymentUtil.createJarFile(DeploymentUtil.java:201) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:221) ... 36 more [WARNING] Ignoring failure ! [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 minute 14 seconds [INFO] Finished at: Wed Jan 16 16:25:47 CET 2008 [INFO] Final Memory: 9M/17M [INFO] [EMAIL PROTECTED] mvn -e geronimo:deploy [INFO] [geronimo:deploy] [INFO] Using artifact based module archive(s)... [INFO] Distributing module artifact: /home/maven/.m2/repository/com/oxseed/saas/oxseed.orderstorage.app/1.0.6/oxseed.orderstorage.app-1.0.6.ear with plan /home/maven/orderstorage/oxseed
[jira] Assigned: (GSHELL-58) Layout command aliases should be allowed to reference relative command paths for targets
[
https://issues.apache.org/jira/browse/GSHELL-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GSHELL-58:
--
Assignee: Jason Warner (was: Jason Dillon)
> Layout command aliases should be allowed to reference relative command paths
> for targets
>
>
> Key: GSHELL-58
> URL: https://issues.apache.org/jira/browse/GSHELL-58
> Project: GShell
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 1.0-alpha-1
>Reporter: Jason Dillon
>Assignee: Jason Warner
> Fix For: 1.0-alpha-2
>
>
> For example:
> {code}
> ...
>
> remote
>
>
> rsh
> gshell-remote:rsh
>
>
> rsh-server
> gshell-remote:rsh-server
>
>
> rshd
> rsh-server
>
>
>
>
>
> {code}
> In this example, the {{remote/rshd}} command alias really wants to point to
> {{remote/rsh-server}} but current alias target resolve works from the layout
> root.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-54) Allow relative (../ and ./) as well as absolute paths (/foo/bar) to resolve as expected in the layout manager
[ https://issues.apache.org/jira/browse/GSHELL-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner reassigned GSHELL-54: -- Assignee: Jason Warner (was: Jason Dillon) > Allow relative (../ and ./) as well as absolute paths (/foo/bar) to resolve > as expected in the layout manager > - > > Key: GSHELL-54 > URL: https://issues.apache.org/jira/browse/GSHELL-54 > Project: GShell > Issue Type: Bug > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.0-alpha-1 >Reporter: Jason Dillon >Assignee: Jason Warner > Fix For: 1.0-alpha-2 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3605) GShell-ize deployer commands
[ https://issues.apache.org/jira/browse/GERONIMO-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3605. --- Resolution: Fixed All the standard deployer commands are now ported to/accessible via GShell. However, I'm not sure about removing the standard command line tools just yet as GShell still seems to be evolving. > GShell-ize deployer commands > > > Key: GERONIMO-3605 > URL: https://issues.apache.org/jira/browse/GERONIMO-3605 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.1 >Reporter: David Jencks >Assignee: Jarek Gawor > Fix For: 2.1 > > > make the cli deployer commands such as list-plugins accessible through gshell > (and then remove the standalone deployer) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2946) Add StAX specs into Geronimo Specs project
[ https://issues.apache.org/jira/browse/GERONIMO-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor closed GERONIMO-2946. - Resolution: Fixed Closing as this work was done by Matt a while ago. > Add StAX specs into Geronimo Specs project > -- > > Key: GERONIMO-2946 > URL: https://issues.apache.org/jira/browse/GERONIMO-2946 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: specs >Affects Versions: 2.0-M4 > Environment: All >Reporter: Matt Hogstrom >Assignee: Matt Hogstrom > > The StAX API 1.0.1 at Codehaus has introduced a fix for a problem on > javax.xml.stream.XMLOutputFactory. The fix in the API is not compatible with > the RI and was introduced in an attempt to fix this problem as outlined in > JSR 173 MR1. This MR was rejected by Sun and as such the recently released > API is no longer compatible with the Java EE 5 RI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
monitoring portlet is not up to date with dojo 1.0 -- Key: GERONIMO-3753 URL: https://issues.apache.org/jira/browse/GERONIMO-3753 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Trivial I noticed that when a user clicks on a Graph's name, the graph does not render correctly. I'm pretty sure it has something to do with the new version of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new version of dojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3694) gsh script in javaee5 server assemblies is not marked executable
[ https://issues.apache.org/jira/browse/GERONIMO-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3694. --- Resolution: Fixed Committed a fix to trunk (revision 612494). All files in the bin/ directory will now be marked as executable except the .bat files. > gsh script in javaee5 server assemblies is not marked executable > - > > Key: GERONIMO-3694 > URL: https://issues.apache.org/jira/browse/GERONIMO-3694 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.1 >Reporter: Kevan Miller >Assignee: Jarek Gawor > Fix For: 2.1 > > > 'gsh' is not marked as executable. there seem to be different mechanisms for > the different assemblies. > looks like gsh is executable in framework/minimal assemblies (in fact all > files are executable in the bin directory of these assemblies). Better if > only shell scripts were marked executable... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3694) gsh script in javaee5 server assemblies is not marked executable
[ https://issues.apache.org/jira/browse/GERONIMO-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3694: - Assignee: Jarek Gawor (was: Jason Dillon) > gsh script in javaee5 server assemblies is not marked executable > - > > Key: GERONIMO-3694 > URL: https://issues.apache.org/jira/browse/GERONIMO-3694 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.1 >Reporter: Kevan Miller >Assignee: Jarek Gawor > Fix For: 2.1 > > > 'gsh' is not marked as executable. there seem to be different mechanisms for > the different assemblies. > looks like gsh is executable in framework/minimal assemblies (in fact all > files are executable in the bin directory of these assemblies). Better if > only shell scripts were marked executable... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
2.1 Release -- Banging the drum
All, This note is a bit overdue (it's been a distracting start to the New Year for me). Time, IMO, for us to get focused on our 2.1 release. As David Jencks has pointed out. We need to start cleaning out the 2.1 Jiras. It looks like I've got several open that have been fixed, either by additional development activities or redundant jira's. First step is to take a look at Jira's that you've created and make sure they are still valid and if you think it's important that they be fixed for 2.1. We also need to be taking a close look at our current functionality. Make sure things are working the way we want them to... Especially need to cast a critical eye on our the usability aspects of the new 2.1. Along the way, will be great if we can start pulling docs together. I started running tests last night. Right away, I'm noticing little things like warning messages being sent to STDOUT, etc. I'll start registering problem areas that I'm seeing. I'd like to set a target of 2 weeks for reviewing and fixing problems. After that would start the branching, final tck, and packaging work. If we feel this might negatively impact post-2.1 development activities. We can consider creating a 2.1 branch sooner... Thoughts? --kevan
[jira] Closed: (GERONIMO-3069) Rework AJAX style console screens to work on Safari
[ https://issues.apache.org/jira/browse/GERONIMO-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3069. --- > Rework AJAX style console screens to work on Safari > --- > > Key: GERONIMO-3069 > URL: https://issues.apache.org/jira/browse/GERONIMO-3069 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0-M7 >Reporter: Jay D. McHugh >Assignee: Jay D. McHugh > Fix For: 2.0.2, 2.1 > > Attachments: geronimo-3069-jmx-1.patch > > > Some of the newer console screens do not work properly in Safari. > Try to rewrite the javascript code so that it works on safari. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3069) Rework AJAX style console screens to work on Safari
[ https://issues.apache.org/jira/browse/GERONIMO-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3069. - Resolution: Fixed Fix Version/s: 2.0.2 2.1 Either Dojo or Safari (or both) made changes that resolved the display problems. > Rework AJAX style console screens to work on Safari > --- > > Key: GERONIMO-3069 > URL: https://issues.apache.org/jira/browse/GERONIMO-3069 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0-M7 >Reporter: Jay D. McHugh >Assignee: Jay D. McHugh > Fix For: 2.1, 2.0.2 > > Attachments: geronimo-3069-jmx-1.patch > > > Some of the newer console screens do not work properly in Safari. > Try to rewrite the javascript code so that it works on safari. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r612439 [1/2] - in /geronimo/server/trunk: assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-tomcat6-javaee5/ plugins/clustering/ plugins/clustering/clustering/ plugins/clusterin
On Jan 16, 2008, at 7:48 AM, [EMAIL PROTECTED] wrote: Author: gdamour Date: Wed Jan 16 04:48:37 2008 New Revision: 612439 URL: http://svn.apache.org/viewvc?rev=612439&view=rev Log: Move farm related classes to new sub-project geronimo-farm. Add a new configuration "farming" and move farming related GBeans from the clustering config. to this new one. Also, by default this configuration is not started. Cool. Gianny, can you give us a bit of status about where you are with this? Looks like you're laying some groundwork for OpenEJB dependencies... Enhanced clustering support is really great to have. Want to understand what additional dependencies this is going to require. I think we're overdue for a 2.1 release. We have polish and a number of usability issues to work out in current trunk, prior to this. However, worried about also pushing in a bunch of new function is going to make this difficult... --kevan
Re: Geronimo v2.1 documentation
On Jan 10, 2008, at 5:14 PM, Hernan Cunico wrote: Hi All, some time ago I started to put together some topics for Geronimo v2.1 documentation. I tried to focus on the biggest new things we are offering now, topics we didn't have before and now we need to start from scratch. The Geronimo v2.1 documentation space is already available here http://cwiki.apache.org/GMOxDOC21/documentation.html The initial TOC includes: * Configuration changes * Deployment ** Deployment plan creator * Geronimo Administration Console enhancements * GShell * Monitoring * Pluggable console * Plugin infrastructure enhancements * RELEASE-NOTES-2.1.TXT * Sample applications * Security * Tooling * What's new? Each of these pages already contain a few lines with some initial thoughts. Need your input for adding topics to this list as well as developing them. There might be things we already had in 2.0x but we didn't cover it in the doc, pls need your comments on that as well. I think I'm finish covering *Deployment plan creator*, will do a refresh later on as new code gets in. I also created this "place holder" http://cwiki.apache.org/GMOxPMGT/geronimo-v21-list-of-functions-status.html under *Apache Geronimo Project Management* on the wiki so we can keep track there the features we have ready for prime time and those that are not so ready ;-) I could definitively use that info to build up a new set of docs, would also help users to see where we are at. Hernan, Thanks for this. Time to start pulling these docs together to prepare for release. It can't all be generated by Hernan. We'll need to chip in... --kevan
[jira] Issue Comment Edited: (GERONIMO-1775) Internationalization of the Admin Console
[
https://issues.apache.org/jira/browse/GERONIMO-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559487#action_12559487
]
akulshre edited comment on GERONIMO-1775 at 1/16/08 6:02 AM:
---
could you have used the i18N facilities defined by PLT.6.2 Portlet Resource
Bundle and PLT.21.10 Resource Bundles in the JSR 168 Specification?
e.g. somehing like the following in portlet.xml and use standard keywords
javax.portlet.title, javax.portlet.short-title, and
javax.portlet.keywords.
{code:xml}
...
zh
com.foo.myApp.QuotePortlet
Stock Quote Portlet
Stock
finance,stock market
...
{code}
was (Author: akulshre):
could you have used the i18N facilities defined by PLT.6.2 Portlet
Resource Bundle and PLT.21.10 Resource Bundles in the JSR 168 Specification?
e.g. somehing like this in portlet.xml:
{code:xml}
...
Stock Quote Portlet
Stock
finance,stock market
com.foo.myApp.QuotePortlet
...
{code}
> Internationalization of the Admin Console
> -
>
> Key: GERONIMO-1775
> URL: https://issues.apache.org/jira/browse/GERONIMO-1775
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
>Reporter: Yeray Cabrera Santana
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.1
>
> Attachments: chinese_console.JPG, GERONIMO-1775-1.patch,
> GERONIMO-1775-2.patch, GERONIMO-1775.patch, screen1.GIF
>
>
> Provide the internationalization of the administration console so it can be
> translated to different languages. This is a feature I would like to
> contribute with.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2712) LDAP editing capability from Admin Console
[ https://issues.apache.org/jira/browse/GERONIMO-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hernan Cunico updated GERONIMO-2712: Affects Version/s: (was: 2.0-M5) (was: 2.0-M2) (was: 2.0-M4) (was: 1.2) (was: 2.0-M3) (was: 2.0-M1) Wish List Moved to wish list. The idea was not to duplicate other projects functionality but to expand some basic capabilities, just for practical purposes. If a Geronimo LDAP plugin is available and Geronimo also provides a way to browse the LDAP server then it would be great to have the ability to perform some very basic functions directly from the Geronimo Administration Console (like importing an ldif). > LDAP editing capability from Admin Console > -- > > Key: GERONIMO-2712 > URL: https://issues.apache.org/jira/browse/GERONIMO-2712 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: Wish List >Reporter: Hernan Cunico > Fix For: Wish List > > > Currently from the console we are able to just view the content of the LDAP > server but rely on external applications to actually import data to this DB. > As a new feature and as an improvement from the usability perspective it > would be great if we can provide a method to load the *.ldif* files directly > form the console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-1775) Internationalization of the Admin Console
[
https://issues.apache.org/jira/browse/GERONIMO-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559487#action_12559487
]
Anita Kulshreshtha commented on GERONIMO-1775:
--
could you have used the i18N facilities defined by PLT.6.2 Portlet Resource
Bundle and PLT.21.10 Resource Bundles in the JSR 168 Specification?
e.g. somehing like this in portlet.xml:
{code:xml}
...
Stock Quote Portlet
Stock
finance,stock market
com.foo.myApp.QuotePortlet
...
{code}
> Internationalization of the Admin Console
> -
>
> Key: GERONIMO-1775
> URL: https://issues.apache.org/jira/browse/GERONIMO-1775
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
>Reporter: Yeray Cabrera Santana
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.1
>
> Attachments: chinese_console.JPG, GERONIMO-1775-1.patch,
> GERONIMO-1775-2.patch, GERONIMO-1775.patch, screen1.GIF
>
>
> Provide the internationalization of the administration console so it can be
> translated to different languages. This is a feature I would like to
> contribute with.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2614) LDAP Viewer portlet should warn you is the LDAP support plugin is not installed and/or started
[ https://issues.apache.org/jira/browse/GERONIMO-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hernan Cunico closed GERONIMO-2614. --- Resolution: Fixed Fix Version/s: 2.1 There was an error first time you accessed the portlet, it seemed it was looking for a local LDAP by default. This is fixed in 2.1 trunk. Closing this issue. > LDAP Viewer portlet should warn you is the LDAP support plugin is not > installed and/or started > -- > > Key: GERONIMO-2614 > URL: https://issues.apache.org/jira/browse/GERONIMO-2614 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2 > Environment: this is for revision r480769 >Reporter: Hernan Cunico > Fix For: 2.1 > > > LDAP support is available only via plugins now. The LDAP Viewer portlet shown > an error pop-up window stating there is a connection error. > The portlet should either know the plugin is not installed or the portlet > itself should be provided as part of the LDAP support plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3707) use Executor rather than ExecutorService for thread pools that are passed into AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3707. -- > use Executor rather than ExecutorService for thread pools that are passed > into AsyncHttpClient > -- > > Key: GERONIMO-3707 > URL: https://issues.apache.org/jira/browse/GERONIMO-3707 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: AsyncHttpClient >Affects Versions: 1.x >Reporter: Sangjin Lee >Assignee: Rick McGuire >Priority: Minor > > Currently AsyncHttpClient takes an ExecutorService as an argument for the > thread pool that gets passed into the SocketConnector constructor. Also, it > uses ExecutorService as the type for the event thread pool which is passed to > the ExecutorFilter. > In both cases, Mina APIs actually take simply Executor. Therefore, it is > possible to simply pass in Executor rather than ExecutorService. This is > very helpful because the caller may need to retrofit existing thread pool > implementations. Implementing Executor is considerably easier than > ExecutorService. > One implication of this change is that AsyncHttpClient will no longer "own" > and manage the thread pool that gets passed in. I believe that is also OK as > the caller can (and perhaps should) handle the lifecycle of a thread pool > that it created. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3706) support for proxy
[ https://issues.apache.org/jira/browse/GERONIMO-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3706. -- > support for proxy > - > > Key: GERONIMO-3706 > URL: https://issues.apache.org/jira/browse/GERONIMO-3706 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: AsyncHttpClient >Affects Versions: 1.x >Reporter: Sangjin Lee > Attachments: proxy_poc.patch > > > Proxy support is a critical feature for HTTP clients. I'd like to have > AsyncHttpClient support proxy. The following would be considered as the > basic features: > - Enabling connecting through proxies for http and https targets > - Exclusion (domains that should not go through proxies) > - Allowing proxy related configuration on AsyncHttpClient > - Support for proxy authentication, at least for Basic authentication (and > perhaps Digest too?) > There are things like SOCKS support, etc., but the above will be a good > start. Thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3717) Queries provided through the URL argument to HttpRequestMessage get lost
[
https://issues.apache.org/jira/browse/GERONIMO-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick McGuire closed GERONIMO-3717.
--
> Queries provided through the URL argument to HttpRequestMessage get lost
>
>
> Key: GERONIMO-3717
> URL: https://issues.apache.org/jira/browse/GERONIMO-3717
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: AsyncHttpClient
>Affects Versions: 1.x
>Reporter: Sangjin Lee
>Assignee: Rick McGuire
> Attachments: 3717.patch
>
>
> There are two different ways of providing a query parameter to
> HttpRequestMessage, and both ways should be supported. One way is through
> the URL argument in the HttpRequestMessage constructor, and the other is via
> HttpRequestMessage.setParameter(). However, if you supply a query parameter
> via the former, it gets lost, and is not sent.
> For example, suppose you want to make a request to
> "http://some_host/path?foo=bar";. One way to construct the request object is
> HttpRequestMessage msg = new HttpRequestMessage(new
> URL("http://some_host/path?foo=bar";, cb);
> The other way is
> HttpRequestMessage msg = new HttpRequestMessage(new
> URL("http://some_host/path";), cb);
> msg.setParameter("foo", "bar");
> However, the encoder (HttpRequestEncoder) uses only URL.getPath() (which
> returns only "/path" in this example) to form the request line. The correct
> method it should have used is URL.getFile() (which returns "/path?foo=bar" in
> this example).
> It is apparent that AHC expects to support both usages, as there is code that
> tries to add any parameter in addition to any existing queries already in the
> URL, except it's not done quite right.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3711) NPE if connection fails and callback is not provided
[ https://issues.apache.org/jira/browse/GERONIMO-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3711. -- > NPE if connection fails and callback is not provided > > > Key: GERONIMO-3711 > URL: https://issues.apache.org/jira/browse/GERONIMO-3711 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: AsyncHttpClient >Affects Versions: 1.x >Reporter: Sangjin Lee >Priority: Minor > Attachments: 3711.patch > > > Callbacks are now optional as it is no longer the only way to handle the > result from asynchronous requests. In the implementation, the callbacks are > now included as part of completing the ResponseFuture. Thus, as the > operations complete, the callbacks should be invoked (if set) inside > ResponseFuture. > If connection fails, the connect future object gets invoked, but the current > connect future (AsyncHttpClient.FutureListener) contains direct calls to > AsyncHttpClientCallback.onException(). There are two problems with this: (1) > callbacks may be null, so this may result in NPE, and (2) future will not be > completed if connection fails. > The solution is to properly set the exception on the ResponseFuture, and that > will take care of the callback invocation as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent
[ https://issues.apache.org/jira/browse/GERONIMO-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3686. -- > AsyncHttpClient does not reuse connection even if connections are persistent > > > Key: GERONIMO-3686 > URL: https://issues.apache.org/jira/browse/GERONIMO-3686 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: AsyncHttpClient >Affects Versions: 1.x >Reporter: Sangjin Lee >Assignee: Rick McGuire > Attachments: 3686.patch > > > Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is > opened, even though connections may be kept alive per HTTP spec. If > connections are kept open, they should be reused for more requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3689) should provide additional thread pool to isolate running of the callback & event notification
[ https://issues.apache.org/jira/browse/GERONIMO-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3689. -- > should provide additional thread pool to isolate running of the callback & > event notification > - > > Key: GERONIMO-3689 > URL: https://issues.apache.org/jira/browse/GERONIMO-3689 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: AsyncHttpClient >Affects Versions: 1.x >Reporter: Sangjin Lee > Attachments: 3689.patch > > > The mina 1.1 documentation recommends disabling the default ThreadModel, as > well as additionally providing an ExecutorFilter to isolate code that runs > when events are notified (IoHandler) and thus in our case callback code. > The default ThreadModel should be disabled by > SocketConnectorConfig.setThreadModel(ThreadModel.MANUAL), and there should be > an option of supplying a thread pool at the end of the filter chain. > Please see http://mina.apache.org/configuring-thread-model.html for more > discussion... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default
[ https://issues.apache.org/jira/browse/GERONIMO-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3638. -- > should allow URL encoding with custom encoding charset other than the default > - > > Key: GERONIMO-3638 > URL: https://issues.apache.org/jira/browse/GERONIMO-3638 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: AsyncHttpClient >Affects Versions: 1.x >Reporter: Sangjin Lee >Assignee: Rick McGuire > Attachments: 3638.patch > > > Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the > query string. However, applications may want to use a different encoding > than the machine default charset; e.g. UTF-8. It needs to provide a way to > specify an encoding that AHC should use to encode the query string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3703) should allow custom SSL context for AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3703. -- > should allow custom SSL context for AsyncHttpClient > --- > > Key: GERONIMO-3703 > URL: https://issues.apache.org/jira/browse/GERONIMO-3703 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: AsyncHttpClient >Affects Versions: 1.x >Reporter: Sangjin Lee >Priority: Critical > Attachments: 3703.patch, test.patch > > > Currently the SSLContext that's used to do https cannot be configured or > customized. One needs to be able to create and pass in custom SSLContext to > be able to use its own cert directory, keystore file, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3617) AsyncHttpClient should support retries on connection failures
[ https://issues.apache.org/jira/browse/GERONIMO-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3617. -- > AsyncHttpClient should support retries on connection failures > - > > Key: GERONIMO-3617 > URL: https://issues.apache.org/jira/browse/GERONIMO-3617 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: AsyncHttpClient >Affects Versions: 1.x >Reporter: Sangjin Lee >Assignee: Rick McGuire > Attachments: 3617.patch > > > AsyncHttpClient should provide a way to support retries if initial connection > attempts fail. There should be a configuration where connection retries are > enabled and also the maximum number of attempts is specified. If these are > set, connection attempts should be retried. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3618) when redirected via status code 30x, the original query is incorrectly appended to the location
[ https://issues.apache.org/jira/browse/GERONIMO-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3618. -- > when redirected via status code 30x, the original query is incorrectly > appended to the location > --- > > Key: GERONIMO-3618 > URL: https://issues.apache.org/jira/browse/GERONIMO-3618 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: AsyncHttpClient >Affects Versions: 1.x >Reporter: Sangjin Lee >Assignee: Rick McGuire > Attachments: HttpIoHandler.patch, patch.zip > > > If you're redirected via status code 30x (302, 301, ...), the code that > handles following redirects (HttpIoHandler.messageRecieved()) tries to append > the original query from the first request to the URL obtained from the > Location header of the response. This is incorrect per HTTP specification. > The spec says the value of the Location header is an absoluteURI which is a > full URL that includes the proper query if any: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30. The query > from the original request should not be part of the second URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3751) callbacks may not be completed when caller uses future.get() too to complete request handling
[ https://issues.apache.org/jira/browse/GERONIMO-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-3751. Resolution: Fixed Committed revision 612422. Thanks Sangjin! > callbacks may not be completed when caller uses future.get() too to complete > request handling > - > > Key: GERONIMO-3751 > URL: https://issues.apache.org/jira/browse/GERONIMO-3751 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: AsyncHttpClient >Affects Versions: 1.x >Reporter: Sangjin Lee >Priority: Minor > Attachments: GERONIMO-3751.patch > > > Currently the callback methods from AsyncHttpClientCallback get called > *after* the response future object is completed. I think this causes a > subtle bug that may prevent the callback methods from being completed if one > uses both the callback and the future. > For example, consider the following case: > ResponseFuture future = client.invoke(..., callback); // callback is not null > HttpResponseMessage response = future.get(); // this blocks until future is > complete > Since the future is completed before the callback is invoked, the caller > thread in this case gets unblocked before the callback is called. If the > caller thread goes away, then there is possibility that the callback may not > be completed or may not even be called, depending on the timing. > This strikes me as a bug... I propose we invoke the callback first and then > complete the future so the callbacks are guaranteed to be completed even if > future is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3749) Global session cache can cause multiple client instances to reuse incorrectly configured connections.
[ https://issues.apache.org/jira/browse/GERONIMO-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-3749. Resolution: Fixed Committed revision 612419. > Global session cache can cause multiple client instances to reuse incorrectly > configured connections. > - > > Key: GERONIMO-3749 > URL: https://issues.apache.org/jira/browse/GERONIMO-3749 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: AsyncHttpClient >Reporter: Rick McGuire >Priority: Minor > Attachments: 3749.patch > > > The current connection reuse mechanism relies on a single global session > class per process (or really, per class loader that loads the ahc code) to > store all of the i/o sessions indexed by host/port. Since the selection is > made based totally on host and port, it is possible that one ahc client could > end up reusing a connection created by a client with a completely different > connection configuration. Caching should be implemented using a > instance-based cache rather than a single global session cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How to change KeyStore type?
I think we should add PKCS12 to Geronimo. If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose what keystore to use? We can specify keystore in configs or choose type from available on current VM. SY, Alexey 2008/1/15, Zakharov, Vasily M <[EMAIL PROTECTED]>: > Hi, all, > > Is there a way to change the geronimo-default keystore > from JKS to, say, PKCS12 without patching the > org.apache.geronimo.security.keystore.FileKeystore* classes? > > That way of patching sources is suggested at GERONIMO-2015, > and it works, but it's probably not the best idea. > > I see the reasons of not making PKCS12 a default keystore type, > but what about making it possible to change keystore type > using config.xml, without source recompilation? > > I've browsed through the configuration options of geronimo-security > gbean, a found no way for that. Should I provide a patch for > that to be possible, would that be appropriate? > > Thank you! > > Vasily Zakharov > Intel ESSD > > > > --- > >
[jira] Commented: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type
[ https://issues.apache.org/jira/browse/GERONIMO-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559433#action_12559433 ] Alexey Petrenko commented on GERONIMO-2015: --- If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose? We can specify keystore in configs or choose type from available on current VM. > Let's replace JKS to PKCS12 key store type > -- > > Key: GERONIMO-2015 > URL: https://issues.apache.org/jira/browse/GERONIMO-2015 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: security >Reporter: Nikolay Chugunov > Fix For: Wish List > > Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java, > jksToPKCS12.patch, keystore > > > Hello > Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key > store and Geronimo may not work on non-Sun VMs. > To fix this problem I have created the patch for Geronimo sources. > In brief the patch (attached) replaces JKS to PKCS12 key store type in > configurations files. > PKCS12 format of key store file is not java-specific and can be created and > read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in > Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is > Sun specific key store and does not exist in Bouncy Castle. > Also it is needed to replace JKS to PKCS12 keystore file (attached) to > assemblies/j2ee-tomcat-server/src/var/security, > assemblies/j2ee-installer/src/var/security, > assemblies/j2ee-jetty-server/src/var/security directories. Key store file was > generating using JKSToPKCS12 class (attached). This class transfers key and > certificate of Geronimo from JKS to PKCS12. > After I apply this patch to Geronimo 1.0 sources and build Geronimo I can > login to Geronimo console over https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [AsyncHttpClient] order of Future completion and callback invocation
Sangjin Lee wrote: Currently the callback methods from AsyncHttpClientCallback get called *after* the response future object is completed. I think this causes a subtle bug that may prevent the callback methods from being completed if one uses both the callback and the future. For example, consider the following case: ResponseFuture future = client.invoke(..., callback); // callback is not null HttpResponseMessage response = future.get(); // this blocks until future is complete Since the future is completed before the callback is invoked, the caller thread in this case gets unblocked before the callback is called. If the caller thread goes away, then there is possibility that the callback may not be completed or may not even be called, depending on the timing. This strikes me as a bug... I propose we invoke the callback first and then complete the future so the callbacks are guaranteed to be completed even if future is used. What do you think? I'll open a JIRA issue if you guys agree this is a bug. Yes, I agree. If the callback is used, then we should ensure that it gets called appropriately. Thanks, Sangjin
Re: [YOKO]
I'm +1 for 1.0 release too. I've reviewed japitool results for ORB area of Harmony and I have not find any differences which are result of 1.4 compatibility of Yoko. So it looks like there is no difference for Harmony in this case. But yes, Harmony is 1.5 (however it has 1.6 branch :) and any 1.5 compatible code is acceptable for it. 2008/1/15, Lars Kühne <[EMAIL PROTECTED]>: > On Jan 14, 2008 8:05 PM, Alan D. Cabrera wrote: > > > > On Jan 14, 2008, at 4:35 AM, Rick McGuire wrote: > > > > > What cleanup steps need to be taken with the yoko code now that it's > > > been made a subproject in Geronimo? The first obvious one would be > > > to remove the non-core components from the trunk. The second would > > > be to remove the "incubating" from the version names. > > > > Agreed > > +1 > > Is JDK 1.4 still a given or has geronimo upgraded it's JDK dependency > to 1.5 since yoko entered the incubator? We shouldn't change the > required JDK in a point release, so this seems like a good time to > revisit this decision. > > > > The current code was never made into an official Yoko release. > > > Should we attempt to get this out as an official v1 release as soon > > > as the basic cleanup is completed? > > > > I think that some people had some concerns about a release but I think > > that they were more focused on proper documentation and releasing a > > well rounded product. > > That was me. My concern wasn't so much about user docs but developer > level documentation, see the "Answer this question..." yoko issues in > jira. Those questions mostly about being able to attract new > developers. > > > It's my opinion that it's ok to release so long > > as the code is good enough. With that said, I would like to make a > > 1.0 release. > > Yes, the code could use some cleanup but it does pass certification > and we can always improve things later, in another release. > > This of course assumes that we don't have to pay too much attention to > backward compatibility. Does each follow-up version have to be a > drop-in replacement of the first 1.0 release? Or is it OK to change > ORB properties and such, as long as the changes are documented in the > release notes (which is what I hope, but I don't know the requirements > of Geronimo and Harmony)? It's OK from Harmony point of view. SY, Alexey
[jira] Updated: (GERONIMO-3752) JACC principal-role mapping installation is too tied to our policy implementation.
[ https://issues.apache.org/jira/browse/GERONIMO-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-3752: --- Attachment: GERONIMO-3752.patch I think this patch should work fine but I'll have to try it out tomorrow. > JACC principal-role mapping installation is too tied to our policy > implementation. > -- > > Key: GERONIMO-3752 > URL: https://issues.apache.org/jira/browse/GERONIMO-3752 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.1 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1 > > Attachments: GERONIMO-3752.patch > > > We need a couple interfaces to avoid tying the installation of principal-role > mapping to our specific jacc implementation. Someone else might want to use > it with their jacc implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3752) JACC principal-role mapping installation is too tied to our policy implementation.
JACC principal-role mapping installation is too tied to our policy implementation. -- Key: GERONIMO-3752 URL: https://issues.apache.org/jira/browse/GERONIMO-3752 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 We need a couple interfaces to avoid tying the installation of principal-role mapping to our specific jacc implementation. Someone else might want to use it with their jacc implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3069) Rework AJAX style console screens to work on Safari
[ https://issues.apache.org/jira/browse/GERONIMO-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559399#action_12559399 ] Joseph Leong commented on GERONIMO-3069: Hey there Jay, Just confirming as well, everything seems to look/work fine on OSX 10.5.1 : Safari 3.0.4 (5523.10) for the trunk -Joseph Leong > Rework AJAX style console screens to work on Safari > --- > > Key: GERONIMO-3069 > URL: https://issues.apache.org/jira/browse/GERONIMO-3069 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0-M7 >Reporter: Jay D. McHugh >Assignee: Jay D. McHugh > Attachments: geronimo-3069-jmx-1.patch > > > Some of the newer console screens do not work properly in Safari. > Try to rewrite the javascript code so that it works on safari. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
