Re: grails plugin
Just curios why one would even bother with this? Seems that this would only be useful when someone deploys more than one grails-based app into the sever... do folks even do that? And what if the 2 apps evolve differently and then need different versions of grails/groovy? And then the need of tools to take a grails war and turn it into a geronimo grails war... seems like too much work for little gain... and in some respect some loss. How big are the dependencies anyways? --jason On Nov 15, 2008, at 5:43 AM, Joe Bohn wrote: I started some preliminary work on a grails plugin that could be used to collect all of the grails dependencies so that they can be shared. Along with this we would need to provide a mechanism to generate a war file in grails which does not contain any of the common elements. I'd like to check in what I have thus far. There is only one catch. Some of the dependencies are Hibernate (LGPL). I've updated my poms with a scope of provided for the hibernate dependencies. Is that sufficient so that I can check the plugin into our SVN without any legal issues if somebody installs it? I'm also interested in additional thoughts on how to deal with the hibernate dependencies. Should I consider using prerequisite instead of dependency so that they must be installed (I'm not yet sure if a grails application will work without hibernate but I suspect that it should)? Comments appreciated. I'd really like to get this checked in under https://svn.apache.org/repos/asf/geronimo/plugins so it doesn't get lost even if it isn't quite ready for prime-time yet. Joe
[BUILD] trunk: Failed for Revision: 714213
Geronimo Revision: 714213 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081114/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081114
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 42 seconds
[INFO] Finished at: Fri Nov 14 21:43:17 EST 2008
[INFO] Final Memory: 388M/1013M
[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/20081114/logs-2100-tomcat/test.log
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:44.579
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:16.683)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:29.235)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.594)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:16.184)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:18.367)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:36.726)
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:44.476)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:44.905)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:55.264)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:45.853)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:30.787)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:27.111)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:29.025)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:47.517)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:47.860)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:51.995)
[INFO] enterprise-testsuite/sec-client RUNNING
[INFO] enterprise-testsuite/sec-client SUCCESS (0:00:26.336)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:50.844)
[INFO] security-testsuite/test-security RUNNING
[INFO] security
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
On 15/11/2008, at 5:08 AM, David Jencks wrote: On Nov 14, 2008, at 12:40 AM, Gianny Damour wrote: Hi, The definition of mark-up interfaces may require the definition of a specific mark-up interface for each deployer type. For instance, a MBE may be specific to Tomcat and not to Jetty. Hence we may need WebMBE, TomcatMBE amd JettyMBE. 1. So far we don't have any examples of such MBEs 2. Even if we did, this can easily be handled with a single WebMBE interface by not deploying the e.g. JettyMBEImpl on a tomcat server. Indeed, we do not have an example yet. Let's assume that we do. Also for kind of the same reason than giving a deployer reference to the MBE does not work, the mark-up interface is not the silver- bullet as it is not flexible enough: you may have two deployers and you may only want to add the MBE to one of them. I can't think of a remotely plausible example of this, could you suggest one? Let's also assume that we have Jetty and Tomcat deployers running in the same server. In this situation, we cannot selectively deploy the MBE as the server is running our two deployers and you only want to update one of them. Obviously the above point w/o an actual example is moot. Do you think that we will never see a deployer specific MBE? The explicit addition of a reference pattern provides the best flexibility. As pointed out, it requires some explicit configuration. However it is already supported through two mechanisms: manual update of config.xml or script deployment. True, but it is not a declarative solution to the problem, it involves procedural code. Since we've gotten everything else to work with a declarative solution I'd like to see if we can solve this problem declaratively also. OK. I have started to believe that XML declarations should be replaced by DSLs. Also, the introduction of mark-up interfaces increases the number of things that developers need to know. What do you think of using annotations instead of interfaces? This is the preferred style I think. Thanks, Gianny thanks david jencks Thanks, Gianny On 14/11/2008, at 4:58 AM, Vamsavardhana Reddy wrote: I agree that we need a general solution to dynamically add MBEs. The trick that Gianny showed does got me going with the Tuscany plugin work that I am doing. On Thu, Nov 13, 2008 at 11:21 PM, David Jencks <[EMAIL PROTECTED]> wrote: These solutions certainly work but don't address the fundamental problem of adding MBE's dynamically to some builders and not others. For instance we can just modify the tomcat6-deployer plan right now to include the tuscany MBE and guess that eventually we'll have a jetspeed MBE and try to think of some more. But when someone comes up with a new one we didn't imagine -- jspwiki MBE or something -- they'll have to update the list again. I would like to solve the problem once and for all so that no specific configuration for particular MBE's is needed. Making the reference go the other way -- giving the MBE a reference to the web deployer -- won't work well for the same reason, we don't know how many web deployers there will be next week, even if we only have two this week. thanks david jencks On Nov 13, 2008, at 3:21 AM, Vamsavardhana Reddy wrote: Thanks Gianny. I could add the MBE to TomcatBuilder by modifying config.xml. I have added the following gbean under "org.apache.geronimo.configs/tomcat6-deployer/2.1.3/car" to modify the reference to include a new MBE: PersistenceUnitBuilder JspModuleBuilderExtension MyFacesModuleBuilderExtension TuscanyModuleBuilderExtension On Thu, Nov 13, 2008 at 4:10 PM, Gianny Damour <[EMAIL PROTECTED]> wrote: On 13/11/2008, at 10:08 AM, David Jencks wrote: On Nov 12, 2008, at 1:07 PM, Vamsavardhana Reddy wrote: As part of deploying SCA enhanced Web Applications in Geronimo with Tuscany Plugin, I am looking to add a ModuleBuilderExtension (MBE) to TomcatModuleBuilder and a NamingBuilder. The purpose of the MBE is to add SCA related EmbeddedRuntimeGBean to the web application config which will deploy the application composite to the SCA domain. The purpose of the NamingBuilder is to add SCA Domain and other objects (required for injection of SCA references in servlets etc.) into the WebAppContext. I am seeing that the MBE and NamingBuilder GBeans which are added as part of the Tuscany Plugin can not get dynamically added to the MBEs configured in tomcat6-builder config and NamingBuilders configured in j2ee-deployer config. The one option I see is to update the plan.xml files in tomcat6- builder and j2ee-deployer configs and rebuild the server. But this won't be like the
[jira] Commented: (GERONIMO-4387) Incorrect JNDI name in the monitor portlet's plan file
[ https://issues.apache.org/jira/browse/GERONIMO-4387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647793#action_12647793 ] Ivan commented on GERONIMO-4387: Thanks Jarek, I always use EJBBeanRemoteHome for jndi-name, and EJBBeanLocalHome for local-jndi-name. After googled, it seems that in EJB 3.0, we always use EJBBean for the JNDI name, for no home interface is required. Right ? > Incorrect JNDI name in the monitor portlet's plan file > -- > > Key: GERONIMO-4387 > URL: https://issues.apache.org/jira/browse/GERONIMO-4387 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.2 > Environment: Windows XP > JDK 1.5 >Reporter: Ivan >Assignee: Jarek Gawor > Fix For: 2.2 > > Attachments: Geronimo-4387-11.14.patch, Geronimo-4387.patch > > > Incorrect jndi name is set in monitor portlet, the home JNDI name should be > "ejb/mgmt/MEJBRemoteHome", or the > org.apache.geronimo.monitoring.MasterRemoteControl will throw the exception > : javax.naming.NameNotFoundException: Name "ejb/mgmt/MEJBRemoteHome" not > found. -- 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-4395) EmployeeDatasource and jdbc/EmployeeDatasource create the same files under $geronimo_install_dir/repository/console/dbpool directory
True, I will open a JIRA to track it.Thanks, Lin ! 2008/11/15 Lin Sun (JIRA) <[EMAIL PROTECTED]> > >[ > https://issues.apache.org/jira/browse/GERONIMO-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647653#action_12647653] > > Lin Sun commented on GERONIMO-4395: > --- > > BTW, I forgot to mention - I think a better approach is to allow users to > config their own groupid (currently has to be console.db), version > (currently has to be 1.0) and artifactId, from the portlet page. Ivan, if > you like you are welcome to submit a patch for that. > > Thanks > > Lin > > > EmployeeDatasource and jdbc/EmployeeDatasource create the same files > under $geronimo_install_dir/repository/console/dbpool directory > > > > > > > Key: GERONIMO-4395 > > URL: https://issues.apache.org/jira/browse/GERONIMO-4395 > > Project: Geronimo > > Issue Type: Bug > > Security Level: public(Regular issues) > > Components: databases > >Affects Versions: 2.1.3 > > Environment: Any platform > >Reporter: viola.lu > >Assignee: Lin Sun > >Priority: Minor > > Attachments: Geronimo-4395-1109.patch, > Geronimo-4395-1114-with-replace.patch, > Geronimo-4395-1114-without-replace.patch, Geronimo-4395.patch > > > > > > Steps: > > 1.Login geronimo, go to database pool, create a "EmployeeDatasource" > datasource with any db type. > > 2.create another "jdbc/EmployeeDatasource" datasource with any db type. > But some read error display that > > EmployeeDatasource has existed in database pool. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- Ivan
Re: [jira] Resolved: (GERONIMO-4141) The war exported as a geronimo plugin in admin console cannot be installed with install-plugin command of deploy.bat|.sh
Thanks for the comment, Lin, I will be care while creating the patch. 2008/11/15 Lin Sun (JIRA) <[EMAIL PROTECTED]> > > [ > https://issues.apache.org/jira/browse/GERONIMO-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Lin Sun resolved GERONIMO-4141. > --- > > Resolution: Fixed > > Patch committed to branch 2.1 + trunk (see revisions under subversion > commit tab) > > Ivan, please generate patch from the root dir in the future. Thanks for > the patch > > Lin > > > The war exported as a geronimo plugin in admin console cannot be > installed with install-plugin command of deploy.bat|.sh > > > > > > > Key: GERONIMO-4141 > > URL: https://issues.apache.org/jira/browse/GERONIMO-4141 > > Project: Geronimo > > Issue Type: Bug > > Security Level: public(Regular issues) > >Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3 > > Environment: SLES 10 SP2, JDK 1.5.0 > >Reporter: Forrest Xia > >Assignee: Lin Sun > >Priority: Minor > > Fix For: 2.1.4 > > > > Attachments: Geronimo-4141.patch, jsp-examples-2.1.0.0.war, > jsp-examples-war-2.1-SNAPSHOT.war > > > > > > Steps: > > 1. install a war > > 2. export the war as a G plugin with admin console's export plugin > function > > 3. undeploy it thru console, and use deployer install-plugin command to > install the exported war > > Results: The installation failed with message like this "installation > FAILED: start of org.apache.geronimo.samples/cviewer/2.1.0.0/war failed". > > The server log includes these exceptions: > > "17:12:38,335 ERROR [GBeanInstance] Problem in doFail of samples/cviewer/ > 2.1.0.0/war?J2EEApplication=null,j2eeType=WebModule,name=samples/cviewer/2.1.0.0/war > > java.lang.NullPointerException > > at > org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:380) > > at > org.apache.geronimo.tomcat.TomcatWebAppContext.doFail(TomcatWebAppContext.java:540) > > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1028) > > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) > > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541) > > at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) > > at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) > > at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) > > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) > > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) > > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) > > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) > > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) > > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555) > > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) > > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) > > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) > > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562) > > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:543) > > at > org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:684) > > at > org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:877) > > at > org.apache.geronimo.system.plugin.PluginInstallerGBean$4.run(PluginInstallerGBean.java:787) > > at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214) > > at > org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) > > at > java.util.concu
Re: grails plugin
On Nov 14, 2008, at 2:43 PM, Joe Bohn wrote: I started some preliminary work on a grails plugin that could be used to collect all of the grails dependencies so that they can be shared. Along with this we would need to provide a mechanism to generate a war file in grails which does not contain any of the common elements. I'd like to check in what I have thus far. There is only one catch. Some of the dependencies are Hibernate (LGPL). I've updated my poms with a scope of provided for the hibernate dependencies. Is that sufficient so that I can check the plugin into our SVN without any legal issues if somebody installs it? I think so but get confused by the legal issues. I'm also interested in additional thoughts on how to deal with the hibernate dependencies. Should I consider using prerequisite instead of dependency so that they must be installed (I'm not yet sure if a grails application will work without hibernate but I suspect that it should)? I think this is the most plausible use of prerequisites that anyone has suggested so far. Comments appreciated. I'd really like to get this checked in under https://svn.apache.org/repos/asf/geronimo/plugins so it doesn't get lost even if it isn't quite ready for prime-time yet. That's fine with me sandbox would also be ok if you foresee problems getting it done but I'd prefer plugins. Does grails use proprietary hibernate features not available in jpa or are they just stuck on a particular dependency for no particular reason? thanks david jencks Joe
grails plugin
I started some preliminary work on a grails plugin that could be used to collect all of the grails dependencies so that they can be shared. Along with this we would need to provide a mechanism to generate a war file in grails which does not contain any of the common elements. I'd like to check in what I have thus far. There is only one catch. Some of the dependencies are Hibernate (LGPL). I've updated my poms with a scope of provided for the hibernate dependencies. Is that sufficient so that I can check the plugin into our SVN without any legal issues if somebody installs it? I'm also interested in additional thoughts on how to deal with the hibernate dependencies. Should I consider using prerequisite instead of dependency so that they must be installed (I'm not yet sure if a grails application will work without hibernate but I suspect that it should)? Comments appreciated. I'd really like to get this checked in under https://svn.apache.org/repos/asf/geronimo/plugins so it doesn't get lost even if it isn't quite ready for prime-time yet. Joe
[jira] Created: (GERONIMO-4412) Upgrade jspc-maven-plugin and jspc-compiler-tomcat6 to 2.0-alpha-2
Upgrade jspc-maven-plugin and jspc-compiler-tomcat6 to 2.0-alpha-2 -- Key: GERONIMO-4412 URL: https://issues.apache.org/jira/browse/GERONIMO-4412 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Affects Versions: 2.2 Reporter: Joe Bohn Assignee: Joe Bohn Priority: Minor Fix For: 2.2 from 2.0-alpha-2-SNAPSHOT. -- 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: 714122
Geronimo Revision: 714122 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081114/build-1500.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081114
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 39 minutes
[INFO] Finished at: Fri Nov 14 15:43:32 EST 2008
[INFO] Final Memory: 387M/1012M
[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/20081114/logs-1500-tomcat/test.log
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:47.734
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:13.753)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:29.012)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.934)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:15.876)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:18.611)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:38.094)
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:45.275)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:46.507)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:01:34.815)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:45.066)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:30.786)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:27.802)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:29.588)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:46.384)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:47.970)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:51.057)
[INFO] enterprise-testsuite/sec-client RUNNING
[INFO] enterprise-testsuite/sec-client SUCCESS (0:00:26.456)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:54.766)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
On Nov 14, 2008, at 12:40 AM, Gianny Damour wrote: Hi, The definition of mark-up interfaces may require the definition of a specific mark-up interface for each deployer type. For instance, a MBE may be specific to Tomcat and not to Jetty. Hence we may need WebMBE, TomcatMBE amd JettyMBE. 1. So far we don't have any examples of such MBEs 2. Even if we did, this can easily be handled with a single WebMBE interface by not deploying the e.g. JettyMBEImpl on a tomcat server. Also for kind of the same reason than giving a deployer reference to the MBE does not work, the mark-up interface is not the silver- bullet as it is not flexible enough: you may have two deployers and you may only want to add the MBE to one of them. I can't think of a remotely plausible example of this, could you suggest one? The explicit addition of a reference pattern provides the best flexibility. As pointed out, it requires some explicit configuration. However it is already supported through two mechanisms: manual update of config.xml or script deployment. True, but it is not a declarative solution to the problem, it involves procedural code. Since we've gotten everything else to work with a declarative solution I'd like to see if we can solve this problem declaratively also. thanks david jencks Thanks, Gianny On 14/11/2008, at 4:58 AM, Vamsavardhana Reddy wrote: I agree that we need a general solution to dynamically add MBEs. The trick that Gianny showed does got me going with the Tuscany plugin work that I am doing. On Thu, Nov 13, 2008 at 11:21 PM, David Jencks <[EMAIL PROTECTED] > wrote: These solutions certainly work but don't address the fundamental problem of adding MBE's dynamically to some builders and not others. For instance we can just modify the tomcat6-deployer plan right now to include the tuscany MBE and guess that eventually we'll have a jetspeed MBE and try to think of some more. But when someone comes up with a new one we didn't imagine -- jspwiki MBE or something -- they'll have to update the list again. I would like to solve the problem once and for all so that no specific configuration for particular MBE's is needed. Making the reference go the other way -- giving the MBE a reference to the web deployer -- won't work well for the same reason, we don't know how many web deployers there will be next week, even if we only have two this week. thanks david jencks On Nov 13, 2008, at 3:21 AM, Vamsavardhana Reddy wrote: Thanks Gianny. I could add the MBE to TomcatBuilder by modifying config.xml. I have added the following gbean under "org.apache.geronimo.configs/tomcat6-deployer/2.1.3/car" to modify the reference to include a new MBE: PersistenceUnitBuilder JspModuleBuilderExtension MyFacesModuleBuilderExtension TuscanyModuleBuilderExtension On Thu, Nov 13, 2008 at 4:10 PM, Gianny Damour <[EMAIL PROTECTED] > wrote: On 13/11/2008, at 10:08 AM, David Jencks wrote: On Nov 12, 2008, at 1:07 PM, Vamsavardhana Reddy wrote: As part of deploying SCA enhanced Web Applications in Geronimo with Tuscany Plugin, I am looking to add a ModuleBuilderExtension (MBE) to TomcatModuleBuilder and a NamingBuilder. The purpose of the MBE is to add SCA related EmbeddedRuntimeGBean to the web application config which will deploy the application composite to the SCA domain. The purpose of the NamingBuilder is to add SCA Domain and other objects (required for injection of SCA references in servlets etc.) into the WebAppContext. I am seeing that the MBE and NamingBuilder GBeans which are added as part of the Tuscany Plugin can not get dynamically added to the MBEs configured in tomcat6-builder config and NamingBuilders configured in j2ee-deployer config. The one option I see is to update the plan.xml files in tomcat6-builder and j2ee-deployer configs and rebuild the server. But this won't be like the MBE and NamingBuilder is getting added as part of Tuscany-plugin installation. The other option is to add (don't know if it is easy to do this hack) the MBE and NamingBuilder to the corresponding collections in TomcatModuleBuilder and NamingBuilder GBeans. I appreciate any suggestions/comments or inputs on any alternate approach that I am not seeing. Yup, this is a problem. So far we've sidestepped it by just adding all the known desired MBE's to the appropriate *-deployer plan, and as you have found this is non-extensible. I do not understand why overriding the relevant TomcatModuleBuilder GBean pattern in config.xml does not work. This is better than having to redeploy the tomcat6-builder plugin. If the problem is to provide a way to update th
Re: Update on documentation progress of Geronimo v2.2
I "fixed up" some of the references to GEP pages. There is some duplication of GEP info between two sets of pages: "Development environment" and "How to install Geronimo Eclipse Plugin". A couple of months ago I removed the installation instructions from the former, and replaced them with a link to the latter. The idea is to keep this information in one place. You can follow the gory details of this work in GERONIMODEVTOOLS-461. The plan is that there will be a "How to install Geronimo Eclipse Plugin" page for each release. Old and new releases are children of this page. The design of "Development environment" page seemed to be to put everything on one big page. I don't think this is a good approach. I think pages should be shorter and more focused. For example, breaking out the installation information. Hopefully, we can all by in sync moving forward. I think the GEP doc needs some work in terms of integrating it into the overall G doc, and eliminating duplication. Hopefully this can occur in G 2.2 and beyond. Thanks, Ted Kirby On Fri, Nov 14, 2008 at 1:13 AM, chi runhua <[EMAIL PROTECTED]> wrote: > Hi all, > > We just created a page with one table of content to track progress of > Geronimo 2.2 documentation. In this table, we highlighted some topics to be > updated based on G 2.2 release roadmap. We believe that not every topic was > included so far. Therefore, don't hesitate updating the table if you have > new discoveries or topics. We also encourage everyone in this community to > adopt topics and contribute more to the success of Geronimo. > > Here is the linkage for your reference. > http://cwiki.apache.org/confluence/display/GMOxDOC22/Apache+Geronimo+v2.2+documentation+development+status > > What we are planning to do next are: > > 1. Moving pages to their appropriate parent so that the structure will be > more like a "tree"; ---> Ongoing > 2. Keep the consistency between different topics including subject, wording > and phrases; > 3. Keep migrating topics from previous documentation and update them if > capable; > 4. Refine the granuality by dividing unique topics into pages, in this way, > contibutors can include existing pages while writing a new topics instead of > introducing basic concepts again and again. (might be difficult, but I hope > it's the right direction); > > We are expecting to receive as much as feedback and opinions about > documentation so that we can make it better and better. > > Thanks alot. > > > > > > > > > > >
[jira] Resolved: (GERONIMO-4141) The war exported as a geronimo plugin in admin console cannot be installed with install-plugin command of deploy.bat|.sh
[ https://issues.apache.org/jira/browse/GERONIMO-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4141. --- Resolution: Fixed Patch committed to branch 2.1 + trunk (see revisions under subversion commit tab) Ivan, please generate patch from the root dir in the future. Thanks for the patch Lin > The war exported as a geronimo plugin in admin console cannot be installed > with install-plugin command of deploy.bat|.sh > > > Key: GERONIMO-4141 > URL: https://issues.apache.org/jira/browse/GERONIMO-4141 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3 > Environment: SLES 10 SP2, JDK 1.5.0 >Reporter: Forrest Xia >Assignee: Lin Sun >Priority: Minor > Fix For: 2.1.4 > > Attachments: Geronimo-4141.patch, jsp-examples-2.1.0.0.war, > jsp-examples-war-2.1-SNAPSHOT.war > > > Steps: > 1. install a war > 2. export the war as a G plugin with admin console's export plugin function > 3. undeploy it thru console, and use deployer install-plugin command to > install the exported war > Results: The installation failed with message like this "installation FAILED: > start of org.apache.geronimo.samples/cviewer/2.1.0.0/war failed". > The server log includes these exceptions: > "17:12:38,335 ERROR [GBeanInstance] Problem in doFail of > samples/cviewer/2.1.0.0/war?J2EEApplication=null,j2eeType=WebModule,name=samples/cviewer/2.1.0.0/war > java.lang.NullPointerException > at > org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:380) > at > org.apache.geronimo.tomcat.TomcatWebAppContext.doFail(TomcatWebAppContext.java:540) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1028) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) > at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:543) > at > org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:684) > at > org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:877) > at > org.apache.geronimo.system.plugin.PluginInstallerGBean$4.run(PluginInstallerGBean.java:787) > at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214) > at > org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) > at java.lang.Thread.run(Thread.java:810) > 17:12:38,338 ERROR [GBeanInstanceState] Error while starting; GBean is now in > the FAILED state: >
[jira] Commented: (GERONIMO-4395) EmployeeDatasource and jdbc/EmployeeDatasource create the same files under $geronimo_install_dir/repository/console/dbpool directory
[ https://issues.apache.org/jira/browse/GERONIMO-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647653#action_12647653 ] Lin Sun commented on GERONIMO-4395: --- BTW, I forgot to mention - I think a better approach is to allow users to config their own groupid (currently has to be console.db), version (currently has to be 1.0) and artifactId, from the portlet page. Ivan, if you like you are welcome to submit a patch for that. Thanks Lin > EmployeeDatasource and jdbc/EmployeeDatasource create the same files under > $geronimo_install_dir/repository/console/dbpool directory > > > Key: GERONIMO-4395 > URL: https://issues.apache.org/jira/browse/GERONIMO-4395 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: databases >Affects Versions: 2.1.3 > Environment: Any platform >Reporter: viola.lu >Assignee: Lin Sun >Priority: Minor > Attachments: Geronimo-4395-1109.patch, > Geronimo-4395-1114-with-replace.patch, > Geronimo-4395-1114-without-replace.patch, Geronimo-4395.patch > > > Steps: > 1.Login geronimo, go to database pool, create a "EmployeeDatasource" > datasource with any db type. > 2.create another "jdbc/EmployeeDatasource" datasource with any db type. But > some read error display that > EmployeeDatasource has existed in database pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4395) EmployeeDatasource and jdbc/EmployeeDatasource create the same files under $geronimo_install_dir/repository/console/dbpool directory
[ https://issues.apache.org/jira/browse/GERONIMO-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMO-4395. - Close issue. Tested with many scenarios and the itest. > EmployeeDatasource and jdbc/EmployeeDatasource create the same files under > $geronimo_install_dir/repository/console/dbpool directory > > > Key: GERONIMO-4395 > URL: https://issues.apache.org/jira/browse/GERONIMO-4395 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: databases >Affects Versions: 2.1.3 > Environment: Any platform >Reporter: viola.lu >Assignee: Lin Sun >Priority: Minor > Attachments: Geronimo-4395-1109.patch, > Geronimo-4395-1114-with-replace.patch, > Geronimo-4395-1114-without-replace.patch, Geronimo-4395.patch > > > Steps: > 1.Login geronimo, go to database pool, create a "EmployeeDatasource" > datasource with any db type. > 2.create another "jdbc/EmployeeDatasource" datasource with any db type. But > some read error display that > EmployeeDatasource has existed in database pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4395) EmployeeDatasource and jdbc/EmployeeDatasource create the same files under $geronimo_install_dir/repository/console/dbpool directory
[ https://issues.apache.org/jira/browse/GERONIMO-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4395. --- Resolution: Fixed Patch with slight modification committed to trunk and branch 2.1 (see revisions under subversion tab). Took Ivan and David's suggestion and simply replace / with _. Many thanks Ivan for the patches and David for the input! > EmployeeDatasource and jdbc/EmployeeDatasource create the same files under > $geronimo_install_dir/repository/console/dbpool directory > > > Key: GERONIMO-4395 > URL: https://issues.apache.org/jira/browse/GERONIMO-4395 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: databases >Affects Versions: 2.1.3 > Environment: Any platform >Reporter: viola.lu >Assignee: Lin Sun >Priority: Minor > Attachments: Geronimo-4395-1109.patch, > Geronimo-4395-1114-with-replace.patch, > Geronimo-4395-1114-without-replace.patch, Geronimo-4395.patch > > > Steps: > 1.Login geronimo, go to database pool, create a "EmployeeDatasource" > datasource with any db type. > 2.create another "jdbc/EmployeeDatasource" datasource with any db type. But > some read error display that > EmployeeDatasource has existed in database pool. -- 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: 714007
Geronimo Revision: 714007 built with tests included
See the full build-0900.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081114/build-0900.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081114
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 44 minutes 9 seconds
[INFO] Finished at: Fri Nov 14 09:47:46 EST 2008
[INFO] Final Memory: 368M/1013M
[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/20081114/logs-0900-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.framework:geronimo-deploy-jsr88:2.2-SNAPSHOT: checking for
updates from apache.snapshots
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:46.901
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:13.946)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:28.739)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.575)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:15.748)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:17.690)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:36.664)
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:44.315)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:45.899)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:44.215)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:46.346)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:30.356)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:27.258)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:29.189)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:48.718)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:49.425)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:56.378)
[INFO] enterprise-testsuite/sec-client RUNNING
[INFO] enterprise-testsuite/sec-client SUCCESS (0:00:26.565)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise
[jira] Resolved: (GERONIMO-4409) Eliminate ianal-maven-plugin snapshot
[ https://issues.apache.org/jira/browse/GERONIMO-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn resolved GERONIMO-4409. Resolution: Fixed > Eliminate ianal-maven-plugin snapshot > -- > > Key: GERONIMO-4409 > URL: https://issues.apache.org/jira/browse/GERONIMO-4409 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 2.2 >Reporter: Joe Bohn >Assignee: Joe Bohn >Priority: Minor > Fix For: 2.2 > > > replace with released 1.0-alpha-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tools.jar expected but not found on Mac OS 10.5.5
Jarek, OK, issue created. Thanks Karel Jarek Gawor-2 wrote: > > First, create account on > https://issues.apache.org/jira/secure/Dashboard.jspa and then use > "create new issue" link to create a new bug report. Make sure to > specify "Geronimo" as the project name. > > Jarek > > On Thu, Nov 13, 2008 at 2:35 PM, yosemite <[EMAIL PROTECTED]> wrote: >> >> Hello Jarek >> >> can u give me a few pointers how to open a bug, please, I'm a total >> novice >> to Geronimo project >> >> Thanks >> Karel >> >> >> >> Jarek Gawor-2 wrote: >>> >>> Can you please open a bug on this issue? >>> >>> Jarek >>> >>> On Thu, Nov 13, 2008 at 10:12 AM, yosemite <[EMAIL PROTECTED]> wrote: Hello, @WebService used on EJB3 @Stateless does not generate the service complaining about tools.jar not found. Kevan suggested this: $ cd /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0 $ sudo mkdir lib $ cd lib $ sudo ln -s ../Classes/classes.jar tools.jar then it works. Mac OS Java does not contain the /lib folder nor tools.jar Karel -- View this message in context: http://www.nabble.com/Tools.jar-expected-but-not-found-on-Mac-OS-10.5.5-tp20481641s134p20481641.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Tools.jar-expected-but-not-found-on-Mac-OS-10.5.5-tp20481641s134p20487928.html >> Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Tools.jar-expected-but-not-found-on-Mac-OS-10.5.5-tp20481641s134p20500889.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Created: (GERONIMO-4411) Tools.jar expected but not found on Mac OS 10.5.5
Tools.jar expected but not found on Mac OS 10.5.5 - Key: GERONIMO-4411 URL: https://issues.apache.org/jira/browse/GERONIMO-4411 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1.3 Environment: Mac OS X 10.5.5 Reporter: Karel Michek @WebService used on EJB3 @Stateless does not generate the service complaining about tools.jar not found. Kevan suggested this: $ cd /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0 $ sudo mkdir lib $ cd lib $ sudo ln -s ../Classes/classes.jar tools.jar then it works. Mac OS Java does not contain the /lib folder nor tools.jar Karel -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 2.2 (trunk) bucket-o-snapshots
Gianny Damour wrote: On 13/11/2008, at 5:13 AM, Joe Bohn wrote: Gianny Damour wrote: On 12/11/2008, at 10:04 AM, Joe Bohn wrote: It has been mentioned several times that we should be looking to release Geronimo 2.2 before the end of the year (preferrably mid-December). Before we can consider a release there are a large number of snapshots that need to be removed/replaced in our project. Can anybody shed any light on these (or others that I may have missed)? -wadi 2.1-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're using 2.0. What function requires 2.1-SNAPSHOT and is can somebody directly involved with wadi provide an estimate on when this might be released? I will release WADI 2.1 whenever a release version is required for Geronimo. Thanks Gianny. Is there any reason to avoid pursuing a release now? Are you anticipating more changes from Geronimo or other projects soon? Any snapshot dependencies that we can quickly remove will help us more keenly focus on those that require a bit more effort. Well, I am working on and off on WADI cache, which will provide a distributed, replicated and transactional cache. Have a look here https://svn.codehaus.org/wadi/trunk/wadi/wadi-cache/src/test/java/org/codehaus/wadi/cache/demo/Main.java if you want to see a sample. Obviously, if people are interested to help, then please ping me. I understand where you are coming from. Rest assure that the cut of a WADI release is not a severe dependency for Geronimo 2.2. What do you think of me cutting a release end November, say the week-end of November 29th? Thanks, Gianny Thanks for the information. The end of November is great! I'm just trying to eliminate as many unknowns as possible. You have been very responsive and helpful - much thanks! Joe
Re: 2.2 (trunk) bucket-o-snapshots
Jarek, Thanks for the information. I know that you are still spending a lot of time on Axis2 so let me know if you want help getting the concurrent spec out for vote. If Axis2 and it's dependencies aren't released in time we may have to consider a private build :-( (or a later release of 2.2). Joe Jarek Gawor wrote: Axiom, XmlSchema, and Woden are all dependencies of Axis2. There is a plan for Axis2 release at the end of this month but I'm not sure if it's going to happen with all these dependencies. So getting Axis2 release might be an issue to us. As to geronimo-concurrent_1.0_spec 1.0-SNAPSHOT, we can get that released now. I have no pending updates for it. Jarek On Tue, Nov 11, 2008 at 6:04 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: It has been mentioned several times that we should be looking to release Geronimo 2.2 before the end of the year (preferrably mid-December). Before we can consider a release there are a large number of snapshots that need to be removed/replaced in our project. Can anybody shed any light on these (or others that I may have missed)? OpenEJB 3.1-SNAPSHOT - Actually, OpenEJB 3.1 was released in late October. However, the trunk version was never updated and some additional changes have been included. Recent changes in Geronimo trunk now require this snapshot that is actually newer than the 3.1 release. IMO we should revert the trunk change and attempt to work with the released OpenEJB 3.1. Axis2 SNAPSHOT (yep, it's just SNAPSHOT without a number). IIUC correctly we need to get an Axis2 release before we can consider a Geronimo 2.2 release. Does anybody know how close we are to getting an Axis2 release? Axiom SNAPSHOT (yep. it's just SNAPSHOT too). I believe this is required by Axis2 ... so if Axis2 is released then they will have to get Axiom released as well (and we can pick up the released version). -xBean 3.5-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're still using 3.3. It looks like the latest released version is 3.4.3. I'll give that a shot if I don't hear from anybody that we really need 3.5. -wadi 2.1-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're using 2.0. What function requires 2.1-SNAPSHOT and is can somebody directly involved with wadi provide an estimate on when this might be released? -geronimo_j2ee-connector_1.6_spec 1.0-EA-SNAPSHOT. Are we at a point where we can release this spec or do we need to wait until we verify tck? - geronimo-jaspi_1.0_spec 1.0-SNAPSHOT. Are we at a point where we can release this spec or do we need to wait until we verify tck? - geronimo-servlet_3.0_spec 1.0-EA-SNAPSHOT. Are we at a point where we can release this spec or do we need to wait until we verify tck? - geronimo-jaspi 1.0-SNAPSHOT. This is a new geronimo component. How close is this to being able to be released? - geronimo-concurrent_1.0_spec 1.0-SNAPSHOT. How close is this to being able to be released? - XmlSchema SNAPSHOT (yep, it's just SNAPSHOT). I believe this is also related to Axis2 dependencies and will have to be resolved by Axis2 as they release. - woden* 1.0-SNAPSHOT. This is also related to Axis2 and will have to be resolved for an Axis2 release so we will pull in whatever they require. - selenium-maven-plugin 1.0-rc-1-SNAPSHOT. I believe that we pulled this in trying to resolve the FF3 issues. It's not clear to me if we would have to remove this SNAPSHOT prior to a release but I think it would be best to ensure that the tagged release can always be built and run with tests - therefore I think we should remove it. Any other opinions? - jspc-maven-plugin 2.0-alpha-2-SNAPSHOT. I'm not sure why this is updated (in branches/2.1 we use 2.0-alpha-1-20070806). Anybody know? We should remove it. - jspc-compiler-tomcat6 2.0-alpha-2-SNAPSHOT. I'm not sure why this was updated either. In branches/2.1 we updated the maven plugin (above) but not the compiler but in trunk both were updated to the alpha-2-SNAPSHOT. Anybody know why? - ianal-maven-plugin 1.0-alpha-1-SNAPSHOT. No doubt to support the new legal file processing. Is there a released version we can use instead of the SNAPSHOT or do we need to get a release here are well? Joe
[jira] Commented: (GERONIMODEVTOOLS-473) Problem starting server with WTP201
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647573#action_12647573 ] Jean-Jacques Parent commented on GERONIMODEVTOOLS-473: -- Pb with first email> Date: Thu, 13 Nov 2008 23:24:47 -0800> From: [EMAIL PROTECTED]> To: [EMAIL PROTECTED]> Subject: [jira] Commented: (GERONIMODEVTOOLS-473) Problem starting server with WTP201> > > [ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647531#action_12647531 ] > > Jean-Jacques Parent commented on GERONIMODEVTOOLS-473:> --> > > Tim I apologized for my late answer.Very busy: 2 new applications with geronimo and the new brussels website on line this month.I have no time for the moment to deal with your last mail, but as soon as possible, I will give you a feedback For your infiormation, for the last developments with Geronimo, I prefered using the myEclipse plugin (unfortunatetly in production mode: issue 472):According to the type of J2EE files here is the behavior, which is better than GEP (for the moment with my ear application) - When modifying a helper/controller/dao class, the hot deployment works- When modifying a POJO, I had to restart the application server. (But it was also the case with weblogic even in development mode)- When modifying a jsp, hot deployment does not work, but I manually copy them from my workspace to the geronimo application repositoryThis way, I am not losing so much development time As I am talking about the myEclipse plugin for geronimo, I make you notice that I have another issue 472 dealing with the problem that I can't do an exploded deployment (development mode) because of my Ejb. In the meantime, I have posted an issue to the myEclipse team support, according to them, this is a problem with the geronimo deployment process...Here is the issue for information:http://www.myeclipseide.com/index.php?name=PNphpBB2&file=viewtopic&p=98020#98020 Whatever, I will work on those problem asap. I really need a convenient development environment for the next year as the number of geronimo projects increase! Kind regards Jean-Jacques Date: Fri, 10 Oct 2008 19:31:44 -0700> From: [EMAIL PROTECTED]> To: [EMAIL PROTECTED]> Subject: [jira] Issue Comment Edited: (GERONIMODEVTOOLS-473) Problem starting server with WTP201> > > [ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638706#action_12638706 ] > > mcconne edited comment on GERONIMODEVTOOLS-473 at 10/10/08 7:30 PM:> --> > Hi Jean-Jacques, I finally have a better understanding of your problem. Thanks for all the material you've supplied via this Jira and as email attachments. One option that we've had a lot of success in the past with to speed up deployment/redeployment from the GEP is to use the sharedlib capability of Geronimo. Since you cannot send me your Eclipse workspace I wonder if you have one or more POJO projects in your workspace that is shared amongst multiple web projects in your workspace (i.e, there is a J2EE dependency between the Web project and the POJO which will embed the POJO JAR in the Web project's WAR).> > If so, when using sharedlib support, when the WAR gets deployed the POJO project will get deployed in-place to the sharedlib, and the actual contents of the POJO do not get copied over. instead a Dummy JAR gets created inside sharedlib that contains a manifest file that points back to the project in the workspace. This can significantly speed up deployments within Eclipse especially when there are many deployable artifacts with the same POJO dependency. > > Do you know if this is the case with your workspace ?? If not we'll have to search for another alternative. Thanks much> > was (Author: mcconne):> Hi Jean-Jacques, I finally have a better understanding of your problem. Thanks for all the material you've supplied via this Jira and as email attachments. One option that we've had a lot of success in the past with to speed up deployment/redeployment from the GEP is to use the sharedlib capability of Geronimo. Since you cannot send me your Eclipse workspace I wonder if you have one or more POJO projects in your workspace that is shared amongst multiple web projects in your workspace (i.e, there is a J2EE dependency between the Web project and the POJO which will embed the POJO JAR in the Web project's WAR).> > If so, when using sharedlib support, when the WAR gets deployed the POJO project will get deployed in-place to the sharedlib, and the actual contents of the POJO do not get copied over. instead a Dummy JAR gets created inside sharedl
Re: 2.2 (trunk) bucket-o-snapshots
On 13/11/2008, at 5:13 AM, Joe Bohn wrote: Gianny Damour wrote: On 12/11/2008, at 10:04 AM, Joe Bohn wrote: It has been mentioned several times that we should be looking to release Geronimo 2.2 before the end of the year (preferrably mid- December). Before we can consider a release there are a large number of snapshots that need to be removed/replaced in our project. Can anybody shed any light on these (or others that I may have missed)? -wadi 2.1-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're using 2.0. What function requires 2.1-SNAPSHOT and is can somebody directly involved with wadi provide an estimate on when this might be released? I will release WADI 2.1 whenever a release version is required for Geronimo. Thanks Gianny. Is there any reason to avoid pursuing a release now? Are you anticipating more changes from Geronimo or other projects soon? Any snapshot dependencies that we can quickly remove will help us more keenly focus on those that require a bit more effort. Well, I am working on and off on WADI cache, which will provide a distributed, replicated and transactional cache. Have a look here https://svn.codehaus.org/wadi/trunk/wadi/wadi-cache/src/test/java/org/ codehaus/wadi/cache/demo/Main.java if you want to see a sample. Obviously, if people are interested to help, then please ping me. I understand where you are coming from. Rest assure that the cut of a WADI release is not a severe dependency for Geronimo 2.2. What do you think of me cutting a release end November, say the week-end of November 29th? Thanks, Gianny Thanks, Joe
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
Hi,
The definition of mark-up interfaces may require the definition of a
specific mark-up interface for each deployer type. For instance, a
MBE may be specific to Tomcat and not to Jetty. Hence we may need
WebMBE, TomcatMBE amd JettyMBE.
Also for kind of the same reason than giving a deployer reference to
the MBE does not work, the mark-up interface is not the silver-bullet
as it is not flexible enough: you may have two deployers and you may
only want to add the MBE to one of them.
The explicit addition of a reference pattern provides the best
flexibility. As pointed out, it requires some explicit configuration.
However it is already supported through two mechanisms: manual update
of config.xml or script deployment.
Thanks,
Gianny
On 14/11/2008, at 4:58 AM, Vamsavardhana Reddy wrote:
I agree that we need a general solution to dynamically add MBEs.
The trick that Gianny showed does got me going with the Tuscany
plugin work that I am doing.
On Thu, Nov 13, 2008 at 11:21 PM, David Jencks
<[EMAIL PROTECTED]> wrote:
These solutions certainly work but don't address the fundamental
problem of adding MBE's dynamically to some builders and not
others. For instance we can just modify the tomcat6-deployer plan
right now to include the tuscany MBE and guess that eventually
we'll have a jetspeed MBE and try to think of some more. But when
someone comes up with a new one we didn't imagine -- jspwiki MBE or
something -- they'll have to update the list again. I would like
to solve the problem once and for all so that no specific
configuration for particular MBE's is needed.
Making the reference go the other way -- giving the MBE a reference
to the web deployer -- won't work well for the same reason, we
don't know how many web deployers there will be next week, even if
we only have two this week.
thanks
david jencks
On Nov 13, 2008, at 3:21 AM, Vamsavardhana Reddy wrote:
Thanks Gianny. I could add the MBE to TomcatBuilder by modifying
config.xml. I have added the following gbean under
"org.apache.geronimo.configs/tomcat6-deployer/2.1.3/car" to modify
the reference to include a new MBE:
PersistenceUnitBuilder
JspModuleBuilderExtension
MyFacesModuleBuilderExtension
TuscanyModuleBuilderExtension
On Thu, Nov 13, 2008 at 4:10 PM, Gianny Damour
<[EMAIL PROTECTED]> wrote:
On 13/11/2008, at 10:08 AM, David Jencks wrote:
On Nov 12, 2008, at 1:07 PM, Vamsavardhana Reddy wrote:
As part of deploying SCA enhanced Web Applications in Geronimo
with Tuscany Plugin, I am looking to add a ModuleBuilderExtension
(MBE) to TomcatModuleBuilder and a NamingBuilder. The purpose of
the MBE is to add SCA related EmbeddedRuntimeGBean to the web
application config which will deploy the application composite to
the SCA domain. The purpose of the NamingBuilder is to add SCA
Domain and other objects (required for injection of SCA references
in servlets etc.) into the WebAppContext. I am seeing that the
MBE and NamingBuilder GBeans which are added as part of the
Tuscany Plugin can not get dynamically added to the MBEs
configured in tomcat6-builder config and NamingBuilders configured
in j2ee-deployer config. The one option I see is to update the
plan.xml files in tomcat6-builder and j2ee-deployer configs and
rebuild the server. But this won't be like the MBE and
NamingBuilder is getting added as part of Tuscany-plugin
installation. The other option is to add (don't know if it is
easy to do this hack) the MBE and NamingBuilder to the
corresponding collections in TomcatModuleBuilder and NamingBuilder
GBeans. I appreciate any suggestions/comments or inputs on any
alternate approach that I am not seeing.
Yup, this is a problem. So far we've sidestepped it by just
adding all the known desired MBE's to the appropriate *-deployer
plan, and as you have found this is non-extensible.
I do not understand why overriding the relevant
TomcatModuleBuilder GBean pattern in config.xml does not work.
This is better than having to redeploy the tomcat6-builder plugin.
If the problem is to provide a way to update the tomcat6-builder
plugin when the Tuscany Plugin is installed, then an approach is
to package within the Tuscany plugin a script to update the
reference patterns of the GBean TomcatWebBuilder. For instance, by
dropping a file named
GBeansTuscanyEnhancer.groovy
in the folder
repository/org/apache/geronimo/configs/tomcat6-deployer/2.*/
tomcat6-deployer-2.*.car/
which kind of looks like (indicative...)
import org.apache.geronimo.gbean.AbstractNameQuery
def tomcatWebBuilderGBean = gbeanDatas.find
{ it.gbeanInfo.className ==
'org.apache.geronimo.tomca
Re: Update on documentation progress of Geronimo v2.2
Please use firefox to view the table. I just tried with IE, it turns out to be an deadlock(keep refreshing the page). Not sure about the reason yet. :( Jeff RunHua Chi wrote: > > Hi all, > > We just created a page with one table of content to track progress of > Geronimo 2.2 documentation. In this table, we highlighted some topics to > be > updated based on G 2.2 release roadmap. We believe that not every topic > was > included so far. Therefore, don't hesitate updating the table if you have > new discoveries or topics. We also encourage everyone in this community to > adopt topics and contribute more to the success of Geronimo. > > Here is the linkage for your reference. > http://cwiki.apache.org/confluence/display/GMOxDOC22/Apache+Geronimo+v2.2+documentation+development+status > > What we are planning to do next are: > > 1. Moving pages to their appropriate parent so that the structure will be > more like a "tree"; ---> Ongoing > 2. Keep the consistency between different topics including subject, > wording > and phrases; > 3. Keep migrating topics from previous documentation and update them if > capable; > 4. Refine the granuality by dividing unique topics into pages, in this > way, > contibutors can include existing pages while writing a new topics instead > of > introducing basic concepts again and again. (might be difficult, but I > hope > it's the right direction); > > We are expecting to receive as much as feedback and opinions about > documentation so that we can make it better and better. > > Thanks alot. > > -- View this message in context: http://www.nabble.com/Update-on-documentation-progress-of-Geronimo-v2.2-tp20495528s134p20496723.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[BUILD] trunk: Failed for Revision: 713949
Geronimo Revision: 713949 built with tests included
See the full build-0300.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081114/build-0300.log
See the unit test reports at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081114/unit-test-reports
[INFO] [jar:jar]
[INFO] Building jar:
/home/geronimo/geronimo/trunk/plugins/jaxws/geronimo-jaxws/target/geronimo-jaxws-2.2-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] Checking legal files in: geronimo-jaxws-2.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/geronimo/geronimo/trunk/plugins/jaxws/geronimo-jaxws/target/geronimo-jaxws-2.2-SNAPSHOT.jar
to
/home/geronimo/.m2/repository/org/apache/geronimo/modules/geronimo-jaxws/2.2-SNAPSHOT/geronimo-jaxws-2.2-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo Plugins, Web Services
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: process}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [site:attach-descriptor]
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] [install:install]
[INFO] Installing /home/geronimo/geronimo/trunk/plugins/webservices/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/plugins/webservices/2.2-SNAPSHOT/webservices-2.2-SNAPSHOT.pom
[INFO]
[INFO] Building Geronimo Plugins, Web Services :: Core
[INFO]task-segment: [install]
[INFO]
Downloading: http://download.java.net/maven/1//axis/poms/axis-1.4.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//axis/axis/1.4/axis-1.4.pom
Downloading: http://repo1.maven.org/maven2/axis/axis/1.4/axis-1.4.pom
Downloading:
http://download.java.net/maven/1//com.sun.xml.messaging.saaj/poms/saaj-impl-1.3.pom
348b downloaded
Downloading: http://download.java.net/maven/1//axis/jars/axis-1.4.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//axis/axis/1.4/axis-1.4.jar
Downloading: http://repo1.maven.org/maven2/axis/axis/1.4/axis-1.4.jar
1562K downloaded
Downloading:
http://download.java.net/maven/1//com.sun.xml.messaging.saaj/jars/saaj-impl-1.3.jar
271K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: process}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 24 source files to
/home/geronimo/geronimo/trunk/plugins/webservices/geronimo-webservices/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to
/home/geronimo/geronimo/trunk/plugins/webservices/geronimo-webservices/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/geronimo/geronimo/trunk/plugins/webservices/geronimo-webservices/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.webservices.saaj.SAAJUniverseTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.304 sec <<<
FAILURE!
Results :
Tests in error:
testBasic(org.apache.geronimo.webservices.saaj.SAAJUniverseTest)
testNested(org.apache.geronimo.webservices.saaj.SAAJUniverseTest)
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] There are test failures.
Please refer to
/home/geronimo/geronimo/trunk/plugins/webservices/geronimo-webservices/target/surefire-reports
for the individual test results.
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: There are test failures.
Please refer to
/home/geronimo/geronimo/trunk/plugins/webservices/geronimo-webservices/target/surefire-reports
for the individual test results.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
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)
[jira] Commented: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647543#action_12647543 ] Manu T George commented on GERONIMO-4369: - Clarification: So I think it may be better to have a new console utility method that does both these things and all the console portlets that want to make changes can call that method. Here by both these things I mean update both the config.xml and the gbeandatas in the configuration. > The new attribute values are overwrote while restarting the DB pool connector > - > > Key: GERONIMO-4369 > URL: https://issues.apache.org/jira/browse/GERONIMO-4369 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: Geronimo 2.2 snapshot > JDK 1.5 > Windows XP >Reporter: Ivan >Assignee: Joe Bohn > Fix For: 2.2 > > Attachments: Geronimo-4369-11.13.patch > > > After editing the values in the db pool, then restart it in the console, the > new values lost. > When saving the new attribute values, such as user name, the gbeandata in > the configurationManager is not updated, so while restarting the connector, > the gbinstance copies those old values from it. So the new persistent values > do not take effect, > Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647542#action_12647542 ] Manu T George commented on GERONIMO-4369: - But we also need to restart the child configurations I think that the reason that restart doesn't re-read the configuration is to improve the performance. So its faster than stop and start since it just restarts the configuration instead of loading and starting. Also users will be usually restarting webapps etc which may not have gbean updates that need to be picked up most of the time. So I think it may be better to have a new console utility method that does both these things and all the console portlets that want to make changes can call that method. Maybe there is one already and i am not aware of it. Just my 2 cents > The new attribute values are overwrote while restarting the DB pool connector > - > > Key: GERONIMO-4369 > URL: https://issues.apache.org/jira/browse/GERONIMO-4369 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: Geronimo 2.2 snapshot > JDK 1.5 > Windows XP >Reporter: Ivan >Assignee: Joe Bohn > Fix For: 2.2 > > Attachments: Geronimo-4369-11.13.patch > > > After editing the values in the db pool, then restart it in the console, the > new values lost. > When saving the new attribute values, such as user name, the gbeandata in > the configurationManager is not updated, so while restarting the connector, > the gbinstance copies those old values from it. So the new persistent values > do not take effect, > Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
