[jira] Created: (SM-1046) Modify servicemix-file to read files by request
Modify servicemix-file to read files by request --- Key: SM-1046 URL: https://issues.apache.org/activemq/browse/SM-1046 Project: ServiceMix Issue Type: New Feature Components: servicemix-file Reporter: Andrew Romanenco Right now servicemix-sftp can be used using two use cases: 1. As poller - periodic check of target dir, with creating InOnly messages 2. As sender - InOnly messages are saved to files I need next use case: servicemix-sftp should use InOut exchange flow In message will contain full path of file to read Out message will contain file content. In message should be in format: request filefile:///somefile/file renamenewname/rename /request when this event is in process, component will read file identified by URI and will pack it with some marshal if tag raname present, then its value will be used as file name for marshal this new feature will allow file copy based on event -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3450) Unable to Run Pluto 1.1 on Geronimo 2.0
[ https://issues.apache.org/jira/browse/GERONIMO-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh B updated GERONIMO-3450: --- Attachment: geronimo-web.xml The Geronimo-web.xml that i'm using for deployment. Unable to Run Pluto 1.1 on Geronimo 2.0 --- Key: GERONIMO-3450 URL: https://issues.apache.org/jira/browse/GERONIMO-3450 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M2 Environment: Operating System : Windows 2k3 Pluto Version: 1.1.0 Geronimo with Jetty Version 2.0.1 Reporter: Ramesh B Fix For: 1.1.2, 1.1.x Attachments: geronimo-web.xml Hi, I'm new to geronimo webserver. I've been trying to deploy pluto 1.1 on geronimo with jetty 2.0.1. For this I have done the following steps: 1) I've added the following additional jars to common libs before deployment: * pluto-container-1.1.0.jar * pluto-descriptor-api-1.1.0.jar * pluto-descriptor-impl-1.1.0.jar * pluto-taglib-1.1.0.jar * xalan 2.6.0 2) I've modified the castor.properties for pluto/web-inf/classes and set all parameters to false. 3) i've added a geronimo-web.xml to the /web-inf folder. I created a war of the pluto folder. however while deploying it it gives the following error: 3582: 11:02:34,501 ERROR [log] Nested in org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/pluto-portal-driver-services-config.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface: After throwing this error on the console it shows as successfully deployed and successfully running. However when i'm trying to access the pluto portal, it says service unavailable. Please help me with this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3450) Unable to Run Pluto 1.1 on Geronimo 2.0
[ https://issues.apache.org/jira/browse/GERONIMO-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh B updated GERONIMO-3450: --- Attachment: geronimo.log The log of error generated Unable to Run Pluto 1.1 on Geronimo 2.0 --- Key: GERONIMO-3450 URL: https://issues.apache.org/jira/browse/GERONIMO-3450 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M2 Environment: Operating System : Windows 2k3 Pluto Version: 1.1.0 Geronimo with Jetty Version 2.0.1 Reporter: Ramesh B Fix For: 1.1.2, 1.1.x Attachments: geronimo-web.xml, geronimo.log Hi, I'm new to geronimo webserver. I've been trying to deploy pluto 1.1 on geronimo with jetty 2.0.1. For this I have done the following steps: 1) I've added the following additional jars to common libs before deployment: * pluto-container-1.1.0.jar * pluto-descriptor-api-1.1.0.jar * pluto-descriptor-impl-1.1.0.jar * pluto-taglib-1.1.0.jar * xalan 2.6.0 2) I've modified the castor.properties for pluto/web-inf/classes and set all parameters to false. 3) i've added a geronimo-web.xml to the /web-inf folder. I created a war of the pluto folder. however while deploying it it gives the following error: 3582: 11:02:34,501 ERROR [log] Nested in org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/pluto-portal-driver-services-config.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface: After throwing this error on the console it shows as successfully deployed and successfully running. However when i'm trying to access the pluto portal, it says service unavailable. Please help me with this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3327) When both tomcat http and https connector gbeans are unloaded, java.net.MalformedURLException occurs while starting server.
[
https://issues.apache.org/jira/browse/GERONIMO-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523775
]
Kan Ogawa commented on GERONIMO-3327:
-
By GERONIMO-3350 fix, this MalformedURLException wasn't thrown.
https://issues.apache.org/jira/browse/GERONIMO-3350
When both tomcat http and https connector gbeans are unloaded,
java.net.MalformedURLException occurs while starting server.
---
Key: GERONIMO-3327
URL: https://issues.apache.org/jira/browse/GERONIMO-3327
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 1.x, 2.0-M6
Reporter: Kan Ogawa
When both tomcat http and https connector gbeans are unloaded,
java.net.MalformedURLException occurs while running tomcat module startup.
This configuration is, for example, a typical case that other web server (
Apache HTTP Server, IIS, etc. ) connects geronimo server and processes all
http requests firstly as the main http server.
Tomcat module setting in config.xml:
module name=org.apache.geronimo.configs/tomcat6/2.0-M6/car
gbean name=TomcatResources/
gbean load=false name=TomcatWebConnector
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanHTTPPortPrimary +
portOffset}/attribute
attribute name=redirectPort${PlanHTTPSPortPrimary +
portOffset}/attribute
/gbean
gbean name=TomcatAJPConnector
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanAJPPortPrimary +
portOffset}/attribute
attribute name=redirectPort${PlanHTTPSPortPrimary +
portOffset}/attribute
/gbean
gbean load=false name=TomcatWebSSLConnector
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanHTTPSPortPrimary +
portOffset}/attribute
/gbean
/module
Stack trace in geronimo log:
18:30:41,156 ERROR [TomcatWebAppContext] Bad URL to connect to web app
java.net.MalformedURLException: unknown protocol: ajp
at java.net.URL.init(URL.java:574)
at java.net.URL.init(URL.java:464)
at java.net.URL.init(URL.java:413)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.getURLFor(TomcatWebAppContext.java:383)
at
org.apache.geronimo.tomcat.TomcatWebAppContext$$FastClassByCGLIB$$776c85b4.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanAttribute.getValue(GBeanAttribute.java:390)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.getAttribute(GBeanInstance.java:689)
at
org.apache.geronimo.kernel.basic.BasicKernel.getAttribute(BasicKernel.java:178)
at
org.apache.geronimo.deployment.plugin.local.CommandSupport.addWebURLs(CommandSupport.java:295)
at
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getModules(JMXDeploymentManager.java:177)
at
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getAvailableModules(JMXDeploymentManager.java:118)
at
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(DirectoryHotDeployer.java:160)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:994)
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.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:551)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:442)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:511)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
[jira] Updated: (GERONIMO-3327) When both tomcat http and https connector gbeans are unloaded, java.net.MalformedURLException occurs while starting server.
[
https://issues.apache.org/jira/browse/GERONIMO-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kan Ogawa updated GERONIMO-3327:
Fix Version/s: 2.1
2.0
When both tomcat http and https connector gbeans are unloaded,
java.net.MalformedURLException occurs while starting server.
---
Key: GERONIMO-3327
URL: https://issues.apache.org/jira/browse/GERONIMO-3327
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 1.x, 2.0-M6
Reporter: Kan Ogawa
Fix For: 2.0, 2.1
When both tomcat http and https connector gbeans are unloaded,
java.net.MalformedURLException occurs while running tomcat module startup.
This configuration is, for example, a typical case that other web server (
Apache HTTP Server, IIS, etc. ) connects geronimo server and processes all
http requests firstly as the main http server.
Tomcat module setting in config.xml:
module name=org.apache.geronimo.configs/tomcat6/2.0-M6/car
gbean name=TomcatResources/
gbean load=false name=TomcatWebConnector
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanHTTPPortPrimary +
portOffset}/attribute
attribute name=redirectPort${PlanHTTPSPortPrimary +
portOffset}/attribute
/gbean
gbean name=TomcatAJPConnector
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanAJPPortPrimary +
portOffset}/attribute
attribute name=redirectPort${PlanHTTPSPortPrimary +
portOffset}/attribute
/gbean
gbean load=false name=TomcatWebSSLConnector
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanHTTPSPortPrimary +
portOffset}/attribute
/gbean
/module
Stack trace in geronimo log:
18:30:41,156 ERROR [TomcatWebAppContext] Bad URL to connect to web app
java.net.MalformedURLException: unknown protocol: ajp
at java.net.URL.init(URL.java:574)
at java.net.URL.init(URL.java:464)
at java.net.URL.init(URL.java:413)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.getURLFor(TomcatWebAppContext.java:383)
at
org.apache.geronimo.tomcat.TomcatWebAppContext$$FastClassByCGLIB$$776c85b4.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanAttribute.getValue(GBeanAttribute.java:390)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.getAttribute(GBeanInstance.java:689)
at
org.apache.geronimo.kernel.basic.BasicKernel.getAttribute(BasicKernel.java:178)
at
org.apache.geronimo.deployment.plugin.local.CommandSupport.addWebURLs(CommandSupport.java:295)
at
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getModules(JMXDeploymentManager.java:177)
at
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getAvailableModules(JMXDeploymentManager.java:118)
at
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(DirectoryHotDeployer.java:160)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:994)
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.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:551)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:442)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:511)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
[jira] Updated: (GERONIMODEVTOOLS-190) Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-190: - Attachment: HelloWorld.war Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc) --- Key: GERONIMODEVTOOLS-190 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Shiva Kumar H R Fix For: 2.0 Attachments: HelloWorld.war Import the attached HelloWorld.war and double click on geronimo-web.xml. An error window will pop up saying .. elements in the plan may not be qualified ... This is caused by trying to parse v2.0 of Geronimo plans with v1.1 of schemas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-190) Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc)
Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc) --- Key: GERONIMODEVTOOLS-190 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Shiva Kumar H R Fix For: 2.0 Attachments: HelloWorld.war Import the attached HelloWorld.war and double click on geronimo-web.xml. An error window will pop up saying .. elements in the plan may not be qualified ... This is caused by trying to parse v2.0 of Geronimo plans with v1.1 of schemas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-189) Error opening geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523812 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-189: -- I tried with g-eclipse-plugin-2.0.0-v20070829.1146-deployable.zip available at http://people.apache.org/dist/geronimo/eclipse/unstable/ . Created a new Dynamic Web Project with 'Apache Geronimo v2.0' as Target Runtime and then double-clicked on the generated geronimo-web.xml. It opened successfully without any errors. So Shane Blake, please see if restarting eclipse with a clean workspace solves your problem. I see that the generated plan points to v1.1 of Geronimo plans (web-1.1, naming-1.1, deployment-1.1 etc). If we however try to change the version to 2.0, save, close reopen, it fails by throwing an error as reported in GERONIMODEVTOOLS-190. Error opening geronimo-web.xml -- Key: GERONIMODEVTOOLS-189 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-189 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Eclipse SDK Version: 3.3.0 Build id: I20070525-1350 Build id: I20070625-1500 Latest August 23 build from unstable Reporter: Shane Blake Assignee: Tim McConnell Opening geronimo-web.xml getting the following stack trace: java.lang.IllegalArgumentException at org.eclipse.wst.server.core.internal.facets.FacetUtil.getRuntime(FacetUtil.java:61) at org.eclipse.jst.server.core.FacetUtil.getRuntime(FacetUtil.java:47) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.getLoader(SharedDeploymentPlanEditor.java:97) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.loadDeploymentPlan(SharedDeploymentPlanEditor.java:86) at org.apache.geronimo.st.ui.editors.AbstractGeronimoDeploymentPlanEditor.init(AbstractGeronimoDeploymentPlanEditor.java:181) at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:794) at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:643) at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592) at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299) at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179) at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268) at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65) at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:400) at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256) at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209) at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604) at org.eclipse.ui.internal.PartStack.add(PartStack.java:499) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103) at org.eclipse.ui.internal.PartStack.add(PartStack.java:485) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112) at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63) at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217) at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207) at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774) at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673) at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633) at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625) at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2547) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:644) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:603) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:285)
[jira] Commented: (GERONIMODEVTOOLS-183) Eclipse doesnot launch the application with context root instead launches the application with the name of application module
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523817 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-183: -- This looks to have been fixed in trunk by other fixes. Can be closed. Eclipse doesnot launch the application with context root instead launches the application with the name of application module - Key: GERONIMODEVTOOLS-183 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-183 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Microsoft Windows XP Professional version 2002 Service Pack2 Reporter: Ashish Jain Assignee: Tim McConnell Fix For: 2.0 I am using *wtp-all-in-one-sdk-R-2.0-200706260303* and *g-eclipse-plugin-2.0.0-v20070812.0209-deployable*. While I run application hello-1.1.1.war using Eclipse, instead of launching the application with the context root that is *hello* it launches the application with *hello-1.1.1* and I get a 404 error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-183) Eclipse doesnot launch the application with context root instead launches the application with the name of application module
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-183. -- Resolution: Fixed Closing, per Shiva, as other fixes in trunk have fixed this problem Eclipse doesnot launch the application with context root instead launches the application with the name of application module - Key: GERONIMODEVTOOLS-183 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-183 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Microsoft Windows XP Professional version 2002 Service Pack2 Reporter: Ashish Jain Assignee: Tim McConnell Fix For: 2.0 I am using *wtp-all-in-one-sdk-R-2.0-200706260303* and *g-eclipse-plugin-2.0.0-v20070812.0209-deployable*. While I run application hello-1.1.1.war using Eclipse, instead of launching the application with the context root that is *hello* it launches the application with *hello-1.1.1* and I get a 404 error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tuscany plugin for Geronimo moved from Geronimo sandbox to Geronimo Plugins
I'm getting a compile error building this as one of the Tuscany interfaces has been changed recently. Is it intended to be used with the Tuscany trunk or with a particular release of Tuscany? ...ant On 8/29/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I have moved the Tuscany Plugin for Geronimo from sandbox to Geronimo Plugins. The svn URL is https://svn.apache.org/repos/asf/geronimo/plugins/tuscany . I had to add a few additional repositories to the parent pom so that the plugin can be built successfully with a clean m2 local repository. The plugin can be installed on Geronimo 2.0.1. There is a version of the plugin for Geronimo Tomcat distribution and another for Geronimo Jetty distribution. There are a few samples in Geronimo sandbox at https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/samplesthat can be used with the plugin. Thanks and regards, Vamsi
[jira] Updated: (GERONIMO-3447) Tuscany plugin for Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated GERONIMO-3447: Attachment: ServletHostPatch.txt Here's a patch (ServletHostPatch.txt) to get this compiling with the latest Tuscany trunk code. The added methods are empty so need to be implemented at some point but they're also empty right now in some of the Tuscany ServletHost impls. Tuscany plugin for Geronimo --- Key: GERONIMO-3447 URL: https://issues.apache.org/jira/browse/GERONIMO-3447 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Environment: G 2.0.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Attachments: ServletHostPatch.txt This JIRA is created to track moving of Tuscany plugin for geronimo into geronimo\plugins. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Splitting up the server into a few more chunks
On Aug 29, 2007, at 1:12 PM, Prasad Kashyap wrote: 2. We have to split the current build tree into support, framework, and plugins sub-trees. Other than support and framework, everything else should be plugins. This includes jee5, non-jee5, samples etc. which could go in their own subtrees or be together. I like your ideas. Taking a step back are we in agreement on the everything else as plugins approach? We have been hinting at this for some time and doing various interesting things with plugins but I don't see enough of the big picture yet to provide much useful feedback on your proposal. Maybe the time is right to start a big picture discussion about plugins. I'll cook something up and maybe that thread will help us answer some of your questions. Best wishes, Paul
[DISCUSS] to plugin or not to plugin, that is the question
We've been excited about and doing lots of interesting things with plugins lately. From a big picture perspective I'm wondering where we are headed. Some of my questions are: - So do we all really agree that plugins are The Way and are we prepared to reconsider how Geronimo is developed, built, and deployed around that approach? Or should plugins remain as simply an alternate mechanism for installing components and applications? - What is the purpose of the framework assembly and how are the other various assemblies built, installed, and configured? - Can/should we build assemblies for TCK from plugins and if so how would they be made available to end users? I heard some ideas about using plugins as a component grouping mechanism that would allow users to transform their server into a certified assembly by simply installing their plugin of choice. That sounds promising and needs more thought. - There is some work going on in GERONIMO-3330 to improve the robustness and maintainability plugin catalogs. What other infrastructure type requirements do we have for making plugin repositories easy to use and maintain? - What usability improvements are needed in the plugin CLI and admin console portlets? - Is there any place for OSGI in Geronimo's plugin strategy? - Java EE 6 (JSR 316) has a major theme of modularity and extensibility in the application server[1]. How can we align our plugin strategy with what's coming our way at a specification level? Looking forward to your thoughts and follow on questions. Best wishes, Paul [1] http://www.infoq.com/news/2007/07/jee6
Re: [DISCUSS] to plugin or not to plugin, that is the question
Hey Paul ... thanks for getting these discussions started. I had intended to do the same (though perhaps not quite as thorough as you have done). Paul McMahan wrote: We've been excited about and doing lots of interesting things with plugins lately. From a big picture perspective I'm wondering where we are headed. Some of my questions are: - So do we all really agree that plugins are The Way and are we prepared to reconsider how Geronimo is developed, built, and deployed around that approach? Or should plugins remain as simply an alternate mechanism for installing components and applications? I think going this route is a must. We've been touting how flexible Geronimo is and this makes it much more of a reality for our users. Hopefully it will make it easier for us to manage all the moving parts as well. - What is the purpose of the framework assembly and how are the other various assemblies built, installed, and configured? We had a brief discussion of this on another thread where I questioned if we wanted to keep framework around. It's better to centralize the discussion here. Framework was originally created with the idea that it would be the core assembly and we could build up the other assemblies from it by installing plugins. I think that's still the most architecturally pure approach. (Note: we may want to try to remove more from framework so that it doesn't include so many j2ee* configs). However in the other thread, I was wondering if it makes sense to have a core framework that really isn't of any use (to a user) without installing some additional plugins. Perhaps the minimal assemblies would be better roots since they have a purpose even without any additional plugins. I keep waffling on this ... but at the moment I like the architectural purity of having just one core assembly from which all others could be built. - Can/should we build assemblies for TCK from plugins and if so how would they be made available to end users? I heard some ideas about using plugins as a component grouping mechanism that would allow users to transform their server into a certified assembly by simply installing their plugin of choice. That sounds promising and needs more thought. Absolutely yes!!! I think we need to make the TCK changes regardless of what we do with the main plugin strategy. However, I'm not clear on the idea of a plugin itself being used to group other plugins. I was thinking more along the lines of another construct which groups plugins (we've referred to this as templates at various times). I suppose we could build plugins that aggregated other plugins to accomplish this too and that would negate the need for yet another type of item a user must deal with. - There is some work going on in GERONIMO-3330 to improve the robustness and maintainability plugin catalogs. What other infrastructure type requirements do we have for making plugin repositories easy to use and maintain? I think there's a lot of work to do here. IMO, we need to start providing more capabilities for plugins to express compatibility with other plugins (for example so that a plugin containing a web app could express a dependency on a web container without having to call out jetty or tomcat specifically if there are no hard dependencies). I also think we need to make it so that plugins are not so tightly coupled to a particular Geronimo version if not absolutely required. It would be nice if we didn't have to re-release the JSP sample plugins for each new Geronimo release. - What usability improvements are needed in the plugin CLI and admin console portlets? I think there are definitely some .. but I won't try to itemize them now. - Is there any place for OSGI in Geronimo's plugin strategy? Good question ... I think there probably is but I'm a little concerned about opening pandora's box. If OSGI makes it easier and quicker to get to a more pluggable server and bring benefits for other integrators then I think we should definitely consider it now. However, if it would cause a significant delay in our delivery of a pluggable server I would prefer we deliver the function first and swap out the engine later. Of course there will be trade-offs here ... I guess the real question is how substantial would a change to OSGI be at this time or later and is that the direction that we want to move in? - Java EE 6 (JSR 316) has a major theme of modularity and extensibility in the application server[1]. How can we align our plugin strategy with what's coming our way at a specification level? Looks like more reading I need to catch up on :-) Looking forward to your thoughts and follow on questions. Best wishes, Paul [1] http://www.infoq.com/news/2007/07/jee6
[jira] Commented: (GERONIMO-3450) Unable to Run Pluto 1.1 on Geronimo 2.0
[ https://issues.apache.org/jira/browse/GERONIMO-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523901 ] Kevan Miller commented on GERONIMO-3450: Ramesh I'm not sure I understand what you mean by 1). Where are your adding the jars? You're declaring pluto dependencies, but then you're filtering pluto from your parent ClassLoaders: hidden-classes filterorg.apache.pluto/filter filterorg.springframework/filter /hidden-classes So, I'm a little confused... Anyway, to the heart of the matter... You need to filter spring resources as well as spring classes: hidden-classes filterorg.apache.pluto/filter filterorg.springframework/filter filterMETA-INF/spring/filter /hidden-classes Unable to Run Pluto 1.1 on Geronimo 2.0 --- Key: GERONIMO-3450 URL: https://issues.apache.org/jira/browse/GERONIMO-3450 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M2 Environment: Operating System : Windows 2k3 Pluto Version: 1.1.0 Geronimo with Jetty Version 2.0.1 Reporter: Ramesh B Fix For: 1.1.2, 1.1.x Attachments: geronimo-web.xml, geronimo.log Hi, I'm new to geronimo webserver. I've been trying to deploy pluto 1.1 on geronimo with jetty 2.0.1. For this I have done the following steps: 1) I've added the following additional jars to common libs before deployment: * pluto-container-1.1.0.jar * pluto-descriptor-api-1.1.0.jar * pluto-descriptor-impl-1.1.0.jar * pluto-taglib-1.1.0.jar * xalan 2.6.0 2) I've modified the castor.properties for pluto/web-inf/classes and set all parameters to false. 3) i've added a geronimo-web.xml to the /web-inf folder. I created a war of the pluto folder. however while deploying it it gives the following error: 3582: 11:02:34,501 ERROR [log] Nested in org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/pluto-portal-driver-services-config.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface: After throwing this error on the console it shows as successfully deployed and successfully running. However when i'm trying to access the pluto portal, it says service unavailable. Please help me with this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3115) MDB pool size should be able to be configurable in openejb-jar.xsd
[ https://issues.apache.org/jira/browse/GERONIMO-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523909 ] Aman Nanner commented on GERONIMO-3115: --- I had tried this at one time and it didn't work: http://www.nabble.com/Sharing-resources-in-an-MDB-tf3412013s134.html#a9506828 MDB pool size should be able to be configurable in openejb-jar.xsd -- Key: GERONIMO-3115 URL: https://issues.apache.org/jira/browse/GERONIMO-3115 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0-M6 Reporter: Aman Nanner Fix For: 2.0.x, 2.1 There should be an attribute for message driven beans in the openejb-jar.xsd schema that will configure the pool size. For example, if a pool size of 1 were configured for a specific bean, then there would only be a maximum of 1 message driven bean instance of that type that would be instantiated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [BUILD] Trunk: Failed for Revision: 570882
On Aug 29, 2007, at 10:11 PM, Jason Dillon wrote: You are very correct... :-) IMO slf4j is the way to go... drop JCL like a rock... Logback is LGPL, to be precise -- not that it makes any difference... I haven't looked at sl4j. What are the motivations to switch? --kevan
[jira] Updated: (GERONIMODEVTOOLS-190) Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-190: --- Affects Version/s: (was: 2.0) 2.1.x Fix Version/s: (was: 2.0) 2.0.x Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc) --- Key: GERONIMODEVTOOLS-190 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Fix For: 2.0.x Attachments: HelloWorld.war Import the attached HelloWorld.war and double click on geronimo-web.xml. An error window will pop up saying .. elements in the plan may not be qualified ... This is caused by trying to parse v2.0 of Geronimo plans with v1.1 of schemas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-190) Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-190: --- Affects Version/s: (was: 2.1.x) 2.0.x Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc) --- Key: GERONIMODEVTOOLS-190 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.x Reporter: Shiva Kumar H R Fix For: 2.0.x Attachments: HelloWorld.war Import the attached HelloWorld.war and double click on geronimo-web.xml. An error window will pop up saying .. elements in the plan may not be qualified ... This is caused by trying to parse v2.0 of Geronimo plans with v1.1 of schemas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-187) EMF for new schema version of Geronimo Deployment Plans
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-187: --- Fix Version/s: (was: 2.0) 2.0.x Affects Version/s: (was: 2.0) 2.0.x EMF for new schema version of Geronimo Deployment Plans --- Key: GERONIMODEVTOOLS-187 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-187 Project: Geronimo-Devtools Issue Type: Task Components: eclipse-plugin Affects Versions: 2.0.x Reporter: Shiva Kumar H R Priority: Critical Fix For: 2.0.x Attachments: GERONIMODEVTOOLS-187-reference.patch plugins\org.apache.geronimo.st.v20.core is currently using EMF classes from org.apache.geronimo.v11.deployment.model. However Geronimo v2.0.1 has new schema versions for its deployment plans. We need to generate EMF for these new schemas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-181) Plugin build process should use maven-ant-plugin to download required Eclipse artifacts
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-181: --- Fix Version/s: (was: 2.0) 2.1.x Affects Version/s: (was: 2.0) 2.1.x Plugin build process should use maven-ant-plugin to download required Eclipse artifacts Key: GERONIMODEVTOOLS-181 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-181 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.x The Eclipse plugin build process should use maven-ant-plugin to download the required Eclipse artifacts from the Eclipse website rather than copying the artifacts into a local maven repository on people.apache.org -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-176) GeronimoServerBehaviourDelegate always uses rmi port 1099
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-176: --- Affects Version/s: (was: 2.0) 2.0.x Fix Version/s: (was: 2.0) 2.0.x GeronimoServerBehaviourDelegate always uses rmi port 1099 - Key: GERONIMODEVTOOLS-176 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-176 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.x Reporter: Donald Woods Fix For: 2.0.x We need to allow the user to reconfigure the RMI port, for the cases where they have mapped the server to use something besides the default 1099 port. Also, this would allow the plugin to support the new multiple server instance feature in the 2.0 server -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-189) Error opening geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-189: --- Affects Version/s: (was: 2.0) 2.0.x Fix Version/s: 2.0.x Error opening geronimo-web.xml -- Key: GERONIMODEVTOOLS-189 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-189 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.x Environment: Eclipse SDK Version: 3.3.0 Build id: I20070525-1350 Build id: I20070625-1500 Latest August 23 build from unstable Reporter: Shane Blake Assignee: Tim McConnell Fix For: 2.0.x Opening geronimo-web.xml getting the following stack trace: java.lang.IllegalArgumentException at org.eclipse.wst.server.core.internal.facets.FacetUtil.getRuntime(FacetUtil.java:61) at org.eclipse.jst.server.core.FacetUtil.getRuntime(FacetUtil.java:47) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.getLoader(SharedDeploymentPlanEditor.java:97) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.loadDeploymentPlan(SharedDeploymentPlanEditor.java:86) at org.apache.geronimo.st.ui.editors.AbstractGeronimoDeploymentPlanEditor.init(AbstractGeronimoDeploymentPlanEditor.java:181) at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:794) at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:643) at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592) at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299) at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179) at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268) at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65) at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:400) at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256) at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209) at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604) at org.eclipse.ui.internal.PartStack.add(PartStack.java:499) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103) at org.eclipse.ui.internal.PartStack.add(PartStack.java:485) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112) at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63) at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217) at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207) at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774) at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673) at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633) at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625) at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2547) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:644) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:603) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:285) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:138) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:194) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:175) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:268) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:244) at org.eclipse.jdt.internal.ui.navigator.OpenAndExpand.run(OpenAndExpand.java:50) at
[jira] Updated: (GERONIMODEVTOOLS-171) Remove hard-coded Geronimo name from launch console message and tool-tip
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim McConnell updated GERONIMODEVTOOLS-171:
---
Fix Version/s: 2.0.x
Affects Version/s: (was: 2.0)
2.0.x
Remove hard-coded Geronimo name from launch console message and tool-tip
Key: GERONIMODEVTOOLS-171
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-171
Project: Geronimo-Devtools
Issue Type: Improvement
Components: eclipse-plugin
Affects Versions: 2.0.x
Reporter: Ted Kirby
Assignee: Tim McConnell
Fix For: 2.0.x
Attachments: GD-171.patch
Replace:
console=Geronimo Console
consoleTooltip=Apache Geronimo Console
with:
console={0} Console
consoleTooltip={0} Console
in
eclipse-plugin\plugins\org.apache.geronimo.st.ui\src\org\apache\geronimo\st\ui\internal\Messages.properties,
and allow the server name to be determined by server.getName().
This allows for an extensible approach, for servers based on Geronimo. No
change is required to support other servers.
In this particular case,
plugins\org.apache.geronimo.st.ui\src\org\apache\geronimo\st\ui\actions\LaunchGeronimoConsoleAction.G_SERVER_PREFIX
is hard-coded to org.apache.geronimo. It would be nice if this could be
paramterized in some fashion to avoid having to replace the class in its
entirety, just to change this value to determine if the Launch {ServerName}
Console menu item should be activated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-188) devtools\eclipse-plugin\assembly\src\main\assembly\site.xml does not look like it has svn keyword properties set
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-188: --- Affects Version/s: (was: 2.0) 2.0.x Fix Version/s: 2.0.x devtools\eclipse-plugin\assembly\src\main\assembly\site.xml does not look like it has svn keyword properties set Key: GERONIMODEVTOOLS-188 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-188 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.x Reporter: Ted Kirby Assignee: Tim McConnell Priority: Minor Fix For: 2.0.x the $Rev$ tag is not being set and updated via svn The file was added in August, but the $Rev$ tag is from April. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-113) Granualize trace statements
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-113: --- Fix Version/s: (was: 1.2.1) 2.0.x Assignee: Tim McConnell (was: Sachin Patel) Affects Version/s: (was: 1.2.1) 2.0.x Granualize trace statements --- Key: GERONIMODEVTOOLS-113 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-113 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.0.x Reporter: Sachin Patel Assignee: Tim McConnell Priority: Minor Fix For: 2.0.x Too many trace statements, need to break them down into INFO, ERROR, FINE and FINEST or something similar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-177) Start of Remote Geronimo Server from within Eclipse fails
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-177: --- Affects Version/s: 2.1.x Fix Version/s: 2.1.x Start of Remote Geronimo Server from within Eclipse fails - Key: GERONIMODEVTOOLS-177 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-177 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.x Environment: Geronimo Eclipse Plug-in v1.2.1 and v2.0 Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.x Scenario: Using Eclipse to deploy apps to a remote instance of Geronimo. Add a remote instance of Geronimo server (say v2.0) inside Eclipse as per the instructions in http://www.ibm.com/developerworks/java/library/os-ag-remotedeploy/index.html Upon trying to Start that remote Geronimo server from within Eclipse, it immediately fails with an error Server Apache Geronimo v2.0 Server at remote-server-name failed to start. However if the remote server is manually started (outside of Eclipse), after a while its state changes to Started inside Eclipse. And we can deploy/redeploy/undeploy stop the remote server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-118) Complete Editor Support for specifying Dependencies, Hidden Classes, Non Overridable Classes GBean References in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-118: --- Fix Version/s: 2.1.x Assignee: Tim McConnell (was: Sachin Patel) Affects Version/s: (was: 1.2.1) 2.1.x Complete Editor Support for specifying Dependencies, Hidden Classes, Non Overridable Classes GBean References in geronimo-web.xml --- Key: GERONIMODEVTOOLS-118 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-118 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.x Attachments: GERONIMODEVTOOLS-118.patch, Snapshot-1a.gif, Snapshot-1b.gif, Snapshot-2a.gif, Snapshot-2b.gif, Snapshot-2c.gif, Snapshot-3a.gif, Snapshot-3b.gif, Snapshot-3c.gif Please see the discussion going on about this at dev@geronimo.apache.org mailing list: http://www.mail-archive.com/dev@geronimo.apache.org/msg35865.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-120) Refinements to the Web Container section of Deployment Plan Editors
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-120: --- Fix Version/s: (was: 1.2.1) 2.1.x Assignee: Tim McConnell (was: Sachin Patel) Affects Version/s: (was: 1.2.1) 2.1.x Refinements to the Web Container section of Deployment Plan Editors - Key: GERONIMODEVTOOLS-120 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-120 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.x Attachments: GERONIMODEVTOOLS-120.patch, Snapshot-1.gif, Snapshot-2.gif GUI for Web Container section in General tab is updated as shown in Snapshot1.gif and Snapshot2.gif . When Specify as GBean Link radio button is chosen, the section will only ask for GBean Link. And when Specify as GBean Pattern radio button is chosen, it will only ask for the sub-elements of pattern element. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-123) Complete Editor Support for specifying EJB References, EJB Local References, Resource References Resource Environment References in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-123: --- Fix Version/s: (was: 1.2.1) 2.1.x Affects Version/s: (was: 1.2.1) 2.1.x Complete Editor Support for specifying EJB References, EJB Local References, Resource References Resource Environment References in geronimo-web.xml -- Key: GERONIMODEVTOOLS-123 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-123 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Sachin Patel Fix For: 2.1.x Attachments: 1a.gif, 1b.gif, 1c.gif, 1d.gif, 1e.gif, 2a.gif, 2b.gif, 3a.gif, 3b.gif, 4a.gif, 4b.gif, GERONIMODEVTOOLS-118-120-122-123-124-consolidated.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-128) Complete Editor Support for specifying Web Service References in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-128: --- Fix Version/s: (was: 1.2.1) 2.1.x Assignee: Tim McConnell (was: Sachin Patel) Affects Version/s: (was: 1.2.1) 2.1.x Complete Editor Support for specifying Web Service References in geronimo-web.xml - Key: GERONIMODEVTOOLS-128 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.x Attachments: 1.gif, 2.gif, 3.gif, 4.gif, 5.gif Enhancements to Web Service References wizard: The wizard that comes up when Add or Edit button in Service Refs section is clicked, is updated to provide full support for adding/editing of gernaming:service-refType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-129) Enhanced Editor Support for specifying GBeans in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-129: --- Fix Version/s: (was: 1.2.1) 2.1.x Assignee: Tim McConnell (was: Sachin Patel) Affects Version/s: (was: 1.2.1) 2.1.x Enhanced Editor Support for specifying GBeans in geronimo-web.xml - Key: GERONIMODEVTOOLS-129 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-129 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.x Attachments: 1.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif, webplans_editor cumulative-118-120-122-123-124-127-128-129.patch Enhancements to GBeans wizard: The wizard that comes up when Add or Edit button in GBeans section is clicked, is updated to provide enhanced support for adding/editing of sys:gbeanType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-123) Complete Editor Support for specifying EJB References, EJB Local References, Resource References Resource Environment References in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-123: --- Assignee: Tim McConnell (was: Sachin Patel) Complete Editor Support for specifying EJB References, EJB Local References, Resource References Resource Environment References in geronimo-web.xml -- Key: GERONIMODEVTOOLS-123 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-123 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.x Attachments: 1a.gif, 1b.gif, 1c.gif, 1d.gif, 1e.gif, 2a.gif, 2b.gif, 3a.gif, 3b.gif, 4a.gif, 4b.gif, GERONIMODEVTOOLS-118-120-122-123-124-consolidated.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-127) Complete Editor Support for specifying Security Configuration in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-127: --- Fix Version/s: (was: 1.2.1) 2.1.x Affects Version/s: (was: 1.2.1) 2.1.x Complete Editor Support for specifying Security Configuration in geronimo-web.xml - Key: GERONIMODEVTOOLS-127 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Sachin Patel Fix For: 2.1.x Attachments: 1.gif, 10.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif, 7.gif, 8.gif, 9.gif The Security page of Geronimo Deployment Plan Editor is now enhanced and supports adding/editing of complete Security Configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-124) Add editor support for specifying gernaming:message-destination elements in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-124: --- Fix Version/s: (was: 1.2.1) 2.1.x Affects Version/s: (was: 1.2.1) 2.1.x Add editor support for specifying gernaming:message-destination elements in geronimo-web.xml Key: GERONIMODEVTOOLS-124 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-124 Project: Geronimo-Devtools Issue Type: New Feature Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Sachin Patel Fix For: 2.1.x Attachments: 1a.gif, 1b.gif, 2.gif This feature enables the user to add/edit gernaming:message-destination elements in geronimo-web.xml. Snapshots 1a.gif 1b.gif demonstrate this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-127) Complete Editor Support for specifying Security Configuration in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-127: --- Assignee: Tim McConnell (was: Sachin Patel) Complete Editor Support for specifying Security Configuration in geronimo-web.xml - Key: GERONIMODEVTOOLS-127 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.x Attachments: 1.gif, 10.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif, 7.gif, 8.gif, 9.gif The Security page of Geronimo Deployment Plan Editor is now enhanced and supports adding/editing of complete Security Configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-124) Add editor support for specifying gernaming:message-destination elements in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-124: --- Assignee: Tim McConnell (was: Sachin Patel) Add editor support for specifying gernaming:message-destination elements in geronimo-web.xml Key: GERONIMODEVTOOLS-124 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-124 Project: Geronimo-Devtools Issue Type: New Feature Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.x Attachments: 1a.gif, 1b.gif, 2.gif This feature enables the user to add/edit gernaming:message-destination elements in geronimo-web.xml. Snapshots 1a.gif 1b.gif demonstrate this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] to plugin or not to plugin, that is the question
On 8/30/07, Paul McMahan [EMAIL PROTECTED] wrote: We've been excited about and doing lots of interesting things with plugins lately. From a big picture perspective I'm wondering where we are headed. Some of my questions are: - So do we all really agree that plugins are The Way and are we prepared to reconsider how Geronimo is developed, built, and deployed around that approach? Or should plugins remain as simply an alternate mechanism for installing components and applications? I am totally hooked on to the idea of a fully flexible, build your own server. To achieve this, the perfect stackable components are plugins. So I'd like us to make everything other than the framework as plugins. - What is the purpose of the framework assembly and how are the other various assemblies built, installed, and configured? From an architectural standpoint, we shall always begin with a framework as our foundation. This will contain the least common denominator set of components that any conceivable assembly will contain. It will also contain the infrastructure to install other plugins. However, a framework by itself is of no business value to anybody. And since we are in the business of providing an application server, I think we should provide the 2 minimal assemblies as outputs to our end users. Those will be the ones we release. - Can/should we build assemblies for TCK from plugins and if so how would they be made available to end users? I heard some ideas about using plugins as a component grouping mechanism that would allow users to transform their server into a certified assembly by simply installing their plugin of choice. That sounds promising and needs more thought. My thoughts on this was to assemble the CTS server by applying the relevant JEE5 plugins on the framework.Installing a plugin installs all it's dependencies too. So if a plugin with a certain profile is installed, it's dependencies will all be installed and thus we build a CTS server. - There is some work going on in GERONIMO-3330 to improve the robustness and maintainability plugin catalogs. What other infrastructure type requirements do we have for making plugin repositories easy to use and maintain? To begin with, the ability to install and remove plugins is the most basic requirement. - What usability improvements are needed in the plugin CLI and admin console portlets? The plugins catalog must be viewable from the console. The plugin components should be listed with a checkbox next to it. Each plugin component can be further expanded/collapsed to reveal their runtime, deployer and admin plugins. Selecting a checkbox next to a component should install all it's 3 plugin pieces. However, the component can be expanded and it's individual plugin pieces can be selected too. Selecting a plugin's checkbox should also select all it's other dependencies' checkboxes. Plugin catalog o + jetty o - openejb o openejb-runtime o openejb-deployer o openejb-admin Imagine the o to be checkboxes. - Is there any place for OSGI in Geronimo's plugin strategy? If all the plugins are developed and released independently, I wonder if dependencies on multiple versions can cause potential problems. Hmmm.. If somebody with a more thorough knowledge of how plugins currently handle versioning can throw some light on this, it would be much appreciated. - Java EE 6 (JSR 316) has a major theme of modularity and extensibility in the application server[1]. How can we align our plugin strategy with what's coming our way at a specification level? Looking forward to your thoughts and follow on questions. Best wishes, Paul [1] http://www.infoq.com/news/2007/07/jee6 Cheers Prasad
[jira] Updated: (GERONIMODEVTOOLS-187) EMF for new schema version of Geronimo Deployment Plans
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-187: --- Assignee: Tim McConnell EMF for new schema version of Geronimo Deployment Plans --- Key: GERONIMODEVTOOLS-187 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-187 Project: Geronimo-Devtools Issue Type: Task Components: eclipse-plugin Affects Versions: 2.0.x Reporter: Shiva Kumar H R Assignee: Tim McConnell Priority: Critical Fix For: 2.0.x Attachments: GERONIMODEVTOOLS-187-reference.patch plugins\org.apache.geronimo.st.v20.core is currently using EMF classes from org.apache.geronimo.v11.deployment.model. However Geronimo v2.0.1 has new schema versions for its deployment plans. We need to generate EMF for these new schemas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-57) When user configure server and put wrong password, no message is shown
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-57: -- Affects Version/s: 2.0.x Fix Version/s: (was: 1.2.1) 2.0.x Assignee: Tim McConnell When user configure server and put wrong password, no message is shown -- Key: GERONIMODEVTOOLS-57 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-57 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.x Environment: Win2K, Sun JDK 1.4.2, Eclipse 3.11 with WTP 1.0.1 and latest daily build of eclipse plugin (20060130-0958) Reporter: Edson Richter Assignee: Tim McConnell Fix For: 2.0.x When developer configure a new server, it should select HTTP Port, RMI Port and administration user and password. If user and/or password is wrong, when Geronimo is started by developer, no message is shown about wrong user or password, and status for server stay on starting forever (or, at least, until timeout occur). Expected behaviour is if user or password is incorrect, a message is shown so developer could correct this in server properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-75) DEBUG messages are shown when INFO was selected.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-75: -- Affects Version/s: (was: 1.0.0) 2.0.x Fix Version/s: (was: 1.2.1) 2.0.x Assignee: Tim McConnell DEBUG messages are shown when INFO was selected. Key: GERONIMODEVTOOLS-75 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-75 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.x Reporter: Archimedes Trajano Assignee: Tim McConnell Priority: Minor Fix For: 2.0.x DEBUG messages are shown in the console, although I only had INFO selected in Console Output -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-67) M2 plugin to generate WTP adopter API usage report
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-67: -- Fix Version/s: (was: 1.2.1) 2.1.x Assignee: Tim McConnell Affects Version/s: 2.1.x M2 plugin to generate WTP adopter API usage report -- Key: GERONIMODEVTOOLS-67 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-67 Project: Geronimo-Devtools Issue Type: Task Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Sachin Patel Assignee: Tim McConnell Priority: Minor Fix For: 2.1.x -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-125) Unable to upgrade from 1.1 to 1.2 Release through Eclipse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-125: --- Affects Version/s: (was: 1.2.0) 2.1.x Fix Version/s: 2.1.x Assignee: Tim McConnell Unable to upgrade from 1.1 to 1.2 Release through Eclipse - Key: GERONIMODEVTOOLS-125 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-125 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.x Environment: Linux (JDK 1.4.2) Windows XP (JDK 1.4.2, 1.5.0, 1.6.0) Reporter: Reiner Kappenberger Assignee: Tim McConnell Priority: Critical Fix For: 2.1.x I've performed the following tasks: 1. Fresh Install of Eclipse (3.2.1) (removed previous eclipse workspace 2. Update eclipse 3. Install Calisto Bundle 4. Install Geronimo support through Don't see your server listed link in Add Server Runtime 5. Update Eclipse to latest version(s) During this latest update I receive the error that files cannot be created. In the configuration I receive the following for the org.apache.geronimo.feature (v1.2.0): Plug-in org.apache.geronimo.deployment.model version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.runtime.v1 version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.deployment.model.edit version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.v11.deployment.model.edit version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.common.deployment.model.edit version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.v11.deployment.model version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.common.deployment.model version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.v11.ui version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.v11.core version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.v1.ui version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.v1.core version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.ui version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.core version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.runtime.v11 version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.runtime.common version 1.1.0 referenced by this feature is missing. Reiner -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-65) Support qualifer builds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-65: -- Fix Version/s: (was: 1.2.1) 2.0.x Assignee: Tim McConnell Affects Version/s: 2.0.x Support qualifer builds --- Key: GERONIMODEVTOOLS-65 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-65 Project: Geronimo-Devtools Issue Type: Task Components: eclipse-plugin Affects Versions: 2.0.x Reporter: Sachin Patel Assignee: Tim McConnell Fix For: 2.0.x Support qualifiers in plugins and features. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3233) Local EJB references cannot be resolved when inverse-classloading is set in web application
[
https://issues.apache.org/jira/browse/GERONIMO-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aman Nanner updated GERONIMO-3233:
--
Affects Version/s: (was: 2.0-M6)
2.1
2.0.x
Local EJB references cannot be resolved when inverse-classloading is set in
web application
-
Key: GERONIMO-3233
URL: https://issues.apache.org/jira/browse/GERONIMO-3233
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.0.x, 2.1
Environment: Windows XP SP2
Reporter: Aman Nanner
Priority: Critical
Attachments: ejb-reference-fails.ear.zip
It seems that setting the {{inverse-classloading}} element in the
geronimo-web.xml for a web application causes Local EJB references to fail
when looked up. This is because a new SystemInstance is created via a
different classloader, and the existing SystemInstance singleton is not used.
Here is a stack trace of the error:
{code}
15:46:49,877 WARN [EjbFactory] Unable to lookup up EJB by reference name
'ejb/common/SequenceGenerator'; you must define the EJB reference
javax.naming.NamingException: Could not look up :
ejb/common/SequenceGenerator [Root exception is
java.lang.NullPointerException]
at org.apache.xbean.naming.context.ContextUtil.resolve(
ContextUtil.java:65)
at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:112)
at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:611)
at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:152)
at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:611)
at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:152)
at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:597)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
.
at org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:109)
at org.apache.catalina.valves.AccessLogValve.invoke(
AccessLogValve.java:563)
at org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:261)
at org.apache.coyote.http11.Http11Processor.process(
Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
Http11Protocol.java:581)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(
JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
at org.apache.openejb.core.ivm.naming.IntraVmJndiReference.getObject(
IntraVmJndiReference.java:38)
at org.apache.openejb.core.ivm.naming.Reference.getContent(
Reference.java:40)
at org.apache.xbean.naming.context.ContextUtil.resolve(
ContextUtil.java:61)
... 50 more
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] to plugin or not to plugin, that is the question
On Aug 30, 2007, at 3:39 PM, Prasad Kashyap wrote: - Is there any place for OSGI in Geronimo's plugin strategy? If all the plugins are developed and released independently, I wonder if dependencies on multiple versions can cause potential problems. My experience so far has been that plugins only work on the version of Geronimo that they are exported from (or the version of car plugin), mainly due to the fact that their configuration data is stored in a serialized gbean info java object. When an API changes in the server it usually makes previously exported plugins incompatible. This has a lot of ramifications on release management. Using XML as the serialization format for configuration data could help, I forget where that discussion left off. Best wishes, Paul
[jira] Updated: (GERONIMODEVTOOLS-175) javamail package is not included in server runtime
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-175: --- Fix Version/s: 2.0 Assignee: Tim McConnell javamail package is not included in server runtime -- Key: GERONIMODEVTOOLS-175 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-175 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Song Assignee: Tim McConnell Fix For: 2.0 If an application uses javamail, user have to manually add geronimo's javamail jar into build path. Why javamail jar is not included in server runtime by default? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-175) javamail package is not included in server runtime
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523926 ] Ted Kirby commented on GERONIMODEVTOOLS-175: Thanks for the input Kan. It seems easy to add a jar to the classpath, but for me that raises the questions: What should be in the classpath? I don't think adding a few jars here and there that are someone's favorite at the time is what we ought to do. It seems to me that all jars that are on the classpath by default when a module is deployed ought to be there. If a user will have to add them to his classpath for them to work when deployed on the server, then having us add them here I do not think is proper, nor does it really help the user out. I'd like further input on what the classpath should be. javamail package is not included in server runtime -- Key: GERONIMODEVTOOLS-175 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-175 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Song Assignee: Tim McConnell Fix For: 2.0 If an application uses javamail, user have to manually add geronimo's javamail jar into build path. Why javamail jar is not included in server runtime by default? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-101) remote debugging
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-101: --- Fix Version/s: 2.1.x Assignee: Tim McConnell Affects Version/s: (was: 1.1.0) 2.1.x remote debugging Key: GERONIMODEVTOOLS-101 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-101 Project: Geronimo-Devtools Issue Type: New Feature Components: eclipse-plugin Affects Versions: 2.1.x Environment: IBM JVM 1.5, Eclipse 3.2.0, WTP 1.5, w2k/w3k, remote either w?k or linux Reporter: Oleg Gusakov Assignee: Tim McConnell Fix For: 2.1.x The publish by copy seems to open a very interesting possibility of publishing to a remote server and attaching to it fro remote debugging. As this is possible to do manually, I think plugin should be able to support such deployment - maybe setup a file receiver on the other end. Such functionality will definitely open the door into real life [semi-]production debugging. Even QA problems may be solved much faster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-135) WTP server adapter creates wrong security markup
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-135: --- Affects Version/s: 2.1.x Fix Version/s: 2.1.x Assignee: Tim McConnell WTP server adapter creates wrong security markup Key: GERONIMODEVTOOLS-135 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-135 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.x Environment: Rational Software Architect v7 Eclipse WTP server adapter V1.1 WASCE V1.1.0.1 java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32devifx-20061016 (ifix 110599: SR3 + 109 092)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223ifx-20061016 (JIT enabled) J9VM - 20061012_08722_lHdSMR JIT - 20060908_1811ifx1_r8 GC - 20060906_AA) JCL - 20061002 Reporter: Daniel S. Haischt Assignee: Tim McConnell Fix For: 2.1.x After having added a security role to geronimo-web.xml using the Eclipse deployment plan editor, I am getting the following error: Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: [error: cvc-complex-type.2.4a: Expected elements ... Deployment Plan: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; xmlns:nam=http://geronimo.apache.org/xml/ns/naming-1.1; xmlns:sec=http://geronimo.apache.org/xml/ns/security-1.1; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.1; sys:environment sys:moduleId sys:groupIddefault/sys:groupId sys:artifactIdMYARTIFACT/sys:artifactId sys:version1.0/sys:version sys:typecar/sys:type /sys:moduleId /sys:environment context-root/mymoduleWAR/context-root sec:security sec:role-mappings sec:role role-name=myconfig sec:descriptionmyconfig/sec:description /sec:role /sec:role-mappings /sec:security /web-app -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-130) Geronimo service projects don't deploy
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-130: --- Affects Version/s: (was: 1.1.0) 2.1.x Fix Version/s: 2.1.x Assignee: Tim McConnell Geronimo service projects don't deploy -- Key: GERONIMODEVTOOLS-130 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-130 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.x Environment: Eclipse 3.2.1; WST 1.5.2.v200610070620-X3Tmm8_VLz2EcCH; JST 1.5.2.v200610070620-kW-OA1vfaZTJtXg Reporter: Chris Curtis Assignee: Tim McConnell Fix For: 2.1.x Geronimo service projects (created as J2EE utility projects, with a geronimo-service.xml deployment plan) do not actually deploy into a running Geronimo server. The Server pane shows the service as deployed, and the normal synchronized/republish state tracking appears to work, but nothing actually happens in Geronimo itself. There appears to be an edit that addressed this issue (http://svn.apache.org/viewvc?view=revrevision=417199) but I'm not an Eclipse internals wizard. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-190) Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-190: --- Affects Version/s: (was: 2.0.x) 2.1.x Fix Version/s: (was: 2.0.x) 2.1.x Assignee: Tim McConnell Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc) --- Key: GERONIMODEVTOOLS-190 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.x Attachments: HelloWorld.war Import the attached HelloWorld.war and double click on geronimo-web.xml. An error window will pop up saying .. elements in the plan may not be qualified ... This is caused by trying to parse v2.0 of Geronimo plans with v1.1 of schemas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-174) Distribution of configuration failed when attempting to deploy using Geronimo 2.0 adapter
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-174: --- Affects Version/s: (was: 2.0) 2.1.x Fix Version/s: 2.1.x Assignee: Tim McConnell Distribution of configuration failed when attempting to deploy using Geronimo 2.0 adapter --- Key: GERONIMODEVTOOLS-174 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-174 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Tom Mutdosch Assignee: Tim McConnell Fix For: 2.1.x Using the following Geronimo 2.0 runtime server and adapter: (*) Server: http://people.apache.org/dist/geronimo/eclipse/unstable/servers/geronimo-tomcat6-jee5-2.0-SNAPSHOT-bin.zip (*)Server plugins: http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-2.0.0-v20070621.1204-deployable.zip Using eclipse WTP, I create a simple Dynamic Web Project targeting Geronimo with a single HTML file. When I do a Run on Server I get the following error in an error dialog and my page does not run. Error: Distribution of configuration failed. See log for details. Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer1127.tmpdir\geronimoTestEAR.zip) org.apache.geronimo.common.DeploymentException: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer1127.tmpdir\geronimoTestEAR.zip) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:239) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:863) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:863) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:231) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:238) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1423) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:96) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1260) at java.security.AccessController.doPrivileged(AccessController.java:275) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1363) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:797) at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309) at sun.rmi.transport.Transport$1.run(Transport.java:168) at java.security.AccessController.doPrivileged(AccessController.java:275) at
[jira] Updated: (GERONIMODEVTOOLS-179) XDoclet 1.2 Support
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-179: --- Fix Version/s: 2.1.x Assignee: Tim McConnell Affects Version/s: 2.1.x XDoclet 1.2 Support --- Key: GERONIMODEVTOOLS-179 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-179 Project: Geronimo-Devtools Issue Type: New Feature Affects Versions: 2.1.x Reporter: Jonathan Gallimore Assignee: Tim McConnell Fix For: 2.1.x Currently, there is no XDoclet support available to generate openejb-jar.xml deployment descriptors from annotations on EJB classes. XDoclet already has plugins to generate ejb-jar.xml, and descriptors for other EJB containers such as JBoss, and it would be nice to have this available to Geronimo developers as well. I have made a start on an XDoclet plugin that generates a basic openejb-jar.xml, the code for which I have made available in my subversion repository here: https://jrg.me.uk/XDoclet-Geronimo/Geronimo-Plugin/trunk Currently this is doing the bear minimum to assist with the project I'm currently working on, I feel that this could be extended and made more robost - the following issues need to be addressed before this is really usable: * Provide a test suite to verify the descriptors generated by the plugin (currently I'm eyeballing them using the sample Bank Geronimo project) * Thoroughly go through the schemas for openejb-jar.xml and geronimo-web.xml and remove stuff that is currently hardcoded in my templates, and add any tags necessary to build more complete descriptors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-185) Enhance SharedLibEntryCreationOperation to respect entries in classpath containers
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-185: --- Fix Version/s: 2.1.x Assignee: Tim McConnell Affects Version/s: 2.1.x Enhance SharedLibEntryCreationOperation to respect entries in classpath containers -- Key: GERONIMODEVTOOLS-185 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-185 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.x Please see the discussion thread: http://www.mail-archive.com/[EMAIL PROTECTED]/msg06976.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-176) GeronimoServerBehaviourDelegate always uses rmi port 1099
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-176: --- Affects Version/s: (was: 2.0.x) 2.1.x Fix Version/s: (was: 2.0.x) 2.1.x GeronimoServerBehaviourDelegate always uses rmi port 1099 - Key: GERONIMODEVTOOLS-176 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-176 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Donald Woods Fix For: 2.1.x We need to allow the user to reconfigure the RMI port, for the cases where they have mapped the server to use something besides the default 1099 port. Also, this would allow the plugin to support the new multiple server instance feature in the 2.0 server -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-176) GeronimoServerBehaviourDelegate always uses rmi port 1099
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-176: --- Assignee: Tim McConnell GeronimoServerBehaviourDelegate always uses rmi port 1099 - Key: GERONIMODEVTOOLS-176 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-176 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Donald Woods Assignee: Tim McConnell Fix For: 2.1.x We need to allow the user to reconfigure the RMI port, for the cases where they have mapped the server to use something besides the default 1099 port. Also, this would allow the plugin to support the new multiple server instance feature in the 2.0 server -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-42) Support for unix distributions for installable runtimes
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-42: -- Fix Version/s: 2.1.x Assignee: Tim McConnell Affects Version/s: (was: 1.1.0) 2.1.x Support for unix distributions for installable runtimes --- Key: GERONIMODEVTOOLS-42 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-42 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Environment: Environment: Eclipse: 3.1.1 (Build ID: M20050929-0840) Java 2 SE: 1.4.2_10-b03 OS: Linux ubuntu-abysssix 2.6.12-10-686-smp Reporter: Daniel S. Haischt Assignee: Tim McConnell Priority: Minor Fix For: 2.1.x Would it be possible to use a gzipped archive on a Unice OS? I for instance did download geronimo-jetty.(tgz|tar.gz). Unfortunatly maven searches for a ZIP and tries to download it because it is non-existant. + | Executing jar:install org.apache.geronimo.j2ee.server.v1 | Memory: 8M/11M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: build:start: java:prepare-filesystem: java:compile: [echo] Compiling to /home/haischt/geronimo-eclipse-tools/plugins/org.apache.geronimo.j2ee.server.v1/target/classes [echo] No java source files to compile. java:jar-resources: getzip: [get] Getting: http://www.apache.org/dist/geronimo/1.0/geronimo-jetty-j2ee-1.0.zip [get] To: /home/haischt/.maven/repository/geronimo/distributions/geronimo-jetty-j2ee-1.0.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Exception in thread Persistence Adaptor Task
I left geronimo overnight on a remote machine and forgot to shut it down. Next morning I found the following exception on the console. There were some exception in geronimo.log which I think are not related to this. Exception in thread Persistence Adaptor Task java.lang.NullPointerException at org.apache.derby.jdbc.XAStatementControl.init(Unknown Source) at org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(Unknown Source) at org.apache.derby.iapi.jdbc.BrokeredConnection.prepareStatement(Unknow n Source) at org.tranql.connector.jdbc.ConnectionHandle.prepareStatement(Connectio nHandle.java:231) at org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doDeleteOld Messages(DefaultJDBCAdapter.java:538) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.cleanup(JDBCPer sistenceAdapter.java:211) at org.apache.activemq.store.journal.JournalPersistenceAdapter.doCheckpo int(JournalPersistenceAdapter.java:416) at org.apache.activemq.store.journal.JournalPersistenceAdapter$2.iterate (JournalPersistenceAdapter.java:129) at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner. java:117) at org.apache.activemq.thread.PooledTaskRunner.access$100(PooledTaskRunn er.java:26) at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.ja va:44) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor ker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor ker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:803) -- geronimo.log .. 22:05:35,015 INFO [OpenEJB] The following method doesn't have a transaction policy assigned: public abstract java.util.Set javax.management.j2ee.Management.queryNames(javax.management.ObjectName,javax.management.QueryExp) throws java.rmi.RemoteException . . 22:05:39,656 INFO [OpenEJB] The following method doesn't have a transaction policy assigned: public abstract java.lang.Object javax.management.j2ee.Management.getAttribute(javax.management.ObjectName,java.lang.String) throws javax.management.MBeanException,javax.management.AttributeNotFoundException,javax.management.InstanceNotFoundException,javax.management.ReflectionException,java.rmi.RemoteException . The stand alone client seemed to work correctly. Thanks Anita Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222
[jira] Commented: (GERONIMO-3115) MDB pool size should be able to be configurable in openejb-jar.xsd
[ https://issues.apache.org/jira/browse/GERONIMO-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523935 ] Aman Nanner commented on GERONIMO-3115: --- Has this been shown to work in a real example? MDB pool size should be able to be configurable in openejb-jar.xsd -- Key: GERONIMO-3115 URL: https://issues.apache.org/jira/browse/GERONIMO-3115 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0-M6 Reporter: Aman Nanner Fix For: 2.0.x, 2.1 There should be an attribute for message driven beans in the openejb-jar.xsd schema that will configure the pool size. For example, if a pool size of 1 were configured for a specific bean, then there would only be a maximum of 1 message driven bean instance of that type that would be instantiated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Trouble with 2.0.1 main pom and building anything a G dependency
Hi, I was building a 3rd party application with a dependency on the Geronimo specs (jee)...and I could not get it to build because it was looking for axis-saaj-1.3-r562247 For the life of me, I thought I had that usual maven corrupt repo issues and I wiped out my local repo...a number of times. I began looking through repos and sure enough it didn't exist. Well..I decided to look in our pom and I found: axis2Version1.3-r562247/axis2Version Further discussion with others resulted in finding that we have a special repository that pulls these special versions. (Ok I forgot about that). This is going to be a problem for anyone who has a dependency on our jars (ie. wanting to use the specs jars for a web applications, etc). If I (a committer) had to go through this much trouble trying to figure out how to get that dependency...I can't imagine what the standard user will go through when writing a web or webservices application. The point I am making here is if we are going to have special versions of jars, we need to make these more readily available. Here are some options I thought of: A) Place the special jars in central so they are automatically available to others. (Easiest approach for the user - but we are going to have to convince other projects to put them out into their locations - that may prove difficult). B) Heavily, heavily document how to get around this problem by adding our repo to their pom. This should be easily Googled and placed in a FAQ, because I would hazard to guess this will be a frequent question. (probably the easiest approach for us, but this needs to be a short term solution - and its still a PITA for our users). C) Convince the other projects to get their releases in order and get good versions of their product on central. (Should do this regardless of any other option). D) Rename our special versions to g-axis-saaj-1.3-r562247 and house those under our own control (org.apache.geronimo...) in central on our next build (2.0.2). (The easy and quick, and very temprary fix!) Thoughts? Comments? Thanks, Jeff
[jira] Commented: (GERONIMODEVTOOLS-189) Error opening geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523954 ] Shane Blake commented on GERONIMODEVTOOLS-189: -- Shiva, The version of the tool I am running seems to produce 2.0 deployment plans when creating the Dynamic Web Project as you tried. I am getting the same error as in 190 (that is what I was originally reporting). Error opening geronimo-web.xml -- Key: GERONIMODEVTOOLS-189 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-189 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.x Environment: Eclipse SDK Version: 3.3.0 Build id: I20070525-1350 Build id: I20070625-1500 Latest August 23 build from unstable Reporter: Shane Blake Assignee: Tim McConnell Fix For: 2.0.x Opening geronimo-web.xml getting the following stack trace: java.lang.IllegalArgumentException at org.eclipse.wst.server.core.internal.facets.FacetUtil.getRuntime(FacetUtil.java:61) at org.eclipse.jst.server.core.FacetUtil.getRuntime(FacetUtil.java:47) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.getLoader(SharedDeploymentPlanEditor.java:97) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.loadDeploymentPlan(SharedDeploymentPlanEditor.java:86) at org.apache.geronimo.st.ui.editors.AbstractGeronimoDeploymentPlanEditor.init(AbstractGeronimoDeploymentPlanEditor.java:181) at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:794) at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:643) at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592) at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299) at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179) at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268) at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65) at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:400) at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256) at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209) at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604) at org.eclipse.ui.internal.PartStack.add(PartStack.java:499) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103) at org.eclipse.ui.internal.PartStack.add(PartStack.java:485) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112) at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63) at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217) at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207) at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774) at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673) at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633) at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625) at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2547) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:644) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:603) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:285) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:138) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:194) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:175) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:268) at
[jira] Commented: (GERONIMODEVTOOLS-101) remote debugging
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523964 ] Oleg Gusakov commented on GERONIMODEVTOOLS-101: --- Thank you Tim! This also calls for pluggable copy process. Geronimo plugin should be easially reconfigurable to support various methods of delivering files to the remote server and configuration restart methods. One of the obvious solutions would be ssh copy and remote restart. Problem here is that not all server versions may be supporting remote configuration restart. In this case - a simple agent on the server with a custom RPC call into it ? remote debugging Key: GERONIMODEVTOOLS-101 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-101 Project: Geronimo-Devtools Issue Type: New Feature Components: eclipse-plugin Affects Versions: 2.1.x Environment: IBM JVM 1.5, Eclipse 3.2.0, WTP 1.5, w2k/w3k, remote either w?k or linux Reporter: Oleg Gusakov Assignee: Tim McConnell Fix For: 2.1.x The publish by copy seems to open a very interesting possibility of publishing to a remote server and attaching to it fro remote debugging. As this is possible to do manually, I think plugin should be able to support such deployment - maybe setup a file receiver on the other end. Such functionality will definitely open the door into real life [semi-]production debugging. Even QA problems may be solved much faster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Regarding the recent hibernate problems...
Hey all, After the recent fiasco involving converting a jboss application that utilized Hibernate over to Geronimo, Viet Nguyen and I dove into the samples residing in the Geronimo 1.0 wiki to try and get a hold on the issues that were at hand, only to find not only inherent issues with getting it to work as advertised on Geronimo 1.0, but also that it desperately needed updating in order to be usable as a viable example for migrating an application utilizing hibernate to Geronimo 2.0.x. Yesterday and into the night we managed to get a new version of the hibernate Online Brokerage demo app up and running, as well as documented on the Geronimo 2.0 wiki here: http://cwiki.apache.org/GMOxDOC20/jboss-to-geronimo-hibernate-migration.html Now that this has been completed, we are currently working on taking this the next logical step and getting all of the migration examples that exist in the Geronimo 1.0 wiki updated and functioning fully as examples for Geronimo 2.0, as well as verifying that they examples do in fact work on the latest official JBoss release as well (4.2.3.. blasphemous, I know). Hopefully this will help to fill what has shown itself to be somewhat of a large hole in our migration assistance and documentation. We will use this thread to update everyone on our progress. Thanks -- Erik B. Craig
[Discuss] What next?
Getting 2.0.1 out the door was a great step and now might be a good time to start discussing where we want geronimo to head next. Here are some ideas I've had or think are important. If I were to try to write actual sentences about all of this I'd probably never send the email so this is way too fragmentary but maybe can spark more discussion. I'm hoping everyone will chime in with their interests and viewpoints, this is just what I've been thinking about lately. Modularity. For a long time we've been on the brink of having an actually modular server, not just a conceptually modular server. As reflected in a lot of recent discussion on the dev list, I think we are so close we should really work hard to make this a pleasant reality. Some of the steps I see: - enhance the plugin framework so bits of more config files can be added, in particular artifact_aliases.properties and config_substitutions.properties. IIUC Paul has some schema changes and xml handling rewrites in the wings as well - finish up the pluggable admin console work and actually split the admin console into appropriate bits for the plugins - rearrange the build so it is organized by plugin - actually assemble the servers we ship using plugins, perhaps using gshell scripts - have more server-building tools. For instance, a button to push that spits out a server with just what is needed for a set of apps and nothing else. Clustering IIUC we have a lot of partial clustering solutions. For instance there's WADI, native tomcat clustering, a terracotta integration, and IIUC Jeff has been working on a clustering solution (my apologies if I left any out). I'd like to know where these efforts are in terms of actual functionality and reliability and what they can be extended to do. We also need some kind of cluster admin tools. Security jaspi triplesec administration beyond javaee security for jetspeed and roller There are some good things about javaee security such as the idea of using Permissions and evaluating them in a policy but there are also a lot of limitations and problems such as no support for restricting access to user generated content that didn't exist when the security was originally configured. At least roller and jetspeed have run into this problem. I think triplesec may provide a fairly generic solution and it might be interesting to see if other projects are interested in this. Other apps roller jetspeed proximity etc It would be great to get all popular apps available as geronimo plugins. Management and troubleshooting ARM trace on error facility. Have a list of info that each component can add to as the request moves through the system. If there's an error, we can show the entire path taken with all data. Otherwise we discared it. server farm management (gshell?) Transaction manager implement a do work in a new tx interface, hook it up to openjpa. IIUC IBM has proposed an interface that lets server pieces submit work to be done in a new transaction, thus eliminating the need to deal with suspend etc yourself. There's been some discussion on the openjpa lists, and we should definitely do this. There may be more commonj work to do also, but I've more or less lost track of that project. make sure recovery actually works Core Better Spring application management Investigate OSGI and figure out how it is different from what we are doing, what it can do better, and what is missing from it. Figure out an integration strategy whether it be run OSGI as an application or replace the kernel with OSGI Don't break stuff if we start using OSGI more :-) Figure out what to do with our config.ser in modules/ configurations. At least get it into real xml, maybe using something like jaxb with schema/gbean. Personally I'm interested in most of these projects but only have a finite amount of time. Right now I'm concentrating on triplesec and want to work on jetspeed integration after that. thanks david jencks
Re: Trouble with 2.0.1 main pom and building anything a G dependency
On Aug 30, 2007, at 6:05 PM, Jeff Genender wrote: Hi, I was building a 3rd party application with a dependency on the Geronimo specs (jee)...and I could not get it to build because it was looking for axis-saaj-1.3-r562247 For the life of me, I thought I had that usual maven corrupt repo issues and I wiped out my local repo...a number of times. I began looking through repos and sure enough it didn't exist. Well..I decided to look in our pom and I found: axis2Version1.3-r562247/axis2Version Further discussion with others resulted in finding that we have a special repository that pulls these special versions. (Ok I forgot about that). This is going to be a problem for anyone who has a dependency on our jars (ie. wanting to use the specs jars for a web applications, etc). If I (a committer) had to go through this much trouble trying to figure out how to get that dependency...I can't imagine what the standard user will go through when writing a web or webservices application. The point I am making here is if we are going to have special versions of jars, we need to make these more readily available. I see your point. And agree that it's a general problem. Vamsi was having this same general problem with the Tuscany plugin, recently. I'm surprised that you get to this through a geronimo spec, though. I wouldn't have predicted that. In fact, it seems wrong... What's the chain from specs to geronimo? That said, we'd definitely have a problem with any 2.0.1 server artifact... Here are some options I thought of: A) Place the special jars in central so they are automatically available to others. (Easiest approach for the user - but we are going to have to convince other projects to put them out into their locations - that may prove difficult). Agreed that it's best for the user, but I think it's next to impossible. I think we'd accept artifacts from other projects and place them in our space... B) Heavily, heavily document how to get around this problem by adding our repo to their pom. This should be easily Googled and placed in a FAQ, because I would hazard to guess this will be a frequent question. (probably the easiest approach for us, but this needs to be a short term solution - and its still a PITA for our users). Probably have to do that for 2.0.1 resources regardless. C) Convince the other projects to get their releases in order and get good versions of their product on central. (Should do this regardless of any other option). I think we've done that and are doing that. Axis2, JPA, etc have shipped, etc. So G 2.0.2 would be better than 2.0.1 in this regard. However, I think we'll always have a tension between getting a release out and getting all of our dependencies to line up. For a major release like a 2.0, I think it's highly unlikely that we'll get all dependencies to a released level... D) Rename our special versions to g-axis-saaj-1.3-r562247 and house those under our own control (org.apache.geronimo...) in central on our next build (2.0.2). (The easy and quick, and very temprary fix!) This is probably my favored option. I guess another option would be not to declare these artifacts as maven dependencies. It's not like they have poms, etc. However, would present their own set of issues. Definitely beyond my maven capabilities... --kevan
Re: Exception in thread Persistence Adaptor Task
On Aug 30, 2007, at 4:59 PM, Anita Kulshreshtha wrote: I left geronimo overnight on a remote machine and forgot to shut it down. Next morning I found the following exception on the console. There were some exception in geronimo.log which I think are not related to this. Exception in thread Persistence Adaptor Task java.lang.NullPointerException at org.apache.derby.jdbc.XAStatementControl.init(Unknown Source) at org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(Unknown Source) snip Hi Anita, Were you running tests from the standalone client? Were you running the admin console, perhaps? I've certainly left servers running for extended periods, without a problem... --kevan geronimo.log .. 22:05:35,015 INFO [OpenEJB] The following method doesn't have a transaction policy assigned: public abstract java.util.Set javax.management.j2ee.Management.queryNames (javax.management.ObjectName,javax.management.QueryExp) throws java.rmi.RemoteException . . 22:05:39,656 INFO [OpenEJB] The following method doesn't have a transaction policy assigned: public abstract java.lang.Object javax.management.j2ee.Management.getAttribute (javax.management.ObjectName,java.lang.String) throws javax.management.MBeanException,javax.management.AttributeNotFoundExce ption,javax.management.InstanceNotFoundException,javax.management.Refl ectionException,java.rmi.RemoteException . The stand alone client seemed to work correctly.
Re: [BUILD] Trunk: Failed for Revision: 570882
On Aug 30, 2007, at 11:53 AM, Kevan Miller wrote:
On Aug 29, 2007, at 10:11 PM, Jason Dillon wrote:
You are very correct... :-)
IMO slf4j is the way to go... drop JCL like a rock...
Logback is LGPL, to be precise -- not that it makes any difference...
The docs for logback actually appear to suggest that developers use
slf4j anyways, and only use logback for the back-end processing muck.
I haven't looked at sl4j. What are the motivations to switch?
It core jar dependency is smaller.
Its API includes support for context (Markers and MDC stuff).
Parameterized logging support... so instead of:
if (log.isDebugEnabled()) {
log.debug(This is some important thingy: + thingy);
}
You can simply:
log.debug(This is some important thingy: {}, thingy);
It does not suffer from classloader crapo like JCL... as you might
know, JCL is very picky about CL muck, and if you happen to have more
than one JCL jar on the CP (which can happen from time to time) it
becomes very, very unpredictable. Nor does it eat memory like JCL.
Its also got some adapters to allow code that currently uses JCL or
log4j to get piped into slf4j so that everything can get tunneled
through the same logging mechanism very easily.
IMO, this is the way to go... Not a huge change either, mostly a
global search replace on a few things, but we also need to do other
clean up of logging too, which would be ideal to do around the same
time.
--jason
Re: [BUILD] Trunk: Failed for Revision: 570882
On Aug 30, 2007, at 8:48 PM, Jason Dillon wrote:
On Aug 30, 2007, at 11:53 AM, Kevan Miller wrote:
On Aug 29, 2007, at 10:11 PM, Jason Dillon wrote:
You are very correct... :-)
IMO slf4j is the way to go... drop JCL like a rock...
Logback is LGPL, to be precise -- not that it makes any difference...
The docs for logback actually appear to suggest that developers use
slf4j anyways, and only use logback for the back-end processing muck.
I haven't looked at sl4j. What are the motivations to switch?
It core jar dependency is smaller.
Its API includes support for context (Markers and MDC stuff).
Parameterized logging support... so instead of:
if (log.isDebugEnabled()) {
log.debug(This is some important thingy: + thingy);
}
You can simply:
log.debug(This is some important thingy: {}, thingy);
Nice...
It does not suffer from classloader crapo like JCL... as you might
know, JCL is very picky about CL muck, and if you happen to have
more than one JCL jar on the CP (which can happen from time to
time) it becomes very, very unpredictable. Nor does it eat memory
like JCL.
Heh. Was hoping this would be the case...
Its also got some adapters to allow code that currently uses JCL or
log4j to get piped into slf4j so that everything can get tunneled
through the same logging mechanism very easily.
IMO, this is the way to go... Not a huge change either, mostly a
global search replace on a few things, but we also need to do other
clean up of logging too, which would be ideal to do around the same
time.
Agreed. IMO, improving our logging is one of the biggest improvements
we could make to G...
Thanks for the info!
--kevan
Re: Exception in thread Persistence Adaptor Task
--- Kevan Miller [EMAIL PROTECTED] wrote: On Aug 30, 2007, at 4:59 PM, Anita Kulshreshtha wrote: I left geronimo overnight on a remote machine and forgot to shut it down. Next morning I found the following exception on the console. There were some exception in geronimo.log which I think are not related to this. Exception in thread Persistence Adaptor Task java.lang.NullPointerException at org.apache.derby.jdbc.XAStatementControl.init(Unknown Source) at org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(Unknown Source) snip Hi Anita, Were you running tests from the standalone client? The methods mentioned in geronimo.log were used in the stand alone client. Were you running the admin console, perhaps? I've certainly left servers running for extended periods, without a problem... I did start console on the remote machine to use JNDIViewer. AFAIK, I did not perform any operation to cause exception in thread Persistence Adaptor Task. Thanks Anita --kevan geronimo.log .. 22:05:35,015 INFO [OpenEJB] The following method doesn't have a transaction policy assigned: public abstract java.util.Set javax.management.j2ee.Management.queryNames (javax.management.ObjectName,javax.management.QueryExp) throws java.rmi.RemoteException . . 22:05:39,656 INFO [OpenEJB] The following method doesn't have a transaction policy assigned: public abstract java.lang.Object javax.management.j2ee.Management.getAttribute (javax.management.ObjectName,java.lang.String) throws javax.management.MBeanException,javax.management.AttributeNotFoundExce ption,javax.management.InstanceNotFoundException,javax.management.Refl ectionException,java.rmi.RemoteException . The stand alone client seemed to work correctly. Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
[jira] Created: (GERONIMODEVTOOLS-191) Not able to find site.xml file on Mac OS
Not able to find site.xml file on Mac OS Key: GERONIMODEVTOOLS-191 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-191 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Mac OS Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.0 [[INFO] Error adding file to archive: /Users/kevan/geronimo/devtools/eclipse-plugin/trunk/src/main/assembly/site.xml isn't a file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
On Aug 29, 2007, at 6:12 PM, Karan Malhi wrote: Or maybe in one of the very first OpenEJB methods called by Geronimo to start openejb in embedded mode we could add some code like System.setProperty(openejb.logging,external); the first time the Logger class is loaded, we check for this property and if it has a value of external, then we do not use embedded.logging.properties otherwise we assume our default strategy. Sounds like that's the way to go. Just check for don't configure logging and follow those orders if it's set. Let's make the property be true/false. Maybe openejb.logging.external=true or something similar. -David
Re: Standalone Geronimo 2.0.1 client
On Aug 30, 2007, at 5:32 AM, Anita Kulshreshtha wrote:
I have successfully used
props.put(java.naming.provider.url, 127.0.0.1:4201)
to run stand alone remote client to access MEJB. Should we be using
ejbd://?
We should, yes. If you don't specify a protocol, we assume ejbd.
1 The JNDI name for MEJB is
MEJBGBean/MEJB/javax.management.j2ee.Management.
Is it possible to have it as ejb/mgmt/MEJB?
We can as of the code I checked in yesterday specify a new jndi
format for an ejb-jar. So we could use ejb/mgmt/{deploymentId}
for that resulting in ejb/mgmt/MEJB. If that's what people want.
2. Why does MEJB not show up in the JNDIViewer in console?
That I do not know.
-David
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
Okay, Will implement it with openejb.logging.external=true/false. On 8/30/07, David Blevins [EMAIL PROTECTED] wrote: On Aug 29, 2007, at 6:12 PM, Karan Malhi wrote: Or maybe in one of the very first OpenEJB methods called by Geronimo to start openejb in embedded mode we could add some code like System.setProperty(openejb.logging,external); the first time the Logger class is loaded, we check for this property and if it has a value of external, then we do not use embedded.logging.properties otherwise we assume our default strategy. Sounds like that's the way to go. Just check for don't configure logging and follow those orders if it's set. Let's make the property be true/false. Maybe openejb.logging.external=true or something similar. -David -- Karan Singh Malhi
Re: Trouble with 2.0.1 main pom and building anything a G dependency
On Aug 30, 2007, at 6:05 PM, Jeff Genender wrote: D) Rename our special versions to g-axis-saaj-1.3-r562247 and house those under our own control (org.apache.geronimo...) in central on our next build (2.0.2). (The easy and quick, and very temprary fix!) This option seems most reasonable to me (least ugly :-) Best wishes, Paul
Re: Exception in thread Persistence Adaptor Task
On Aug 30, 2007, at 9:21 PM, Anita Kulshreshtha wrote: snip I did start console on the remote machine to use JNDIViewer. AFAIK, I did not perform any operation to cause exception in thread Persistence Adaptor Task. K. Well, if you can reproduce the error, we should create a Jira and track it down. --kevan
Re: Regarding the recent hibernate problems...
On Aug 30, 2007, at 8:09 PM, Erik B. Craig wrote: Hey all, After the recent fiasco involving converting a jboss application that utilized Hibernate over to Geronimo, Viet Nguyen and I dove into the samples residing in the Geronimo 1.0 wiki to try and get a hold on the issues that were at hand, only to find not only inherent issues with getting it to work as advertised on Geronimo 1.0, but also that it desperately needed updating in order to be usable as a viable example for migrating an application utilizing hibernate to Geronimo 2.0.x. Yesterday and into the night we managed to get a new version of the hibernate Online Brokerage demo app up and running, as well as documented on the Geronimo 2.0 wiki here: http://cwiki.apache.org/GMOxDOC20/jboss-to-geronimo-hibernate- migration.html Cool. Can't step through it at the moment, but hope to soon. I wouldn't say it was a fiasco. There was a Hibernate scenario that hadn't been worked through for 2.0. Now it's worked through... :D Now that this has been completed, we are currently working on taking this the next logical step and getting all of the migration examples that exist in the Geronimo 1.0 wiki updated and functioning fully as examples for Geronimo 2.0, as well as verifying that they examples do in fact work on the latest official JBoss release as well (4.2.3.. blasphemous, I know). Hopefully this will help to fill what has shown itself to be somewhat of a large hole in our migration assistance and documentation. We will use this thread to update everyone on our progress. That's great. Thanks a lot for the help... --kevan
[jira] Commented: (GERONIMO-3450) Unable to Run Pluto 1.1 on Geronimo 2.0
[ https://issues.apache.org/jira/browse/GERONIMO-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523995 ] Ramesh B commented on GERONIMO-3450: Hi Kevan, Many thanks for the help... i've been struggling with this for days. The reason why i had filtered org.apache.pluto was this comes by default with geronimo and i didn't want to use these jars. I had added these jars seperately in the web-inf/lib folder of the war. The pluto portal has successfully deployed after implementing your suggestion. thanks again for the help. Regards, Ramesh B. Unable to Run Pluto 1.1 on Geronimo 2.0 --- Key: GERONIMO-3450 URL: https://issues.apache.org/jira/browse/GERONIMO-3450 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M2 Environment: Operating System : Windows 2k3 Pluto Version: 1.1.0 Geronimo with Jetty Version 2.0.1 Reporter: Ramesh B Fix For: 1.1.2, 1.1.x Attachments: geronimo-web.xml, geronimo.log Hi, I'm new to geronimo webserver. I've been trying to deploy pluto 1.1 on geronimo with jetty 2.0.1. For this I have done the following steps: 1) I've added the following additional jars to common libs before deployment: * pluto-container-1.1.0.jar * pluto-descriptor-api-1.1.0.jar * pluto-descriptor-impl-1.1.0.jar * pluto-taglib-1.1.0.jar * xalan 2.6.0 2) I've modified the castor.properties for pluto/web-inf/classes and set all parameters to false. 3) i've added a geronimo-web.xml to the /web-inf folder. I created a war of the pluto folder. however while deploying it it gives the following error: 3582: 11:02:34,501 ERROR [log] Nested in org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/pluto-portal-driver-services-config.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface: After throwing this error on the console it shows as successfully deployed and successfully running. However when i'm trying to access the pluto portal, it says service unavailable. Please help me with this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
AbstractConverter.setValue()
I ran into the following error on G 2.0.1 with Spring versions 2.0.5-2.0.7-SNAPSHOT. PropertyEditor.setValue() is being called with an object whose type does not match the defined type. 15:54:12,596 ERROR [ContextLoader] Context initialization failed org.springframework.beans.factory.access.BootstrapException: Unable to initialize group definition. Group resource name [classpath*:beanRefContext.xml], factory key [ear.context]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ear.context' defined in URL [jar:file:/ Users/kevan/Desktop/geronimo-tomcat6-jee5-2.0.1/repository/org/spring/ example/MultipleContexts/1.0/MultipleContexts-1.0.ear/lib/ SampleJava.jar!/beanRefContext.xml]: Instantiation of bean failed; nested exception is org.apache.xbean.propertyeditor.PropertyEditorException: Value is not an instance of String Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ear.context' defined in URL [jar:file:/Users/ kevan/Desktop/geronimo-tomcat6-jee5-2.0.1/repository/org/spring/ example/MultipleContexts/1.0/MultipleContexts-1.0.ear/lib/ SampleJava.jar!/beanRefContext.xml]: Instantiation of bean failed; nested exception is org.apache.xbean.propertyeditor.PropertyEditorException: Value is not an instance of String Caused by: org.apache.xbean.propertyeditor.PropertyEditorException: Value is not an instance of String at org.apache.xbean.propertyeditor.AbstractConverter.setValue (AbstractConverter.java:67) at org.springframework.beans.TypeConverterDelegate.doConvertValue (TypeConverterDelegate.java:276) at org.springframework.beans.TypeConverterDelegate.convertIfNecessary (TypeConverterDelegate.java:192) snip Spring has been updated in latest builds to ignore this problem (see http://opensource.atlassian.com/projects/spring/browse/SPR-3799). There's some question about what the proper behavior is in this case... I didn't find any spec-level guidance... http:// weblogs.java.net/blog/ljnelson/archive/2007/08/objects_and_str.html (search for 'dilemma') recommends logging the condition and ignoring the type mismatch. This pretty much exhausts my knowledge of the subject. Any thoughts on being a little less dogmatic and ignoring the type mismatch? --kevan
