Re: [jira] Commented: (GERONIMO-4353) An uniform way to show error messages on the console
Hi, Yes, in the last discussion, for currently no component uses the dojo (only plancreator uses the legacy dojo, I remember that it would migrate to the new dojo version ?), so we temporary removed it from the server. But dojo is really a good tool to improve the usability of the admin console, I guess we need it. And since a compact mini-dojo is created, it currently only contains those must files. The reason that dojo is used here is also due to some technical reason. For I want to display those messages on the portlets and wish it does not impact the current existing portlets, so I print the messages in a hidden html div tag and use dojo to load those messages. And so that the developers of the portlets do not need to take care too much on the message display, no extra work needs to done. Thanks for any comment ! 2008/10/16 Lin Sun (JIRA) <[EMAIL PROTECTED]> > >[ > https://issues.apache.org/jira/browse/GERONIMO-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640040#action_12640040] > > Lin Sun commented on GERONIMO-4353: > --- > > Hi, I'd like to understand why dojo is needed here since this is a change > to the base console. I am under the impression that we want to reduce > server size (from discussion on dev list, dojo seems to have lots of files) > and make some console components optional. > > Thanks Lin > > > An uniform way to show error messages on the console > > > > > > Key: GERONIMO-4353 > > URL: https://issues.apache.org/jira/browse/GERONIMO-4353 > > Project: Geronimo > > Issue Type: Improvement > > Security Level: public(Regular issues) > > Components: console > >Affects Versions: 2.1.3 > >Reporter: Ivan > > Attachments: Geronimo-4353.patch, snapshot.JPG > > > > > > Currently, different portlets uses different way to show those error > messages to the end user. We need a uniform way to do it. The simliar issue > is opened in GERONIMO-2621, but it was closed due to overwork on it in the > past. > > I am trying to provide a solution, and will provide a demo in the next > few days. Thanks ! > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- Ivan
[jira] Created: (GERONIMO-4365) Pull in TranQL Informix XA connector
Pull in TranQL Informix XA connector Key: GERONIMO-4365 URL: https://issues.apache.org/jira/browse/GERONIMO-4365 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: databases Affects Versions: 2.1.3, 2.2 Reporter: Rex Wang We can pull in the patch in TranQL which provides informix XA connector. http://jira.codehaus.org/browse/TQL-12 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4353) An uniform way to show error messages on the console
[ https://issues.apache.org/jira/browse/GERONIMO-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640040#action_12640040 ] Lin Sun commented on GERONIMO-4353: --- Hi, I'd like to understand why dojo is needed here since this is a change to the base console. I am under the impression that we want to reduce server size (from discussion on dev list, dojo seems to have lots of files) and make some console components optional. Thanks Lin > An uniform way to show error messages on the console > > > Key: GERONIMO-4353 > URL: https://issues.apache.org/jira/browse/GERONIMO-4353 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.3 >Reporter: Ivan > Attachments: Geronimo-4353.patch, snapshot.JPG > > > Currently, different portlets uses different way to show those error messages > to the end user. We need a uniform way to do it. The simliar issue is opened > in GERONIMO-2621, but it was closed due to overwork on it in the past. > I am trying to provide a solution, and will provide a demo in the next few > days. Thanks ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 705114
Geronimo Revision: 705114 built with tests included See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081015/build-2100.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081015/unit-test-reports Then, install it using the command: mvn install:install-file -DgroupId=org.openqa.selenium.server -DartifactId=selenium-server -Dversion=1.0-beta-1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.openqa.selenium.server -DartifactId=selenium-server -Dversion=1.0-beta-1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.testsupport:testsupport-selenium:jar:2.2-SNAPSHOT 2) org.openqa.selenium.server:selenium-server:jar:1.0-beta-1 -- 2 required artifacts are missing. for artifact: org.apache.geronimo.testsupport:testsupport-selenium:jar:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), releases.openqa.org (http://archiva.openqa.org/repository/releases), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), snapshots.openqa.org (http://archiva.openqa.org/repository/snapshots), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) org.openqa.selenium.client-drivers:selenium-java-client-driver:jar:1.0-beta-1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.openqa.selenium.client-drivers -DartifactId=selenium-java-client-driver -Dversion=1.0-beta-1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.openqa.selenium.client-drivers -DartifactId=selenium-java-client-driver -Dversion=1.0-beta-1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.testsupport:testsupport-selenium:jar:2.2-SNAPSHOT 2) org.openqa.selenium.client-drivers:selenium-java-client-driver:jar:1.0-beta-1 2) org.openqa.selenium.server:selenium-server:jar:1.0-beta-1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.openqa.selenium.server -DartifactId=selenium-server -Dversion=1.0-beta-1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.openqa.selenium.server -DartifactId=selenium-server -Dversion=1.0-beta-1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.testsupport:testsupport-selenium:jar:2.2-SNAPSHOT 2) org.openqa.selenium.server:selenium-server:jar:1.0-beta-1 -- 2 required artifacts are missing. for artifact
[jira] Commented: (GERONIMO-4360) Connector 1.6 implementation
[ https://issues.apache.org/jira/browse/GERONIMO-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640019#action_12640019 ] David Jencks commented on GERONIMO-4360: Rev 705104 (components/txmanager/trunk) switches component to 1.6 api and implements InflowContext handling. The new LazyAssociatableConnectionManager.inactiveConnectionClosed method is present but not implemented until I understand it better. > Connector 1.6 implementation > > > Key: GERONIMO-4360 > URL: https://issues.apache.org/jira/browse/GERONIMO-4360 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.2 > > > We'll need some changes in component and in the wrapping in server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4360) Connector 1.6 implementation
[ https://issues.apache.org/jira/browse/GERONIMO-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640017#action_12640017 ] David Jencks commented on GERONIMO-4360: Rev 705102 (server/trunk) implements resource adapter-aware admin objects. This doesn't use any new apis. It also changes our vendor plan schema without changing the namespace. > Connector 1.6 implementation > > > Key: GERONIMO-4360 > URL: https://issues.apache.org/jira/browse/GERONIMO-4360 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.2 > > > We'll need some changes in component and in the wrapping in server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: An idea for defining custom valves in config.xml
Hi Gianny, First, I'd like to make sure I understand the philosophy behind your proposals. IIUC they both involve the idea of making it easy to modify an existing plugin rather than making it easy to replace an existing plugin with a similar one. Why is this a good idea? My idea has been that we should make it easier to replace a plugin with a similar one than modify an existing one, and then we will have the best of all worlds. All this being said, I think your ideas are both quite interesting. I'm especially interested in the groovy builder approach. I'll be fairly unavailable until next week but might keep thinking about this anyway. thanks! david jencks On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote: On 15/10/2008, at 4:16 AM, David Jencks wrote: That's one of the main missing bits of functionality. Right now the only way to get the g-p.xml is to use c-m-p or to export the plugin from a server it's been deployed into, or to do something by hand with jar packing and unpacking. The biggest problem here, in my mind, is that jsr88 only wants you to have one "plan": to deploy something you get to specify the artifact and one "plan". Our deployment system is built around jsr88 so we either have to condense the g-p.xml and plan into one "plan" or abandon jsr88. At the moment I'm thinking that one satisfactory solution might be to more or less embed the plan into g-p.xml. Perhaps we could avoid duplicating most of the dependency info by adding the element to the dependencies in g-p.xml. I guess we'd expect a more or less empty element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g- p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks
Where will ee6 development take place?
I realize I've been assuming that we'll just develop ee6 features in trunk and release 2.2 with a bunch or all of ee6 implemented. I have some connector 1.6 stuff I'm about to commit This attitude might cause tck problems especially with signature tests. On the other hand maybe we can get signature updates. What do other people think we should do? thanks david jencks
Re: Multiple Instances With One Repository
On Oct 15, 2008, at 1:38 PM, pdennis wrote: Hi, I've looked around the documentation and the forum to find my answer and I haven't found it, yet. I just read about Multiple Repositories http://cwiki.apache.org/GMOxDOC20/multiple-repositories.html here , so I can start several instances and create a local repository for each instance. What I want to do is to create a Repository, deploy an ear and a database pool, and start several instances that use that Repository. In the WASCE_HOME directory, there is the main repository and var directories, what I would like to do is to create a local repository, and start several instances that use that repository. So I think I am after a structure like this: WASCE_HOME repo1 instance1 instance2 instance3 repo2 instance1 instance2 instance3 repo3 instance1 instance2 instance3 Is this possible? If so, how would I do this? I'm not sure why you want mutliple repositories. I think you can do what you want with only the default repository. We actually have sort of a sample of multiple servers sharing a repository. One version that may be usable is at http://people.apache.org/~djencks/failover2.tar.gz To build it yourself build serve/trunk, then checkout svn co https://svn.apache.org/repos/asf/geronimo/sandbox/failover and build the pieces independently. There's a linux script that makes a bunch of server copies (copying the var directory) and a couple scripts that start the servers on different ports. This sample works on plugins so you can see plugins installed on each of the "servers". The first time a plugin is installed it actually gets into the repository and the installation process may unpack stuff into that server's var dir. When the plugin is installed on the other servers sharing the repo the only thing that happens is the unpacking into the var dir. You can do something similar with apps that you aren't thinking of as plugins by deploying the app into the appropriate first server, then starting the app in the other servers you want it running in. Productive use of this feature is just starting so please let us know what is unclear or if you run into problems or have more questions. many thanks david jencks Thanks, Patrick -- View this message in context: http://www.nabble.com/Multiple-Instances-With-One-Repository-tp20001882s134p20001882.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Multiple Instances With One Repository
Hi, I've looked around the documentation and the forum to find my answer and I haven't found it, yet. I just read about Multiple Repositories http://cwiki.apache.org/GMOxDOC20/multiple-repositories.html here , so I can start several instances and create a local repository for each instance. What I want to do is to create a Repository, deploy an ear and a database pool, and start several instances that use that Repository. In the WASCE_HOME directory, there is the main repository and var directories, what I would like to do is to create a local repository, and start several instances that use that repository. So I think I am after a structure like this: WASCE_HOME repo1 instance1 instance2 instance3 repo2 instance1 instance2 instance3 repo3 instance1 instance2 instance3 Is this possible? If so, how would I do this? Thanks, Patrick -- View this message in context: http://www.nabble.com/Multiple-Instances-With-One-Repository-tp20001882s134p20001882.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Commented: (GERONIMO-4364) Split the assemblylist page to 2 pages
[ https://issues.apache.org/jira/browse/GERONIMO-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639947#action_12639947 ] Lin Sun commented on GERONIMO-4364: --- Good suggestion. Thanks Jarek. > Split the assemblylist page to 2 pages > -- > > Key: GERONIMO-4364 > URL: https://issues.apache.org/jira/browse/GERONIMO-4364 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Lin Sun >Assignee: Lin Sun >Priority: Minor > Fix For: 2.2 > > > Currently, this page is a bit cluttered. I propose we split it into 2 pages: > 1st page - Name the server to be assembled > 2nd page - Select from plugins in current server -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-384) unable to set relationships
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed resolved GERONIMODEVTOOLS-384. Resolution: Fixed Fix Version/s: (was: 2.2.0) 2.1.4 Fixed with revision 704999 to 2.1.4 and revision 705002 in trunk. Added EJB Relation tree section to the naming page for the OpenEJB Deployment Plan Editor. > unable to set relationships > --- > > Key: GERONIMODEVTOOLS-384 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-384 > Project: Geronimo-Devtools > Issue Type: Sub-task > Components: eclipse-plugin >Affects Versions: 2.1.3 >Reporter: B.J. Reed >Assignee: B.J. Reed >Priority: Minor > Fix For: 2.1.4 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4364) Split the assemblylist page to 2 pages
[ https://issues.apache.org/jira/browse/GERONIMO-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639926#action_12639926 ] Jarek Gawor commented on GERONIMO-4364: --- Not sure if this is the best place to bring this up... but if I remember correctly, the plugin descriptions are displayed only after the user explicitly clicks or selects a given plugin. I think it would be nice if the descriptions were displayed as the user hovers over the given plugin. > Split the assemblylist page to 2 pages > -- > > Key: GERONIMO-4364 > URL: https://issues.apache.org/jira/browse/GERONIMO-4364 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Lin Sun >Assignee: Lin Sun >Priority: Minor > Fix For: 2.2 > > > Currently, this page is a bit cluttered. I propose we split it into 2 pages: > 1st page - Name the server to be assembled > 2nd page - Select from plugins in current server -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reopened GERONIMO-4350: Assignee: Dain Sundstrom (was: David Jencks) The problem was in the (admittedly extremely badly written) resource adapter, not application code. I can't find any parts of the spec that prohibit a ConnectionFactory from assuming that what it gets from the ConnectionManager.allocateConnection is the same object that the ManagedConnection.getConnection(...) produced. Can you point to the part of the spec you're thinking of? Or, in fact, any part of the spec that indicates why you have to specify interfaces as well as implementation classes for connection factory and connection? > Connection proxying to imitate DissociatableManagedConnection can easily > cause problems > --- > > Key: GERONIMO-4350 > URL: https://issues.apache.org/jira/browse/GERONIMO-4350 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.1, 2.2 >Reporter: David Jencks >Assignee: Dain Sundstrom > Fix For: 2.1.4, 2.2 > > > We have some code to imitate the DissociatableManagedConnection to avoid > connection leaks that proxies connections from the supplied > ManagedConnectionFactory: the proxy implements all the interfaces of the > connection, but not the class itself. However, there's nothing stopping the > ConnectionFactory from casting the (now proxied) connection to the > implementation class it expects. > The TxConnect project at sourceforge illustrates this approach in the > EisConnectionFactory. > http://txconnect.sourceforge.net > One possible solution would be to have a flag to turn on this proxying > behavior. I don't immediately see a way to detect if the problem will occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4364) Split the assemblylist page to 2 pages
Split the assemblylist page to 2 pages -- Key: GERONIMO-4364 URL: https://issues.apache.org/jira/browse/GERONIMO-4364 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.2 Reporter: Lin Sun Assignee: Lin Sun Priority: Minor Fix For: 2.2 Currently, this page is a bit cluttered. I propose we split it into 2 pages: 1st page - Name the server to be assembled 2nd page - Select from plugins in current server -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4363) Update plugin metadata (especially category) to represent function of a plugin
Update plugin metadata (especially category) to represent function of a plugin -- Key: GERONIMO-4363 URL: https://issues.apache.org/jira/browse/GERONIMO-4363 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.2 In addition to plugin profiles, we decided on dev list that we can assign tags to plugins. Category was proposed to tag all the plugins. For example, if a plugin has JMS function, we want to make sure word JMS exists in the plugin's category. If a plugin belongs to admin console, we want to make sure word Administration Console exists in the plugin's category.I'll perform a scan on our plugins and update them, so that changes in G4362 will work accurately. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4362) Allow users to filter plugins on server assembly portlet & allow users to turn on expert users mode
[ https://issues.apache.org/jira/browse/GERONIMO-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4362. --- Resolution: Fixed rev 704973 contains the following - 1. allow users to see only related plugins on the custom server assembly portlet. currently the search is only performed on the category column but could be enhance to search all the columns.If a user types "ejb", he can see all ejb related plugins. If a user types "ejb jms", he can see all ejb and jms related plugins. 2. allow users to turn on/off expert user mode. This is stored as a cookie. when expert mode is turned on, a user will get to see all the system plugins that are hidden in non-expert mode. In additional to the names, version, category of the plugins, I also added a new column to show configid in the system plugin table. 3. I disabled the sort column functions on the page, as it is not quite working and I don't feel sort is needed now that we allow users to filter contents. > Allow users to filter plugins on server assembly portlet & allow users to > turn on expert users mode > --- > > Key: GERONIMO-4362 > URL: https://issues.apache.org/jira/browse/GERONIMO-4362 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.2 > > > Per discussion on dev list - > http://www.nabble.com/Re%3A-svn-commit%3A-r702586---in--geronimo-server-trunk-plugingroups-console-jetty%3A-.--pom.xml-src--src-main--src-main-history--src-main-history-dependencies.xml-src-main-plan--to19871519s134.html#a19871519 > It is desired to have some sort of filter function on the custom server > assembly portlet. If a user types "ejb", he can see all ejb related plugins. > If a user types "ejb jms", he can see all ejb and jms related plugins. > It is also desired to have an expert user mode so that a user can see all the > system plugins optionally. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4361) Resource injection of simple env. entry types
[ https://issues.apache.org/jira/browse/GERONIMO-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4361. --- Resolution: Fixed Fix Version/s: 2.2 2.1.4 Committed fixes for these issues to trunk (revision 704968) and branches/2.1 (revision 704978). > Resource injection of simple env. entry types > - > > Key: GERONIMO-4361 > URL: https://issues.apache.org/jira/browse/GERONIMO-4361 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.1.3, 2.2 >Reporter: Jarek Gawor >Assignee: Jarek Gawor > Fix For: 2.1.4, 2.2 > > > There are a couple problems with @Resource injection of simple env. types: > 1) If @Resource.mappedName attribute is specified, it becomes the env-entry > value. For example, if we have @Resource(mappedName = "java:comp/env/bar") > String foo, the injected value of "foo" will be "java:comp/env/bar". That's > incorrect. > 2) Right now, @Resource String foo = "bar". without a corresponding env-entry > in the DD will cause a deployment (injection) exception (since there is no > entry for it in the JNDI context). However, according to the Java EE 5 spec, > section EE.5.4.1.3, "... the container must only inject a value for this > resource if the deployer has specified a value to override the default value" > and since the generated DD entry for this resource will have no > env-entry-value element, the injection should not happen (and so the > application should deploy without an error). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4362) Allow users to filter plugins on server assembly portlet & allow users to turn on expert users mode
Allow users to filter plugins on server assembly portlet & allow users to turn on expert users mode --- Key: GERONIMO-4362 URL: https://issues.apache.org/jira/browse/GERONIMO-4362 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.2 Per discussion on dev list - http://www.nabble.com/Re%3A-svn-commit%3A-r702586---in--geronimo-server-trunk-plugingroups-console-jetty%3A-.--pom.xml-src--src-main--src-main-history--src-main-history-dependencies.xml-src-main-plan--to19871519s134.html#a19871519 It is desired to have some sort of filter function on the custom server assembly portlet. If a user types "ejb", he can see all ejb related plugins. If a user types "ejb jms", he can see all ejb and jms related plugins. It is also desired to have an expert user mode so that a user can see all the system plugins optionally. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4361) Resource injection of simple env. entry types
Resource injection of simple env. entry types - Key: GERONIMO-4361 URL: https://issues.apache.org/jira/browse/GERONIMO-4361 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.1.3, 2.2 Reporter: Jarek Gawor Assignee: Jarek Gawor There are a couple problems with @Resource injection of simple env. types: 1) If @Resource.mappedName attribute is specified, it becomes the env-entry value. For example, if we have @Resource(mappedName = "java:comp/env/bar") String foo, the injected value of "foo" will be "java:comp/env/bar". That's incorrect. 2) Right now, @Resource String foo = "bar". without a corresponding env-entry in the DD will cause a deployment (injection) exception (since there is no entry for it in the JNDI context). However, according to the Java EE 5 spec, section EE.5.4.1.3, "... the container must only inject a value for this resource if the deployer has specified a value to override the default value" and since the generated DD entry for this resource will have no env-entry-value element, the injection should not happen (and so the application should deploy without an error). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed GERONIMO-4350. Resolution: Invalid Assignee: David Jencks (was: Dain Sundstrom) The problem was in user code that was attempting to downcast a connection proxy to a specific implementation class which is not allowed by the JEE Connector specification. > Connection proxying to imitate DissociatableManagedConnection can easily > cause problems > --- > > Key: GERONIMO-4350 > URL: https://issues.apache.org/jira/browse/GERONIMO-4350 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.1, 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1.4, 2.2 > > > We have some code to imitate the DissociatableManagedConnection to avoid > connection leaks that proxies connections from the supplied > ManagedConnectionFactory: the proxy implements all the interfaces of the > connection, but not the class itself. However, there's nothing stopping the > ConnectionFactory from casting the (now proxied) connection to the > implementation class it expects. > The TxConnect project at sourceforge illustrates this approach in the > EisConnectionFactory. > http://txconnect.sourceforge.net > One possible solution would be to have a flag to turn on this proxying > behavior. I don't immediately see a way to detect if the problem will occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: dojo-tomcat/jetty6
I just realized this morning that you were using Jetty rather than Tomcat (which I usually use) - And so I thought that might be figuring into your problem. So I did a fresh build of trunk and tested the Jetty version to see where I would find dojo.js. And, it was right where I thought it would be: http://localhost:8080/dojo/dojo/dojo.js Where did you get the snapshot that you were testing with? And what is the location of the plugin repository that you were pulling in Dojo from? Did you build the snapshot version yourself? And if you did, did you clear out your maven repository before you started? The current builds no longer include the Dojo plugin by default (it needs to be manually pulled in). If you did not do this and you had Dojo available as an installed system module, then you are using an older version. Lots of questions, I know. I just can't understand why you aren't finding Dojo where I am. Let me know what you find, Jay Ivan wrote: > I guess the dojo webapp is deployed with the web context "dojo", so >http://localhost:8080/dojo <---(webapp context) / dojo <-- > (parent folder) / dojo <-- (sub folder, which has a brother folder "dijit") > / dojo.js > > 2008/10/15 Jay D. McHugh <[EMAIL PROTECTED]> > >> Ivan, >> >> The location that you saw is correct (as of Dojo version 1.x). >> >> Ever since they (Dojo) began releases of Dojo that include dijit and >> dojox (those started with 0.9), they have nested those folders within a >> parent dojo folder. >> >> So, the folder structure should be: >> --dojo >> dojo >> dojo.js >> >> dijit >> >> >> And the path you would need to specify to access the dojo.js file would be: >> >> http://localhost:8080/dojo/dojo/dojo.js >> >> It still feels like an extra level of directories (to me also). But the >> only alternative to that would be for us to break apart the release from >> Dojo into multiple plugins. Then, there would be a dojo plugin and a >> dijit plugin. But for Geronimo's use of Dojo (and I would assume most >> others) the widgets are a big part of the draw - and splitting Dojo >> apart would be adding extra work to make things more complicated for us >> and users. >> >> Jay >> >> Ivan wrote: >>> After running mvn install on my local svn folder, I checked the file >>> dojo-tomcat-2.2-SNAPSHOT.car in the target folder, it has the same >> structure >>> with the previous one. >>> >>> ---dojo---dojo >>> ---dijit >>> ---WEB-INF >>> ---MENTA-INF >>> >>> Adding the web context "dojo", I guess we still need >>> /dojo/dojo/dojo/dojo.js, have I missed anything ? >>> >>> >>> 2008/10/14 Jay D. McHugh <[EMAIL PROTECTED]> >>> Ivan, Have you had a chance to try a newer snapshot? Is Dojo showing up in the correct location for you? Jay Ivan wrote: > Just find in the newest snapshot, after I manually install the dojo plugin, > it has an extra folder "dojo", currently when we want the refer to dojo.js, > the url will be /dojo/dojo/dojo/dojo.js. > I suggest to repackage the dojo-mini.zip file. > > > 2008/10/8 Lin Sun <[EMAIL PROTECTED]> > >> Hi Manu, Ok, making it optional sounds good. >> >> Lin >> >> On Wed, Oct 8, 2008 at 8:24 AM, Manu George <[EMAIL PROTECTED]> >> wrote: >>> Hi Lin, >>> >>> I am using it in the EjbServer Portlet I am developing. But I guess >>> that it can also be made an optional console plugin >>> >>> Regards >>> Manu >>> >>> On Wed, Oct 8, 2008 at 1:43 AM, Lin Sun <[EMAIL PROTECTED]> >> wrote: Jay, Right, I don't know how far that work went either. Thus, I didn't include the dojo-tomcat/jetty6 in the new javaee5-tomcat/jetty plugin group(profile), which will be used to build the javaee5 assemblies. Lin n Tue, Oct 7, 2008 at 3:41 PM, Jay D. McHugh <[EMAIL PROTECTED]> >> wrote: > Lin, > > Someone was working on upgrading the views in Geronimo to use the > widgets in the new version of Dojo. I don't know how far that work >> went. > So, I believe you are correct that the legacy set are the only ones >> that > are currently in use. > > Jay > > Lin Sun wrote: >> I think these two portlets are using the >> dojo-legacy-tomcat/jetty6. >> Nothing except the javaee5 assemblies lists dojo-tomcat/jetty6 as >> dependency. >> >> Lin >> >> On Tue, Oct 7, 2008 at 3:10 PM, Donald Woods <[EMAIL PROTECTED]> >> wrote: >>> I believe only the Debug Views and Plan Creator portlets need >> Dojo >> right >>> now, which I'm going to remove from the JEE5 assemblies and let users >>> optionally install them, once I've updated the Welcome portlet to >> include >>> some informat
[jira] Updated: (GERONIMO-4345) jar-file in persistence.xml overwrites toplink.ddl-generation
[
https://issues.apache.org/jira/browse/GERONIMO-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Berndt updated GERONIMO-4345:
--
Priority: Minor (was: Critical)
I wasn't aware of the OpenJPA property {{openjpa.jdbc.SynchronizeMappings}}
which prevents OpenJPA from schema modifications.
I do not close this entry because I think behavior shouldn't change using
{{}}.
> jar-file in persistence.xml overwrites toplink.ddl-generation
> -
>
> Key: GERONIMO-4345
> URL: https://issues.apache.org/jira/browse/GERONIMO-4345
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 2.1.3
> Environment: assumedly all
>Reporter: Matthias Berndt
>Priority: Minor
>
> If an addtional jar with entities is specified in the persistence.xml with
> {{}}, the {{ value="none"/>}} is overwritten or ignored an OpenJPA tries to create tables
> in the database.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (GERONIMO-4337) Upgrade to activeMQ 5.x
BTW - activeio is still listed as a dependency in the activemq-core-5.1.0 pom.xml file and the activeio pom still lists backport-util-concurrent as a dependency -Donald David Jencks (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639741#action_12639741 ] David Jencks commented on GERONIMO-4337: Hi John, I'll keep my eyes out for the icla to arrive. I thought that activemq 5 did not use activeio at all. I don't understand what you mean by creating placeholders in .m2/repository. Maven will create any directories it needs when it needs them. You should try to build from plugins/activemq5 and let maven figure out the order to build the modules in. Before updating the activemq versions I see: [INFO] Geronimo Plugins, ActiveMQ 5 [INFO] Geronimo Plugins, ActiveMQ5 :: Management Interfaces [INFO] Geronimo Plugins, ActiveMQ5 :: Core [INFO] Geronimo Plugins, ActiveMQ5 :: Broker [INFO] Geronimo Plugins, ActiveMQ5 :: Resource Adapter Core [INFO] Geronimo Plugins, ActiveMQ5 :: Resource Adapter [INFO] Geronimo Plugins, ActiveMQ5 :: Portlets [INFO] Geronimo Plugins, ActiveMQ5 :: Console (Jetty) [INFO] Geronimo Plugins, ActiveMQ5 :: Console (Tomcat) The error you get appears to refer to org.apache.geronimo.configs:activemq-ra and activemq-ra-4.1.2 which seems to indicate that some pom versions have not been updated to the proper values for activemq 5 or geronimo activemq5. If it is not clear how to proceed please attach a patch from svn diff and I will investigate. I would be surprised if the ActiveMQ5 Core module compiled successfully. Upgrade to activeMQ 5.x --- Key: GERONIMO-4337 URL: https://issues.apache.org/jira/browse/GERONIMO-4337 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.2 Reporter: David Jencks Fix For: 2.2 Upgrade activemq support to 5.x. A few steps along the way: - create an activemq5 work area under plugins - move the specification of amq version from the root pom dependency management to the activemq and activemq5 plugins. - keep only the broker gbean - use an activemq configuration file in var/activemq, referenced by the broker gbean - update dependencies to latest activemq - figure out how much of the current jms portlet functionality can be reasonably kept. From discussions with Hiram I think that trying to reconfigure the broker while its running is a very bad idea and we should just drop the parts of the console that try to do this. - investigate how to run the amq console in geronimo, preferably as portlets inside the g. admin console.
[jira] Commented: (GERONIMO-4337) Upgrade to activeMQ 5.x
[ https://issues.apache.org/jira/browse/GERONIMO-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639840#action_12639840 ] Donald Woods commented on GERONIMO-4337: John, I just made a small update to the activemq5/pom.xml in Rev704910 to upgrade to the AMQ 5.1.0 artifacts and to keep the console modules from building. Feel free to start creating patches and attaching them to this JIRA and we'll get them applied ASAP, so you can keep making progress. Thanks! > Upgrade to activeMQ 5.x > --- > > Key: GERONIMO-4337 > URL: https://issues.apache.org/jira/browse/GERONIMO-4337 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 2.2 >Reporter: David Jencks > Fix For: 2.2 > > > Upgrade activemq support to 5.x. A few steps along the way: > - create an activemq5 work area under plugins > - move the specification of amq version from the root pom dependency > management to the activemq and activemq5 plugins. > - keep only the broker gbean > - use an activemq configuration file in var/activemq, referenced by the > broker gbean > - update dependencies to latest activemq > - figure out how much of the current jms portlet functionality can be > reasonably kept. From discussions with Hiram I think that trying to > reconfigure the broker while its running is a very bad idea and we should > just drop the parts of the console that try to do this. > - investigate how to run the amq console in geronimo, preferably as portlets > inside the g. admin console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: An idea for defining custom valves in config.xml
On 15/10/2008, at 4:16 AM, David Jencks wrote: That's one of the main missing bits of functionality. Right now the only way to get the g-p.xml is to use c-m-p or to export the plugin from a server it's been deployed into, or to do something by hand with jar packing and unpacking. The biggest problem here, in my mind, is that jsr88 only wants you to have one "plan": to deploy something you get to specify the artifact and one "plan". Our deployment system is built around jsr88 so we either have to condense the g-p.xml and plan into one "plan" or abandon jsr88. At the moment I'm thinking that one satisfactory solution might be to more or less embed the plan into g-p.xml. Perhaps we could avoid duplicating most of the dependency info by adding the element to the dependencies in g-p.xml. I guess we'd expect a more or less empty element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g- p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/ tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks
[jira] Issue Comment Edited: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639780#action_12639780 ] weberjn edited comment on GERONIMO-4350 at 10/15/08 2:36 AM: -- The analysis of David Jencks is good, thanks very much. I changed EisConnectionFactory so it uses IEisConnection instead of the implementation EisConnection and txconnect.sourceforge.net works now (http://www.nabble.com/%24Proxy33-cannot-be-cast-to-com.dsoft.jca.eis.EisConnection-td19610387s134.html) was (Author: weberjn): The analysis of David Jencks is good, thanks very much. I changed EisConnectionFactory so it uses IEisConnection instead of the implementation EisConnection and an txconnector works now (http://www.nabble.com/%24Proxy33-cannot-be-cast-to-com.dsoft.jca.eis.EisConnection-td19610387s134.html) > Connection proxying to imitate DissociatableManagedConnection can easily > cause problems > --- > > Key: GERONIMO-4350 > URL: https://issues.apache.org/jira/browse/GERONIMO-4350 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.1, 2.2 >Reporter: David Jencks >Assignee: Dain Sundstrom > Fix For: 2.1.4, 2.2 > > > We have some code to imitate the DissociatableManagedConnection to avoid > connection leaks that proxies connections from the supplied > ManagedConnectionFactory: the proxy implements all the interfaces of the > connection, but not the class itself. However, there's nothing stopping the > ConnectionFactory from casting the (now proxied) connection to the > implementation class it expects. > The TxConnect project at sourceforge illustrates this approach in the > EisConnectionFactory. > http://txconnect.sourceforge.net > One possible solution would be to have a flag to turn on this proxying > behavior. I don't immediately see a way to detect if the problem will occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639780#action_12639780 ] Jürgen Weber commented on GERONIMO-4350: The analysis of David Jencks is good, thanks very much. I changed EisConnectionFactory so it uses IEisConnection instead of the implementation EisConnection and an txconnector works now (http://www.nabble.com/%24Proxy33-cannot-be-cast-to-com.dsoft.jca.eis.EisConnection-td19610387s134.html) > Connection proxying to imitate DissociatableManagedConnection can easily > cause problems > --- > > Key: GERONIMO-4350 > URL: https://issues.apache.org/jira/browse/GERONIMO-4350 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.1, 2.2 >Reporter: David Jencks >Assignee: Dain Sundstrom > Fix For: 2.1.4, 2.2 > > > We have some code to imitate the DissociatableManagedConnection to avoid > connection leaks that proxies connections from the supplied > ManagedConnectionFactory: the proxy implements all the interfaces of the > connection, but not the class itself. However, there's nothing stopping the > ConnectionFactory from casting the (now proxied) connection to the > implementation class it expects. > The TxConnect project at sourceforge illustrates this approach in the > EisConnectionFactory. > http://txconnect.sourceforge.net > One possible solution would be to have a flag to turn on this proxying > behavior. I don't immediately see a way to detect if the problem will occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 704797
Geronimo Revision: 704797 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081015/build-0300.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20081015 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 41 minutes 35 seconds [INFO] Finished at: Wed Oct 15 03:46:19 EDT 2008 [INFO] Final Memory: 403M/1024M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081015/logs-0300-tomcat/test.log Booting Geronimo Kernel (in Java 1.5.0_12)... Module 1/73 org.apache.geronimo.framework/j2ee-system/2.2-SNAPSHOT/car started in .000s Module 2/73 org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car started in .001s Module 3/73 org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car started in .224s Module 4/73 org.apache.geronimo.plugins.classloaders/geronimo-javaee-deployment_1.1MR3_spec/2.2-SNAPSHOT/car started in .001s Module 5/73 org.apache.geronimo.framework/plugin/2.2-SNAPSHOT/car started in .759s Module 6/73 org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car started in .265s Module 7/73 org.apache.geronimo.configs/j2ee-server/2.2-SNAPSHOT/car started in .082s Module 8/73 org.apache.geronimo.configs/transaction/2.2-SNAPSHOT/car started in .292s Module 9/73 org.apache.geronimo.framework/server-security-config/2.2-SNAPSHOT/car started in .083s Module 10/73 org.apache.geronimo.configs/jasper/2.2-SNAPSHOT/car started in .004s Module 11/73 org.apache.geronimo.framework/xmlbeans/2.2-SNAPSHOT/car started in .000s Module 12/73 org.apache.geronimo.plugins.classloaders/geronimo-schema-jee_5/2.2-SNAPSHOT/car started in .000s Module 13/73 org.apache.geronimo.configs/webservices-common/2.2-SNAPSHOT/car started in .000s Module 14/73 org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car started in 3.464s Module 15/73 org.apache.geronimo.configs/welcome-tomcat/2.2-SNAPSHOT/car started in .249s Module 16/73 org.apache.geronimo.framework/gshell-framework/2.2-SNAPSHOT/car started in .000s Module 17/73 org.apache.geronimo.framework/gshell-geronimo/2.2-SNAPSHOT/car started in .000s Module 18/73 org.apache.geronimo.framework/gshell-remote/2.2-SNAPSHOT/car started in .000s Module 19/73 org.apache.geronimo.configs/sharedlib/2.2-SNAPSHOT/car started in .007s Module 20/73 org.apache.geronimo.framework/transformer-agent/2.2-SNAPSHOT/car started in .000s Module 21/73 org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car started in .358s Module 22/73 org.apache.geronimo.configs/remote-deploy-tomcat/2.2-SNAPSHOT/car started in .188s Module 23/73 org.apache.geronimo.plugins.classloaders/xbean-finder/2.2-SNAPSHOT/car started in .000s Module 24/73 org.apache.geronimo.configs/j2ee-deployer/2.2-SNAPSHOT/car started in .272s Module 25/73 org.apache.geronimo.configs/connector-deployer/2.2-SNAPSHOT/car started in .119s Module 26/73 org.apache.geronimo.configs/tomcat6-deployer/2.2-SNAPSHOT/car started in .087s Module 27/73 org.apache.geronimo.configs/jasper-deployer/2.2-SNAPSHOT/car started in .010s Module 28/73 org.apache.geronimo.configs/hot-deployer/2.2-SNAPSHOT/car started in .325s Module 29/73 org.apache.geronimo.configs/client-deployer/2.2-SNAPSHOT/car 03:52:08,944 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName="org.apache.geronimo.configs/client-deployer/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/client-deployer/2.2-SNAPSHO
