[jira] Created: (GERONIMO-4347) Console should have server version and ip name in HTML title
Console should have server version and ip name in HTML title Key: GERONIMO-4347 URL: https://issues.apache.org/jira/browse/GERONIMO-4347 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Reporter: Jürgen Weber Priority: Minor Right now the browser title for Geronimo console is Geronimo Console This should be changed to Geronimo 2.1.3 Console @ myserver.mydomain If you have open consoles for different versions and on different servers, then windows toolbar tooltips display this information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12638510#action_12638510 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- up-to-tuscany-1.4-snapshot.diff applied in rev 703354. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: asm.diff, GeronimoServletHost1.diff, GeronimoServletHost2.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, up-to-tuscany-1.4-snapshot.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4243) EAR Deploy Error
[ https://issues.apache.org/jira/browse/GERONIMO-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12638545#action_12638545 ] gennadibereshnoi commented on GERONIMO-4243: Hi! Sorry for delay... ...after moving back to 2.1.1 the pb was not actulal some time. Currently i check the same deployment already with G.2.1.3 ( jetty + tomcat), and in both cases the same (or similar) error : (see below). The workaround in my case was - undeploy the jaxws org.apache.geronimo.configs/jaxws-deployer/2.1.3/car + axis2 + cxf (i need it not currently). 10x for JAVA_OPTS - i will check it ASAP. As for EAR - attach ~40MB? --- callstacktrace--- 14:41:04,305 ERROR [Deployer] Deployment failed due to java.lang.ArrayIndexOutOfBoundsException: 48188 at org.objectweb.asm.ClassReader.readClass(Unknown Source) at org.objectweb.asm.ClassReader.accept(Unknown Source) at org.objectweb.asm.ClassReader.accept(Unknown Source) at org.apache.xbean.finder.ClassFinder.readClassDef(ClassFinder.java:690) at org.apache.xbean.finder.ClassFinder.init(ClassFinder.java:139) at org.apache.geronimo.jaxws.builder.WARWebServiceFinder.discoverWebServices(WARWebServiceFinder.java:154) at org.apache.geronimo.jaxws.builder.AdvancedWARWebServiceFinder.discoverPOJOWebServices(AdvancedWARWebServiceFinder.java:73) at org.apache.geronimo.jaxws.builder.AdvancedWARWebServiceFinder.discoverWebServices(AdvancedWARWebServiceFinder.java:45) at org.apache.geronimo.jaxws.builder.WARWebServiceFinder.discoverWebServices(WARWebServiceFinder.java:70) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.discoverWebServices(JAXWSServiceBuilder.java:97) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.findWebServices(JAXWSServiceBuilder.java:80) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.basicInitContext(AbstractWebModuleBuilder.java:364) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.initContext(TomcatModuleBuilder.java:330) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.initContext(SwitchingModuleBuilder.java:159) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1350) at
[jira] Updated: (GERONIMO-4243) EAR Deploy Error
[
https://issues.apache.org/jira/browse/GERONIMO-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gennadibereshnoi updated GERONIMO-4243:
---
Affects Version/s: 2.1.3
EAR Deploy Error
Key: GERONIMO-4243
URL: https://issues.apache.org/jira/browse/GERONIMO-4243
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: console, deployment, Tomcat
Affects Versions: 2.1.2, 2.1.3
Environment: Java
java.awt.graphicsenv sun.awt.X11GraphicsEnvironment
java.awt.printerjob sun.print.PSPrinterJob
java.class.path
/usr/local/geronimo/bin/server.jar
/usr/local/geronimo/bin/jpa.jar
java.class.version49.0
java.endorsed.dirs
/usr/local/geronimo/lib/endorsed
/usr/local/java/jre/lib/endorsed
java.ext.dirs
/usr/local/geronimo/lib/ext
/usr/local/java/jre/lib/ext
java.home /home/oxseed/jdk1.5.0_15/jre
java.io.tmpdir/home/oxseed/geronimo-tomcat6-javaee5-2.1.2/var/temp
java.library.path
/home/oxseed/jdk1.5.0_15/jre/lib/i386/server
/home/oxseed/jdk1.5.0_15/jre/lib/i386
/home/oxseed/jdk1.5.0_15/jre/../lib/i386
java.runtime.name Java(TM) 2 Runtime Environment, Standard Edition
java.runtime.version 1.5.0_15-b04
java.specification.name Java Platform API Specification
java.specification.vendor Sun Microsystems Inc.
java.specification.version1.5
java.util.prefs.PreferencesFactory
java.vendor- Sun Microsystems Inc.
java.vendor.url http://java.sun.com/
java.vendor.url.bug http://java.sun.com/cgi-bin/bugreport.cgi
java.version- 1.5.0_15
Virtual Machine
java.vm.info mixed mode
java.vm.name Java HotSpot(TM) Server VM
java.vm.specification.nameJava Virtual Machine Specification
java.vm.specification.vendor Sun Microsystems Inc.
java.vm.specification.version 1.0
java.vm.vendorSun Microsystems Inc.
java.vm.version 1.5.0_15-b04
Operating System
os.arch i386
os.name Linux
os.version2.6.16.33-xen
Sun
sun.arch.data.model 32
sun.boot.class.path
/usr/local/geronimo/lib/endorsed/yoko-spec-corba-1.0.jar
/usr/local/geronimo/lib/endorsed/yoko-rmi-spec-1.0.jar
/home/oxseed/jdk1.5.0_15/jre/lib/rt.jar
/home/oxseed/jdk1.5.0_15/jre/lib/i18n.jar
/home/oxseed/jdk1.5.0_15/jre/lib/sunrsasign.jar
/home/oxseed/jdk1.5.0_15/jre/lib/jsse.jar
/home/oxseed/jdk1.5.0_15/jre/lib/jce.jar
/home/oxseed/jdk1.5.0_15/jre/lib/charsets.jar
/home/oxseed/jdk1.5.0_15/jre/classes
sun.boot.library.path
/home/oxseed/jdk1.5.0_15/jre/lib/i386
sun.cpu.endianlittle
sun.cpu.isalist
sun.io.unicode.encoding UnicodeLittle
sun.java2d.fontpath
sun.os.patch.levelunknown
User
user.country US
user.dir /home/oxseed
user.home /home/oxseed
user.language en
user.name oxseed
user.timezone Europe/Berlin
user.variant
Etc
admin.disabledtrue
catalina.base /home/oxseed/geronimo-tomcat6-javaee5-2.1.2/var/catalina
catalina.home /home/oxseed/geronimo-tomcat6-javaee5-2.1.2/var/catalina
catalina.useNamingfalse
com.sun.management.jmxremote
com.sun.management.jmxremote.authenticate false
com.sun.management.jmxremote.port 8004
com.sun.management.jmxremote.ssl false
common.loader ${catalina.home}/lib ${catalina.home}/lib/*.jar
derby.storage.fileSyncTransactionLog true
derby.system.home /home/oxseed
duct tape
file.encoding ANSI_X3.4-1968
file.encoding.pkg sun.io
file.separator/
java.naming.factory.initial
org.apache.xbean.naming.global.GlobalContextManager
java.naming.factory.url.pkgs org.apache.xbean.naming
java.naming.provider.url rmi://0.0.0.0:1099
java.net.preferIPv4Stack true
java.rmi.server.RMIClassLoaderSpi
org.apache.geronimo.kernel.rmi.RMIClassLoaderSpiImpl
java.rmi.server.randomIDs true
java.security.ProviderSUN
javax.rmi.CORBA.PortableRemoteObjectClass
org.apache.yoko.rmi.impl.PortableRemoteObjectImpl
javax.rmi.CORBA.StubClass org.apache.yoko.rmi.impl.StubImpl
javax.rmi.CORBA.UtilClass org.apache.geronimo.corba.util.UtilDelegateImpl
javax.security.jacc.PolicyConfigurationFactory.provider
org.apache.geronimo.security.jacc.mappingprovider.GeronimoPolicyConfigurationFactory
javax.security.jacc.policy.provider
org.apache.geronimo.security.jacc.mappingprovider.GeronimoPolicy
javax.xml.soap.MessageFactory
org.apache.geronimo.webservices.saaj.GeronimoMessageFactory
javax.xml.soap.MetaFactory
org.apache.geronimo.webservices.saaj.GeronimoMetaFactory
javax.xml.soap.SOAPConnectionFactory
org.apache.geronimo.webservices.saaj.GeronimoSOAPConnectionFactory
javax.xml.soap.SOAPFactory
org.apache.geronimo.webservices.saaj.GeronimoSOAPFactory
line.separator
[jira] Updated: (GERONIMO-4243) EAR Deploy Error
[
https://issues.apache.org/jira/browse/GERONIMO-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gennadibereshnoi updated GERONIMO-4243:
---
Component/s: webservices
Jetty
EAR Deploy Error
Key: GERONIMO-4243
URL: https://issues.apache.org/jira/browse/GERONIMO-4243
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: console, deployment, Jetty, Tomcat, webservices
Affects Versions: 2.1.2, 2.1.3
Environment: Java
java.awt.graphicsenv sun.awt.X11GraphicsEnvironment
java.awt.printerjob sun.print.PSPrinterJob
java.class.path
/usr/local/geronimo/bin/server.jar
/usr/local/geronimo/bin/jpa.jar
java.class.version49.0
java.endorsed.dirs
/usr/local/geronimo/lib/endorsed
/usr/local/java/jre/lib/endorsed
java.ext.dirs
/usr/local/geronimo/lib/ext
/usr/local/java/jre/lib/ext
java.home /home/oxseed/jdk1.5.0_15/jre
java.io.tmpdir/home/oxseed/geronimo-tomcat6-javaee5-2.1.2/var/temp
java.library.path
/home/oxseed/jdk1.5.0_15/jre/lib/i386/server
/home/oxseed/jdk1.5.0_15/jre/lib/i386
/home/oxseed/jdk1.5.0_15/jre/../lib/i386
java.runtime.name Java(TM) 2 Runtime Environment, Standard Edition
java.runtime.version 1.5.0_15-b04
java.specification.name Java Platform API Specification
java.specification.vendor Sun Microsystems Inc.
java.specification.version1.5
java.util.prefs.PreferencesFactory
java.vendor- Sun Microsystems Inc.
java.vendor.url http://java.sun.com/
java.vendor.url.bug http://java.sun.com/cgi-bin/bugreport.cgi
java.version- 1.5.0_15
Virtual Machine
java.vm.info mixed mode
java.vm.name Java HotSpot(TM) Server VM
java.vm.specification.nameJava Virtual Machine Specification
java.vm.specification.vendor Sun Microsystems Inc.
java.vm.specification.version 1.0
java.vm.vendorSun Microsystems Inc.
java.vm.version 1.5.0_15-b04
Operating System
os.arch i386
os.name Linux
os.version2.6.16.33-xen
Sun
sun.arch.data.model 32
sun.boot.class.path
/usr/local/geronimo/lib/endorsed/yoko-spec-corba-1.0.jar
/usr/local/geronimo/lib/endorsed/yoko-rmi-spec-1.0.jar
/home/oxseed/jdk1.5.0_15/jre/lib/rt.jar
/home/oxseed/jdk1.5.0_15/jre/lib/i18n.jar
/home/oxseed/jdk1.5.0_15/jre/lib/sunrsasign.jar
/home/oxseed/jdk1.5.0_15/jre/lib/jsse.jar
/home/oxseed/jdk1.5.0_15/jre/lib/jce.jar
/home/oxseed/jdk1.5.0_15/jre/lib/charsets.jar
/home/oxseed/jdk1.5.0_15/jre/classes
sun.boot.library.path
/home/oxseed/jdk1.5.0_15/jre/lib/i386
sun.cpu.endianlittle
sun.cpu.isalist
sun.io.unicode.encoding UnicodeLittle
sun.java2d.fontpath
sun.os.patch.levelunknown
User
user.country US
user.dir /home/oxseed
user.home /home/oxseed
user.language en
user.name oxseed
user.timezone Europe/Berlin
user.variant
Etc
admin.disabledtrue
catalina.base /home/oxseed/geronimo-tomcat6-javaee5-2.1.2/var/catalina
catalina.home /home/oxseed/geronimo-tomcat6-javaee5-2.1.2/var/catalina
catalina.useNamingfalse
com.sun.management.jmxremote
com.sun.management.jmxremote.authenticate false
com.sun.management.jmxremote.port 8004
com.sun.management.jmxremote.ssl false
common.loader ${catalina.home}/lib ${catalina.home}/lib/*.jar
derby.storage.fileSyncTransactionLog true
derby.system.home /home/oxseed
duct tape
file.encoding ANSI_X3.4-1968
file.encoding.pkg sun.io
file.separator/
java.naming.factory.initial
org.apache.xbean.naming.global.GlobalContextManager
java.naming.factory.url.pkgs org.apache.xbean.naming
java.naming.provider.url rmi://0.0.0.0:1099
java.net.preferIPv4Stack true
java.rmi.server.RMIClassLoaderSpi
org.apache.geronimo.kernel.rmi.RMIClassLoaderSpiImpl
java.rmi.server.randomIDs true
java.security.ProviderSUN
javax.rmi.CORBA.PortableRemoteObjectClass
org.apache.yoko.rmi.impl.PortableRemoteObjectImpl
javax.rmi.CORBA.StubClass org.apache.yoko.rmi.impl.StubImpl
javax.rmi.CORBA.UtilClass org.apache.geronimo.corba.util.UtilDelegateImpl
javax.security.jacc.PolicyConfigurationFactory.provider
org.apache.geronimo.security.jacc.mappingprovider.GeronimoPolicyConfigurationFactory
javax.security.jacc.policy.provider
org.apache.geronimo.security.jacc.mappingprovider.GeronimoPolicy
javax.xml.soap.MessageFactory
org.apache.geronimo.webservices.saaj.GeronimoMessageFactory
javax.xml.soap.MetaFactory
org.apache.geronimo.webservices.saaj.GeronimoMetaFactory
javax.xml.soap.SOAPConnectionFactory
org.apache.geronimo.webservices.saaj.GeronimoSOAPConnectionFactory
javax.xml.soap.SOAPFactory
Re: Improved EJB integration... can we get some portlets?
I was wrong in my assumption that gbeans are not recreated at startup. They are and their constructors are called.However the portlet should still depend on the openejb configuration and so it will be stopped in case openejb configuration is stopped. Regards Manu On Fri, Oct 10, 2008 at 5:47 PM, Manu George [EMAIL PROTECTED] wrote: Hi David, Thanks for replying. I have put a few questions/comments inline below On Wed, Oct 8, 2008 at 10:09 PM, David Jencks [EMAIL PROTECTED] wrote: On Oct 8, 2008, at 7:42 AM, Manu George wrote: To me it looks like you are basically proposing a plan editor or config.xml editor for openejb. You can't safely change the actual attribute values at runtime so lets look for a solution that doesn't pretend to be able to. I think you have three possible strategies here: 1. create a plan editor for plans similar to the openejb plugin and use it to generate replacements for the openejb plugin Generating an entire new plugin, and installing it seems to be a lot of work for the user for just changing configuration parameters. A restart of the openejb configuration looks to be simpler. Another factor here is that there is no mention of the MdbContainer in the plan as it is generated dynamically for the RA. So such an editor won't show the Mdb Container properties. 2. create an editor for specified customizations of config.xml. This might or might not be practical. It's more likely to work if the openejb plugin is stopped when you edit gbean attribute values. If I do stop the openejb configuration then would I be able to edit the gbean attributes? After all they are final and would have already been intialized. I am assuming that even before a gbean is started its constructor is called. (GBean Loading Stage). Another issue here is since the portlet should depend on the openejb configuration it will also get stopped and removed from the admin console if I stop the openejb configuration. I am unable to change the attributes of the gbean at runtime as all the fields are final and there are no setter methods. However if I have setter methods then i would be able to set the attributes at runtime to the gbean. However the ejb containers will need to be reinitialized which needs a restart of the openejb container system. We can prompt the user to restart the openejb configuration. 3. put all the things you want to be able to change into config-substitutions as variables and edit those (in the in-memory map accessible through () ArtifactResolver). This sounds interesting. How can I access this inMemoryMap (not yet figured out) and will the changes to the Map be persisted to the config.xml file or the config-substitutions.properties file? If not the changes will be lost on server shutdown. The other issue here is that the Mdb Containers are created dynamically for each RA. So its not possible to make entries for these in config-substitution.properties. However I can add a properties attribute to the OpenEJBSystemGBean and during container creation check it for custom values. I can then externalize this to config-substitution.properties if required. Regards Manu
[jira] Resolved: (GERONIMO-4346) c-m-p leaves invalid plugin in plugin catalog and doesn't update plugin catalog when desp is updated
[ https://issues.apache.org/jira/browse/GERONIMO-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4346. --- Resolution: Fixed Fix Version/s: 2.2 fix in rev 703450. Add description and pluginGroup to PluginKey and add code to remove the invalid plugin without any pluginartifact elements. c-m-p leaves invalid plugin in plugin catalog and doesn't update plugin catalog when desp is updated Key: GERONIMO-4346 URL: https://issues.apache.org/jira/browse/GERONIMO-4346 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: car-maven-plugin Affects Versions: 2.2 Reporter: Lin Sun Assignee: Lin Sun Priority: Minor Fix For: 2.2 when I made changes (http://svn.apache.org/viewvc?rev=703224view=rev) and build locally at trunk/plugins/console, I found out the local m2's geronimo-plugins.xml isn't updated with the new description I added. This is likely a c-m-p issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard [EMAIL PROTECTED] wrote: Joe Bohn wrote: Any ideas on PHP and if this would be another potential area for integration? Python Joe Bill Also JavaScript with Rhino, and that gives you the big four - Groovy, JRuby, Rhino, and Jython. PHP would good but i've never found a PHP impl with Java integration and a compatible license. You can also use the JSR-223 APIs (Apache BSF) and get easy access to lots of lesser well known script language engines. I've done a bit with all those in Tuscany so will be interested to see what happens in Geronimo. ...ant
Re: Improved EJB integration... can we get some portlets?
Hi David, Thanks for replying. I have put a few questions/comments inline below On Wed, Oct 8, 2008 at 10:09 PM, David Jencks [EMAIL PROTECTED] wrote: On Oct 8, 2008, at 7:42 AM, Manu George wrote: To me it looks like you are basically proposing a plan editor or config.xml editor for openejb. You can't safely change the actual attribute values at runtime so lets look for a solution that doesn't pretend to be able to. I think you have three possible strategies here: 1. create a plan editor for plans similar to the openejb plugin and use it to generate replacements for the openejb plugin Generating an entire new plugin, and installing it seems to be a lot of work for the user for just changing configuration parameters. A restart of the openejb configuration looks to be simpler. Another factor here is that there is no mention of the MdbContainer in the plan as it is generated dynamically for the RA. So such an editor won't show the Mdb Container properties. 2. create an editor for specified customizations of config.xml. This might or might not be practical. It's more likely to work if the openejb plugin is stopped when you edit gbean attribute values. If I do stop the openejb configuration then would I be able to edit the gbean attributes? After all they are final and would have already been intialized. I am assuming that even before a gbean is started its constructor is called. (GBean Loading Stage). Another issue here is since the portlet should depend on the openejb configuration it will also get stopped and removed from the admin console if I stop the openejb configuration. I am unable to change the attributes of the gbean at runtime as all the fields are final and there are no setter methods. However if I have setter methods then i would be able to set the attributes at runtime to the gbean. However the ejb containers will need to be reinitialized which needs a restart of the openejb container system. We can prompt the user to restart the openejb configuration. 3. put all the things you want to be able to change into config-substitutions as variables and edit those (in the in-memory map accessible through () ArtifactResolver). This sounds interesting. How can I access this inMemoryMap (not yet figured out) and will the changes to the Map be persisted to the config.xml file or the config-substitutions.properties file? If not the changes will be lost on server shutdown. The other issue here is that the Mdb Containers are created dynamically for each RA. So its not possible to make entries for these in config-substitution.properties. However I can add a properties attribute to the OpenEJBSystemGBean and during container creation check it for custom values. I can then externalize this to config-substitution.properties if required. Regards Manu
[jira] Created: (GERONIMO-4348) when a user use deploy.sh deploy command to deploy a car file we should give a informative message
when a user use deploy.sh deploy command to deploy a car file we should give a informative message -- Key: GERONIMO-4348 URL: https://issues.apache.org/jira/browse/GERONIMO-4348 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Affects Versions: 2.2 Reporter: Lin Sun Priority: Minor Fix For: 2.2 We should check if .car file (or other type of invalid file extension) is used, we suggest a informative message. lin-suns-macbook-pro:bin linsun$ ./deploy.sh deploy ~/gtrunk/plugins/console/plugin-console-tomcat/target/plugin-console-tomcat-2.2-SNAPSHOT.car Using GERONIMO_BASE: /Users/linsun/gtrunk/assemblies/geronimo-tomcat6-javaee5/target/assembly Using GERONIMO_HOME: /Users/linsun/gtrunk/assemblies/geronimo-tomcat6-javaee5/target/assembly Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Error: Unable to distribute plugin-console-tomcat-2.2-SNAPSHOT.car: web.xml for web app default/plugin-console-tomcat-2.2-SNAPSHOT/1223649642933/car includes security elements but Geronimo deployment plan is not provided or does not contain security-realm-name element necessary to configure security accordingly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4348) when a user uses deploy.sh deploy command to deploy a car file we should give an informative message
[ https://issues.apache.org/jira/browse/GERONIMO-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4348: -- Summary: when a user uses deploy.sh deploy command to deploy a car file we should give an informative message (was: when a user use deploy.sh deploy command to deploy a car file we should give a informative message) when a user uses deploy.sh deploy command to deploy a car file we should give an informative message Key: GERONIMO-4348 URL: https://issues.apache.org/jira/browse/GERONIMO-4348 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 2.2 Reporter: Lin Sun Priority: Minor Fix For: 2.2 We should check if .car file (or other type of invalid file extension) is used, we suggest a informative message. lin-suns-macbook-pro:bin linsun$ ./deploy.sh deploy ~/gtrunk/plugins/console/plugin-console-tomcat/target/plugin-console-tomcat-2.2-SNAPSHOT.car Using GERONIMO_BASE: /Users/linsun/gtrunk/assemblies/geronimo-tomcat6-javaee5/target/assembly Using GERONIMO_HOME: /Users/linsun/gtrunk/assemblies/geronimo-tomcat6-javaee5/target/assembly Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Error: Unable to distribute plugin-console-tomcat-2.2-SNAPSHOT.car: web.xml for web app default/plugin-console-tomcat-2.2-SNAPSHOT/1223649642933/car includes security elements but Geronimo deployment plan is not provided or does not contain security-realm-name element necessary to configure security accordingly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
On Oct 10, 2008, at 4:27 AM, Joe Bohn wrote: Grails framework - This is a self contained framework that leverages groovy for scripting. It uses a rails like code by convention approach to generate and host web applications. It is licensed under Apache. It embeds Jetty for hosting the generated web applications but can also export WAR files which can be then deployed application servers like Geronimo. There is an article that gives a nice description on how to utilize Grails to generate a web app and deploy it into Geronimo (http://www.ibm.com/developerworks/opensource/library/os-ag-grails/ ). As far as integration with Geronimo goes, I'm not sure that there is much to we can do. I guess we could document this in our wiki or perhaps generate a plugin (or whatever the Grails term is) so that the geronimo deployment plan can be generated rather than created manually, but I'm not sure that is worth the effort. There doesn't seem to be a good place for programmatic integration with regard to the framework itself. Um, there isn't a good place, because there isn't really any need for anything. From the containers perspective its just another WAR deployment. I would still be interested to see something, a sample even, running under Grails inside of Geronimo. AFAICT Grails is a very powerful framework for whipping up apps, so we could potentially use it... say for the console :-P JRuby on Rails - My understanding is that this is basically a Ruby implementation that runs on the Java VM (the JRuby portion) and leverages the Rails framework. It is licensed under CPL/GPL/LGPL. In many ways it is similar to Grails using an embedded web server to facilitate a rapid application development environment ... this time built upon the JRuby language interpreter. Here again, I suspect we can provide some directions so that an exported war could be deployed in Geronimo (or perhaps a plugin to generate geronimo deployment plans) but there doesn't seem to be much in the way of direct integration that we can provide. There are other frameworks as well. Trails is one that I stumbled on which is also in the same vein as Grails with a focus on definition of the domain model and generating the rest of the app dynamically. From what I have seen, most dynamic languages which run in Java also support some-sort of web/WAR integration. But don't really require much else to work. So I think that simply providing samples is sufficient. I guess supporting the javax.script/JSR-223 stuff via Apache BSF 3.x is a good idea, though really I've no idea how/if/why someone would want to use it. Maybe someone wants to generate a web-page, or maybe someone wants to get the return value of a script injected into their GBean, or wants the script to be their GBean, or wants to have a chunk of script executed when the server loads... who knows. --jason
[jira] Created: (GERONIMO-4349) jdbc driver is installed to wrong repository after installed server specific repo plugin
jdbc driver is installed to wrong repository after installed server specific repo plugin Key: GERONIMO-4349 URL: https://issues.apache.org/jira/browse/GERONIMO-4349 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1.3 Reporter: Forrest Xia Priority: Minor 1. start default server instance 2. install server specific repo plugin at http://geronimo.apache.org/plugins/geronimo-2.1.3/ 3. create a database pool with wizard, click download driver to install postgresql jdbc driver 4. after downloaded and installed, check where it is stored Issue: it is installed into GERONIMO_HOME/var/repository. But I think it should be installed into GERONIMO_HOME/repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Continuous TCK Testing
On Oct 8, 2008, at 11:56 PM, Kevan Miller wrote: On Oct 8, 2008, at 4:31 PM, Jason Warner wrote: We had some suggestions earlier for some alternate means of implementing this (Hudson, Conitnuum, etc...). Now that we've had Jason Dillon provide an overview of what we had in place before, does anyone have thoughts on what we should go with? I'm thinking we should stick with the AHP based solution. It will need to be updated most likely, but it's been tried and tested and shown to meet our needs. I'm wondering, though, why we stopped using it before. Was there a specific issue we're going to have to deal with again? IIRC, the overwhelming reason we stopped using it before was because of hosting issues -- spotty networking, hardware failures, poor colo support, etc. We shouldn't have any of these problems, now. If we do run into problems, they should now be fixable. I have no reason to favor Hudson/Continuum over AHP. So, if we can get AHP running easily, I'm all for it. There's only one potential issue, that I'm aware of. We previously had an Open Source License issued for our use of Anthill. Here's some of the old discussion -- http://www.nabble.com/Geronimo-build-automation-status-(longish)-tt7649902.html#a7649902 Although the board was aware of our usage of AntHill, since we weren't running AntHill on ASF hardware, I'm not sure the license was fully vetted by Infra. I don't see any issues, but I'll want to run this by Infra. Jason D, will the existing license cover the version of AntHill that we'll want to use? I'll run the license by Infra and will also describe the issue for review by the Board, in our quarterly report. IMO, I'd proceed with the assumption that we'll be using AHP. Just don't install it on Apache hardware, yet. I've requested a new license from Anthill. Will let you know when I get it. --kevan
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
On Oct 10, 2008, at 10:52 AM, Jason Dillon wrote: On Oct 10, 2008, at 4:27 AM, Joe Bohn wrote: Grails framework - This is a self contained framework that leverages groovy for scripting. It uses a rails like code by convention approach to generate and host web applications. It is licensed under Apache. It embeds Jetty for hosting the generated web applications but can also export WAR files which can be then deployed application servers like Geronimo. There is an article that gives a nice description on how to utilize Grails to generate a web app and deploy it into Geronimo (http://www.ibm.com/developerworks/opensource/library/os-ag-grails/ ). As far as integration with Geronimo goes, I'm not sure that there is much to we can do. I guess we could document this in our wiki or perhaps generate a plugin (or whatever the Grails term is) so that the geronimo deployment plan can be generated rather than created manually, but I'm not sure that is worth the effort. There doesn't seem to be a good place for programmatic integration with regard to the framework itself. Um, there isn't a good place, because there isn't really any need for anything. From the containers perspective its just another WAR deployment. One thing I was thinking about was to create a Grails plugin (which contains the jars required to run a Grails web app). Thus avoiding having to package all of the Grails dependencies in the WAR, itself. Instead, they'd be declared as a dependency. Pushing wars with a bunch of redundant jars, didn't strike me as very desirable. Grails might need a bit of customization to build suitable WARS. I would still be interested to see something, a sample even, running under Grails inside of Geronimo. AFAICT Grails is a very powerful framework for whipping up apps, so we could potentially use it... say for the console :-P A sample would certainly be helpful... Agreed about Grails, in general. I was thinking it would be interesting to see if we could make it simpler/more efficient to bridge between the two environments. JRuby on Rails - My understanding is that this is basically a Ruby implementation that runs on the Java VM (the JRuby portion) and leverages the Rails framework. It is licensed under CPL/GPL/LGPL. In many ways it is similar to Grails using an embedded web server to facilitate a rapid application development environment ... this time built upon the JRuby language interpreter. Here again, I suspect we can provide some directions so that an exported war could be deployed in Geronimo (or perhaps a plugin to generate geronimo deployment plans) but there doesn't seem to be much in the way of direct integration that we can provide. There are other frameworks as well. Trails is one that I stumbled on which is also in the same vein as Grails with a focus on definition of the domain model and generating the rest of the app dynamically. From what I have seen, most dynamic languages which run in Java also support some-sort of web/WAR integration. But don't really require much else to work. So I think that simply providing samples is sufficient. I guess supporting the javax.script/JSR-223 stuff via Apache BSF 3.x is a good idea, though really I've no idea how/if/why someone would want to use it. Maybe someone wants to generate a web-page, or maybe someone wants to get the return value of a script injected into their GBean, or wants the script to be their GBean, or wants to have a chunk of script executed when the server loads... who knows. Personally, I thought Grails was the best fit, but that may be because I've used Groovy more (which isn't saying a whole lot) and new a bit more about it... --kevan
Re: Improved EJB integration... can we get some portlets?
On Oct 10, 2008, at 5:17 AM, Manu George wrote: Hi David, Thanks for replying. I have put a few questions/comments inline below On Wed, Oct 8, 2008 at 10:09 PM, David Jencks [EMAIL PROTECTED] wrote: On Oct 8, 2008, at 7:42 AM, Manu George wrote: To me it looks like you are basically proposing a plan editor or config.xml editor for openejb. You can't safely change the actual attribute values at runtime so lets look for a solution that doesn't pretend to be able to. I think you have three possible strategies here: 1. create a plan editor for plans similar to the openejb plugin and use it to generate replacements for the openejb plugin Generating an entire new plugin, and installing it seems to be a lot of work for the user for just changing configuration parameters. A restart of the openejb configuration looks to be simpler. Another factor here is that there is no mention of the MdbContainer in the plan as it is generated dynamically for the RA. So such an editor won't show the Mdb Container properties. I'm not sure whether to regard creating a new plugin as a significant step or not. I think most of us are thinking of it as a larger bit of work than it is. The mdb configuration seems to be a sticky point everywhere. I don't really know what is available to configure on it. If the knobs you can turn are the same for all inbound resource adapters then perhaps we need a mdbtemplate gbean with named attributes for them, that provides the defaults for and MDBContainers we create for specific mdbs. 2. create an editor for specified customizations of config.xml. This might or might not be practical. It's more likely to work if the openejb plugin is stopped when you edit gbean attribute values. If I do stop the openejb configuration then would I be able to edit the gbean attributes? After all they are final and would have already been intialized. I am assuming that even before a gbean is started its constructor is called. (GBean Loading Stage). Another issue here is since the portlet should depend on the openejb configuration it will also get stopped and removed from the admin console if I stop the openejb configuration. I am unable to change the attributes of the gbean at runtime as all the fields are final and there are no setter methods. However if I have setter methods then i would be able to set the attributes at runtime to the gbean. However the ejb containers will need to be reinitialized which needs a restart of the openejb container system. We can prompt the user to restart the openejb configuration. Stopping a gbean discards the gbean object instance. You're left with the GBeanData which is basically a map holding attribute values. This you can definitely edit. Any kind of configuration facility like this would not require the openjeb plugin to be started, just loaded. You can specify a importclasses/import dependency on openejb to get this, just like the openejb-deployer plugin does. This would let you cycle the openejb plugin while the console is running. (Obviously this won't work for a jetty/tomcat console plugin :-) 3. put all the things you want to be able to change into config-substitutions as variables and edit those (in the in-memory map accessible through () ArtifactResolver). This sounds interesting. How can I access this inMemoryMap (not yet figured out) and will the changes to the Map be persisted to the config.xml file or the config-substitutions.properties file? If not the changes will be lost on server shutdown. The method is org .apache .geronimo .system .configuration.PluginAttributeStore.addConfigSubstitutions(Properties properties) which is implemented in LocalAttributeManager. You can't read the values here but you might be able to get them from the gbean. This is a little odd because the openejb console plugin will need to know the names of the config-subst. variables used in the config.xml bit: I normally think of this as a configuration detail rather than something that is hardcoded. Maybe this is not a big problem. The other issue here is that the Mdb Containers are created dynamically for each RA. So its not possible to make entries for these in config-substitution.properties. However I can add a properties attribute to the OpenEJBSystemGBean and during container creation check it for custom values. I can then externalize this to config-substitution.properties if required. see comment above. hope this helps david jencks Regards Manu
[jira] Created: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems
Connection proxying to imitate DissociatableManagedConnection can easily cause problems --- Key: GERONIMO-4350 URL: https://issues.apache.org/jira/browse/GERONIMO-4350 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector Affects Versions: 2.1, 2.2 Reporter: David Jencks Assignee: Dain Sundstrom Fix For: 2.1.4, 2.2 We have some code to imitate the DissociatableManagedConnection to avoid connection leaks that proxies connections from the supplied ManagedConnectionFactory: the proxy implements all the interfaces of the connection, but not the class itself. However, there's nothing stopping the ConnectionFactory from casting the (now proxied) connection to the implementation class it expects. The TxConnect project at sourceforge illustrates this approach in the EisConnectionFactory. http://txconnect.sourceforge.net One possible solution would be to have a flag to turn on this proxying behavior. I don't immediately see a way to detect if the problem will occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Kevan Miller wrote: On Oct 10, 2008, at 10:52 AM, Jason Dillon wrote: On Oct 10, 2008, at 4:27 AM, Joe Bohn wrote: Grails framework - This is a self contained framework that leverages groovy for scripting. It uses a rails like code by convention approach to generate and host web applications. It is licensed under Apache. It embeds Jetty for hosting the generated web applications but can also export WAR files which can be then deployed application servers like Geronimo. There is an article that gives a nice description on how to utilize Grails to generate a web app and deploy it into Geronimo (http://www.ibm.com/developerworks/opensource/library/os-ag-grails/). As far as integration with Geronimo goes, I'm not sure that there is much to we can do. I guess we could document this in our wiki or perhaps generate a plugin (or whatever the Grails term is) so that the geronimo deployment plan can be generated rather than created manually, but I'm not sure that is worth the effort. There doesn't seem to be a good place for programmatic integration with regard to the framework itself. Um, there isn't a good place, because there isn't really any need for anything. From the containers perspective its just another WAR deployment. One thing I was thinking about was to create a Grails plugin (which contains the jars required to run a Grails web app). Thus avoiding having to package all of the Grails dependencies in the WAR, itself. Instead, they'd be declared as a dependency. Pushing wars with a bunch of redundant jars, didn't strike me as very desirable. Grails might need a bit of customization to build suitable WARS. Interesting idea. I hadn't really thought of that ... I just was planning to work with the war generated by Grails. I'll think about constructing the war differently (or perhaps doing some inplace deployment) and moving the grails jars to a plugin. I would still be interested to see something, a sample even, running under Grails inside of Geronimo. AFAICT Grails is a very powerful framework for whipping up apps, so we could potentially use it... say for the console :-P A sample would certainly be helpful... Agreed about Grails, in general. I was thinking it would be interesting to see if we could make it simpler/more efficient to bridge between the two environments. There is a sample of sorts in the article referenced earlier. But, this doesn't really do anything for Geronimo/Grails integration and is a little hard to find. We could certainly do something to provide a sample/tutorial in our wiki ... but perhaps it would be much more interesting if we did something with the grails gbean you proposed and then some type of in-place deployment to make creating and running in Geronimo quick and easy. Something more to think about. Thanks! JRuby on Rails - My understanding is that this is basically a Ruby implementation that runs on the Java VM (the JRuby portion) and leverages the Rails framework. It is licensed under CPL/GPL/LGPL. In many ways it is similar to Grails using an embedded web server to facilitate a rapid application development environment ... this time built upon the JRuby language interpreter. Here again, I suspect we can provide some directions so that an exported war could be deployed in Geronimo (or perhaps a plugin to generate geronimo deployment plans) but there doesn't seem to be much in the way of direct integration that we can provide. There are other frameworks as well. Trails is one that I stumbled on which is also in the same vein as Grails with a focus on definition of the domain model and generating the rest of the app dynamically. From what I have seen, most dynamic languages which run in Java also support some-sort of web/WAR integration. But don't really require much else to work. So I think that simply providing samples is sufficient. I guess supporting the javax.script/JSR-223 stuff via Apache BSF 3.x is a good idea, though really I've no idea how/if/why someone would want to use it. Maybe someone wants to generate a web-page, or maybe someone wants to get the return value of a script injected into their GBean, or wants the script to be their GBean, or wants to have a chunk of script executed when the server loads... who knows. Personally, I thought Grails was the best fit, but that may be because I've used Groovy more (which isn't saying a whole lot) and new a bit more about it... --kevan
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
IMO, language is irrelevant. What you want to consider is what you want the scripting language to do for you... that is what is important. Basically (almost) any scripting language can be integrated (bsf or direct) but what is missing is the users use-cases for what the really want scripted. But.. users't don't always tell you want they want up front, they look at what you have and then complain when its broken wrt their own needs. So it might be worthwhile doing some POC work to add more scripting support. Though I don't think that web-app scripting crapski is the best way to provide that. If you think about it, there are a few uses for scripting in the application server's context. First is that the app developers prefer the language, but they still provide JavaEE muck to install/run. So we could reduce some footprint by providing plugins, but that not really that important, as the feature will still work w/o it. The second is where the application exposes some configuration logic which is intended to be easily augmented when installing/running the application. In this model part of the application's behavior is configured via some scripting language, which is intended to be changed (slightly or dramatically) to fit the application installations requirements. The third is where the application wants to provide an extensible action interface, so allow such an application to do whatever it wants. For example, if an application supports some concept of filtering, one might desire that the filter be implemented by a script which the administrator of the application could writte/configure. I'm sure I'm missing more examples, but it should be sufficient to point these out. Scripting is a very powerful way to extend you application, and I'm certainly a proponent. But what I'm having trouble realizing is... for a JavaEE application server, what/how/why would a developer want to script? --jason On Oct 11, 2008, at 1:13 AM, Joe Bohn wrote: ant elder wrote: On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Joe Bohn wrote: Any ideas on PHP and if this would be another potential area for integration? Python Joe Bill Also JavaScript with Rhino, and that gives you the big four - Groovy, JRuby, Rhino, and Jython. PHP would good but i've never found a PHP impl with Java integration and a compatible license. You can also use the JSR-223 APIs (Apache BSF) and get easy access to lots of lesser well known script language engines. I've done a bit with all those in Tuscany so will be interested to see what happens in Geronimo. Thanks for the input. Yes, I thought about BSF too. Regarding the others languages (Python, Rhino, Jython and PHP) licenses could be issues have to keep an eye on that. I thought about BSF too ... need to do some more research there. Actually, at this point it's all just some investigation and we'll see where it goes. Joe
[jira] Created: (GERONIMO-4351) Use CXF tooling to generate WSDL and other artifacts for JAX-WS services
Use CXF tooling to generate WSDL and other artifacts for JAX-WS services Key: GERONIMO-4351 URL: https://issues.apache.org/jira/browse/GERONIMO-4351 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: webservices Affects Versions: 2.2 Reporter: Jarek Gawor Assignee: Jarek Gawor Use CXF tooling (instead of Sun tooling) to generate WSDL and other artifacts for JAX-WS services. In order to achieve this, the first step will be to factor out the existing wsgen functionality into a separate plugin. That way, the plugin could be easily replaced with another plugin that provides the same functionality but using CXF tools. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12638652#action_12638652 ] Dain Sundstrom commented on GERONIMO-4350: -- I'm not sure I understand the problem. IIRC, a spec-compliant RA is required to list all interfaces that are needed by calling code (so we know what to add to the proxy). Anyway, if this is something we want/need to support, I can this of a few workarounds/solutions (listed in order of difficulty for Geronimo): 1) add a getDelegate method one of the interfaces like JDBC and JPA use 2) add a flag to turn of connection GC 3) rewrite the connection pool code to use weak references for garbage detection Option 3 is the most reliable but a lot more work. Connection proxying to imitate DissociatableManagedConnection can easily cause problems --- Key: GERONIMO-4350 URL: https://issues.apache.org/jira/browse/GERONIMO-4350 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 2.1, 2.2 Reporter: David Jencks Assignee: Dain Sundstrom Fix For: 2.1.4, 2.2 We have some code to imitate the DissociatableManagedConnection to avoid connection leaks that proxies connections from the supplied ManagedConnectionFactory: the proxy implements all the interfaces of the connection, but not the class itself. However, there's nothing stopping the ConnectionFactory from casting the (now proxied) connection to the implementation class it expects. The TxConnect project at sourceforge illustrates this approach in the EisConnectionFactory. http://txconnect.sourceforge.net One possible solution would be to have a flag to turn on this proxying behavior. I don't immediately see a way to detect if the problem will occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (XBEAN-111) Only register Converters with the VM when requested
Only register Converters with the VM when requested --- Key: XBEAN-111 URL: https://issues.apache.org/jira/browse/XBEAN-111 Project: XBean Issue Type: Improvement Components: reflect Affects Versions: 3.4.2, 3.4.1, 3.4 Reporter: Dain Sundstrom Assignee: Dain Sundstrom Fix For: 3.4.3 Registering the Converters in xbean-reflect with the VM PropertyEditorManager creates lots of problems for some libraries and IDEs. Since xbean-reflect has a private converter registry there is no need to register the Converters with the VM. I have add the boolean flag registerWithVM to PropertyEditors. When this flag is set, all Converters registered with PropertyEditors are registered with the VM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[reflect] registering converters with the VM
Currently, we are registering our Converters with the VM PropertyEditorManager, and this is creating all sorts of problems for libraries like Spring and IDEs like netbeans. Our code has it's own registry and only a registers them with the VM as a convenience. As a compromise between those that like to have the Converters registered and those that can't, I have add the boolean flag registerWithVM to PropertyEditors. When this flag is set, all Converters registered with PropertyEditors are registered with the VM. The only real issues, is if your code relies on having the Converters registered with the PropertyEditorManager, you will need to set the flag. If this is a problem, let me know and hopefully we can come up with another solution for everyone. -dain
[jira] Closed: (XBEAN-111) Only register Converters with the VM when requested
[ https://issues.apache.org/jira/browse/XBEAN-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed XBEAN-111. Resolution: Fixed Only register Converters with the VM when requested --- Key: XBEAN-111 URL: https://issues.apache.org/jira/browse/XBEAN-111 Project: XBean Issue Type: Improvement Components: reflect Affects Versions: 3.4, 3.4.1, 3.4.2 Reporter: Dain Sundstrom Assignee: Dain Sundstrom Fix For: 3.4.3 Registering the Converters in xbean-reflect with the VM PropertyEditorManager creates lots of problems for some libraries and IDEs. Since xbean-reflect has a private converter registry there is no need to register the Converters with the VM. I have add the boolean flag registerWithVM to PropertyEditors. When this flag is set, all Converters registered with PropertyEditors are registered with the VM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4352) IMAP provider: accessing parts of a multipart/mixed message causes invalid command
IMAP provider: accessing parts of a multipart/mixed message causes invalid command -- Key: GERONIMO-4352 URL: https://issues.apache.org/jira/browse/GERONIMO-4352 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: mail Reporter: Andreas Veithen When accessing the content of the second part of a multipart/mixed message (see attachment), the following IMAP command is sent: FETCH 1 (BODY.PEEK[2.TEXT]) This results in an error (FETCH failed). IMAP server is GreenMail: http://www.icegreen.com/greenmail/ RFC3501 says about the TEXT part specifier: The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part specifiers can be the sole part specifier or can be prefixed by one or more numeric part specifiers, provided that the numeric part specifier refers to a part of type MESSAGE/RFC822. The MIME part specifier MUST be prefixed by one or more numeric part specifiers. Since the second part is not message/rfc822, the command issued is incorrect. I believe that the correct command in this case should be: FETCH 1 (BODY.PEEK[2]) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4352) IMAP provider: accessing parts of a multipart/mixed message causes invalid command
[ https://issues.apache.org/jira/browse/GERONIMO-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated GERONIMO-4352: -- Attachment: 03-javamail.log IMAP provider: accessing parts of a multipart/mixed message causes invalid command -- Key: GERONIMO-4352 URL: https://issues.apache.org/jira/browse/GERONIMO-4352 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Andreas Veithen Attachments: 03-javamail.log When accessing the content of the second part of a multipart/mixed message (see attachment), the following IMAP command is sent: FETCH 1 (BODY.PEEK[2.TEXT]) This results in an error (FETCH failed). IMAP server is GreenMail: http://www.icegreen.com/greenmail/ RFC3501 says about the TEXT part specifier: The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part specifiers can be the sole part specifier or can be prefixed by one or more numeric part specifiers, provided that the numeric part specifier refers to a part of type MESSAGE/RFC822. The MIME part specifier MUST be prefixed by one or more numeric part specifiers. Since the second part is not message/rfc822, the command issued is incorrect. I believe that the correct command in this case should be: FETCH 1 (BODY.PEEK[2]) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Hi, I also do not see a lot of room for improvement in Grails integration. FWIW, in addition to the sample Grails application of the IBM article, the WADI administration console, a Grails Web-app, can be deployed out-of-the-box to Geronimo to introspect WADI clusters. I believe there is room for scripting languages in Geronimo. For instance, gshell users can source command files to automate some of their actions. A more powerful approach would be to provide scripting capabilities to gshell users. I believe, Groovy is an appropriate scripting language choice as it is very easy to learn for Java people. Another user case would be to use scripting to replace the serialized configuration, I mean the config.ser. An xmlbean serialization of configurations is way better than a native Java serialization as end- users can easily see and update values of serialized stuff. A YAML or even better a Groovy builder serialization would be way better than a xmlbean serialization. i would even go a step further and say that the geronimo DD could be replaced by scripts. A programmatic way to configure GBeans would be simpler. This could be a little bit like the programmatic servlet component configuration mechanism defined by the upcoming Servlet spec. A third example is to provide a simpler extension of configurations. The addition of a custom Tomcat valve to the tomcat6 config is a use case. When a configuration is started a script is executed to provide GBean overrides (add, update or remove) and dependencies overrides to the pre-canned configuration. In the scripting context, users have access to the pre-canned configuration and are able to return an altered one if they want. Thanks, Gianny On 11/10/2008, at 5:42 AM, Jason Dillon wrote: IMO, language is irrelevant. What you want to consider is what you want the scripting language to do for you... that is what is important. Basically (almost) any scripting language can be integrated (bsf or direct) but what is missing is the users use- cases for what the really want scripted. But.. users't don't always tell you want they want up front, they look at what you have and then complain when its broken wrt their own needs. So it might be worthwhile doing some POC work to add more scripting support. Though I don't think that web-app scripting crapski is the best way to provide that. If you think about it, there are a few uses for scripting in the application server's context. First is that the app developers prefer the language, but they still provide JavaEE muck to install/ run. So we could reduce some footprint by providing plugins, but that not really that important, as the feature will still work w/o it. The second is where the application exposes some configuration logic which is intended to be easily augmented when installing/running the application. In this model part of the application's behavior is configured via some scripting language, which is intended to be changed (slightly or dramatically) to fit the application installations requirements. The third is where the application wants to provide an extensible action interface, so allow such an application to do whatever it wants. For example, if an application supports some concept of filtering, one might desire that the filter be implemented by a script which the administrator of the application could writte/configure. I'm sure I'm missing more examples, but it should be sufficient to point these out. Scripting is a very powerful way to extend you application, and I'm certainly a proponent. But what I'm having trouble realizing is... for a JavaEE application server, what/how/why would a developer want to script? --jason On Oct 11, 2008, at 1:13 AM, Joe Bohn wrote: ant elder wrote: On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Joe Bohn wrote: Any ideas on PHP and if this would be another potential area for integration? Python Joe Bill Also JavaScript with Rhino, and that gives you the big four - Groovy, JRuby, Rhino, and Jython. PHP would good but i've never found a PHP impl with Java integration and a compatible license. You can also use the JSR-223 APIs (Apache BSF) and get easy access to lots of lesser well known script language engines. I've done a bit with all those in Tuscany so will be interested to see what happens in Geronimo. Thanks for the input. Yes, I thought about BSF too. Regarding the others languages (Python, Rhino, Jython and PHP) licenses could be issues have to keep an eye on that. I thought about BSF too ... need to do some more research there. Actually, at this point it's all just some investigation and we'll see where it goes. Joe
[jira] Commented: (GERONIMODEVTOOLS-473) Problem starting server with WTP201
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12638706#action_12638706 ] Tim McConnell commented on GERONIMODEVTOOLS-473: Hi Jean-Jacques, I finally have a better understanding of your problem. Thanks for all the material you've supplied via this Jira and as email attachments. One option that we've had a lot of success in the past with to speed up deployment/redeployment from the GEP is to use the sharedlib capability of Geronimo. Since you cannot send me your Eclipse workspace I wonder if you have one or more POJO projects in your workspace that is shared amongst multiple web projects in your workspace (i.e, there is a J2EE dependency between the Web project and the POJO which will embed the POJO JAR in the Web project's WAR). If so, when using sharedlib support, when the WAR gets deployed the POJO project will get deployed in-place to the sharedlib, and the actual contents of the POJO do not get copied over. instead a Dummy JAR gets created inside sharedlib that contains a manifest file that points back to the project in the workspace. This can significantly speed up deployments within Eclipse especially when there are many deployable artifacts with the same POJO dependency. Do you know if this is the case with your workspace ?? If not we'll have to search for another alternative. Thanks much Since you can't send me your EAR I wonder if it has some POJO JAR that is in your Eclipse workspace and it used in multiple Problem starting server with WTP201 --- Key: GERONIMODEVTOOLS-473 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-473 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Environment: Windows XP WTP 201 Reporter: Jean-Jacques Parent Assignee: Tim McConnell Fix For: 2.2.0 Attachments: .log, geronimo.log, JIRA-473.doc, web.xml I have installed wtp-all-in-one-sdk-win32 and than follow the instructions as suggested in http://geronimo.apache.org/geronimo-eclipse-plugin-installation-instructions.html. I have also manually installed the plugin: geronimo-eclipse-plugin-2.0.0-deployable.zip I configured the server geronimo and try to start it without deploying anything yet. In the eclipse console, a message indicates that the server startup is complete, but the status in Eclipse is still 'starting'. Indeed, the server is started, I can use the web console, but then comes the timeout and the server stops. Is it a configuration problem? Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-473) Problem starting server with WTP201
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12638706#action_12638706 ] mcconne edited comment on GERONIMODEVTOOLS-473 at 10/10/08 7:30 PM: -- Hi Jean-Jacques, I finally have a better understanding of your problem. Thanks for all the material you've supplied via this Jira and as email attachments. One option that we've had a lot of success in the past with to speed up deployment/redeployment from the GEP is to use the sharedlib capability of Geronimo. Since you cannot send me your Eclipse workspace I wonder if you have one or more POJO projects in your workspace that is shared amongst multiple web projects in your workspace (i.e, there is a J2EE dependency between the Web project and the POJO which will embed the POJO JAR in the Web project's WAR). If so, when using sharedlib support, when the WAR gets deployed the POJO project will get deployed in-place to the sharedlib, and the actual contents of the POJO do not get copied over. instead a Dummy JAR gets created inside sharedlib that contains a manifest file that points back to the project in the workspace. This can significantly speed up deployments within Eclipse especially when there are many deployable artifacts with the same POJO dependency. Do you know if this is the case with your workspace ?? If not we'll have to search for another alternative. Thanks much was (Author: mcconne): Hi Jean-Jacques, I finally have a better understanding of your problem. Thanks for all the material you've supplied via this Jira and as email attachments. One option that we've had a lot of success in the past with to speed up deployment/redeployment from the GEP is to use the sharedlib capability of Geronimo. Since you cannot send me your Eclipse workspace I wonder if you have one or more POJO projects in your workspace that is shared amongst multiple web projects in your workspace (i.e, there is a J2EE dependency between the Web project and the POJO which will embed the POJO JAR in the Web project's WAR). If so, when using sharedlib support, when the WAR gets deployed the POJO project will get deployed in-place to the sharedlib, and the actual contents of the POJO do not get copied over. instead a Dummy JAR gets created inside sharedlib that contains a manifest file that points back to the project in the workspace. This can significantly speed up deployments within Eclipse especially when there are many deployable artifacts with the same POJO dependency. Do you know if this is the case with your workspace ?? If not we'll have to search for another alternative. Thanks much Since you can't send me your EAR I wonder if it has some POJO JAR that is in your Eclipse workspace and it used in multiple Problem starting server with WTP201 --- Key: GERONIMODEVTOOLS-473 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-473 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Environment: Windows XP WTP 201 Reporter: Jean-Jacques Parent Assignee: Tim McConnell Fix For: 2.2.0 Attachments: .log, geronimo.log, JIRA-473.doc, web.xml I have installed wtp-all-in-one-sdk-win32 and than follow the instructions as suggested in http://geronimo.apache.org/geronimo-eclipse-plugin-installation-instructions.html. I have also manually installed the plugin: geronimo-eclipse-plugin-2.0.0-deployable.zip I configured the server geronimo and try to start it without deploying anything yet. In the eclipse console, a message indicates that the server startup is complete, but the status in Eclipse is still 'starting'. Indeed, the server is started, I can use the web console, but then comes the timeout and the server stops. Is it a configuration problem? Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: dojo-tomcat/jetty6
Just find in the newest snapshot, after I manually install the dojo plugin, it has an extra folder dojo, currently when we want the refer to dojo.js, the url will be /dojo/dojo/dojo/dojo.js. I suggest to repackage the dojo-mini.zip file. 2008/10/8 Lin Sun [EMAIL PROTECTED] Hi Manu, Ok, making it optional sounds good. Lin On Wed, Oct 8, 2008 at 8:24 AM, Manu George [EMAIL PROTECTED] wrote: Hi Lin, I am using it in the EjbServer Portlet I am developing. But I guess that it can also be made an optional console plugin Regards Manu On Wed, Oct 8, 2008 at 1:43 AM, Lin Sun [EMAIL PROTECTED] wrote: Jay, Right, I don't know how far that work went either. Thus, I didn't include the dojo-tomcat/jetty6 in the new javaee5-tomcat/jetty plugin group(profile), which will be used to build the javaee5 assemblies. Lin n Tue, Oct 7, 2008 at 3:41 PM, Jay D. McHugh [EMAIL PROTECTED] wrote: Lin, Someone was working on upgrading the views in Geronimo to use the widgets in the new version of Dojo. I don't know how far that work went. So, I believe you are correct that the legacy set are the only ones that are currently in use. Jay Lin Sun wrote: I think these two portlets are using the dojo-legacy-tomcat/jetty6. Nothing except the javaee5 assemblies lists dojo-tomcat/jetty6 as dependency. Lin On Tue, Oct 7, 2008 at 3:10 PM, Donald Woods [EMAIL PROTECTED] wrote: I believe only the Debug Views and Plan Creator portlets need Dojo right now, which I'm going to remove from the JEE5 assemblies and let users optionally install them, once I've updated the Welcome portlet to include some information about what optional Console plugins are available -Donald Lin Sun wrote: Hi, I don't see dojo-tomcat/jetty6 is used by admin console right now in trunk thus I plan to remove it from the javaee5 assembly. Any objection? Whenever we have converted some of our admin console to use dojo-tomcat/jetty6, dojo-tomcat/jetty6 should be automatically pulled into javaee5 assembly via transitive dependency, similar like dojo-legacy-tomcat/jetty6 today. Lin -- Ivan
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
On Oct 11, 2008, at 7:07 AM, Gianny Damour wrote: I also do not see a lot of room for improvement in Grails integration. FWIW, in addition to the sample Grails application of the IBM article, the WADI administration console, a Grails Web-app, can be deployed out-of-the-box to Geronimo to introspect WADI clusters. I believe there is room for scripting languages in Geronimo. For instance, gshell users can source command files to automate some of their actions. A more powerful approach would be to provide scripting capabilities to gshell users. I believe, Groovy is an appropriate scripting language choice as it is very easy to learn for Java people. GShell has had a BSF-driven 'script' command for a long time now ;-) --jason
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Great! It seems that it is not yet enabled thought. Thanks, Gianny On 11/10/2008, at 4:34 PM, Jason Dillon wrote: On Oct 11, 2008, at 7:07 AM, Gianny Damour wrote: I also do not see a lot of room for improvement in Grails integration. FWIW, in addition to the sample Grails application of the IBM article, the WADI administration console, a Grails Web- app, can be deployed out-of-the-box to Geronimo to introspect WADI clusters. I believe there is room for scripting languages in Geronimo. For instance, gshell users can source command files to automate some of their actions. A more powerful approach would be to provide scripting capabilities to gshell users. I believe, Groovy is an appropriate scripting language choice as it is very easy to learn for Java people. GShell has had a BSF-driven 'script' command for a long time now ;-) --jason
