[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 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> > > > > > Since you can't send me your EAR I wonder if it has some POJO JAR that is in your Eclipse workspace and it used in multiple > > > Pro
Update on documentation progress of Geronimo v2.2
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.
Re: 2.2 (trunk) bucket-o-snapshots
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] Resolved: (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:all-tabpanel ] Jarek Gawor resolved GERONIMO-4387. --- Resolution: Fixed Fix Version/s: 2.2 Assignee: Jarek Gawor The "ejb/mgmt/MEJB" is a standard name for the Management EJB so the jndi-name specified in the current plan is correct and the jndi name used in the code is incorrect. I updated the code to use the standard name. Committed the change to trunk (revision 713919). > 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.
[jira] Resolved: (GERONIMO-4408) install-library goal for geronimo-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4408. --- Resolution: Fixed Fix Version/s: 2.2 Assignee: Jarek Gawor Committed the file to trunk with some minor formatting modifications (revision 713916). Thanks! > install-library goal for geronimo-maven-plugin > --- > > Key: GERONIMO-4408 > URL: https://issues.apache.org/jira/browse/GERONIMO-4408 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: geronimo-maven-plugin >Affects Versions: 2.1.3 >Reporter: Michal Borowiecki >Assignee: Jarek Gawor >Priority: Minor > Fix For: 2.2 > > Attachments: InstallLibraryMojo.java > > > An install-library goal for geronimo-maven-plugin similar to the > install-library option of the deploy command > http://cwiki.apache.org/GMOxDOC21/tools-and-commands.html#Toolsandcommands-Installlibrary > An important use-case is the ability to automatically install jdbc drivers as > part of integration testing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (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 ] Ivan updated GERONIMO-4395: --- Attachment: Geronimo-4395-1114-with-replace.patch Geronimo-4395-1114-without-replace.patch I create two patch, one is with the replacement code, another is not. I added some extra codes to handle if the pool name is end with '/'. I have run the console test suites, the patch does not cause any case fails. By the way, I guess we need to put more validation logic on the client side, not in the port lets, so that we could avoid too many codes in the port let to handle all the user inputs. Please help to review the patch, Thanks ! > 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] Commented: (GERONIMO-4405) Postgresql new drives would not be listed in Drive Jars list and download driver list
[ https://issues.apache.org/jira/browse/GERONIMO-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647506#action_12647506 ] Rex Wang commented on GERONIMO-4405: Yes, Lin. I mean the reporter here wanna install a postgreSQL 8.3 jars to geronimo repository, but after that she can't find that in the jars list of the portlet. I think it is not reasonable that we don't allow user to try installing a new jdbc jars to our server. So I changed it from postgresql/postgresql//jar,postgresql/postgresql-7.3//jar,postgresql/postgresql-7.4//jar,postgresql/postgresql-8.0//jar,postgresql/postgresql-8.1//jar,postgresql/postgresql-8.2//jar to postgresql///jar This can solve her issue and I think it is not conflict with the way we control the tested jdbc jars. > Postgresql new drives would not be listed in Drive Jars list and download > driver list > - > > Key: GERONIMO-4405 > URL: https://issues.apache.org/jira/browse/GERONIMO-4405 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: databases >Affects Versions: 2.1.3 > Environment: Any platform >Reporter: viola.lu >Priority: Minor > Attachments: GERONIMO-4405.patch > > > Steps: > 1.login admin console, go to "repository" porlet, install a postgresql jdbc > driver 8.3 > 2.Go to "database pool" porlet->create a datasource type postgresql local or > XA, click next.Newly installed driver is not listed in driver jars. > 3.CLick "download driver" button, just postgresql 8.1.8.2,7.4 is listed, > can't choose 8.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (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:all-tabpanel ] Ivan updated GERONIMO-4387: --- Attachment: Geronimo-4387-11.14.patch The same with the previous one, but create it from the root folder. > 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 > 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.
[jira] Commented: (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:comment-tabpanel&focusedCommentId=12647501#action_12647501 ] Ivan commented on GERONIMO-4141: Thanks, Lin and David. Actually, as I mentioned in the past comments, the exported war has all the information that to be deployed ( config.ser, geronimo-plugin.xml .etc.). The reason that fails to deploy is just the Maven2Repository does not unpack the war file, it detects that the artifact type is war, not car. In my opinion, I support the option 1. Once we detected the Geronimo configuration information, we may think it is a G's own package. > 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.Threa
[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=12647494#action_12647494 ] Ivan commented on GERONIMO-4395: Thanks for the comments Lin and David. I will recreate the patch from the root dir. a. The reason that I replace the / is for '/' will cause the deployment failed. b. About the random string, for in the current implementation, the codes will check whether there is a '/' in the pool name, if it does, the substring of the pool name is used as the artifact id. Let's take an example, "testpool" and "jdbc/testpool" will get the same artifact id "testpool", I will append a random string if the "testpool" exists already. > 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.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] Commented: (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:comment-tabpanel&focusedCommentId=12647473#action_12647473 ] David Jencks commented on GERONIMO-4141: My opinion is that we should consistently name all deployed apps with type "car" rather than "ear", "rar", etc etc. They aren't really the original type any more -- they have probably been partly unpacked or repackaged and certainly have extra geronimo specific info in them. I argued for this point of view long before plugins arrived but lost the argument. Two more alternatives: 1. modify the code that decides if an artifact needs to be unpacked, that currently just looks at the type, to look inside the artifact for geronimo metadata. IIRC this info is not available at the moment so this would require significant changes to the config store artifact installation code. 2. Modify our classloader so it can work with packed car files. Presumably it would unpack the jars inside on demand. This is probably the conceptually cleanest solution but writing such a classloader might be rather hard. At the moment I think we should make the console try really hard to deploy everything into a car file, e.g. by warning the user that the result wont be a workable plugin if they choose something else. > 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) >
[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=12647469#action_12647469 ] David Jencks commented on GERONIMO-4395: I like replacing / with _. I haven't looked at the patch so I don't know what "random string" means. If it means appending _1, _2, until an unused artifactId is obtained, I've fine with it. I hope there's a way for the user to specify the groupId and artifactId. haven't looked at this portlet page recently. > 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.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.
Re: svn commit: r713680 - in /geronimo/server/trunk/framework/modules: geronimo-service-builder/src/main/java/org/apache/geronimo/deployment/service/ geronimo-service-builder/src/main/xsd/ geronimo-se
Gianny, I think you are correct. The most recent snapshot of OpenEJB still exhibits the same errors that were mentioned previously. Thanks, On Thu, Nov 13, 2008 at 3:10 PM, Gianny Damour < [EMAIL PROTECTED]> wrote: > Hi, > > The feature is still available. However we do not provide a XML > configuration style for it. We only provide a script configuration style. > For instance, by dropping a file named: > > DependenciesPrivateClass.groovy > > in the folder of the plugin to update and with a content looking like > > Set privateClasses = ['hide.this', 'hide.that'] > > configurationData.environment.classLoadingRules.privateRule.addClassPrefixes(privateClasses) > > You can achieve the same effect. > > Let me know if you think that we should also provide a XML configuration > style. > > Regarding the TCK problem, I do not think that this change is related. I > believe that the TCK problem is due to the new OpenEJB snapshot. Jason, > could you please confirm? > > Thanks, > Gianny > > > On 14/11/2008, at 5:19 AM, Joe Bohn wrote: > > I think I was one of the people asking for this to be reverted. >> >> Just to clarify my position: I'm very much in favor of keeping the >> functionality. I think it will help with some of the more obscure >> classloader issues we've been hitting. >> >> My suggestion to revert the change was more pragmatic to resolve two >> issues: >> 1) new TCK failures reported by Jason >> 2) The implicit dependency on a new OpenEJB 3.1.x release >> >> If we can resolve these 2 issues without reverting the change (or for #2 >> if it seems we need a new OpenEJB 3.1.x release for other reasons ... like >> other TCK failures) then I'm very much in favor of keeping this change. >> >> >> Joe >> >> >> David Jencks wrote: >> >>> Um, -1. I thought this was a great idea for 2.2. What's the problem >>> that leads you to revert it? >>> thanks >>> david jencks >>> On Nov 13, 2008, at 12:35 AM, [EMAIL PROTECTED] wrote: >>> Author: gdamour Date: Thu Nov 13 00:35:05 2008 New Revision: 713680 URL: http://svn.apache.org/viewvc?rev=713680&view=rev Log: Revert addition of private-classes element. Private classes can be configured via scripts. (GERONIMO-4403) Provide a mechanism to hide specific classes of a configuration to all its children >>> >> > -- ~Jason Warner
[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=12647405#action_12647405 ] Lin Sun commented on GERONIMO-4395: --- Ivan, can you please generate patch from the root dir (for easily apply)? I'd suggest removing the string replacement line. Also, can you please make sure the patch won't break any unit test or add some unit test as appropriate? 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.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.
Re: 2.2 (trunk) bucket-o-snapshots
Thanks David. I'm not familiar with nexus but I did find this other handy site that has been useful: http://mvnrepository.com/ Is nexus similar? Joe David Jencks wrote: On Nov 11, 2008, at 3:04 PM, 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)? 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. xbean-naming 3.5 is required. Normally we release all xbean modules at once. -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? I wish I knew. I guess we could release any number of x.y-EA followed by 1.0 after the spec is final and we get the 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? Here at least the spec is done. I guess we need to ask geir to look for a tck for it. - 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? Same as connector 1.6 although probably less stable. - geronimo-jaspi 1.0-SNAPSHOT. This is a new geronimo component. How close is this to being able to be released? Let me think about this a bit probably close to releasable. - 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? We should remove it. I think they tagged a working version, don't recall the situation regarding publishing the result dont see it in the nexus index, but may not have the correct repo. - 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? There's a 1.0-alpha-1 version published. I strongly recommend nexus it really helps investigating these questions (this one took about 3 seconds). IMO we should use genesis 2.0 which I think already uses ianal and has all the needed configuration for it. thanks david jencks Joe
Re: svn commit: r713680 - in /geronimo/server/trunk/framework/modules: geronimo-service-builder/src/main/java/org/apache/geronimo/deployment/service/ geronimo-service-builder/src/main/xsd/ geronimo-se
Hi, The feature is still available. However we do not provide a XML configuration style for it. We only provide a script configuration style. For instance, by dropping a file named: DependenciesPrivateClass.groovy in the folder of the plugin to update and with a content looking like Set privateClasses = ['hide.this', 'hide.that'] configurationData.environment.classLoadingRules.privateRule.addClassPref ixes(privateClasses) You can achieve the same effect. Let me know if you think that we should also provide a XML configuration style. Regarding the TCK problem, I do not think that this change is related. I believe that the TCK problem is due to the new OpenEJB snapshot. Jason, could you please confirm? Thanks, Gianny On 14/11/2008, at 5:19 AM, Joe Bohn wrote: I think I was one of the people asking for this to be reverted. Just to clarify my position: I'm very much in favor of keeping the functionality. I think it will help with some of the more obscure classloader issues we've been hitting. My suggestion to revert the change was more pragmatic to resolve two issues: 1) new TCK failures reported by Jason 2) The implicit dependency on a new OpenEJB 3.1.x release If we can resolve these 2 issues without reverting the change (or for #2 if it seems we need a new OpenEJB 3.1.x release for other reasons ... like other TCK failures) then I'm very much in favor of keeping this change. Joe David Jencks wrote: Um, -1. I thought this was a great idea for 2.2. What's the problem that leads you to revert it? thanks david jencks On Nov 13, 2008, at 12:35 AM, [EMAIL PROTECTED] wrote: Author: gdamour Date: Thu Nov 13 00:35:05 2008 New Revision: 713680 URL: http://svn.apache.org/viewvc?rev=713680&view=rev Log: Revert addition of private-classes element. Private classes can be configured via scripts. (GERONIMO-4403) Provide a mechanism to hide specific classes of a configuration to all its children
Re: Tools.jar expected but not found on Mac OS 10.5.5
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. > >
Re: Tools.jar expected but not found on Mac OS 10.5.5
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.
[jira] Created: (GERONIMO-4410) Update JPA 2.0 spec component
Update JPA 2.0 spec component - Key: GERONIMO-4410 URL: https://issues.apache.org/jira/browse/GERONIMO-4410 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: specs Reporter: Jeremy Bauer This task is to update the JPA 2.0 spec component (geronimo-jpa_2.0_spec) with code provided by the OpenJPA project as new JPA 2.0/JSR-317 public spec drafts are made available - through the final draft. Updates will be provided in the form of a patch. After the update is made a snapshot will be pushed out to the maven repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4409) Eliminate ianal-maven-plugin snapshot
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: Updating the JPA spec jar for JPA 2.0
Sounds great. I'll open a JIRA. Thanks! -Jeremy On Thu, Nov 13, 2008 at 11:55 AM, David Jencks <[EMAIL PROTECTED]>wrote: > Hi Jeremy, > I don't think there's any argument about the artifactId of > geronimo-jpa_2.0_spec and version of 1.0-EA-SNAPSHOT for the new work, so as > soon as you supply a patch I can apply it and push a snapshot. I have no > objection to the other ideas but they won't make any immediate difference to > anything. I thought we could wait a bit for other comments. > > If you open a geronimo jira and assign it to me for patches I'll be > reminded on each new patch :-) > > thanks > david jencks > > On Nov 13, 2008, at 7:53 AM, Jeremy Bauer wrote: > > Any news on this item? Does my last suggestion seem reasonable/doable? > We'd like to begin making the 2.0 spec updates and get an artifact > published to the maven repo asap. > -Jeremy > > On Tue, Nov 11, 2008 at 2:41 PM, Jeremy Bauer <[EMAIL PROTECTED]> wrote: > >> Thanks, David, for populating the repository and for your willingness to >> handle commits. >> The naming issue is quite a quandary. Would this approach (or derivation >> of) work? a) Add a JPA 1.0 spec to the repo - this is not necessary, but >> may be good for the sake of completeness. b) Use the new 2.0 repo for 2.0 >> spec work. c) For JPA 3.0, add a 3.0-SNAPSHOT version to >> geronimo-jpa_3.0_spec, leaving the the current 1.0 version intact. >> -Jeremy >> >> On Tue, Nov 11, 2008 at 1:07 PM, Mark Struberg <[EMAIL PROTECTED]> wrote: >> >>> we have to use 2.0-EA-SNAPSHOT! >>> >>> At least '-SNAPSHOT' has to be at the end, because maven does handle >>> snapshot releases completely different than tagged final releases. >>> See [1], [2] + many more internal maven-details you do not want to know >>> about ;) >>> >>> >>> LieGrue, >>> strub >>> >>> [1] http://maven.apache.org/glossary.html >>> [2] http://maven.apache.org/plugins/maven-release-plugin/ >>> >>> >>> --- Michael Dick <[EMAIL PROTECTED]> schrieb am Di, 11.11.2008: >>> >>> > Von: Michael Dick <[EMAIL PROTECTED]> >>> > Betreff: Re: Updating the JPA spec jar for JPA 2.0 >>> > An: [EMAIL PROTECTED], dev@geronimo.apache.org >>> > Datum: Dienstag, 11. November 2008, 19:50 >>> > On Tue, Nov 11, 2008 at 12:07 PM, Craig L Russell >>> > <[EMAIL PROTECTED]>wrote: >>> > >>> > > >>> > > On Nov 11, 2008, at 2:28 AM, Mark Struberg wrote: >>> > > >>> > > --- David Jencks <[EMAIL PROTECTED]> >>> > schrieb am Di, 11.11.2008: >>> > >> >>> > >>> This points out the possible problem that the >>> > jpa 1.0 spec >>> > >>> appeared to be part of the ejb 3.0 spec so I >>> > gave it a spec >>> > >>> version number of 3.0. Any suggestions about >>> > what to do >>> > >>> about this would be appreciated. >>> > >>> >>> > >> >>> > >> >>> > >> Do we really need to change anything? >>> > >> >>> > >> Imho the current >>> > >> geronimo-jpa_3.0_spec >>> > >> with a >>> > >> 1.0 >>> > >> is somehow not really maven stylish, but it >>> > doesn't hinder us ;) >>> > >> The version of the jpa-spec actually is 1.0 and we >>> > do not have any problem >>> > >> other than the confusing term '3.0' in the >>> > groupId since this references EJB >>> > >> and not JPA. >>> > >> >>> > >> So I'd suggest to simply use >>> > >> 2.0-SNAPSHOT >>> > >> and we're done. >>> > >> >>> > > >>> > > Yes, this would be the thing to do. >>> > > >>> > > The original JPA was released as part of EJB, which >>> > had gotten to the 3.0 >>> > > level. But JPA was brand, spanking new 1.0. >>> > > >>> > > The current JPA specification (JSR 317, now in Public >>> > Review Draft stage) >>> > > is being billed as JPA Version 2.0. So 2.0-SNAPSHOT >>> > seems completely >>> > > correct. >>> > > >>> > > So even though it's confusing because of the >>> > original geronimo-jpa_3.0_spec >>> > > nomenclature, I'd say we confuse things even more >>> > if we change the artifact >>> > > id or group id (again). >>> > > >>> > >>> > That's easiest for migration. It's unfortunate that >>> > geronimo-jpa_x.y_spec >>> > doesn't follow the same pattern as the other geronimo >>> > specs though. I have >>> > no strong feelings either way though. >>> > >>> > We might want to keep the EA nomenclature so >>> > 2.0-EA-SNAPSHOT or >>> > 2.0-SNAPSHOT-EA could be the current version. Once the spec >>> > finalizes >>> > 2.0-SNAPSHOT seems fair. >>> > >>> > -mike >>> > >>> > >>> > > Craig >>> > > >>> > >> >>> > >> >>> > >> Humm, btw, what's really confusing me now is >>> > the fact, that there are 2 >>> > >> specs online: >>> > >> >>> > http://repo1.maven.org/maven2/org/apache/geronimo/specs/ >>> > >> http://repo1.maven.org/maven2/geronimo-spec/ >>> > >> >>> > >> I've always used the geronimo-spec until now, >>> > and this doesn't contain the >>> > >> jpa spec anyway. >>> > >> >>> > >> So could someone shed a light on this for me >>> > (I'm not a geronimized one)? >>> > >> >>> > >> txs and LieGrue, >>> > >> strub >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > > Craig L Russell >>> > > Architect, Sun Jav
Re: svn commit: r713680 - in /geronimo/server/trunk/framework/modules: geronimo-service-builder/src/main/java/org/apache/geronimo/deployment/service/ geronimo-service-builder/src/main/xsd/ geronimo-se
I think I was one of the people asking for this to be reverted. Just to clarify my position: I'm very much in favor of keeping the functionality. I think it will help with some of the more obscure classloader issues we've been hitting. My suggestion to revert the change was more pragmatic to resolve two issues: 1) new TCK failures reported by Jason 2) The implicit dependency on a new OpenEJB 3.1.x release If we can resolve these 2 issues without reverting the change (or for #2 if it seems we need a new OpenEJB 3.1.x release for other reasons ... like other TCK failures) then I'm very much in favor of keeping this change. Joe David Jencks wrote: Um, -1. I thought this was a great idea for 2.2. What's the problem that leads you to revert it? thanks david jencks On Nov 13, 2008, at 12:35 AM, [EMAIL PROTECTED] wrote: Author: gdamour Date: Thu Nov 13 00:35:05 2008 New Revision: 713680 URL: http://svn.apache.org/viewvc?rev=713680&view=rev Log: Revert addition of private-classes element. Private classes can be configured via scripts. (GERONIMO-4403) Provide a mechanism to hide specific classes of a configuration to all its children
Re: svn commit: r713680 - in /geronimo/server/trunk/framework/modules: geronimo-service-builder/src/main/java/org/apache/geronimo/deployment/service/ geronimo-service-builder/src/main/xsd/ geronimo-se
Um, -1. I thought this was a great idea for 2.2. What's the problem that leads you to revert it? thanks david jencks On Nov 13, 2008, at 12:35 AM, [EMAIL PROTECTED] wrote: Author: gdamour Date: Thu Nov 13 00:35:05 2008 New Revision: 713680 URL: http://svn.apache.org/viewvc?rev=713680&view=rev Log: Revert addition of private-classes element. Private classes can be configured via scripts. (GERONIMO-4403) Provide a mechanism to hide specific classes of a configuration to all its children
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
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.tomcat.deployment.TomcatModuleBuilder' }
>> def moduleBuilderExtensionsPatterns =
>> tomcatWebBuilderGBean.getReferencePatterns('ModuleBuilderExtensions')
>> Set newPatterns = []
>> newPatterns.addAll(moduleBuilderExtensionsPatterns.patterns)
>> newPatterns.add(new AbstractNameQuery(new
>> URI(PUT_YOUR_TUSCANY_MBE_PATTERN_NAME_HERE)))
>> tomcatWebBuilderGBean.setReferencePatterns(newPatterns)
>>
>>
>> You should be done.
>>
>> Thanks,
>> Gianny
>>
>>
>>
>>> One possiblitly would be to define marker interfaces such as WebMBE,
>>> EjbMBE, etc that the appropriate MBE's could implement and use the interface
>>> in the references pattern.
>>>
>>> An
Re: Updating the JPA spec jar for JPA 2.0
Hi Jeremy, I don't think there's any argument about the artifactId of geronimo- jpa_2.0_spec and version of 1.0-EA-SNAPSHOT for the new work, so as soon as you supply a patch I can apply it and push a snapshot. I have no objection to the other ideas but they won't make any immediate difference to anything. I thought we could wait a bit for other comments. If you open a geronimo jira and assign it to me for patches I'll be reminded on each new patch :-) thanks david jencks On Nov 13, 2008, at 7:53 AM, Jeremy Bauer wrote: Any news on this item? Does my last suggestion seem reasonable/ doable? We'd like to begin making the 2.0 spec updates and get an artifact published to the maven repo asap. -Jeremy On Tue, Nov 11, 2008 at 2:41 PM, Jeremy Bauer <[EMAIL PROTECTED]> wrote: Thanks, David, for populating the repository and for your willingness to handle commits. The naming issue is quite a quandary. Would this approach (or derivation of) work? a) Add a JPA 1.0 spec to the repo - this is not necessary, but may be good for the sake of completeness. b) Use the new 2.0 repo for 2.0 spec work. c) For JPA 3.0, add a 3.0- SNAPSHOT version to geronimo-jpa_3.0_spec, leaving the the current 1.0 version intact. -Jeremy On Tue, Nov 11, 2008 at 1:07 PM, Mark Struberg <[EMAIL PROTECTED]> wrote: we have to use 2.0-EA-SNAPSHOT! At least '-SNAPSHOT' has to be at the end, because maven does handle snapshot releases completely different than tagged final releases. See [1], [2] + many more internal maven-details you do not want to know about ;) LieGrue, strub [1] http://maven.apache.org/glossary.html [2] http://maven.apache.org/plugins/maven-release-plugin/ --- Michael Dick <[EMAIL PROTECTED]> schrieb am Di, 11.11.2008: > Von: Michael Dick <[EMAIL PROTECTED]> > Betreff: Re: Updating the JPA spec jar for JPA 2.0 > An: [EMAIL PROTECTED], dev@geronimo.apache.org > Datum: Dienstag, 11. November 2008, 19:50 > On Tue, Nov 11, 2008 at 12:07 PM, Craig L Russell > <[EMAIL PROTECTED]>wrote: > > > > > On Nov 11, 2008, at 2:28 AM, Mark Struberg wrote: > > > > --- David Jencks <[EMAIL PROTECTED]> > schrieb am Di, 11.11.2008: > >> > >>> This points out the possible problem that the > jpa 1.0 spec > >>> appeared to be part of the ejb 3.0 spec so I > gave it a spec > >>> version number of 3.0. Any suggestions about > what to do > >>> about this would be appreciated. > >>> > >> > >> > >> Do we really need to change anything? > >> > >> Imho the current > >> geronimo-jpa_3.0_spec > >> with a > >> 1.0 > >> is somehow not really maven stylish, but it > doesn't hinder us ;) > >> The version of the jpa-spec actually is 1.0 and we > do not have any problem > >> other than the confusing term '3.0' in the > groupId since this references EJB > >> and not JPA. > >> > >> So I'd suggest to simply use > >> 2.0-SNAPSHOT > >> and we're done. > >> > > > > Yes, this would be the thing to do. > > > > The original JPA was released as part of EJB, which > had gotten to the 3.0 > > level. But JPA was brand, spanking new 1.0. > > > > The current JPA specification (JSR 317, now in Public > Review Draft stage) > > is being billed as JPA Version 2.0. So 2.0-SNAPSHOT > seems completely > > correct. > > > > So even though it's confusing because of the > original geronimo-jpa_3.0_spec > > nomenclature, I'd say we confuse things even more > if we change the artifact > > id or group id (again). > > > > That's easiest for migration. It's unfortunate that > geronimo-jpa_x.y_spec > doesn't follow the same pattern as the other geronimo > specs though. I have > no strong feelings either way though. > > We might want to keep the EA nomenclature so > 2.0-EA-SNAPSHOT or > 2.0-SNAPSHOT-EA could be the current version. Once the spec > finalizes > 2.0-SNAPSHOT seems fair. > > -mike > > > > Craig > > > >> > >> > >> Humm, btw, what's really confusing me now is > the fact, that there are 2 > >> specs online: > >> > http://repo1.maven.org/maven2/org/apache/geronimo/specs/ > >> http://repo1.maven.org/maven2/geronimo-spec/ > >> > >> I've always used the geronimo-spec until now, > and this doesn't contain the > >> jpa spec anyway. > >> > >> So could someone shed a light on this for me > (I'm not a geronimized one)? > >> > >> txs and LieGrue, > >> strub > >> > >> > >> > >> > >> > > Craig L Russell > > Architect, Sun Java Enterprise System > http://db.apache.org/jdo > > 408 276-5638 mailto:[EMAIL PROTECTED] > > P.S. A good JDO? O, Gasp! > > > >
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
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.tomcat.deployment.TomcatModuleBuilder' }
def moduleBuilderExtensionsPatterns =
tomcatWebBuilderGBean.getReferencePatterns('ModuleBuilderExtensions')
Set newPatterns = []
newPatterns.addAll(moduleBuilderExtensionsPatterns.patterns)
newPatterns.add(new AbstractNameQuery(new
URI(PUT_YOUR_TUSCANY_MBE_PATTERN_NAME_HERE)))
tomcatWebBuilderGBean.setReferencePatterns(newPatterns)
You should be done.
Thanks,
Gianny
One possiblitly would be to define marker interfaces such as WebMBE,
EjbMBE, etc that the appropriate MBE's could implement and use the
interface in the references pattern.
Anyone have a better idea?
thanks
david jencks
Thanks,
Vamsi
--
Vamsi
[jira] Updated: (GERONIMO-4408) install-library goal for geronimo-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Borowiecki updated GERONIMO-4408: Patch Info: [Patch Available] I attached a Maven mojo for the goal. Here is a usage example for inclusion in geronimo/buildsupport/geronimo-maven-plugin/src/site/apt/usage/modules.apt org.apache.geronimo.buildsupport geronimo-maven-plugin install-library pre-integration-test install-library path/to/library.jar optional-groupId > install-library goal for geronimo-maven-plugin > --- > > Key: GERONIMO-4408 > URL: https://issues.apache.org/jira/browse/GERONIMO-4408 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: geronimo-maven-plugin >Affects Versions: 2.1.3 >Reporter: Michal Borowiecki >Priority: Minor > Attachments: InstallLibraryMojo.java > > > An install-library goal for geronimo-maven-plugin similar to the > install-library option of the deploy command > http://cwiki.apache.org/GMOxDOC21/tools-and-commands.html#Toolsandcommands-Installlibrary > An important use-case is the ability to automatically install jdbc drivers as > part of integration testing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4408) install-library goal for geronimo-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Borowiecki updated GERONIMO-4408: Attachment: InstallLibraryMojo.java > install-library goal for geronimo-maven-plugin > --- > > Key: GERONIMO-4408 > URL: https://issues.apache.org/jira/browse/GERONIMO-4408 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: geronimo-maven-plugin >Affects Versions: 2.1.3 >Reporter: Michal Borowiecki >Priority: Minor > Attachments: InstallLibraryMojo.java > > > An install-library goal for geronimo-maven-plugin similar to the > install-library option of the deploy command > http://cwiki.apache.org/GMOxDOC21/tools-and-commands.html#Toolsandcommands-Installlibrary > An important use-case is the ability to automatically install jdbc drivers as > part of integration testing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Updating the JPA spec jar for JPA 2.0
Any news on this item? Does my last suggestion seem reasonable/doable? We'd like to begin making the 2.0 spec updates and get an artifact published to the maven repo asap. -Jeremy On Tue, Nov 11, 2008 at 2:41 PM, Jeremy Bauer <[EMAIL PROTECTED]> wrote: > Thanks, David, for populating the repository and for your willingness to > handle commits. > The naming issue is quite a quandary. Would this approach (or derivation > of) work? a) Add a JPA 1.0 spec to the repo - this is not necessary, but > may be good for the sake of completeness. b) Use the new 2.0 repo for 2.0 > spec work. c) For JPA 3.0, add a 3.0-SNAPSHOT version to > geronimo-jpa_3.0_spec, leaving the the current 1.0 version intact. > -Jeremy > > On Tue, Nov 11, 2008 at 1:07 PM, Mark Struberg <[EMAIL PROTECTED]> wrote: > >> we have to use 2.0-EA-SNAPSHOT! >> >> At least '-SNAPSHOT' has to be at the end, because maven does handle >> snapshot releases completely different than tagged final releases. >> See [1], [2] + many more internal maven-details you do not want to know >> about ;) >> >> >> LieGrue, >> strub >> >> [1] http://maven.apache.org/glossary.html >> [2] http://maven.apache.org/plugins/maven-release-plugin/ >> >> >> --- Michael Dick <[EMAIL PROTECTED]> schrieb am Di, 11.11.2008: >> >> > Von: Michael Dick <[EMAIL PROTECTED]> >> > Betreff: Re: Updating the JPA spec jar for JPA 2.0 >> > An: [EMAIL PROTECTED], dev@geronimo.apache.org >> > Datum: Dienstag, 11. November 2008, 19:50 >> > On Tue, Nov 11, 2008 at 12:07 PM, Craig L Russell >> > <[EMAIL PROTECTED]>wrote: >> > >> > > >> > > On Nov 11, 2008, at 2:28 AM, Mark Struberg wrote: >> > > >> > > --- David Jencks <[EMAIL PROTECTED]> >> > schrieb am Di, 11.11.2008: >> > >> >> > >>> This points out the possible problem that the >> > jpa 1.0 spec >> > >>> appeared to be part of the ejb 3.0 spec so I >> > gave it a spec >> > >>> version number of 3.0. Any suggestions about >> > what to do >> > >>> about this would be appreciated. >> > >>> >> > >> >> > >> >> > >> Do we really need to change anything? >> > >> >> > >> Imho the current >> > >> geronimo-jpa_3.0_spec >> > >> with a >> > >> 1.0 >> > >> is somehow not really maven stylish, but it >> > doesn't hinder us ;) >> > >> The version of the jpa-spec actually is 1.0 and we >> > do not have any problem >> > >> other than the confusing term '3.0' in the >> > groupId since this references EJB >> > >> and not JPA. >> > >> >> > >> So I'd suggest to simply use >> > >> 2.0-SNAPSHOT >> > >> and we're done. >> > >> >> > > >> > > Yes, this would be the thing to do. >> > > >> > > The original JPA was released as part of EJB, which >> > had gotten to the 3.0 >> > > level. But JPA was brand, spanking new 1.0. >> > > >> > > The current JPA specification (JSR 317, now in Public >> > Review Draft stage) >> > > is being billed as JPA Version 2.0. So 2.0-SNAPSHOT >> > seems completely >> > > correct. >> > > >> > > So even though it's confusing because of the >> > original geronimo-jpa_3.0_spec >> > > nomenclature, I'd say we confuse things even more >> > if we change the artifact >> > > id or group id (again). >> > > >> > >> > That's easiest for migration. It's unfortunate that >> > geronimo-jpa_x.y_spec >> > doesn't follow the same pattern as the other geronimo >> > specs though. I have >> > no strong feelings either way though. >> > >> > We might want to keep the EA nomenclature so >> > 2.0-EA-SNAPSHOT or >> > 2.0-SNAPSHOT-EA could be the current version. Once the spec >> > finalizes >> > 2.0-SNAPSHOT seems fair. >> > >> > -mike >> > >> > >> > > Craig >> > > >> > >> >> > >> >> > >> Humm, btw, what's really confusing me now is >> > the fact, that there are 2 >> > >> specs online: >> > >> >> > http://repo1.maven.org/maven2/org/apache/geronimo/specs/ >> > >> http://repo1.maven.org/maven2/geronimo-spec/ >> > >> >> > >> I've always used the geronimo-spec until now, >> > and this doesn't contain the >> > >> jpa spec anyway. >> > >> >> > >> So could someone shed a light on this for me >> > (I'm not a geronimized one)? >> > >> >> > >> txs and LieGrue, >> > >> strub >> > >> >> > >> >> > >> >> > >> >> > >> >> > > Craig L Russell >> > > Architect, Sun Java Enterprise System >> > http://db.apache.org/jdo >> > > 408 276-5638 mailto:[EMAIL PROTECTED] >> > > P.S. A good JDO? O, Gasp! >> > > >> > > >> >> >> >> >
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
On Wed, Nov 12, 2008 at 6:08 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > > 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. > > One possiblitly would be to define marker interfaces such as WebMBE, EjbMBE, > etc that the appropriate MBE's could implement and use the interface in the > references pattern. +1 to that idea. This was/is a problem for a long time and needs to be fixed. Jarek
Re: Tools.jar expected but not found on Mac OS 10.5.5
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. > >
Tools.jar expected but not found on Mac OS 10.5.5
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.
[jira] Commented: (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:comment-tabpanel&focusedCommentId=12647301#action_12647301 ] Lin Sun commented on GERONIMO-4141: --- Ivan, thanks for the patch! I think it looks good for solution 3 and solution 3 is better than what we currently have. Since this can be a big usability issue, why don't you start a dev list discussion on this (or resume our previous discussion on this) to gather more feedback? thanks 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)
[jira] Assigned: (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 reassigned GERONIMO-4395: - Assignee: Lin Sun > 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.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] 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=12647300#action_12647300 ] Lin Sun commented on GERONIMO-4395: --- Patch looks good to me. The other thing is that I was not planning to do the string replacement so that we keep the old behavior. I'll try integrate it. > 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.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] 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=12647282#action_12647282 ] Ivan commented on GERONIMO-4369: Yes, the gbeanDatas held by the configuration gbean is the reason that the modifications do not take effect. >From the API of the configuration manager, I guess the method reload is the >one that does the both thing. > 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.
Re: Is there a bp project for Geronimo like petstore?
We have an application called Daytrader that's aimed at being a benchmarking application for geronimo. I'm not sure what features it covers but it's the most complicated sample we have. You can take a look at the source code here if you'd like: http://svn.apache.org/viewvc/geronimo/daytrader/. On Thu, Nov 13, 2008 at 6:33 AM, haidescs <[EMAIL PROTECTED]> wrote: > > HI guys > > Is there a bp project for Geronimo like petstore which is implemented based > on all the basic feature of Geronimo such as OpenEJB, OpenJPA, Activemq, > Derby DB, Webservice, potlets, and so on, and some high level features like > ajax? > > If not, maybe I could make it when I have some leisure time. > -- > View this message in context: > http://www.nabble.com/Is-there-a-bp-project-for-Geronimo-like-petstore--tp20479079s134p20479079.html > Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. > > -- ~Jason Warner
[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=12647278#action_12647278 ] Manu T George commented on GERONIMO-4369: - The workaround that i followed was to update the gbeanDatas in the configuration as well as write to config.xml. Updating the gbeandatas in the configuration will be reflected on restart of the configuration while the persisted values were reflected on stop and start. Maybe there is a method that does both these things which we just need to call? > 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=12647267#action_12647267 ] Manu T George commented on GERONIMO-4369: - Just a clarification. By the attached patch not optimal/working i meant the one attached in Geronimo-4219 :) > 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=12647265#action_12647265 ] Manu T George commented on GERONIMO-4369: - The JIRA is related to https://issues.apache.org/jira/browse/GERONIMO-4219. The attached patch may not be optimal or working. Actually the restart functionality in the admin console starts a configuration and all its child configurations also. That is the functionality of the restartConfiguration method in the configuration Manager. Does the attached patch do this? The issue is that the attribute store is not updated during restart. We should first decide whether to fix it here or in the configuration manager. Why shouldn't the restart method in the configurationManager update the attribute store in case any changes are made? > 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.
Is there a bp project for Geronimo like petstore?
HI guys Is there a bp project for Geronimo like petstore which is implemented based on all the basic feature of Geronimo such as OpenEJB, OpenJPA, Activemq, Derby DB, Webservice, potlets, and so on, and some high level features like ajax? If not, maybe I could make it when I have some leisure time. -- View this message in context: http://www.nabble.com/Is-there-a-bp-project-for-Geronimo-like-petstore--tp20479079s134p20479079.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Created: (GERONIMO-4408) install-library goal for geronimo-maven-plugin
install-library goal for geronimo-maven-plugin --- Key: GERONIMO-4408 URL: https://issues.apache.org/jira/browse/GERONIMO-4408 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: geronimo-maven-plugin Affects Versions: 2.1.3 Reporter: Michal Borowiecki Priority: Minor An install-library goal for geronimo-maven-plugin similar to the install-library option of the deploy command http://cwiki.apache.org/GMOxDOC21/tools-and-commands.html#Toolsandcommands-Installlibrary An important use-case is the ability to automatically install jdbc drivers as part of integration testing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
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.tomcat.deployment.TomcatModuleBuilder' }
> def moduleBuilderExtensionsPatterns =
> tomcatWebBuilderGBean.getReferencePatterns('ModuleBuilderExtensions')
> Set newPatterns = []
> newPatterns.addAll(moduleBuilderExtensionsPatterns.patterns)
> newPatterns.add(new AbstractNameQuery(new
> URI(PUT_YOUR_TUSCANY_MBE_PATTERN_NAME_HERE)))
> tomcatWebBuilderGBean.setReferencePatterns(newPatterns)
>
>
> You should be done.
>
> Thanks,
> Gianny
>
>
>
>> One possiblitly would be to define marker interfaces such as WebMBE,
>> EjbMBE, etc that the appropriate MBE's could implement and use the interface
>> in the references pattern.
>>
>> Anyone have a better idea?
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> Thanks,
>>> Vamsi
>>>
>>
>>
>
--
Vamsi
Re: [Heads up] SSH server in java
Fricken awesome! I'd be more than happy to make the gshell remoting
stuff go away in favor of using ssh ;-) I will take a closer look at
this in the next day or so. I'm very excited by this work!
--jason
On Nov 13, 2008, at 5:58 AM, Guillaume Nodet wrote:
I've just done a real quick prototype to plug into smx kernel and I've
been able to log in into smx kernel using an ssh client and issue a
few commands.
Following is the class that does everything and the spring config to
start the ssh server.
The BogusPasswordAuthenticator is a dummy class which I pasted below
too.
Notice the use of stream filters to convert CR / CRLF stuff. I think
this is because both sshd and the geronimo gshell do not handle well
the pty request and/or VT100 stuff. But I'm still not sure where the
conversion should happen exactly.
Also note that i've redefined the ConsoleErrorHandlerImpl, because the
default one uses the application.getIO() for displaying errors so they
are not available remotely.
Let me know what you think, but it basically makes the whole remote
bits of gshell unused.
I have not implemented the ssh command which should be easy using
jsch lib.
Let me know if / how I can help you with that bits.
==
package org.apache.servicemix.kernel.gshell.core.sshd;
import com.google.code.sshd.PasswordAuthenticator;
public class BogusPasswordAuthenticator implements
PasswordAuthenticator {
public Object authenticate(String username, String password) {
return (username != null && username.equals(password)) ?
username : null;
}
}
==
class
="org.apache.servicemix.kernel.gshell.core.sshd.GShellShellFactory">
class="com.google.code.sshd.hostkeys.FileHostKeyProvider">
${hostKey}
class
=
"org
.apache.servicemix.kernel.gshell.core.sshd.BogusPasswordAuthenticator"
/>
class="com.google.code.sshd.mac.HMACMD5$Factory" />
class="com.google.code.sshd.mac.HMACSHA1$Factory" />
class="com.google.code.sshd.mac.HMACMD596$Factory" />
class="com.google.code.sshd.mac.HMACSHA196$Factory" />
===
package org.apache.servicemix.kernel.gshell.core.sshd;
import java.util.Map;
import java.util.List;
import java.io.OutputStream;
import java.io.InputStream;
import java.io.Closeable;
import java.io.IOException;
import com.google.code.sshd.ShellFactory;
import com.google.code.sshd.shell.CrLfFilterInputStream;
import org.apache.geronimo.gshell.shell.ShellContext;
import org.apache.geronimo.gshell.io.IO;
import org.apache.geronimo.gshell.command.Variables;
import org.apache.geronimo.gshell.console.Console;
import org.apache.geronimo.gshell.console.JLineConsole;
import
org.apache.geronimo.gshell.console.completer.AggregateCompleter;
import org.apache.geronimo.gshell.notification.ExitNotification;
import org.apache.geronimo.gshell.notification.ErrorNotification;
import org.apache.geronimo.gshell.application.model.Branding;
import org.apache.geronimo.gshell.commandline.CommandLineExecutor;
import org.apache.geronimo.gshell.ansi.AnsiRenderer;
import org.slf4j.LoggerFactory;
import org.slf4j.Logger;
import jline.History;
import jline.Completor;
public class GShellShellFactory implements ShellFactory {
private Logger logger = LoggerFactory.getLogger(getClass());
private Branding branding;
private Console.Prompter prompter;
private CommandLineExecutor executor;
private History history;
private List completers;
public Branding getBranding() {
return branding;
}
public void setBranding(Branding branding) {
this.branding = branding;
}
public Console.Prompter getPrompter() {
return prompter;
}
public void setPrompter(Console.Prompter prompter) {
this.prompter = prompter;
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
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.tomcat.deployment.TomcatModuleBuilder' }
def moduleBuilderExtensionsPatterns =
tomcatWebBuilderGBean.getReferencePatterns('ModuleBuilderExtensions')
Set newPatterns = []
newPatterns.addAll(moduleBuilderExtensionsPatterns.patterns)
newPatterns.add(new AbstractNameQuery(new URI
(PUT_YOUR_TUSCANY_MBE_PATTERN_NAME_HERE)))
tomcatWebBuilderGBean.setReferencePatterns(newPatterns)
You should be done.
Thanks,
Gianny
One possiblitly would be to define marker interfaces such as
WebMBE, EjbMBE, etc that the appropriate MBE's could implement and
use the interface in the references pattern.
Anyone have a better idea?
thanks
david jencks
Thanks,
Vamsi
