[jira] Resolved: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller resolved GERONIMO-3746. Resolution: Fixed Fix Version/s: 2.1 Applied patch from Joe. Thanks! Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Kevan Miller Fix For: 2.1 Attachments: GERONIMO-3746-2.patch, GERONIMO-3746-3.patch, GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565459#action_12565459 ] Joseph Leong commented on GERONIMO-3746: Update: Basic-Auth screen was being caused by the output buffer being flushed on the page include. Turning off flushing fixed issue. Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Kevan Miller Attachments: GERONIMO-3746-2.patch, GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3746: --- Attachment: GERONIMO-3746-3.patch Patch 3: *Fixes Basic-Auth Issue *If an Exception Is Thrown, An Indicating Message Will Appear As Well As A Back Button To Bring User Back To Plugin Home. Issues Remaining: CSRF Issue that occurs when a user tries to initiate the install process a second time around Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Kevan Miller Attachments: GERONIMO-3746-2.patch, GERONIMO-3746-3.patch, GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565547#action_12565547 ] Joseph Leong commented on GERONIMO-3746: Update: Added an indicator message on the progress page to list an exception, if one is caught and a back button to bring the user back to the plugin install home page. Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Kevan Miller Attachments: GERONIMO-3746-2.patch, GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565556#action_12565556 ] jleong edited comment on GERONIMO-3746 at 2/4/08 3:00 PM: Patch 3: *Fixes Basic-Auth Issue *If an Exception Is Thrown, An Indicating Message Will Appear As Well As A Back Button To Bring User Back To Plugin Home. Issues Remaining: CSRF Issue that occurs when a user tries to initiate the install process a second time around *Note, Applying Patch 3 will also apply the changes from Patch 2, thus making Patch 2 unnecessary to apply with this. was (Author: jleong): Patch 3: *Fixes Basic-Auth Issue *If an Exception Is Thrown, An Indicating Message Will Appear As Well As A Back Button To Bring User Back To Plugin Home. Issues Remaining: CSRF Issue that occurs when a user tries to initiate the install process a second time around Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Kevan Miller Attachments: GERONIMO-3746-2.patch, GERONIMO-3746-3.patch, GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564732#action_12564732 ] Joseph Leong commented on GERONIMO-3746: The continue form page isn't resolving the CRSF issue, will explicitly handle this with a new session pairing. Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Attachments: GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564806#action_12564806 ] Joseph Leong commented on GERONIMO-3746: Update: Wrapped up results page to display the summary correctly. Having the Done button bring you back to index page of plugin installer instead of viewplugindownload page. Tackling CRSF issue next. Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Attachments: GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3746: --- Attachment: GERONIMO-3746.patch Additions in this patch: Fixed results summary, NPE, Redirect page at Done to the index screen. -Joe Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Attachments: GERONIMO-3746.patch, GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3746: --- Attachment: (was: GERONIMO-3746.patch) Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Attachments: GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3746: --- Attachment: GERONIMO-3746-2.patch Patch 2: *Null Pointer Exception Fixed at ContinueForm. *Summary Page of Results is Now Compatible with ArrayConfigs *Aesthetic, Buttons renamed.. to support multi-plugin *Done Button At End Links Back To Index Page As Opposed to the ViewPlugin Page. Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Attachments: GERONIMO-3746-2.patch, GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reassigned GERONIMO-3746: -- Assignee: Kevan Miller (was: Joseph Leong) Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Kevan Miller Attachments: GERONIMO-3746-2.patch, GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564350#action_12564350 ] Joseph Leong commented on GERONIMO-3746: Update: Getting close! The configIds array is now successfully passing to the DSHandler ActionAfterView. The previous issue was request.getParameterValues was returning a string to the array's memory reference... and i can't make any use of that in java. So i discovered looping through setting the the same hidden fields allows the getParameterValue to create the string[] in a usable form. Last piece getting the (DownloadResults) results from ProgressMonitor and patching up some small type issues with the configIdarray and bingo we'll have the results page and everything in the plugin installer will be good to go. -Joseph Leong Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3746: --- Attachment: GERONIMO-3746.patch This patch is not complete, but up for review to help pipeline the process for gathering opinions for revisions. The following patch will take care of the following: -GERONIMO-2480, 3778, 3777,3746's Gui Issue -Array support for configIds -At the end of the installation the page is now submitting to 'ContinueForm' Remaining Issues: -Passing the results variable to the DownloadStatus handler so it can generate the summary page of what has been installed. -A side effect of fixing the issue listed above may take care of the CRSF issue. Quirks: Jira 3746, regarding the progress bar gui, the bar will not fill at some instances when the file being downloaded is so small that it can be captured in one network burst. This is an improvement that might be considered in future implementation - but is not function critical. Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Attachments: GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3746: --- Patch Info: [Patch Available] Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Attachments: GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564504#action_12564504 ] David Jencks commented on GERONIMO-3746: I applied the patch in rev 617243 with a couple of minor changes to eliminate a NPE I don't know if its due to the problems with DownloadResults but after the progress bar page I was taken to a start the plugin page which wasn't relevant because the plugin had already been started. Pushing the button took me back to the choose plugins to install page which also seems odd... I think I'd prefer to go back to the first plugins page where you choose whether to install more plugins, export plugins, or assemble a server. Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Attachments: GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564532#action_12564532 ] Jarek Gawor commented on GERONIMO-3746: --- Btw, I just added PluginInstallerGBean.checkOnInstall(Object key, boolean remove) function to PluginInstallerGBean so you should be able to use this method to get the DownloadResults from any place without passing the DownloadResults around in the session (committed in revision 617267). Just make sure to call PluginInstallerGBean.checkOnInstall(key, true) somewhere at the end to remove the DownloadResults from the cache. In all other places use PluginInstallerGBean.checkOnInstall(key, false). Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Attachments: GERONIMO-3746.patch When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563118#action_12563118 ] Joseph Leong commented on GERONIMO-3746: Update; This JIRA will now consolidate the progresses of JIRAS: GERONIMO-3778, GERONIMO-3788, GERONIMO-3781 due to the fact that these issues occur in several overlapping files. Thanks! Joseph Leong Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563030#action_12563030 ] Joseph Leong commented on GERONIMO-3746: In the upcoming patch: A check has been added to update the message / bar in the event results.isFinished() was returned true on the first poll. In addition, the getCurrentFilePercent is reflective of the progress of each individual file and not of the overall progress so the problem was not polling each individual progress fast enough to catch the '100%'. Polling speed increased slightly to catch the progress for the really small dependency files. Another check implemented at the end to fill the progress bar before redirecting to continue form. Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561978#action_12561978 ] Joseph Leong commented on GERONIMO-3746: Update: The progress bar isn't updating because the thread delay is set at an interval that isn't sampling the progress fast enough. Another factor occurring is that some of the plugins / dependencies we are downloading is so small that the bandwidth burst can grab it in one shot.. so there is no appearance of an incremental download. After the burst of this download, the download poller will grab a percent value of 0 (technically -1) immediately because it is querying the next file. Thus, the progress bar appearance for a lot of small files will seem as though nothing is downloading. In effect of this, i will be increasing the sampling time and implementing a small aesthetic 250-500millisecond delay after the '100' values so the user can see a full bar. Some issues that will arise because of this, if two files are queried and downloaded sequentially under 250-500ms it won't do a double lapse of a full progress bar. Another issue occurring is that when a plugin fails to install for whatever reason (missing file .. ) it throws an exception which doesn't lead for a proper exit, so the next time someone goes into the plugin installer it will flag the CSRF attack because of a session mismatch. I will open a new Jira for this. One last issue, after everything is downloaded and installed. Expecting to submit a patch shortly -Joseph Leong Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562111#action_12562111 ] Jarek Gawor commented on GERONIMO-3746: --- Maybe that's what you mean by a small aesthetic 250-500millisecond delay after the '100' values but I think the key is to always update the bar (and maybe other info) to 100% (when the installation was successful) whether the while(!results.isFinished()) loop executes or not. Changing the loop delay will make the bar fill up nicer but it won't fix the problem especially when results.isFinished() returns true on the very first time. So I'm not sure we need to change the loop delay as long as we add code outside of the loop to update the bar accordingly. Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559883#action_12559883 ] Joseph Leong commented on GERONIMO-3746: Update: So it may appear that part of the UI process is interfering with properly allowing the installation of a second plugin or following plugins. The first plugin attempt installs.. (although not properly updating the UI with the progress bar). In that process something causes request.isRequestedSessionIdValid() or request.isRequestedSessionIdFromCookie() to invalidate. The side of effect of this is [BATCH] in the DWR files stopping the installation of any plugins in that 'session' because it believes its a CSRF attack. Current direction i'm heading, resolving why the sessions are getting invalidated or consolidate our ajax implementations and move from DWR to DOJO. Still need to research a bit on DOJO and DWR to make sure this effort is possible. Thoughts? Thanks, Joseph Leong Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559883#action_12559883 ] jleong edited comment on GERONIMO-3746 at 1/17/08 2:08 AM: - Update: So it may appear that part of the UI process is interfering with properly allowing the installation of a second plugin or following plugins (from the console side). The first plugin attempt installs.. (although not properly updating the UI with the progress bar). In that process something causes request.isRequestedSessionIdValid() or request.isRequestedSessionIdFromCookie() to invalidate. The side of effect of this is [BATCH] in the DWR files stopping the installation of any plugins in that 'session' because it believes its a CSRF attack. Current direction i'm heading, resolving why the sessions are getting invalidated or consolidate our ajax implementations and move from DWR to DOJO. Still need to research a bit on DOJO and DWR to make sure this effort is possible. Thoughts? Thanks, Joseph Leong was (Author: jleong): Update: So it may appear that part of the UI process is interfering with properly allowing the installation of a second plugin or following plugins. The first plugin attempt installs.. (although not properly updating the UI with the progress bar). In that process something causes request.isRequestedSessionIdValid() or request.isRequestedSessionIdFromCookie() to invalidate. The side of effect of this is [BATCH] in the DWR files stopping the installation of any plugins in that 'session' because it believes its a CSRF attack. Current direction i'm heading, resolving why the sessions are getting invalidated or consolidate our ajax implementations and move from DWR to DOJO. Still need to research a bit on DOJO and DWR to make sure this effort is possible. Thoughts? Thanks, Joseph Leong Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3746) Plugin Progress Bar Not Updating
Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Plugin progress
Hi David, I have taken a stab at converting the servlet-examples and welcome configs to plugins. I have committed the code. Please give it a looksy. Better to catch any mistakes now before I go full steam ahead. Cheers Prasad On 10/1/07, David Jencks [EMAIL PROTECTED] wrote: On Oct 1, 2007, at 3:21 PM, Prasad Kashyap wrote: Does this list of problems still exist ? see comments inline Cheers Prasad On 9/11/07, David Jencks [EMAIL PROTECTED] wrote: I've now updated enough of the configs so we can see if we can assemble them into a server. It would be great if some one else could take a look at some of the remaining ones, list at the end of this email. To get your own list of un-cleaned-up configs build g, fire it up, and run search-plugins from the command line deployer: the no category ones aren't done yet. this list of uncategorized plugins that need attention is still valid. To provide a more reasonable sized testbed for assembling servers out of plugins I also shrank geronimo-framework to the minimum possible size: rmi-naming plus enough security to enable the command line deployer to connect to it. So, while some parts of plugin installation work, overall it doesn't. I keep seeing plugin installation pull in the wrong version of jars and cars and sometimes not find jars that are present in the local maven repo. Here are the problems I've noted so far, in order of discovery: 1. While reviewing config poms I saw some suspicious dependencies. Axis and Axis2 depend on openejb which subverts any attempt to run axis web services on a minimal server. The openejb-deployer requires openejb to be running which subverts any attempt to deploy offline while another server is running on the same machine (port conflicts). I think this is entirely resolved by now. 2. Figuring out which repository to look in doesn't work yet. While what is specified in the geronimo-plugin.xml and geronimo-plugins.xml does appear to be honored, using these isn't compatible with developing and testing plugins, since while a plugin is being worked on you want to use only your local repo but after its published you don't (unless perhaps its is hooked up to some kind of maven proxy) I wonder if having a default repo configured in the plugin installer system would work, or perhaps merging the repos at the end of geronimo-plugins.xml with those in each geronimo-plugin.xml. this is less of an immediate issue, I added the remote maven central repo in and now most things are found, but the problem of moving from I'm developing this on my machine to its published at this repo remains and I don't have any good ideas. 3. version resolution appears to have some serious problems. I think pretty much all of the geronimo-plugin.xmls contain versions for every jar (something I'm hoping to change) but I ran into a lot of problems. First most of the artifacts got resolved to the 2.0.1 released artifacts which didn't work because the car files didn't have valid geronimo-plugin.xmls in them. After I removed all my 2.0.1 artifacts things were slightly better until I got to something that wouldn't resolve at all, xbean-reflect 3.2-SNAPSHOT. The jar is in my local repo but for some reason it wasn't found. Most or all of these problems went away when I added maven central repo in. The problems were mostly caused by missing maven- metadata.xml files: this prevented finding snapshots or resolving dependencies that lacked a version. 4. I am doubting more and more that the current requires and obsoletes data are appropriate. For instance, most of the web apps require jetty (or tomcat, pick your flavor). IMO this is the wrong idea. If I want to install one of these web apps, it should install the web server if it's not already present. What I think is more appropriate would be if I'm trying to install a jetty web app and tomcat is installed it should complain: if no other web server is installed then it should install jetty for me. I still think these are highly questionable. 5. Trying to extract information about what went wrong is really hard and unpleasant. maybe I got used to this one :-) 6. With the CTS configs that happen to be on my machine, there are 93. This is a lot to wade through. We need a better way of organizing them, at least on the command line. Perhaps providing a list of categories to pick from, then the plugins from that category, would be more manageable. Also a deploy this from this maven repo command would be good: this might exist but I haven't found it yet. I think that's related to the install-plugin command :-) Better categorization would still be helpful. hope this helps david jencks thanks david jencks no category Geronimo Configs :: Welcome app Jetty 8 : (2.1-SNAPSHOT) Geronimo Configs :: Unavailable Client
Re: Plugin progress
Does this list of problems still exist ? Cheers Prasad On 9/11/07, David Jencks [EMAIL PROTECTED] wrote: I've now updated enough of the configs so we can see if we can assemble them into a server. It would be great if some one else could take a look at some of the remaining ones, list at the end of this email. To get your own list of un-cleaned-up configs build g, fire it up, and run search-plugins from the command line deployer: the no category ones aren't done yet. To provide a more reasonable sized testbed for assembling servers out of plugins I also shrank geronimo-framework to the minimum possible size: rmi-naming plus enough security to enable the command line deployer to connect to it. So, while some parts of plugin installation work, overall it doesn't. I keep seeing plugin installation pull in the wrong version of jars and cars and sometimes not find jars that are present in the local maven repo. Here are the problems I've noted so far, in order of discovery: 1. While reviewing config poms I saw some suspicious dependencies. Axis and Axis2 depend on openejb which subverts any attempt to run axis web services on a minimal server. The openejb-deployer requires openejb to be running which subverts any attempt to deploy offline while another server is running on the same machine (port conflicts). 2. Figuring out which repository to look in doesn't work yet. While what is specified in the geronimo-plugin.xml and geronimo-plugins.xml does appear to be honored, using these isn't compatible with developing and testing plugins, since while a plugin is being worked on you want to use only your local repo but after its published you don't (unless perhaps its is hooked up to some kind of maven proxy) I wonder if having a default repo configured in the plugin installer system would work, or perhaps merging the repos at the end of geronimo-plugins.xml with those in each geronimo-plugin.xml. 3. version resolution appears to have some serious problems. I think pretty much all of the geronimo-plugin.xmls contain versions for every jar (something I'm hoping to change) but I ran into a lot of problems. First most of the artifacts got resolved to the 2.0.1 released artifacts which didn't work because the car files didn't have valid geronimo-plugin.xmls in them. After I removed all my 2.0.1 artifacts things were slightly better until I got to something that wouldn't resolve at all, xbean-reflect 3.2-SNAPSHOT. The jar is in my local repo but for some reason it wasn't found. 4. I am doubting more and more that the current requires and obsoletes data are appropriate. For instance, most of the web apps require jetty (or tomcat, pick your flavor). IMO this is the wrong idea. If I want to install one of these web apps, it should install the web server if it's not already present. What I think is more appropriate would be if I'm trying to install a jetty web app and tomcat is installed it should complain: if no other web server is installed then it should install jetty for me. 5. Trying to extract information about what went wrong is really hard and unpleasant. 6. With the CTS configs that happen to be on my machine, there are 93. This is a lot to wade through. We need a better way of organizing them, at least on the command line. Perhaps providing a list of categories to pick from, then the plugins from that category, would be more manageable. Also a deploy this from this maven repo command would be good: this might exist but I haven't found it yet. thanks david jencks no category Geronimo Configs :: Welcome app Jetty 8 : (2.1-SNAPSHOT) Geronimo Configs :: Unavailable Client Deployer 9 : (2.1-SNAPSHOT) Geronimo Configs :: GBean Deployer 11: (2.1-SNAPSHOT) Geronimo Configs :: Shared Library 12: (2.1-SNAPSHOT) Geronimo Configs :: System Database 13: (2.1-SNAPSHOT) Geronimo Configs :: Application Client Deployments 14: (2.1-SNAPSHOT) Geronimo Configs :: J2EE Client transaction 15: (2.1-SNAPSHOT) Geronimo Configs :: CLI Upgrade 16: (2.1-SNAPSHOT) Geronimo Configs :: Unavailable EJB Deployer 17: (2.1-SNAPSHOT) Geronimo Configs :: Plan Upgrade 20: (2.1-SNAPSHOT) Geronimo Configs :: Shutdown 21: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 JAR Configurer 23: (2.1-SNAPSHOT) Geronimo Configs :: Welcome app Tomcat 24: (2.1-SNAPSHOT) Geronimo Configs :: Corba J2EE Client 25: (2.1-SNAPSHOT) Geronimo Configs :: Client System 26: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 EAR Configurer 27: (2.1-SNAPSHOT) Geronimo Configs :: GBean Deployer Boostrap version 28: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 DeploymentFactory 29: (2.1-SNAPSHOT) Geronimo Configs :: Servlet Examples for
Re: Plugin progress
On Oct 1, 2007, at 3:21 PM, Prasad Kashyap wrote: Does this list of problems still exist ? see comments inline Cheers Prasad On 9/11/07, David Jencks [EMAIL PROTECTED] wrote: I've now updated enough of the configs so we can see if we can assemble them into a server. It would be great if some one else could take a look at some of the remaining ones, list at the end of this email. To get your own list of un-cleaned-up configs build g, fire it up, and run search-plugins from the command line deployer: the no category ones aren't done yet. this list of uncategorized plugins that need attention is still valid. To provide a more reasonable sized testbed for assembling servers out of plugins I also shrank geronimo-framework to the minimum possible size: rmi-naming plus enough security to enable the command line deployer to connect to it. So, while some parts of plugin installation work, overall it doesn't. I keep seeing plugin installation pull in the wrong version of jars and cars and sometimes not find jars that are present in the local maven repo. Here are the problems I've noted so far, in order of discovery: 1. While reviewing config poms I saw some suspicious dependencies. Axis and Axis2 depend on openejb which subverts any attempt to run axis web services on a minimal server. The openejb-deployer requires openejb to be running which subverts any attempt to deploy offline while another server is running on the same machine (port conflicts). I think this is entirely resolved by now. 2. Figuring out which repository to look in doesn't work yet. While what is specified in the geronimo-plugin.xml and geronimo-plugins.xml does appear to be honored, using these isn't compatible with developing and testing plugins, since while a plugin is being worked on you want to use only your local repo but after its published you don't (unless perhaps its is hooked up to some kind of maven proxy) I wonder if having a default repo configured in the plugin installer system would work, or perhaps merging the repos at the end of geronimo-plugins.xml with those in each geronimo-plugin.xml. this is less of an immediate issue, I added the remote maven central repo in and now most things are found, but the problem of moving from I'm developing this on my machine to its published at this repo remains and I don't have any good ideas. 3. version resolution appears to have some serious problems. I think pretty much all of the geronimo-plugin.xmls contain versions for every jar (something I'm hoping to change) but I ran into a lot of problems. First most of the artifacts got resolved to the 2.0.1 released artifacts which didn't work because the car files didn't have valid geronimo-plugin.xmls in them. After I removed all my 2.0.1 artifacts things were slightly better until I got to something that wouldn't resolve at all, xbean-reflect 3.2-SNAPSHOT. The jar is in my local repo but for some reason it wasn't found. Most or all of these problems went away when I added maven central repo in. The problems were mostly caused by missing maven- metadata.xml files: this prevented finding snapshots or resolving dependencies that lacked a version. 4. I am doubting more and more that the current requires and obsoletes data are appropriate. For instance, most of the web apps require jetty (or tomcat, pick your flavor). IMO this is the wrong idea. If I want to install one of these web apps, it should install the web server if it's not already present. What I think is more appropriate would be if I'm trying to install a jetty web app and tomcat is installed it should complain: if no other web server is installed then it should install jetty for me. I still think these are highly questionable. 5. Trying to extract information about what went wrong is really hard and unpleasant. maybe I got used to this one :-) 6. With the CTS configs that happen to be on my machine, there are 93. This is a lot to wade through. We need a better way of organizing them, at least on the command line. Perhaps providing a list of categories to pick from, then the plugins from that category, would be more manageable. Also a deploy this from this maven repo command would be good: this might exist but I haven't found it yet. I think that's related to the install-plugin command :-) Better categorization would still be helpful. hope this helps david jencks thanks david jencks no category Geronimo Configs :: Welcome app Jetty 8 : (2.1-SNAPSHOT) Geronimo Configs :: Unavailable Client Deployer 9 : (2.1-SNAPSHOT) Geronimo Configs :: GBean Deployer 11: (2.1-SNAPSHOT) Geronimo Configs :: Shared Library 12: (2.1-SNAPSHOT) Geronimo Configs :: System Database 13: (2.1-SNAPSHOT) Geronimo Configs :: Application Client Deployments 14: (2.1-SNAPSHOT) Geronimo Configs :: J2EE Client transaction 15: (2.1-SNAPSHOT)
Re: Plugin progress
I think I resolved most of the resolve to wrong version problems (basically #3 below), and I managed to start with framework and deploy plugins until I got a working web console (jetty, and the old non-modular console). There are still a bunch of weirdnesses going on such as openejb having NCDFE but this seems to me like a significant step towards plugin usability. There may be other problems such as I'm not sure the gbean configs are getting copied into config.xml properly. I'll keep looking at this stuff. thanks david jencks On Sep 11, 2007, at 12:13 AM, David Jencks wrote: I've now updated enough of the configs so we can see if we can assemble them into a server. It would be great if some one else could take a look at some of the remaining ones, list at the end of this email. To get your own list of un-cleaned-up configs build g, fire it up, and run search-plugins from the command line deployer: the no category ones aren't done yet. To provide a more reasonable sized testbed for assembling servers out of plugins I also shrank geronimo-framework to the minimum possible size: rmi-naming plus enough security to enable the command line deployer to connect to it. So, while some parts of plugin installation work, overall it doesn't. I keep seeing plugin installation pull in the wrong version of jars and cars and sometimes not find jars that are present in the local maven repo. Here are the problems I've noted so far, in order of discovery: 1. While reviewing config poms I saw some suspicious dependencies. Axis and Axis2 depend on openejb which subverts any attempt to run axis web services on a minimal server. The openejb-deployer requires openejb to be running which subverts any attempt to deploy offline while another server is running on the same machine (port conflicts). 2. Figuring out which repository to look in doesn't work yet. While what is specified in the geronimo-plugin.xml and geronimo- plugins.xml does appear to be honored, using these isn't compatible with developing and testing plugins, since while a plugin is being worked on you want to use only your local repo but after its published you don't (unless perhaps its is hooked up to some kind of maven proxy) I wonder if having a default repo configured in the plugin installer system would work, or perhaps merging the repos at the end of geronimo-plugins.xml with those in each geronimo-plugin.xml. 3. version resolution appears to have some serious problems. I think pretty much all of the geronimo-plugin.xmls contain versions for every jar (something I'm hoping to change) but I ran into a lot of problems. First most of the artifacts got resolved to the 2.0.1 released artifacts which didn't work because the car files didn't have valid geronimo-plugin.xmls in them. After I removed all my 2.0.1 artifacts things were slightly better until I got to something that wouldn't resolve at all, xbean-reflect 3.2- SNAPSHOT. The jar is in my local repo but for some reason it wasn't found. 4. I am doubting more and more that the current requires and obsoletes data are appropriate. For instance, most of the web apps require jetty (or tomcat, pick your flavor). IMO this is the wrong idea. If I want to install one of these web apps, it should install the web server if it's not already present. What I think is more appropriate would be if I'm trying to install a jetty web app and tomcat is installed it should complain: if no other web server is installed then it should install jetty for me. 5. Trying to extract information about what went wrong is really hard and unpleasant. 6. With the CTS configs that happen to be on my machine, there are 93. This is a lot to wade through. We need a better way of organizing them, at least on the command line. Perhaps providing a list of categories to pick from, then the plugins from that category, would be more manageable. Also a deploy this from this maven repo command would be good: this might exist but I haven't found it yet. thanks david jencks no category Geronimo Configs :: Welcome app Jetty 8 : (2.1-SNAPSHOT) Geronimo Configs :: Unavailable Client Deployer 9 : (2.1-SNAPSHOT) Geronimo Configs :: GBean Deployer 11: (2.1-SNAPSHOT) Geronimo Configs :: Shared Library 12: (2.1-SNAPSHOT) Geronimo Configs :: System Database 13: (2.1-SNAPSHOT) Geronimo Configs :: Application Client Deployments 14: (2.1-SNAPSHOT) Geronimo Configs :: J2EE Client transaction 15: (2.1-SNAPSHOT) Geronimo Configs :: CLI Upgrade 16: (2.1-SNAPSHOT) Geronimo Configs :: Unavailable EJB Deployer 17: (2.1-SNAPSHOT) Geronimo Configs :: Plan Upgrade 20: (2.1-SNAPSHOT) Geronimo Configs :: Shutdown 21: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 JAR Configurer 23: (2.1-SNAPSHOT)
Re: Plugin progress
On 9/11/07, David Jencks [EMAIL PROTECTED] wrote: 1. While reviewing config poms I saw some suspicious dependencies. Axis and Axis2 depend on openejb which subverts any attempt to run axis web services on a minimal server. The openejb-deployer requires openejb to be running which subverts any attempt to deploy offline while another server is running on the same machine (port conflicts). I'll take a look at this again. Here's some background info: http://marc.info/?l=geronimo-devm=117166218232083w=2 Jarek
Re: Plugin progress
With a little more work I'm now able to start with framework and add jetty, jasper, and jetty-admin and get a working web console I guess maybe the next step is to make the car-maven-plugin:assemble use the plugin-install features so it builds up the config.xml and other config files. One or more gshell commands to deal with plugins would be pretty nice too. It might be worthwhile to try to figure out how we want to present this to users. We should be at the point where if they package their applications as plugins then by installing those plugins into g- framework you get a minimal server for running those applications. thanks david jencks On Sep 12, 2007, at 3:34 AM, David Jencks wrote: I think I resolved most of the resolve to wrong version problems (basically #3 below), and I managed to start with framework and deploy plugins until I got a working web console (jetty, and the old non-modular console). There are still a bunch of weirdnesses going on such as openejb having NCDFE but this seems to me like a significant step towards plugin usability. There may be other problems such as I'm not sure the gbean configs are getting copied into config.xml properly. I'll keep looking at this stuff. thanks david jencks On Sep 11, 2007, at 12:13 AM, David Jencks wrote: I've now updated enough of the configs so we can see if we can assemble them into a server. It would be great if some one else could take a look at some of the remaining ones, list at the end of this email. To get your own list of un-cleaned-up configs build g, fire it up, and run search-plugins from the command line deployer: the no category ones aren't done yet. To provide a more reasonable sized testbed for assembling servers out of plugins I also shrank geronimo-framework to the minimum possible size: rmi-naming plus enough security to enable the command line deployer to connect to it. So, while some parts of plugin installation work, overall it doesn't. I keep seeing plugin installation pull in the wrong version of jars and cars and sometimes not find jars that are present in the local maven repo. Here are the problems I've noted so far, in order of discovery: 1. While reviewing config poms I saw some suspicious dependencies. Axis and Axis2 depend on openejb which subverts any attempt to run axis web services on a minimal server. The openejb- deployer requires openejb to be running which subverts any attempt to deploy offline while another server is running on the same machine (port conflicts). 2. Figuring out which repository to look in doesn't work yet. While what is specified in the geronimo-plugin.xml and geronimo- plugins.xml does appear to be honored, using these isn't compatible with developing and testing plugins, since while a plugin is being worked on you want to use only your local repo but after its published you don't (unless perhaps its is hooked up to some kind of maven proxy) I wonder if having a default repo configured in the plugin installer system would work, or perhaps merging the repos at the end of geronimo-plugins.xml with those in each geronimo-plugin.xml. 3. version resolution appears to have some serious problems. I think pretty much all of the geronimo-plugin.xmls contain versions for every jar (something I'm hoping to change) but I ran into a lot of problems. First most of the artifacts got resolved to the 2.0.1 released artifacts which didn't work because the car files didn't have valid geronimo-plugin.xmls in them. After I removed all my 2.0.1 artifacts things were slightly better until I got to something that wouldn't resolve at all, xbean-reflect 3.2- SNAPSHOT. The jar is in my local repo but for some reason it wasn't found. 4. I am doubting more and more that the current requires and obsoletes data are appropriate. For instance, most of the web apps require jetty (or tomcat, pick your flavor). IMO this is the wrong idea. If I want to install one of these web apps, it should install the web server if it's not already present. What I think is more appropriate would be if I'm trying to install a jetty web app and tomcat is installed it should complain: if no other web server is installed then it should install jetty for me. 5. Trying to extract information about what went wrong is really hard and unpleasant. 6. With the CTS configs that happen to be on my machine, there are 93. This is a lot to wade through. We need a better way of organizing them, at least on the command line. Perhaps providing a list of categories to pick from, then the plugins from that category, would be more manageable. Also a deploy this from this maven repo command would be good: this might exist but I haven't found it yet. thanks david jencks no category Geronimo Configs :: Welcome app Jetty 8 : (2.1-SNAPSHOT) Geronimo Configs :: Unavailable
Plugin progress
I've now updated enough of the configs so we can see if we can assemble them into a server. It would be great if some one else could take a look at some of the remaining ones, list at the end of this email. To get your own list of un-cleaned-up configs build g, fire it up, and run search-plugins from the command line deployer: the no category ones aren't done yet. To provide a more reasonable sized testbed for assembling servers out of plugins I also shrank geronimo-framework to the minimum possible size: rmi-naming plus enough security to enable the command line deployer to connect to it. So, while some parts of plugin installation work, overall it doesn't. I keep seeing plugin installation pull in the wrong version of jars and cars and sometimes not find jars that are present in the local maven repo. Here are the problems I've noted so far, in order of discovery: 1. While reviewing config poms I saw some suspicious dependencies. Axis and Axis2 depend on openejb which subverts any attempt to run axis web services on a minimal server. The openejb-deployer requires openejb to be running which subverts any attempt to deploy offline while another server is running on the same machine (port conflicts). 2. Figuring out which repository to look in doesn't work yet. While what is specified in the geronimo-plugin.xml and geronimo-plugins.xml does appear to be honored, using these isn't compatible with developing and testing plugins, since while a plugin is being worked on you want to use only your local repo but after its published you don't (unless perhaps its is hooked up to some kind of maven proxy) I wonder if having a default repo configured in the plugin installer system would work, or perhaps merging the repos at the end of geronimo-plugins.xml with those in each geronimo-plugin.xml. 3. version resolution appears to have some serious problems. I think pretty much all of the geronimo-plugin.xmls contain versions for every jar (something I'm hoping to change) but I ran into a lot of problems. First most of the artifacts got resolved to the 2.0.1 released artifacts which didn't work because the car files didn't have valid geronimo-plugin.xmls in them. After I removed all my 2.0.1 artifacts things were slightly better until I got to something that wouldn't resolve at all, xbean-reflect 3.2-SNAPSHOT. The jar is in my local repo but for some reason it wasn't found. 4. I am doubting more and more that the current requires and obsoletes data are appropriate. For instance, most of the web apps require jetty (or tomcat, pick your flavor). IMO this is the wrong idea. If I want to install one of these web apps, it should install the web server if it's not already present. What I think is more appropriate would be if I'm trying to install a jetty web app and tomcat is installed it should complain: if no other web server is installed then it should install jetty for me. 5. Trying to extract information about what went wrong is really hard and unpleasant. 6. With the CTS configs that happen to be on my machine, there are 93. This is a lot to wade through. We need a better way of organizing them, at least on the command line. Perhaps providing a list of categories to pick from, then the plugins from that category, would be more manageable. Also a deploy this from this maven repo command would be good: this might exist but I haven't found it yet. thanks david jencks no category Geronimo Configs :: Welcome app Jetty 8 : (2.1-SNAPSHOT) Geronimo Configs :: Unavailable Client Deployer 9 : (2.1-SNAPSHOT) Geronimo Configs :: GBean Deployer 11: (2.1-SNAPSHOT) Geronimo Configs :: Shared Library 12: (2.1-SNAPSHOT) Geronimo Configs :: System Database 13: (2.1-SNAPSHOT) Geronimo Configs :: Application Client Deployments 14: (2.1-SNAPSHOT) Geronimo Configs :: J2EE Client transaction 15: (2.1-SNAPSHOT) Geronimo Configs :: CLI Upgrade 16: (2.1-SNAPSHOT) Geronimo Configs :: Unavailable EJB Deployer 17: (2.1-SNAPSHOT) Geronimo Configs :: Plan Upgrade 20: (2.1-SNAPSHOT) Geronimo Configs :: Shutdown 21: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 JAR Configurer 23: (2.1-SNAPSHOT) Geronimo Configs :: Welcome app Tomcat 24: (2.1-SNAPSHOT) Geronimo Configs :: Corba J2EE Client 25: (2.1-SNAPSHOT) Geronimo Configs :: Client System 26: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 EAR Configurer 27: (2.1-SNAPSHOT) Geronimo Configs :: GBean Deployer Boostrap version 28: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 DeploymentFactory 29: (2.1-SNAPSHOT) Geronimo Configs :: Servlet Examples for Tomcat 33: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 CLI 34: (2.1-SNAPSHOT) Geronimo Configs :: J2EE Client 35:
