[jira] Commented: (GERONIMO-3759) Geronimo Tomcat Clustering - No GBeans for adding Static Members
[ https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670635#action_12670635 ] viola.lu commented on GERONIMO-3759: But i tried config_ag21.xml on G2.1.3(replace version from 2.1 to 2.1.3), but get error and can't start current server, pls check the log below,can somebody help it? 12:13:59,515 INFO [Log4jService] -- 12:13:59,515 INFO [Log4jService] Started Logging Service 12:13:59,515 INFO [Log4jService] Runtime Information: 12:13:59,515 INFO [Log4jService] Install Directory = D:\geronimo-tomcat6-javaee5-2.1.3 12:13:59,515 INFO [JvmVendor] Sun JVM 1.5.0_16 12:13:59,515 INFO [Log4jService] JVM in use = Sun JVM 1.5.0_16 12:13:59,515 INFO [Log4jService] Java Information: 12:13:59,515 INFO [Log4jService] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 12:13:59,515 INFO [Log4jService] System property [java.runtime.version] = 1.5.0_16-b02 12:13:59,515 INFO [Log4jService] System property [os.name] = Windows 2003 12:13:59,515 INFO [Log4jService] System property [os.version] = 5.2 12:13:59,515 INFO [Log4jService] System property [sun.os.patch.level] = Service Pack 2 12:13:59,515 INFO [Log4jService] System property [os.arch] = x86 12:13:59,515 INFO [Log4jService] System property [java.class.version] = 49.0 12:13:59,515 INFO [Log4jService] System property [locale] = en_US 12:13:59,515 INFO [Log4jService] System property [unicode.encoding]= UnicodeLittle 12:13:59,515 INFO [Log4jService] System property [file.encoding] = Cp1252 12:13:59,515 INFO [Log4jService] System property [java.vm.name]= Java HotSpot(TM) Client VM 12:13:59,515 INFO [Log4jService] System property [java.vm.vendor] = Sun Microsystems Inc. 12:13:59,515 INFO [Log4jService] System property [java.vm.version] = 1.5.0_16-b02 12:13:59,515 INFO [Log4jService] System property [java.vm.info]= mixed mode 12:13:59,515 INFO [Log4jService] System property [java.home] = C:\Program Files\Java\jdk1.5.0_16\jre 12:13:59,515 INFO [Log4jService] System property [java.classpath] = null 12:13:59,515 INFO [Log4jService] System property [java.library.path] = C:\Program Files\Java\jdk1.5.0_16\jre\bin;.;C:\WINDOWS\system32;C:\WINDOWS;C:\STAF\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Perl\site\bin;C:\Perl\bin;C:\Program Files\IBM\WebSphere MQ\Java\lib;C:\Program Files\IBM\WebSphere MQ\bin;C:\Program Files\IBM\WebSphere MQ\tools\c\samples\bin;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\Microsoft SQL Server\90\DTS\Binn\;C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\;C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\;C:\Program Files\Subversion\bin;C:\Program Files\IBM\Informix\Connect\bin;C:\Program Files\ibm\gsk7\bin;C:\Program Files\ibm\gsk7\lib;C:\PROGRA~1\ibm\gsk7\bin;C:\PROGRA~1\ibm\gsk7\lib;C:\Program Files\IBM\Informix\Client-SDK\bin;C:\PROGRA~1\IBM\SQLLIB\BIN;C:\PROGRA~1\IBM\SQLLIB\FUNCTION;C:\PROGRA~1\IBM\SQLLIB\SAMPLES\REPL;C:\Program Files\Mozilla Firefox;C:\Program Files\Java\jre1.6.0_05\bin;C:\Program Files\Mozilla Firefox;D:\apache-maven-2.0.9\bin 12:13:59,515 INFO [Log4jService] System property [java.endorsed.dirs] = D:\geronimo-tomcat6-javaee5-2.1.3\lib\endorsed;C:\Program Files\Java\jdk1.5.0_16\jre\lib\endorsed 12:13:59,515 INFO [Log4jService] System property [java.ext.dirs] = D:\geronimo-tomcat6-javaee5-2.1.3\lib\ext;C:\Program Files\Java\jdk1.5.0_16\jre\lib\ext 12:13:59,515 INFO [Log4jService] System property [sun.boot.class.path] = D:\geronimo-tomcat6-javaee5-2.1.3\lib\endorsed\yoko-rmi-spec-1.0.jar;D:\geronimo-tomcat6-javaee5-2.1.3\lib\endorsed\yoko-spec-corba-1.0.jar;C:\Program Files\Java\jdk1.5.0_16\jre\lib\rt.jar;C:\Program Files\Java\jdk1.5.0_16\jre\lib\i18n.jar;C:\Program Files\Java\jdk1.5.0_16\jre\lib\sunrsasign.jar;C:\Program Files\Java\jdk1.5.0_16\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.5.0_16\jre\lib\jce.jar;C:\Program Files\Java\jdk1.5.0_16\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.5.0_16\jre\classes 12:13:59,515 INFO [Log4jService] -- 12:14:01,546 INFO [KernelContextGBean] bound gbean org.apache.geronimo.framework/rmi-naming/2.1.3/car?ServiceModule=org.apache.geronimo.framework/rmi-naming/2.1.3/car,j2eeType=Context,name=JavaCompContext at name java:comp 12:14:01,546 INFO [KernelContextGBean] bound gbean org.apache.geronimo.framework/rmi-naming/2.1.3/car?ServiceModule=org.apache.geronimo.framework/rmi-naming/2.1.3/car,j2eeType=Context,name=JavaContext at name java: 12:14:01,546 INFO [KernelContextGBean] bound g
[jira] Issue Comment Edited: (GERONIMO-4037) Geronimo 2.0.3 (and I guess at least 2.0.2) can't run with a security manager settled from the command line using -Djava.security.manager
[ https://issues.apache.org/jira/browse/GERONIMO-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670618#action_12670618 ] xuhaihong edited comment on GERONIMO-4037 at 2/4/09 9:05 PM: As said by Kevan, it is caused by the classloading. IMO, it should not be a security issue. In Geronimo, we would register our own Policy, PolicyConfigurationFactory objects to the security system. I changed the intialization order of that two objects, so that default Policy object is still in effect while the classloader loads the GeronimoPolicyConfigurationFactory. It maybe a trick ^_^ With the patch applied, the server could be started successfully with the security turns on. The patch is based on the 2.2 trunk base. Please help to reivew it, thanks ! was (Author: xuhaihong): As said by Kevan, it is caused by the classloading. IMO, it should not be a security issue. In Geronimo, we would register our own Policy, PolicyConfigurationFactory objects to the security system. I changed the intialization order of that two objects, so that default Policy object is still in effect while the classloader loads the GeronimoPolicyConfigurationFactory. I maybe a trick ^_^ With the patch applied, the server could be started successfully with the security turns on. The patch is based on the 2.2 trunk base. Please help to reivew it, thanks ! > Geronimo 2.0.3 (and I guess at least 2.0.2) can't run with a security > manager settled from the command line using -Djava.security.manager > -- > > Key: GERONIMO-4037 > URL: https://issues.apache.org/jira/browse/GERONIMO-4037 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel, security >Affects Versions: 2.0.2 > Environment: Windows Xp Sp2 >Reporter: Jacques Le Roux >Priority: Blocker > Attachments: Geronimo-4037.patch > > > I'm facing an issue on Windows XPsp2: I can't run WASCE with a security > manager settled from the command line using > -Djava.security.manager-Djava.security.policy=client.policy options. I get > the error below. Note that this is working properly under Linux (Ubuntu and > Suze as well). > C:\geronimo-tomcat6-jee5-2.0.3\bin>geronimo run > Using GERONIMO_BASE: C:\geronimo-tomcat6-jee5-2.0.3 > Using GERONIMO_HOME: C:\geronimo-tomcat6-jee5-2.0.3 > Using GERONIMO_TMPDIR: var\temp > Using JRE_HOME:C:\Program Files\Java\jre1.5.0_11 > Listening for transport dt_socket at address: 5005 > Booting Geronimo Kernel (in Java 1.5.0_11)... > Starting Geronimo Application Server v2.0.3-SNAPSHOT > [***> ] 11% 27s Starting > org.apac...15:57:28,625 ERROR [GBeanInstanceState] Error while starting; > GBean is now in the FAILED state: abstractName="org.apache.geronimo.configs/ > j2ee-security/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-security/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=SecurityService" > java.lang.LinkageError: > org/apache/geronimo/security/jacc/GeronimoPolicyConfigurationFactory > at > org.apache.geronimo.security.jacc.GeronimoPolicy.implies(GeronimoPolicy.java:74) > at java.security.ProtectionDomain.implies(Unknown Source) > at java.security.AccessControlContext.checkPermission(Unknown Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.Thread.setContextClassLoader(Unknown Source) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1056) > 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:553) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke() > at net.sf.cglib.reflect.FastMetho
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: js-localization-activemq.patch patch for activemq > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-activemq.patch, > js-localization-console.patch, js-localization-core.patch, > js-localization-openejb.patch, js-localization-sysdb.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4037) Geronimo 2.0.3 (and I guess at least 2.0.2) can't run with a security manager settled from the command line using -Djava.security.manager
[ https://issues.apache.org/jira/browse/GERONIMO-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4037: --- Attachment: Geronimo-4037.patch As said by Kevan, it is caused by the classloading. IMO, it should not be a security issue. In Geronimo, we would register our own Policy, PolicyConfigurationFactory objects to the security system. I changed the intialization order of that two objects, so that default Policy object is still in effect while the classloader loads the GeronimoPolicyConfigurationFactory. I maybe a trick ^_^ With the patch applied, the server could be started successfully with the security turns on. The patch is based on the 2.2 trunk base. Please help to reivew it, thanks ! > Geronimo 2.0.3 (and I guess at least 2.0.2) can't run with a security > manager settled from the command line using -Djava.security.manager > -- > > Key: GERONIMO-4037 > URL: https://issues.apache.org/jira/browse/GERONIMO-4037 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel, security >Affects Versions: 2.0.2 > Environment: Windows Xp Sp2 >Reporter: Jacques Le Roux >Priority: Blocker > Attachments: Geronimo-4037.patch > > > I'm facing an issue on Windows XPsp2: I can't run WASCE with a security > manager settled from the command line using > -Djava.security.manager-Djava.security.policy=client.policy options. I get > the error below. Note that this is working properly under Linux (Ubuntu and > Suze as well). > C:\geronimo-tomcat6-jee5-2.0.3\bin>geronimo run > Using GERONIMO_BASE: C:\geronimo-tomcat6-jee5-2.0.3 > Using GERONIMO_HOME: C:\geronimo-tomcat6-jee5-2.0.3 > Using GERONIMO_TMPDIR: var\temp > Using JRE_HOME:C:\Program Files\Java\jre1.5.0_11 > Listening for transport dt_socket at address: 5005 > Booting Geronimo Kernel (in Java 1.5.0_11)... > Starting Geronimo Application Server v2.0.3-SNAPSHOT > [***> ] 11% 27s Starting > org.apac...15:57:28,625 ERROR [GBeanInstanceState] Error while starting; > GBean is now in the FAILED state: abstractName="org.apache.geronimo.configs/ > j2ee-security/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-security/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=SecurityService" > java.lang.LinkageError: > org/apache/geronimo/security/jacc/GeronimoPolicyConfigurationFactory > at > org.apache.geronimo.security.jacc.GeronimoPolicy.implies(GeronimoPolicy.java:74) > at java.security.ProtectionDomain.implies(Unknown Source) > at java.security.AccessControlContext.checkPermission(Unknown Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.Thread.setContextClassLoader(Unknown Source) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1056) > 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:553) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke() > 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:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.kernel.con
[BUILD] trunk: Failed for Revision: 740964
Geronimo Revision: 740964 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090204/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090204
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 22 seconds
[INFO] Finished at: Wed Feb 04 21:43:04 EST 2009
[INFO] Final Memory: 596M/1004M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090204/logs-2100-tomcat/test.log
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:42.091
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:00.012)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:28.622)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:33.419)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.685)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:21.098)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:19.288)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:43.454)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:48.154)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:50.587)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:40.066)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:30.878)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:30.126)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:31.226)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:46.366)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests FAILURE (0:00:43.302) Java
returned: 1
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:01:05.288)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:26.722)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:47.217)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security FAILURE (0:00:37.717) Java
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:30.024)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00:27.282)
[INFO] web-testsuite/test-myfaces RUNNING
[INFO] web
[jira] Commented: (GERONIMO-4475) Improve JMS portlet for AMQ 5.3 Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670606#action_12670606 ] Ivan commented on GERONIMO-4475: Donald, that case passed on my windows machine, I used the 20090202 snapshot with the patch applied. Basically, I just set the temp path for the broker in the patch. Thanks ! > Improve JMS portlet for AMQ 5.3 Borker configuration > > > Key: GERONIMO-4475 > URL: https://issues.apache.org/jira/browse/GERONIMO-4475 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Ivan >Assignee: Ivan > Fix For: 2.2 > > Attachments: G4475-activemq-broker-00.patch, > G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch, > G4475-geronimo-activemq.patch, G4475-geronimo-management.patch > > > Currently in the administrator console, the users could not add another embed > broker. Also, they could not edit the broker through administrator console. > I list the features that I could see : > 1. While creating the broker, let the use upload a configuration file. > 2. While editing the broker, show a text area, so that the user could edit > the spring XML file in it. Shall we give the user a more friendly interface, > so that they do not need the edit the XML file directly. I am not sure how it > should look like. > 3. Update the connector port let, so that while creating a new connector, > the user could specify the broker that it belongs to. > Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] branches/2.0: Failed for Revision: 740944
Geronimo Revision: 740944 built with tests included See the full build-2000.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090204/build-2000.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.0/20090204 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 33 minutes 58 seconds [INFO] Finished at: Wed Feb 04 20:39:01 EST 2009 [INFO] Final Memory: 218M/864M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090204/logs-2000-tomcat/test.log [WARNING] Deployer operation failed: java.lang.NullPointerException: key is null [WARNING] org.apache.geronimo.common.DeploymentException: java.lang.NullPointerException: key is null [WARNING] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:400) [WARNING] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:135) [WARNING] at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() [WARNING] at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) [WARNING] at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) [WARNING] at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) [WARNING] at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) [WARNING] at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) [WARNING] at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) [WARNING] at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke() [WARNING] at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) [WARNING] at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) [WARNING] at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) [WARNING] at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) [WARNING] at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) [WARNING] at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) [WARNING] at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) [WARNING] at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) [WARNING] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) [WARNING] at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) [WARNING] at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410) [WARNING] at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) [WARNING] at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247) [WARNING] at java.security.AccessController.doPrivileged(Native Method) [WARNING] at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1350) [WARNING] at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784) [WARNING] at sun.reflect.GeneratedMethodAccessor44.invoke(Unknown Source) [WARNING] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [WARNING] at java.lang.reflect.Method.invoke(Method.java:585) [WARNING] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) [WARNING] at sun.rmi.transport.Transport$1.run(Transport.java:153) [WARNING] at java.security.AccessController.doPrivileged(Native Method) [WARNING] at sun.rmi.transport.Transport.serviceCall(Transport.java:149) [WARNING] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) [WARNING] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) [WARNING] at java.lang.Thread.run(Thread.java:595) [WARNING] Caused by: java.lang.NullPointerException: key is null [WARNING] at org.apache.openejb.jee.KeyedCollection.add(KeyedCollection.java:92) [WARNING] at org.apache.geronimo.openejb.deployment.EjbRefBuilder.addRefs(EjbRefBuilder.java:293) [WARNING] at org.apache.geronimo.openejb.deployment.EjbRefBuilder.buildNaming(EjbRefBuilder.java:119) [WARNING] at org.apache.geronimo.openejb.deployment.EjbRefBuilder$$FastClassByCGLIB$$dbba8597.invoke() [WARNING] at
Re: Access to Bean Validation provider (JSR-303)
This sounds promising. It's especially nice that they are using Apache 2.0 Licensing. I see that they keep up the nightly builds. I wonder how active this group really is. If there's a forum, maybe you can ping them to find out how real they are. Thanks for finding this. Kevin On Wed, Feb 4, 2009 at 12:03 PM, Jeremy Bauer wrote: > Kevin, > > I did some searching and ran across agimatic-validation[1] by agimatic > GmbH, > a JSR-303 implementation in the works. It is published under the Apache > 2.0 > License. The Hibernate JSR-303 spec jar is currently listed as dependency, > but using it with a Geronimo equivalent may be an option. > > -Jeremy > > [1] http://code.google.com/p/agimatec-validation/ > > On Tue, Feb 3, 2009 at 3:55 PM, Kevin Sutter wrote: > > > Hi, > > The JPA 2.0 expert group is looking to incorporate Bean Validation > > (JSR-303). Right now, it looks like we might include it as an optional > > feature. If a Bean Validation provider is available, then the JPA > provider > > should use it. Otherwise, it is not a requirement. > > > > The RI is being developed by Redhat. There was an Apache Commons sandbox > > started for a potential Bean Validator provider, but the activity has > died > > off. > > > > So, I'm wondering from an OpenJPA and OpenEJB perspective, what should we > > do? I may be mistaken, but my guess is that the EJB spec is going to > > contain a similar dependency on Bean Validation. I don't believe the RI > > will be directly accessible to us via a Maven dependency. Does anybody > > know > > of other Bean Validation provider implementations that are in plan? > > > > Thoughts, suggestions? > > > > Kevin > > >
[BUILD] trunk: Failed for Revision: 740829
Geronimo Revision: 740829 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090204/build-1500.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090204
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 39 minutes 35 seconds
[INFO] Finished at: Wed Feb 04 15:47:37 EST 2009
[INFO] Final Memory: 395M/1015M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090204/logs-1500-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:45.739
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:12.751)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:31.763)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:34.697)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.999)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:21.602)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:23.321)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:45.341)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:45.911)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:47.684)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:38.625)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:29.977)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:27.420)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:30.258)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:46.960)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests FAILURE (0:00:40.896) Java
returned: 1
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:01:10.340)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.713)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:47.012)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security SUCCESS (0:00:42.052)
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:29.382)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test
[jira] Updated: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4350: -- Affects Version/s: 2.1.4 Fix Version/s: (was: 2.1.4) Updating versions as it probably will not get fixed for 2.1.4. > 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.1.4, 2.2 >Reporter: David Jencks >Assignee: Dain Sundstrom > Fix For: 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: Time for Geronimo 2.1.4 release?
Jarek, I got spoiled by having the integration tests automatically run on 2.2. I had hoped that the tests were broken before I started - but unfortunately, it really was me that broke them. I will find and fix the problem. Thanks for alerting me to it. Jay Jarek Gawor wrote: > Jay, > > Please run all tests including the integration tests before > committing. Looks like deployment of some apps is failing after the > recent changes, for example see: > http://people.apache.org/builds/geronimo/server/binaries/2.0/20090204/logs-0200-tomcat/test.log > > Jarek > > On Wed, Feb 4, 2009 at 9:55 AM, Jay D. McHugh wrote: >> All of the 2.0.3 build issues are fixed. >> >> I will try building 2.0.3 with XBeans 3.5 now and let you all know what >> happens. >> >> If it will build, then I might take a look to see whether I can figure >> out what changes are necessary for OpenEJB 3.0.1 to use XBeans 3.5 too. >> >> Jay >> >> Jay D. McHugh wrote: >>> The problem is with the version of ASM that is brought in when using a >>> higher version of XBeans. >>> >>> OpenEJB is using a method that has been removed: >>> org.objectweb.asm.ClassReader.accept >>> >>> And Geronimo (already - not counting XBeans 3.5) is using classes that >>> have been removed: >>> LinkResolver >>> UniqueDefaultLinkResolver >>> >>> Jay >>> >>> Joe Bohn wrote: >>>> Thanks for the info Jay and for doing some more digging. >>>> >>>> I don't really have a strong desire to push everything to xBean 3.5. I >>>> was just trying to eliminate the use of multiple xBean versions as this >>>> could potentially cause problems (and confusion) for our users. >>>> >>>> It looks like we originally moved up to xBean 3.5 (actually >>>> 3.5-SNAPSHOT) to resolve a jca context issue (Geronimo-4375). However, >>>> it looks like it was soon discovered that there were issues with the >>>> OpenEJB, ASM and xBean versions in G. As a result ... we ended up >>>> reverting back to an older ASM and xBean 3.3 for finder and reflect >>>> while keeping the newer xbean-naming 3.5 so that the original issue was >>>> still resolved. That seems to be working and is perhaps the best >>>> approach. I was just concerned about using the various xBean versions >>>> in our Geronimo 2.1.4 server. Perhaps using the various xBean versions >>>> is still the best thing to do here. I didn't realize that there were >>>> core issues in OpenEJB attempting to use anything greater than 3.4.1. >>>> >>>> Thanks, >>>> Joe >>>> >>>> >>>> Jay D. McHugh wrote: >>>>> Hey everyone, >>>>> >>>>> If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think >>>>> that we'll need to chip in to resolve the problems that pop up when you >>>>> use a version greater than 3.4.1. >>>>> >>>>> That was the highest version (available at the time) that could be used >>>>> in the OpenEJB 3.0 branch without causing errors. >>>>> >>>>> I'll try switching to XBeans 3.5 (after the build I am in the middle of >>>>> finishes) and let you all know if it goes through cleanly. >>>>> >>>>> My feeling is that it won't though. >>>>> >>>>> Also, I have been trying to get a 'final' Geronimo 2.0.x release put >>>>> together and will need OpenEJB 3.0.1 for that (3.0 no longer builds >>>>> because the artifacts for XBeans changed groupIds). >>>>> >>>>> Jay >>>>> >>>>> Joe Bohn wrote: >>>>>> I was relaying the information second-hand ... so it's very possible I >>>>>> got it wrong. >>>>>> >>>>>> It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 >>>>>> rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can >>>>>> convince OpenEJB 3.0.x to xBean 3.5 we can then make the references >>>>>> consistent in our 2.1 branch. >>>>>> >>>>>> Thanks, >>>>>> Joe >>>>>> >>>>>> >>>>>> Donald Woods wrote: >>>>>>> I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. >>>>>>>
[jira] Resolved: (GERONIMO-4442) Unable to configure IP address for many listening ports
[ https://issues.apache.org/jira/browse/GERONIMO-4442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4442. --- Resolution: Fixed Resolving as indicated by Shawn everything is fixed except ActiveMQ ports and we have a separate JIRA (GERONIMO-4404) to track that. > Unable to configure IP address for many listening ports > --- > > Key: GERONIMO-4442 > URL: https://issues.apache.org/jira/browse/GERONIMO-4442 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.2, 2.1.3 >Reporter: Kevan Miller >Assignee: Kevan Miller >Priority: Critical > Fix For: 2.1.4, 2.2 > > Attachments: G4222_ORBConfigAdapter.patch > > > I tried to configure the listening IP address for our server sockets. I > configured all 'host' properties in config-substitution.properties to be > '127.0.0.1' and got the following results: > Listening on Ports: > 1050 127.0.0.1 CORBA Naming Service > 1099 127.0.0.1 RMI Naming > 1527 127.0.0.1 Derby Connector > 2001 127.0.0.1 OpenEJB ORB Adapter > 4201 127.0.0.1 OpenEJB Daemon > 6882 127.0.0.1 OpenEJB ORB Adapter > 8009 127.0.0.1 Tomcat Connector AJP AJP > 8080 127.0.0.1 Tomcat Connector HTTP BIO HTTP > 8443 127.0.0.1 Tomcat Connector HTTPS BIO HTTPS > 127.0.0.1 JMX Remoting Connector >61613 127.0.0.1 ActiveMQ Transport Connector >61616 127.0.0.1 ActiveMQ Transport Connector > Unfortunately, that's not accurate. netstat reveals the following actual > results: > $ netstat -an | grep LISTEN > tcp4 0 0 *.6882 *.*LISTEN > tcp4 0 0 *.2001 *.*LISTEN > tcp4 0 0 *.63519*.*LISTEN > tcp4 0 0 *.1050 *.*LISTEN > tcp4 0 0 127.0.0.1.4201 *.*LISTEN > tcp4 0 0 127.0.0.1.61613*.*LISTEN > tcp4 0 0 127.0.0.1.61616*.*LISTEN > tcp4 0 0 127.0.0.1.1527 *.*LISTEN > tcp4 0 0 127.0.0.1.8443 *.*LISTEN > tcp4 0 0 127.0.0.1.8009 *.*LISTEN > tcp4 0 0 127.0.0.1.8080 *.*LISTEN > tcp4 0 0 *. *.*LISTEN > tcp4 0 0 *.1099 *.*LISTEN > Configuring the host properties to be an actual ip address/hostname is a bit > worse (not sure what's going on with ActiveMQ): > Listening on Ports: > 1050 10.0.1.196 CORBA Naming Service > 1099 10.0.1.196 RMI Naming > 1527 10.0.1.196 Derby Connector > 2001 10.0.1.196 OpenEJB ORB Adapter > 4201 10.0.1.196 OpenEJB Daemon > 6882 10.0.1.196 OpenEJB ORB Adapter > 8009 10.0.1.196 Tomcat Connector AJP AJP > 8080 10.0.1.196 Tomcat Connector HTTP BIO HTTP > 8443 10.0.1.196 Tomcat Connector HTTPS BIO HTTPS > 10.0.1.196 JMX Remoting Connector >61613 0.0.0.0ActiveMQ Transport Connector >61616 0.0.0.0ActiveMQ Transport Connector > Netstat shows: > $ netstat -an | grep LISTEN > tcp6 0 0 fe80::1%lo0.631*.*LISTEN > tcp4 0 0 *.6882 *.*LISTEN > tcp4 0 0 *.2001 *.*LISTEN > tcp4 0 0 *.63569*.*LISTEN > tcp4 0 0 *.1050 *.*LISTEN > tcp4 0 0 10.0.1.196.4201*.*LISTEN > tcp4 0 0 *.61613*.*LISTEN > tcp4 0 0 *.61616*.*LISTEN > tcp4 0 0 10.0.1.196.1527*.*LISTEN > tcp4 0 0 10.0.1.196.8443*.*LISTEN > tcp4 0 0 10.0.1.196.8009*.*LISTEN > tcp4 0 0 10.0.1.196.8080*.*LISTEN > tcp4 0 0 *. *.*LISTEN > tcp4 0 0 *.1099 *.*LISTEN -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4393) Duplicate Xid with multiple JVMs on single host - default impl needs some 'random' entropy
[ https://issues.apache.org/jira/browse/GERONIMO-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4393. --- Resolution: Fixed Assignee: Jarek Gawor > Duplicate Xid with multiple JVMs on single host - default impl needs some > 'random' entropy > -- > > Key: GERONIMO-4393 > URL: https://issues.apache.org/jira/browse/GERONIMO-4393 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.3 > Environment: multiple JVMs on single machine >Reporter: Gary Tully >Assignee: Jarek Gawor > Fix For: 2.1.4, 2.2 > > Attachments: GERONIMO-4393.patch > > > the default generation of baseId in XidFactoryImpl is not sufficient for > multiple JVMs on a single node. There needs to be some entropy in the form of > a few Random bytes to ensure that ids are different because given a > duplication of code, the hashCode of the XidFactoryImpl will not be unique > across the JVMs and given a single node, the IP addresss will be shared. > This emerged via https://issues.apache.org/activemq/browse/AMQ-1824 where the > workaround was to pass in the baseId as a constructor arg via spring. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4393) Duplicate Xid with multiple JVMs on single host - default impl needs some 'random' entropy
[ https://issues.apache.org/jira/browse/GERONIMO-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670437#action_12670437 ] Jarek Gawor commented on GERONIMO-4393: --- Committed the patch to txmanager trunk (revision 740839) and branches/geronimo-txmanager-parent-2.1 (revision 740842). > Duplicate Xid with multiple JVMs on single host - default impl needs some > 'random' entropy > -- > > Key: GERONIMO-4393 > URL: https://issues.apache.org/jira/browse/GERONIMO-4393 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.3 > Environment: multiple JVMs on single machine >Reporter: Gary Tully > Fix For: 2.1.4, 2.2 > > Attachments: GERONIMO-4393.patch > > > the default generation of baseId in XidFactoryImpl is not sufficient for > multiple JVMs on a single node. There needs to be some entropy in the form of > a few Random bytes to ensure that ids are different because given a > duplication of code, the hashCode of the XidFactoryImpl will not be unique > across the JVMs and given a single node, the IP addresss will be shared. > This emerged via https://issues.apache.org/activemq/browse/AMQ-1824 where the > workaround was to pass in the baseId as a constructor arg via spring. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4446) ServletRequestAttributeListener does not work with G Jetty 2.1.3, works with G Tomcat 2.1.3
[ https://issues.apache.org/jira/browse/GERONIMO-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4446: -- Affects Version/s: 2.1.4 Fix Version/s: (was: 2.1.4) I believe this is a bug in Jetty. The Jetty ContextHandler first invokes the ServletRequestListeners and then registers ServletRequestAttributeListeners. If ServletRequestAttributeListeners were registered before ServletRequestListeners then your test should work. But this is just from looking at the code so I'm not 100% sure about that. Anyway, this probably will not get fixed in 2.1.4. > ServletRequestAttributeListener does not work with G Jetty 2.1.3, works with > G Tomcat 2.1.3 > --- > > Key: GERONIMO-4446 > URL: https://issues.apache.org/jira/browse/GERONIMO-4446 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Jetty >Affects Versions: 2.1.3, 2.1.4, 2.2 > Environment: Geronimo Jetty 2.1.3, Windows XP, Sun JDK 1.5.0_13 >Reporter: Vamsavardhana Reddy > Fix For: 2.2 > > Attachments: helloworld-listener.war > > > I have a web application with a ServletRequestListener and a > ServletRequestAttributeListener. In > ServletRequestListener.requestInitialized() I am adding an attribute > "hellotxt" to the servlet request. In > ServletRequestAttributeListener.attributeAdded(), I am appending some text to > the same attribute. This application deployed in G Tomcat 2.1.3 server, is > working as expected and attributeAdded() method is called for "hellotxt" > attribute. If the same application is deployed in G Jetty 2.1.3 server, > attributeAdded() method is not getting called for "hellotxt" attribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4470) non-overridable filters working properly
[ https://issues.apache.org/jira/browse/GERONIMO-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-4470. -- Resolution: Won't Fix This is a minor issue at best. Unless we have stronger motivation, let's close it. > non-overridable filters working properly > > > Key: GERONIMO-4470 > URL: https://issues.apache.org/jira/browse/GERONIMO-4470 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.3, 2.1.4, 2.2 >Reporter: Kevan Miller > Fix For: 2.2 > > > If we're unable to load a non-overridable class from a parent classloader and > inverse classloading is configured, looks like we'll try to load the class > from the local ClassLoader. I don't think this is correct. If we're unable to > load from a parent classloader, should always return a > ClassNotFoundException... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4519) When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource
[ https://issues.apache.org/jira/browse/GERONIMO-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMO-4519. - > When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send > rollback request again to the XAResource > -- > > Key: GERONIMO-4519 > URL: https://issues.apache.org/jira/browse/GERONIMO-4519 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > as titled, when XAException is XA_RBROLLBACK from XAResource.end, which > indicates that XAResource has already rolled back the transaction, there is > no need > to send rollback request to the XAResource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4506) switch to use txmanager 2.1.2-snapshot in geronimo server 2.1 branch
[ https://issues.apache.org/jira/browse/GERONIMO-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMO-4506. - > switch to use txmanager 2.1.2-snapshot in geronimo server 2.1 branch > > > Key: GERONIMO-4506 > URL: https://issues.apache.org/jira/browse/GERONIMO-4506 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > Attachments: G4506.patch > > > This patch prepares the geronimo server 2.1 branch to use the new txmanager > 2.1.2-snapshot. With this patch, I am able to build branch 2.1 successfully > with all of the testsuites passing. If there is no objection, I'd like to > commit this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4519) When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource
[ https://issues.apache.org/jira/browse/GERONIMO-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4519. --- Resolution: Invalid mark as invalid (see subversion commit tab) > When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send > rollback request again to the XAResource > -- > > Key: GERONIMO-4519 > URL: https://issues.apache.org/jira/browse/GERONIMO-4519 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > as titled, when XAException is XA_RBROLLBACK from XAResource.end, which > indicates that XAResource has already rolled back the transaction, there is > no need > to send rollback request to the XAResource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4451) locking and unlocking for availability of a keystore results in duplicate attributes in config.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4451. --- Resolution: Fixed I believe this problem was caused by GERONIMO-4407 and I'm unable to replicate this problem so I'm resolving this bug. > locking and unlocking for availability of a keystore results in duplicate > attributes in config.xml > -- > > Key: GERONIMO-4451 > URL: https://issues.apache.org/jira/browse/GERONIMO-4451 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, security >Affects Versions: 2.1.3 > Environment: Ubuntu Linux 8.10, Sun Java 1.6, Geronimo 2.1.3 w/ Jetty. >Reporter: Christian Svensson >Assignee: Donald Woods > Fix For: 2.1.4, 2.2 > > > Transcribing mail conversation: > Hello! > I've been trying for the better part of today getting keystores to > automatically unlock on startup - with very limited success. > Is there something that I should know about keystore password / key password? > Digging around some old mailing list threads said something about key > password must be equal to keystore password - any more of those gotchas? > The problem is that I create (or change password on geronimo-default for that > matter) a new keystore, assign SSL to use the certificate and restart the > server: > org.apache.geronimo.management.geronimo.KeystoreIsLocked: Keystore > 'plasma-ssl' is locked; please use the keystore page in the admin console to > unlock it > at > org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLContext(FileKeystoreManager.java:343) > at > org.apache.geronimo.jetty6.connector.GeronimoSelectChannelSSLListener.createSSLContext(GeronimoSelectChannelSSLListener.java:54) > Resetting the SSL connector to using geronimo-default / geronimo with secret > / secret as passwords makes it work again - but why on earth doesn't Geronimo > unlock my keystores on startup? I mean, it saves the password (or something > like it) in config.xml. > - > This is how I created my setup: > 1. Create a new keystore 'plasma-ssl' > 2. Create a new private key 'wildcard' > 3. Now the text on "Available" says "trust only" or something like that, I > lock it and then unlock it in order for it to change to "1 key ready" > 4. Then I configure my HTTPS connector to use the new keystore > 5. Since the web server does not seem to do anything when I press "Shutdown" > in the console, I use Ctrl+C to kill it. > 6. Start the server again > 7. Message appears. > --- > Hmm... the 3rd step is indeed unearthing a bug. At that step, a second > "attribute" element is getting added (instead of replacing the existing > element) to the keystore gbean for keystorePassword and keyPasswords > attributes in config.xml . Can you create an issue in the JIRA [1]? The > problem summary is, "locking and unlocking for availability of a keystore > results in duplicate attributes in config.xml". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Access to Bean Validation provider (JSR-303)
Kevin, I did some searching and ran across agimatic-validation[1] by agimatic GmbH, a JSR-303 implementation in the works. It is published under the Apache 2.0 License. The Hibernate JSR-303 spec jar is currently listed as dependency, but using it with a Geronimo equivalent may be an option. -Jeremy [1] http://code.google.com/p/agimatec-validation/ On Tue, Feb 3, 2009 at 3:55 PM, Kevin Sutter wrote: > Hi, > The JPA 2.0 expert group is looking to incorporate Bean Validation > (JSR-303). Right now, it looks like we might include it as an optional > feature. If a Bean Validation provider is available, then the JPA provider > should use it. Otherwise, it is not a requirement. > > The RI is being developed by Redhat. There was an Apache Commons sandbox > started for a potential Bean Validator provider, but the activity has died > off. > > So, I'm wondering from an OpenJPA and OpenEJB perspective, what should we > do? I may be mistaken, but my guess is that the EJB spec is going to > contain a similar dependency on Bean Validation. I don't believe the RI > will be directly accessible to us via a Maven dependency. Does anybody > know > of other Bean Validation provider implementations that are in plan? > > Thoughts, suggestions? > > Kevin >
jira cleanup
Hey, Can people go through the open bugs for 2.1.4 (or any other version if you have time) and see which ones can be closed? I think at least GERONIMO-4350 and GERONIMO-3907 can be resolved but I'm not 100% sure. Thanks, Jarek
[jira] Updated: (GERONIMO-4470) non-overridable filters working properly
[ https://issues.apache.org/jira/browse/GERONIMO-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4470: -- Affects Version/s: (was: 2.0.4) 2.0.3 > non-overridable filters working properly > > > Key: GERONIMO-4470 > URL: https://issues.apache.org/jira/browse/GERONIMO-4470 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.3, 2.1.4, 2.2 >Reporter: Kevan Miller > Fix For: 2.2 > > > If we're unable to load a non-overridable class from a parent classloader and > inverse classloading is configured, looks like we'll try to load the class > from the local ClassLoader. I don't think this is correct. If we're unable to > load from a parent classloader, should always return a > ClassNotFoundException... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1829) Service Plans should allow GBean references by interface (vs. by name)
[ https://issues.apache.org/jira/browse/GERONIMO-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-1829: -- Fix Version/s: (was: 2.0.4) 2.0.3 > Service Plans should allow GBean references by interface (vs. by name) > -- > > Key: GERONIMO-1829 > URL: https://issues.apache.org/jira/browse/GERONIMO-1829 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.0 >Reporter: Aaron Mulder > Fix For: 2.0.3 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1842) Dynamically load jars from the WEB-INF/lib directory
[ https://issues.apache.org/jira/browse/GERONIMO-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-1842: -- Fix Version/s: (was: 2.0.4) 2.0.3 > Dynamically load jars from the WEB-INF/lib directory > > > Key: GERONIMO-1842 > URL: https://issues.apache.org/jira/browse/GERONIMO-1842 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: core >Reporter: Prasad Kashyap > Fix For: 2.0.3 > > > Currently the server has a hardcoded list of what it expects in the > WEB-INF/lib dir. This means that additions/deletion of jars in that directory > will not be picked up without actually redeploying that app. This seems like > a major irritant. > The best thing of course would be to dynamically pick up or drop jars from > the lib directory as they are added/deleted. > But we can, for now, settle for loading/unloading them at an app restart. > This should be the bare minimum requirement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2127) Expose the ability to use Select for Update on CMP entity beans
[ https://issues.apache.org/jira/browse/GERONIMO-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-2127: -- Fix Version/s: (was: 2.0.4) 2.0.3 > Expose the ability to use Select for Update on CMP entity beans > --- > > Key: GERONIMO-2127 > URL: https://issues.apache.org/jira/browse/GERONIMO-2127 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Environment: All >Reporter: Matt Hogstrom > Fix For: 2.0.3 > > > Currently TranQL supports the generation sql to execute a select for update. > Unfortunately, OpenEJB does not expose the ability in the current XSD to > support this. As a result the CMP implementation we have does pass CTS but > lacks the ability to deploy an application that is performant and provides > for data consistency. > This improvement will add an attribute into the XSD for OpenEJB so a new > attribute will be added that is an indicator to use a > select for update on a query so database locking can be employed. > Changes will be made to TranQL (Syntax Factories) to create the correct SQL > as well as OpenEJB's CMP builders to honor the request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2045) Plugin prerequisites: for DB pools, support DB type/version and table validation
[ https://issues.apache.org/jira/browse/GERONIMO-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-2045: -- Fix Version/s: (was: 2.0.4) 2.0.3 > Plugin prerequisites: for DB pools, support DB type/version and table > validation > > > Key: GERONIMO-2045 > URL: https://issues.apache.org/jira/browse/GERONIMO-2045 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.1 >Reporter: Aaron Mulder > Fix For: 2.0.3 > > > More robust database pool prerequisites for plugins: > - check that one of a specific set of RDBMS name/version combinations is set > for a connection pool prerequisite > - check the schema somehow -- e.g. that some table exists, or some query > returns an expected value -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2210) Enable tests (geronimo-connector-builder :: **/Connector15DCBTest.java)
[
https://issues.apache.org/jira/browse/GERONIMO-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor updated GERONIMO-2210:
--
Fix Version/s: (was: 2.0.4)
2.0.3
> Enable tests (geronimo-connector-builder :: **/Connector15DCBTest.java)
> ---
>
> Key: GERONIMO-2210
> URL: https://issues.apache.org/jira/browse/GERONIMO-2210
> Project: Geronimo
> Issue Type: Sub-task
> Security Level: public(Regular issues)
> Components: connector
>Affects Versions: 1.2
>Reporter: Jason Dillon
>Assignee: Anita Kulshreshtha
> Fix For: 2.0.3
>
>
> A few tests failed in non-obvious ways when run under the m2 build. Need
> someone who knows these tests better to inspect, resolve and enable the test
> (remove the test exclusions in the pom).
> The test fails with (on the console):
> {noformat}
> Ignoring connectiondefinition-instance/config-setting ServerUrl (no matching
> config-property in J2EE DD)
> Ignoring connectiondefinition-instance/config-setting UserName (no matching
> config-property in J2EE DD)
> Ignoring connectiondefinition-instance/config-setting Password (no matching
> config-property in J2EE DD)
> Geronimo connector deployment plan has admin object with interface
> 'javax.jms.Queue' and class 'org.activemq.message.ActiveMQQueue' but the
> ra.xml does not have a matching adminobject declared. Deleting this
> adminobject from the Geronimo plan.
> Geronimo connector deployment plan has admin object with interface
> 'javax.jms.Queue' and class 'org.activemq.message.ActiveMQQueue' but the
> ra.xml does not have a matching adminobject declared. Deleting this
> adminobject from the Geronimo plan.
> Geronimo connector deployment plan has admin object with interface
> 'javax.jms.Topic' and class 'org.activemq.message.ActiveMQTopic' but the
> ra.xml does not have a matching adminobject declared. Deleting this
> adminobject from the Geronimo plan.
> {noformat}
> And in the surefire report:
> {noformat}
> ---
> Test set: org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest
> ---
> Tests run: 4, Failures: 3, Errors: 1, Skipped: 0, Time elapsed: 1.488 sec <<<
> FAILURE!
> testCreateDatabase(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.66 sec <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.geronimo.connector.deployment.jsr88.ConnectionDefinition.configure(ConnectionDefinition.java:64)
> at
> org.apache.geronimo.connector.deployment.jsr88.ResourceAdapter.setConnectionDefinition(ResourceAdapter.java:111)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testCreateDatabase(Connector15DCBTest.java:114)
> testWriteWithNulls(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.046 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at junit.framework.Assert.assertEquals(Assert.java:207)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testWriteWithNulls(Connector15DCBTest.java:205)
> testCreateJMSResource(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.382 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<7> but was:<4>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at junit.framework.Assert.assertEquals(Assert.java:207)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testCreateJMSResource(Connector15DCBTest.java:355)
> testLoadJMSResources(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.38 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<7> but was:<4>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at junit.framework.Assert.assertEquals(Assert.java:207)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testLoadJMSResources(Connector15DCBTest.java:479)
> {n
[jira] Updated: (GERONIMO-2128) Allow user to specify the Isolation Level for a CMP bean's SQL access
[ https://issues.apache.org/jira/browse/GERONIMO-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-2128: -- Fix Version/s: (was: 2.0.4) 2.0.3 > Allow user to specify the Isolation Level for a CMP bean's SQL access > - > > Key: GERONIMO-2128 > URL: https://issues.apache.org/jira/browse/GERONIMO-2128 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Matt Hogstrom > Fix For: 2.0.3 > > > Currently CMP beans all execute in the default isolation level of the > datasource. This means that in many situations higher level locks are > required for the database access than are required. This improvement will > allow the user to specify a new attribute on a CMP entity bean > that will be the isolation level used for database access > on this entity bean. This will require updates to OpenEJB and TranQL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2290) Percent complete goes over 100% when installing configurations
[ https://issues.apache.org/jira/browse/GERONIMO-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-2290: -- Fix Version/s: (was: 2.0.4) 2.0.3 > Percent complete goes over 100% when installing configurations > -- > > Key: GERONIMO-2290 > URL: https://issues.apache.org/jira/browse/GERONIMO-2290 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, core >Affects Versions: 1.1 >Reporter: Aaron Mulder >Priority: Critical > Fix For: 2.0.3 > > > Looks like the UnpackArtifactTypeHandler counts the "uncompressed" bytes, > whereas the % is based on the content size returned by the server for the > download (the "compressed" byte count). > Probably should use an InputStream between the download stream and the ZIP > stream that performs the count on read(byte[],int,int) and them use that > count instead of the uncompressed count. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2288) Abstract/Maven repositories install modules incorrectly
[ https://issues.apache.org/jira/browse/GERONIMO-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-2288: -- Fix Version/s: (was: 2.0.4) 2.0.3 > Abstract/Maven repositories install modules incorrectly > --- > > Key: GERONIMO-2288 > URL: https://issues.apache.org/jira/browse/GERONIMO-2288 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel, Plugins >Affects Versions: 1.1, 1.1.1, 1.2, 2.0-M6 >Reporter: Aaron Mulder >Assignee: Aaron Mulder > Fix For: 2.0.3 > > > The repository unpacks a JAR when it installs it only if the Artifact type is > "car". That is incorrect -- it should unpack any module with > META-INF/config.ser (which is the logic that we use in other places, such as > RepositoryConfigurationStore). This breaks plugins that don't have the type > "car" (such as copying a database pool from server to server). > The currently handling attempts to be generic by associating a behavior with > each file type, though in practice this is only used for type=car. In the > 1.1 branch, I am going to put in a workaround to look up the "car" handler > any time we find a META-INF/config.ser (a pretty minimal workaround). > In trunk, I think we should remove the behavior/type association and instead > have a boolean for whether configurations should be unpacked, or an > "ArtifactTypeHandler" property specifically for configurations and another > one for non-configurations. I don't see any reason to distinguish based on > module type. Input would be appreciated for the 1.2 resolution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2424) Add config.xml support for ConfigurationAwareReference
[ https://issues.apache.org/jira/browse/GERONIMO-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-2424: -- Fix Version/s: (was: 2.0.4) 2.0.3 > Add config.xml support for ConfigurationAwareReference > -- > > Key: GERONIMO-2424 > URL: https://issues.apache.org/jira/browse/GERONIMO-2424 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: common, kernel, naming >Affects Versions: 1.1.1 >Reporter: Aaron Mulder > Fix For: 2.0.3 > > > It would be nice if a GBean property of type ConfigurationAwareReference > could be overridden in config.xml. This seems reasonable in that a > ConfigurationAwareReference essentially holds an Artifact and a set of > AbstractNameQueries, both of which are independently representable as > Strings. Presently it looks like there's a PropertyEditor for > AbstractNameQuery but not for Artifact or ConfigurationAwareReference. Not > sure what XML editors might be available. > (This is because some plugin gbeans use properties of type > ConfigurationAwareReference to refer to e.g. a database connection pool, > where the pool name was configured in some XML file processed by the plugin's > deployer component.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4324) Upgrade to MyFaces v1.2.6
[ https://issues.apache.org/jira/browse/GERONIMO-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4324: -- Fix Version/s: (was: 2.0.4) 2.0.3 > Upgrade to MyFaces v1.2.6 > - > > Key: GERONIMO-4324 > URL: https://issues.apache.org/jira/browse/GERONIMO-4324 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: dependencies >Affects Versions: 2.0.3, 2.1.4, 2.2 >Reporter: Donald Woods >Assignee: Joe Bohn >Priority: Minor > Fix For: 2.0.3, 2.1.4, 2.2 > > > Upgrade to MyFaces v1.2.6 released on January 26, 2009 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3768) deployment failure is not logged in either geronimo.log or deployer.log
[ https://issues.apache.org/jira/browse/GERONIMO-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3768: -- Affects Version/s: 2.1.4 Fix Version/s: (was: 2.1.4) Updating versions as it probably will not get fixed for 2.1.4. > deployment failure is not logged in either geronimo.log or deployer.log > --- > > Key: GERONIMO-3768 > URL: https://issues.apache.org/jira/browse/GERONIMO-3768 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.1, 2.1.1, 2.1.4 >Reporter: Kevan Miller > Fix For: 2.2 > > > Deployment failures should be logged, IMO. Yet there's no indication of the > following deploy failure. The only failure info is in STDOUT for both server > and deploy processes. > coltrane:bin kevan$ ./deploy.sh deploy > ~/Desktop/OS-Projects/artifactory-1.2.2/webapps/artifactory.war > ~/Desktop/OS-Projects/artifactory-1.2.2/webapps/geronimo-web.xml Using > GERONIMO_BASE: /Users/kevan/downloads/geronimo-tomcat6-javaee5-2.1-SNAPSHOT > Using GERONIMO_HOME: > /Users/kevan/downloads/geronimo-tomcat6-javaee5-2.1-SNAPSHOT > Using GERONIMO_TMPDIR: var/temp > Using JRE_HOME: > /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home > 12:42:02,694 WARN [AbstractGBeanReference] GBean references are not using > proxies > org.apache.geronimo.kernel.config.LifecycleException: start of > com.kevan/artifactory/1.2.2/war failed > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:551) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:515) > 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 > javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784) > 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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) > at sun.rmi.tran
[jira] Updated: (GERONIMO-4155) Can use a run-as role without defining it
[ https://issues.apache.org/jira/browse/GERONIMO-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4155: -- Affects Version/s: 2.1.4 Fix Version/s: (was: 2.1.4) Updating versions as it probably will not get fixed for 2.1.4. > Can use a run-as role without defining it > - > > Key: GERONIMO-4155 > URL: https://issues.apache.org/jira/browse/GERONIMO-4155 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment, web >Affects Versions: 2.1.1, 2.1.4, 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.2 > > > The testsuite/enterprise-testsuite/sec-tests app demonstrates that you can > set up a servlet with a run-as role of "baz" that is not mapped to a subject > in the geronimo security element and the app will deploy and run fine. This > should result in a deployment error and failing that a runtime error. > problem present in trunk rev. 670237 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4184) In-doubt transaction Id's could be reused during server startup
[ https://issues.apache.org/jira/browse/GERONIMO-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4184: -- Affects Version/s: 2.1.4 Fix Version/s: (was: 2.1.4) Updating versions as it probably will not get fixed for 2.1.4. > In-doubt transaction Id's could be reused during server startup > --- > > Key: GERONIMO-4184 > URL: https://issues.apache.org/jira/browse/GERONIMO-4184 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.4 >Reporter: Kevan Miller > Fix For: 2.2 > > > During server restart, we may reuse an Xid for a transaction which is > in-doubt. Potentially confusing a resource manager. We need to insure this > does not occur. Simple way is to remember the largest Xid in tran log and > start with a larger number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4526) ejbTimout method not subject to permission checks
[ https://issues.apache.org/jira/browse/GERONIMO-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4526. -- Resolution: Fixed Fixed in 2.2 rev 740811. > ejbTimout method not subject to permission checks > - > > Key: GERONIMO-4526 > URL: https://issues.apache.org/jira/browse/GERONIMO-4526 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.1.4, 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1.4, 2.2 > > > Right now if you have security enabled ejbTimeout calls don't work, they get > an unauth exception. > Need to fix it so the permissions that aren't from an interface get into the > unchecked permissions. If someone adds the ejbTimeout method to an > interface, that will get a different permission so the new unchecked > permission shouldn't allow unwanted access. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3875) Enabling authentication for Derby renders DB Viewer portlet unusable for all db's except SystemDatabase
[
https://issues.apache.org/jira/browse/GERONIMO-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods reassigned GERONIMO-3875:
--
Assignee: (was: Donald Woods)
> Enabling authentication for Derby renders DB Viewer portlet unusable for all
> db's except SystemDatabase
> ---
>
> Key: GERONIMO-3875
> URL: https://issues.apache.org/jira/browse/GERONIMO-3875
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: console
>Affects Versions: 2.1, 2.1.1, 2.1.3, 2.1.4, 2.2
> Environment: Win XP, G 2.1 Tomcat
>Reporter: Vamsavardhana Reddy
> Fix For: 2.2
>
> Attachments: GERONIMO-3875.patch
>
>
> After enabling authentication for Derby, I am noticing that DB Viewer
> portlet is unable to work with any database other that SystemDatabase.
> listTables.jsp has the following code:
> {code}
> <%-- Datasource --%>
>
> <%-- Create the connection manually --%>
>var="ds"
> driver="org.apache.derby.jdbc.EmbeddedDriver"
> url="jdbc:derby:${db};create=true"
> user=""
> password=""
> />
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4076) Console runs in unhandled exception when user starts module with unresolved dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-4076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4076: -- Affects Version/s: 2.1.4 Fix Version/s: (was: 2.1.4) Updating versions as it probably will not get fixed for 2.1.4. > Console runs in unhandled exception when user starts module with unresolved > dependencies > > > Key: GERONIMO-4076 > URL: https://issues.apache.org/jira/browse/GERONIMO-4076 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1, 2.1.4 >Reporter: Daniel > Fix For: 2.2 > > > 1.) The console/web GUI does not explicitly warn the user when he is about to > delete a module which other modules depend upon. [Improvement?] > (Note: the server does then remove the module properly, and all dependent > modules are stopped.) > 2.) When the screen is reloaded, the depending modules are displayed as > stopped, but not as "missing dependencies". [Improvement?] > 3.) When the user now attempts to restart one of these modules, the request > leads to an unhandled exception. The GUI doesn't show up at all. Instead, an > error code 500 is displayed (=> > org.apache.geronimo.console.configmanager.ConfigManagerPortlet.processAction). >[BUG] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3875) Enabling authentication for Derby renders DB Viewer portlet unusable for all db's except SystemDatabase
[
https://issues.apache.org/jira/browse/GERONIMO-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor updated GERONIMO-3875:
--
Affects Version/s: 2.1.4
Fix Version/s: (was: 2.1.4)
Updating versions as it probably will not get fixed for 2.1.4.
> Enabling authentication for Derby renders DB Viewer portlet unusable for all
> db's except SystemDatabase
> ---
>
> Key: GERONIMO-3875
> URL: https://issues.apache.org/jira/browse/GERONIMO-3875
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: console
>Affects Versions: 2.1, 2.1.1, 2.1.3, 2.1.4, 2.2
> Environment: Win XP, G 2.1 Tomcat
>Reporter: Vamsavardhana Reddy
>Assignee: Donald Woods
> Fix For: 2.2
>
> Attachments: GERONIMO-3875.patch
>
>
> After enabling authentication for Derby, I am noticing that DB Viewer
> portlet is unable to work with any database other that SystemDatabase.
> listTables.jsp has the following code:
> {code}
> <%-- Datasource --%>
>
> <%-- Create the connection manually --%>
>var="ds"
> driver="org.apache.derby.jdbc.EmbeddedDriver"
> url="jdbc:derby:${db};create=true"
> user=""
> password=""
> />
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3815) ContextManager.getCurrentContext() throws NullPointerException
[ https://issues.apache.org/jira/browse/GERONIMO-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3815: -- Affects Version/s: 2.1.4 2.0.3 Fix Version/s: (was: 2.0.4) (was: 2.1.4) Updating versions as it probably will not get fixed for 2.1.4. > ContextManager.getCurrentContext() throws NullPointerException > -- > > Key: GERONIMO-3815 > URL: https://issues.apache.org/jira/browse/GERONIMO-3815 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.0.2, 2.0.3, 2.1, 2.1.4 >Reporter: Vamsavardhana Reddy > Fix For: 2.2 > > Attachments: GERONIMO-3815-2.debug.patch, > GERONIMO-3815-3.debug.patch, GERONIMO-3815.debug.patch > > > ContextManager.getCurrentContext() is throwing a NullPointerException. This > is observed only when there is heavy load on the application. Most likely it > is a threading issue where one thread is unregistering the subject while > another is executing getCurrentContext(). Excerpt from stacktrace given > below. > > Caused by: java.lang.NullPointerException > at > org.apache.geronimo.security.ContextManager.getCurrentContext(ContextManager.java:197) > at > org.apache.geronimo.openejb.GeronimoSecurityService.isCallerAuthorized(GeronimoSecurityService.java:101) > at > org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:142) > at > org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(EjbHomeProxyHandler.java:267) > at > org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:158) > at > org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) > at > org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) > at $Proxy16.create(Unknown Source) > ... 53 more > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4305) PortletException with Redeploy application checked for non existent application
[ https://issues.apache.org/jira/browse/GERONIMO-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4305: -- Affects Version/s: 2.1.4 Fix Version/s: (was: 2.1.4) Updating versions as it probably will not get fixed for 2.1.4. > PortletException with Redeploy application checked for non existent > application > --- > > Key: GERONIMO-4305 > URL: https://issues.apache.org/jira/browse/GERONIMO-4305 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.1.3, 2.1.4 >Reporter: Jürgen Weber >Priority: Minor > Fix For: 2.2 > > > If you deploy an application, have "Redeploy application" checked, but the > application does not exist, there is a PortletException. > This does not look very professional, Geronimo should instead handle > gracefully the situation. > HTTP ERROR: 500 > INTERNAL_SERVER_ERROR > RequestURI=/console/portal//Applications/Deploy%20New/__ac0x3plugin0x2Deployment!227983155|0 > Caused by: > javax.portlet.PortletException > at > org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:224) > Caused by: javax.portlet.PortletException: jWhichJSP does not appear to be a > the name of a module available on the selected server. Perhaps it has already > been stopped or undeployed? If you're trying to specify a TargetModuleID, > use the syntax TargetName|ModuleName instead. If you're not sure what's > running, try the list-modules command. > at > org.apache.geronimo.console.configmanager.DeploymentPortlet.identifyTargets(DeploymentPortlet.java:254) > at > org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:142) > ... 57 more > Caused by: org.apache.geronimo.common.DeploymentException: jWhichJSP does not > appear to be a the name of a module available on the selected server. Perhaps > it has already been stopped or undeployed? If you're trying to specify a > TargetModuleID, use the syntax TargetName|ModuleName instead. If you're not > sure what's running, try the list-modules command. > at > org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:205) > at > org.apache.geronimo.console.configmanager.DeploymentPortlet.identifyTargets(DeploymentPortlet.java:242) > ... 58 more > Nested Exception is javax.portlet.PortletException: jWhichJSP does not appear > to be a the name of a module available on the selected server. Perhaps it has > already been stopped or undeployed? If you're trying to specify a > TargetModuleID, use the syntax TargetName|ModuleName instead. If you're not > sure what's running, try the list-modules command. > at > org.apache.geronimo.console.configmanager.DeploymentPortlet.identifyTargets(DeploymentPortlet.java:254) > at > org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:142) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3942) IllegalStateException warning message for Jetty plugin installer
[ https://issues.apache.org/jira/browse/GERONIMO-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3942: -- Affects Version/s: 2.1.4 Fix Version/s: (was: 2.1.4) Updating versions as it probably will not get fixed for 2.1.4. > IllegalStateException warning message for Jetty plugin installer > > > Key: GERONIMO-3942 > URL: https://issues.apache.org/jira/browse/GERONIMO-3942 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 > Environment: Ubuntu 7.10, Firefox >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > Fix For: 2.2 > > > When installing plugins via the admin console (on Jetty) , at times an > IllegalStateException Warning Message Occurs. Otherwise, everything appears > to look and work fine functionality wise. > StackTrace Example: > java.lang.IllegalStateException: Committed > at org.mortbay.jetty.Response.resetBuffer(Response.java:995) > at org.mortbay.jetty.Response.sendRedirect(Response.java:403) > at > org.mortbay.jetty.security.FormAuthenticator.authenticate(FormAuthenticator.java:257) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.checkSecurityConstraints(JettySecurityHandler.java:216) > at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:191) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:114) > at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101(TwistyWebAppContext.java:40) > at > org.apache.geronimo.jetty6.handler.TwistyWebAppContext$TwistyHandler.handle(TwistyWebAppContext.java:65) > at > org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) > at > org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:58) > at > org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48) > at > org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) > at > org.apache.geronimo.jetty6.handler.TwistyWebAppContext.handle(TwistyWebAppContext.java:59) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:324) > at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:374) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4124) Tomcat jacc usage is messed up
[ https://issues.apache.org/jira/browse/GERONIMO-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4124: -- Affects Version/s: 2.1.4 Fix Version/s: (was: 2.1.4) Updating versions as it probably will not get fixed for 2.1.4. > Tomcat jacc usage is messed up > -- > > Key: GERONIMO-4124 > URL: https://issues.apache.org/jira/browse/GERONIMO-4124 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat >Affects Versions: 2.0.2, 2.1.1, 2.1.4, 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.2 > > > Several problems: > 1. UserDataPermissions are not getting evaluated by jacc due to the check for > Subject in handler data. > 2. Subject is never set into handler data (also a problem in jetty, dunno > about openejb). > 3. TomcatGeronimoRealm is calling ContextManager.setCallers before permission > checks. This is wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r740002 - in /geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2: ./ geronimo-connector/pom.xml geronimo-transaction/pom.xml pom.xml
Ok, I thought it would not be long before I can start a vote on this. I'll revert this in case someone else wants to work on the txmanager 2.1.2 branch. Lin On Wed, Feb 4, 2009 at 11:25 AM, Kevan Miller wrote: > > On Feb 2, 2009, at 10:25 AM, lin...@apache.org wrote: > > Author: linsun > Date: Mon Feb 2 15:25:54 2009 > New Revision: 740002 > > URL: http://svn.apache.org/viewvc?rev=740002&view=rev > Log: > [maven-release-plugin] copy for tag geronimo-txmanager-parent-2.1.2 > > Added: >geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/ > - copied from r739997, > geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1/ > > geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/geronimo-connector/pom.xml > - copied unchanged from r740001, > geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1/geronimo-connector/pom.xml > > geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/geronimo-transaction/pom.xml > - copied unchanged from r740001, > geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1/geronimo-transaction/pom.xml >geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/pom.xml > - copied unchanged from r740001, > geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1/pom.xml > > > Lin, > Unless you're starting up a vote, I wouldn't be creating this tag. If you > need to free up trunk for other development, you can create a > branches/geronimo-txmanager-2.1.2. > --kevan
[jira] Updated: (GERONIMO-4443) car-maven-plugin does not support the obsoletes attribute for plugins
[ https://issues.apache.org/jira/browse/GERONIMO-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4443: -- Affects Version/s: 2.1.4 Fix Version/s: (was: 2.1.4) > car-maven-plugin does not support the obsoletes attribute for plugins > - > > Key: GERONIMO-4443 > URL: https://issues.apache.org/jira/browse/GERONIMO-4443 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.1.3, 2.1.4 >Reporter: Donald Woods > Fix For: 2.2 > > > In 2.0, we could provide a attribute in the geronimo-plugins.xml > to specify that a given plugin replaces other plugins. > When using the c-m-p from 2.1.3, neither of the following in pom.xml work as > expected - > > > > org.apache.geronimo.daytrader/daytrader//car > > > > > > org.apache.geronimo.daytrader/daytrader//car > > > as either becomes the following in the generated META-INF/geronimo-plugins.xml > > See daytrader/branches/2.1.3/daytrader-tomcat/pom.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4443) car-maven-plugin does not support the obsoletes attribute for plugins
[ https://issues.apache.org/jira/browse/GERONIMO-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4443: -- Updating versions as it probably will not get fixed for 2.1.4. > car-maven-plugin does not support the obsoletes attribute for plugins > - > > Key: GERONIMO-4443 > URL: https://issues.apache.org/jira/browse/GERONIMO-4443 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.1.3, 2.1.4 >Reporter: Donald Woods > Fix For: 2.2 > > > In 2.0, we could provide a attribute in the geronimo-plugins.xml > to specify that a given plugin replaces other plugins. > When using the c-m-p from 2.1.3, neither of the following in pom.xml work as > expected - > > > > org.apache.geronimo.daytrader/daytrader//car > > > > > > org.apache.geronimo.daytrader/daytrader//car > > > as either becomes the following in the generated META-INF/geronimo-plugins.xml > > See daytrader/branches/2.1.3/daytrader-tomcat/pom.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r740002 - in /geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2: ./ geronimo-connector/pom.xml geronimo-transaction/pom.xml pom.xml
On Feb 2, 2009, at 10:25 AM, lin...@apache.org wrote: Author: linsun Date: Mon Feb 2 15:25:54 2009 New Revision: 740002 URL: http://svn.apache.org/viewvc?rev=740002&view=rev Log: [maven-release-plugin] copy for tag geronimo-txmanager-parent-2.1.2 Added: geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/ - copied from r739997, geronimo/components/txmanager/branches/ geronimo-txmanager-parent-2.1/ geronimo/components/txmanager/tags/geronimo-txmanager- parent-2.1.2/geronimo-connector/pom.xml - copied unchanged from r740001, geronimo/components/txmanager/ branches/geronimo-txmanager-parent-2.1/geronimo-connector/pom.xml geronimo/components/txmanager/tags/geronimo-txmanager- parent-2.1.2/geronimo-transaction/pom.xml - copied unchanged from r740001, geronimo/components/txmanager/ branches/geronimo-txmanager-parent-2.1/geronimo-transaction/pom.xml geronimo/components/txmanager/tags/geronimo-txmanager- parent-2.1.2/pom.xml - copied unchanged from r740001, geronimo/components/txmanager/ branches/geronimo-txmanager-parent-2.1/pom.xml Lin, Unless you're starting up a vote, I wouldn't be creating this tag. If you need to free up trunk for other development, you can create a branches/geronimo-txmanager-2.1.2. --kevan
[jira] Updated: (GERONIMO-3599) Unable to create new JMS Resource group through console in IE7
[ https://issues.apache.org/jira/browse/GERONIMO-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3599: -- Affects Version/s: 2.1.4 Fix Version/s: (was: 2.1.4) > Unable to create new JMS Resource group through console in IE7 > -- > > Key: GERONIMO-3599 > URL: https://issues.apache.org/jira/browse/GERONIMO-3599 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0.1, 2.1.4 > Environment: WIN XP >Reporter: Anish Pathadan >Assignee: Donald Woods > Fix For: 2.2 > > Attachments: GERONIMO-3599-better.patch, GERONIMO-3599.patch > > > I am not able to create a new JMS Resouce group through console. I am getting > cannot display the page error after entering the Q name and physical name and > then pressing next. > The following is the url > http://localhost:8080/console/portal/services/services_jms/_ps_services_jms_row1_col1_p1/normal/_pm_services_jms_row1_col1_p1/view/_ac_services_jms_row1_col1_p1/AC/_st_services_jms_row1_col1_p1/normal/_md_services_jms_row1_col1_p1/view/_pid/services_jms_row1_col1_p1 > The problem only comes with Internet Explorer 7. > Best Regards, > Anish Pathadan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4506) switch to use txmanager 2.1.2-snapshot in geronimo server 2.1 branch
[ https://issues.apache.org/jira/browse/GERONIMO-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4506. --- Resolution: Fixed Fix Version/s: 2.2 resolved - see subversion commit tab > switch to use txmanager 2.1.2-snapshot in geronimo server 2.1 branch > > > Key: GERONIMO-4506 > URL: https://issues.apache.org/jira/browse/GERONIMO-4506 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > Attachments: G4506.patch > > > This patch prepares the geronimo server 2.1 branch to use the new txmanager > 2.1.2-snapshot. With this patch, I am able to build branch 2.1 successfully > with all of the testsuites passing. If there is no objection, I'd like to > commit this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4475) Improve JMS portlet for AMQ 5.3 Borker configuration
[
https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods reassigned GERONIMO-4475:
--
Assignee: Ivan (was: Donald Woods)
Ivan, did you run a full build including the testsuite with this patch?
I'm getting the following testsuite failure with the patch applied -
{noformat}
---
Test set: TestSuite
---
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.908 sec <<<
FAILURE!
sendRequests(org.apache.geronimo.testsuite.enterprise.jms.MessageSenderTest)
Time elapsed: 1.053 sec <<< FAILURE!
java.lang.Exception: did not receive message: 3
at
org.apache.geronimo.testsuite.enterprise.jms.MessageSenderTest.sendRequests(MessageSenderTest.java:74)
{noformat}
> Improve JMS portlet for AMQ 5.3 Borker configuration
>
>
> Key: GERONIMO-4475
> URL: https://issues.apache.org/jira/browse/GERONIMO-4475
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
>Affects Versions: 2.2
>Reporter: Ivan
>Assignee: Ivan
> Fix For: 2.2
>
> Attachments: G4475-activemq-broker-00.patch,
> G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch,
> G4475-geronimo-activemq.patch, G4475-geronimo-management.patch
>
>
> Currently in the administrator console, the users could not add another embed
> broker. Also, they could not edit the broker through administrator console.
> I list the features that I could see :
> 1. While creating the broker, let the use upload a configuration file.
> 2. While editing the broker, show a text area, so that the user could edit
> the spring XML file in it. Shall we give the user a more friendly interface,
> so that they do not need the edit the XML file directly. I am not sure how it
> should look like.
> 3. Update the connector port let, so that while creating a new connector,
> the user could specify the broker that it belongs to.
> Please help to give some comments !
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4511) Daytrader entity beans are not listed in the entity bean container of EJB server portlet
[ https://issues.apache.org/jira/browse/GERONIMO-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia closed GERONIMO-4511. - Resolution: Invalid Thank you Manu for clarifying, agree your comments and close this jira. > Daytrader entity beans are not listed in the entity bean container of EJB > server portlet > > > Key: GERONIMO-4511 > URL: https://issues.apache.org/jira/browse/GERONIMO-4511 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: JDK 1.6 > Ubuntu 8.04 > Firefox 3.0.3 >Reporter: Forrest Xia >Assignee: Forrest Xia > > Deploy daytrader application to geronimo, and check if those entity beans are > listed there. Found out that there are no entity beans in there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Time for Geronimo 2.1.4 release?
Jay, Please run all tests including the integration tests before committing. Looks like deployment of some apps is failing after the recent changes, for example see: http://people.apache.org/builds/geronimo/server/binaries/2.0/20090204/logs-0200-tomcat/test.log Jarek On Wed, Feb 4, 2009 at 9:55 AM, Jay D. McHugh wrote: > All of the 2.0.3 build issues are fixed. > > I will try building 2.0.3 with XBeans 3.5 now and let you all know what > happens. > > If it will build, then I might take a look to see whether I can figure > out what changes are necessary for OpenEJB 3.0.1 to use XBeans 3.5 too. > > Jay > > Jay D. McHugh wrote: >> The problem is with the version of ASM that is brought in when using a >> higher version of XBeans. >> >> OpenEJB is using a method that has been removed: >> org.objectweb.asm.ClassReader.accept >> >> And Geronimo (already - not counting XBeans 3.5) is using classes that >> have been removed: >> LinkResolver >> UniqueDefaultLinkResolver >> >> Jay >> >> Joe Bohn wrote: >>> Thanks for the info Jay and for doing some more digging. >>> >>> I don't really have a strong desire to push everything to xBean 3.5. I >>> was just trying to eliminate the use of multiple xBean versions as this >>> could potentially cause problems (and confusion) for our users. >>> >>> It looks like we originally moved up to xBean 3.5 (actually >>> 3.5-SNAPSHOT) to resolve a jca context issue (Geronimo-4375). However, >>> it looks like it was soon discovered that there were issues with the >>> OpenEJB, ASM and xBean versions in G. As a result ... we ended up >>> reverting back to an older ASM and xBean 3.3 for finder and reflect >>> while keeping the newer xbean-naming 3.5 so that the original issue was >>> still resolved. That seems to be working and is perhaps the best >>> approach. I was just concerned about using the various xBean versions >>> in our Geronimo 2.1.4 server. Perhaps using the various xBean versions >>> is still the best thing to do here. I didn't realize that there were >>> core issues in OpenEJB attempting to use anything greater than 3.4.1. >>> >>> Thanks, >>> Joe >>> >>> >>> Jay D. McHugh wrote: >>>> Hey everyone, >>>> >>>> If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think >>>> that we'll need to chip in to resolve the problems that pop up when you >>>> use a version greater than 3.4.1. >>>> >>>> That was the highest version (available at the time) that could be used >>>> in the OpenEJB 3.0 branch without causing errors. >>>> >>>> I'll try switching to XBeans 3.5 (after the build I am in the middle of >>>> finishes) and let you all know if it goes through cleanly. >>>> >>>> My feeling is that it won't though. >>>> >>>> Also, I have been trying to get a 'final' Geronimo 2.0.x release put >>>> together and will need OpenEJB 3.0.1 for that (3.0 no longer builds >>>> because the artifacts for XBeans changed groupIds). >>>> >>>> Jay >>>> >>>> Joe Bohn wrote: >>>>> I was relaying the information second-hand ... so it's very possible I >>>>> got it wrong. >>>>> >>>>> It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 >>>>> rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can >>>>> convince OpenEJB 3.0.x to xBean 3.5 we can then make the references >>>>> consistent in our 2.1 branch. >>>>> >>>>> Thanks, >>>>> Joe >>>>> >>>>> >>>>> Donald Woods wrote: >>>>>> I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. >>>>>> Maybe you're thinking about OpenEJB? >>>>>> >>>>>> >>>>>> -Donald >>>>>> >>>>>> >>>>>> Joe Bohn wrote: >>>>>>> I agree we should get a 2.1.4 release out ... and you certainly have >>>>>>> my vote for release manager! >>>>>>> >>>>>>> The only thing I would add to the list is to get our xBean references >>>>>>> to a consistent versions. I noticed this as I was updating >>>>>>> branches/2.1 and trunk to pull in the newly relea
[BUILD] trunk: Failed for Revision: 740725
Geronimo Revision: 740725 built with tests included
See the full build-0900.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090204/build-0900.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090204
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 39 minutes 5 seconds
[INFO] Finished at: Wed Feb 04 09:47:36 EST 2009
[INFO] Final Memory: 393M/1001M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090204/logs-0900-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:43.663
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:12.643)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:30.287)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:35.998)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:15.949)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:20.345)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:23.259)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:46.806)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:43.776)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:59.384)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:39.225)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:29.986)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:28.286)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:30.745)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:45.795)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests FAILURE (0:00:40.945) Java
returned: 1
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:01:07.208)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.128)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:47.951)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security SUCCESS (0:00:42.031)
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:29.322)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5
Re: Time for Geronimo 2.1.4 release?
All of the 2.0.3 build issues are fixed. I will try building 2.0.3 with XBeans 3.5 now and let you all know what happens. If it will build, then I might take a look to see whether I can figure out what changes are necessary for OpenEJB 3.0.1 to use XBeans 3.5 too. Jay Jay D. McHugh wrote: > The problem is with the version of ASM that is brought in when using a > higher version of XBeans. > > OpenEJB is using a method that has been removed: > org.objectweb.asm.ClassReader.accept > > And Geronimo (already - not counting XBeans 3.5) is using classes that > have been removed: > LinkResolver > UniqueDefaultLinkResolver > > Jay > > Joe Bohn wrote: >> Thanks for the info Jay and for doing some more digging. >> >> I don't really have a strong desire to push everything to xBean 3.5. I >> was just trying to eliminate the use of multiple xBean versions as this >> could potentially cause problems (and confusion) for our users. >> >> It looks like we originally moved up to xBean 3.5 (actually >> 3.5-SNAPSHOT) to resolve a jca context issue (Geronimo-4375). However, >> it looks like it was soon discovered that there were issues with the >> OpenEJB, ASM and xBean versions in G. As a result ... we ended up >> reverting back to an older ASM and xBean 3.3 for finder and reflect >> while keeping the newer xbean-naming 3.5 so that the original issue was >> still resolved. That seems to be working and is perhaps the best >> approach. I was just concerned about using the various xBean versions >> in our Geronimo 2.1.4 server. Perhaps using the various xBean versions >> is still the best thing to do here. I didn't realize that there were >> core issues in OpenEJB attempting to use anything greater than 3.4.1. >> >> Thanks, >> Joe >> >> >> Jay D. McHugh wrote: >>> Hey everyone, >>> >>> If we want to get OpenEJB 3.0.1 to move up to XBeans 3.5, then I think >>> that we'll need to chip in to resolve the problems that pop up when you >>> use a version greater than 3.4.1. >>> >>> That was the highest version (available at the time) that could be used >>> in the OpenEJB 3.0 branch without causing errors. >>> >>> I'll try switching to XBeans 3.5 (after the build I am in the middle of >>> finishes) and let you all know if it goes through cleanly. >>> >>> My feeling is that it won't though. >>> >>> Also, I have been trying to get a 'final' Geronimo 2.0.x release put >>> together and will need OpenEJB 3.0.1 for that (3.0 no longer builds >>> because the artifacts for XBeans changed groupIds). >>> >>> Jay >>> >>> Joe Bohn wrote: I was relaying the information second-hand ... so it's very possible I got it wrong. It looks like there is a dependency xBean in OpenEJB ... but it's 3.4.1 rather than 3.3 (as we have in the branches/2.1). So, perhaps if we can convince OpenEJB 3.0.x to xBean 3.5 we can then make the references consistent in our 2.1 branch. Thanks, Joe Donald Woods wrote: > I don't see any dependencies on Xbean in OpenJPA 1.0.x or 1.2.x. > Maybe you're thinking about OpenEJB? > > > -Donald > > > Joe Bohn wrote: >> I agree we should get a 2.1.4 release out ... and you certainly have >> my vote for release manager! >> >> The only thing I would add to the list is to get our xBean references >> to a consistent versions. I noticed this as I was updating >> branches/2.1 and trunk to pull in the newly released xBean 3.5. In >> branches/2.1 we have a mix of 3.3 dependencies (finder and reflect) >> and 3.5 dependencies (naming). I've been told that this was due to >> OpenJPA dependencies on 3.3. Now that we are pulling in a new >> OpenJPA release we will hopefully be able to update everything to use >> xBean 3.5. >> >> Joe >> >> >> Jarek Gawor wrote: >>> Hi, >>> >>> I think it's time for Geronimo 2.1.4 release. We've had a lot of >>> important fixes since 2.1.3 and we should get them out to our users. >>> And if we agree, I would also like to volunteer to be a release >>> manager for this release. >>> >>> Looking at the current status for 2.1.4 there are still a few things >>> that we need to do before we can go ahead with the release. I updated >>> the >>> http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status >>> >>> >>> page with some of these items. If there are any open bugs that _need_ >>> to be fixed for 2.1.4 or if I missed anything in that list please >>> just >>> update that wiki page. >>> >>> Thanks, >>> Jarek >>>
[jira] Reopened: (GERONIMO-4475) Improve JMS portlet for AMQ 5.3 Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reopened GERONIMO-4475: Another minor update from Ivan to apply. > Improve JMS portlet for AMQ 5.3 Borker configuration > > > Key: GERONIMO-4475 > URL: https://issues.apache.org/jira/browse/GERONIMO-4475 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Ivan >Assignee: Donald Woods > Fix For: 2.2 > > Attachments: G4475-activemq-broker-00.patch, > G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch, > G4475-geronimo-activemq.patch, G4475-geronimo-management.patch > > > Currently in the administrator console, the users could not add another embed > broker. Also, they could not edit the broker through administrator console. > I list the features that I could see : > 1. While creating the broker, let the use upload a configuration file. > 2. While editing the broker, show a text area, so that the user could edit > the spring XML file in it. Shall we give the user a more friendly interface, > so that they do not need the edit the XML file directly. I am not sure how it > should look like. > 3. Update the connector port let, so that while creating a new connector, > the user could specify the broker that it belongs to. > Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4475) Improve JMS portlet for AMQ 5.3 Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670338#action_12670338 ] Donald Woods commented on GERONIMO-4475: OK, testing out the patch now. > Improve JMS portlet for AMQ 5.3 Borker configuration > > > Key: GERONIMO-4475 > URL: https://issues.apache.org/jira/browse/GERONIMO-4475 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Ivan >Assignee: Donald Woods > Fix For: 2.2 > > Attachments: G4475-activemq-broker-00.patch, > G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch, > G4475-geronimo-activemq.patch, G4475-geronimo-management.patch > > > Currently in the administrator console, the users could not add another embed > broker. Also, they could not edit the broker through administrator console. > I list the features that I could see : > 1. While creating the broker, let the use upload a configuration file. > 2. While editing the broker, show a text area, so that the user could edit > the spring XML file in it. Shall we give the user a more friendly interface, > so that they do not need the edit the XML file directly. I am not sure how it > should look like. > 3. Update the connector port let, so that while creating a new connector, > the user could specify the broker that it belongs to. > Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Time for Geronimo 2.1.4 release?
+1 Thanks Manu On Wed, Feb 4, 2009 at 1:13 AM, Jarek Gawor wrote: > Hi, > > I think it's time for Geronimo 2.1.4 release. We've had a lot of > important fixes since 2.1.3 and we should get them out to our users. > And if we agree, I would also like to volunteer to be a release > manager for this release. > > Looking at the current status for 2.1.4 there are still a few things > that we need to do before we can go ahead with the release. I updated > the > http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status > page with some of these items. If there are any open bugs that _need_ > to be fixed for 2.1.4 or if I missed anything in that list please just > update that wiki page. > > Thanks, > Jarek >
[jira] Assigned: (GERONIMO-4509) Two EJB server portlet issues
[ https://issues.apache.org/jira/browse/GERONIMO-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manu T George reassigned GERONIMO-4509: --- Assignee: Forrest Xia (was: Manu T George) > Two EJB server portlet issues > - > > Key: GERONIMO-4509 > URL: https://issues.apache.org/jira/browse/GERONIMO-4509 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: JDK 1.6 > Ubuntu 8.04 > AG 2.2 snapshot 20090110 >Reporter: Forrest Xia >Assignee: Forrest Xia > > For the new EJB server portlet, there are these problems: > 1. Message prompt just restarting openejb module cause several console > exceptions and EJB server portlet disappear in admin console at next time > restart server. > Steps: > 1.1 Change value of a EJB container parameter, then it prompts OpenEJB module > should be restarted for effectiveness. So I use expert mode to restart module > org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car, confirm restart, then > several exceptions are thrown out as following: > 2009-01-14 09:35:45,546 ERROR [ConfigManagerPortlet] Exception > java.lang.IllegalStateException: Configuration > org.apache.geronimo.configs/axis2-ejb/2.2-SNAPSHOT/car still has children > at > org.apache.geronimo.kernel.config.ConfigurationStatus.destroy(ConfigurationStatus.java:69) > at > org.apache.geronimo.kernel.config.ConfigurationModel.removeConfiguration(ConfigurationModel.java:65) > ... > 2009-01-14 09:35:45,965 ERROR [[SystemModules]] Servlet.service() for servlet > SystemModules threw exception > java.lang.NullPointerException > at > org.apache.geronimo.console.configmanager.ConfigManagerPortlet.getConfigurationState(ConfigManagerPortlet.java:325) > at > org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:272) > ... > 2009-01-14 09:37:08,300 ERROR [[SystemModules]] Servlet.service() for servlet > SystemModules threw exception > java.lang.IllegalStateException: Configuration > org.apache.geronimo.configs/jaxws-ejb-deployer/2.2-SNAPSHOT/car still has > children > at > org.apache.geronimo.kernel.config.ConfigurationStatus.destroy(ConfigurationStatus.java:69) > at > org.apache.geronimo.kernel.config.ConfigurationModel.removeConfiguration(ConfigurationModel.java:65) > ... > 2009-01-14 09:37:19,125 ERROR [[SystemModules]] Servlet.service() for servlet > SystemModules threw exception > java.lang.IllegalStateException: Configuration > org.apache.geronimo.configs/openejb-deployer/2.2-SNAPSHOT/car still has > children > at > org.apache.geronimo.kernel.config.ConfigurationStatus.destroy(ConfigurationStatus.java:69) > at > org.apache.geronimo.kernel.config.ConfigurationModel.removeConfiguration(ConfigurationModel.java:65) > ... > Anyway, the openejb module finally restarted, but no children modules appear > anymore. Consequently the EJB server portlet disappears from the admin > console. No way to check if the changed parameter takes effect. > 2.2 Followed by step 1, restart geronimo by no change of config.xml, still > the EJB server portlet is not there. Then check the config.xml, the portlet > module name="org.apache.geronimo.plugins/openejb-console-tomcat/2.2-SNAPSHOT/car"/> > is load=false > Based on the symptom, I think it might be better to suggest user to restart > geronimo server as a whole, not just openejb module. > 2. Another issue is the parameter value seems be changed only once. For > example, if you changed strictpooling from default true to false, then you > want to change it back without restarting server, there is no way. This > behavior is better to be improved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4511) Daytrader entity beans are not listed in the entity bean container of EJB server portlet
[ https://issues.apache.org/jira/browse/GERONIMO-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manu T George reassigned GERONIMO-4511: --- Assignee: Forrest Xia (was: Manu T George) > Daytrader entity beans are not listed in the entity bean container of EJB > server portlet > > > Key: GERONIMO-4511 > URL: https://issues.apache.org/jira/browse/GERONIMO-4511 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: JDK 1.6 > Ubuntu 8.04 > Firefox 3.0.3 >Reporter: Forrest Xia >Assignee: Forrest Xia > > Deploy daytrader application to geronimo, and check if those entity beans are > listed there. Found out that there are no entity beans in there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4511) Daytrader entity beans are not listed in the entity bean container of EJB server portlet
[ https://issues.apache.org/jira/browse/GERONIMO-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670320#action_12670320 ] Manu T George commented on GERONIMO-4511: - Daytrader 1.1 has entity beans which can be used to test this. The latest versions have JPA entities and not entity beans. If you feel that the ejb container portlet should show jpa entities please open a feature request. > Daytrader entity beans are not listed in the entity bean container of EJB > server portlet > > > Key: GERONIMO-4511 > URL: https://issues.apache.org/jira/browse/GERONIMO-4511 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: JDK 1.6 > Ubuntu 8.04 > Firefox 3.0.3 >Reporter: Forrest Xia >Assignee: Manu T George > > Deploy daytrader application to geronimo, and check if those entity beans are > listed there. Found out that there are no entity beans in there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4511) Daytrader entity beans are not listed in the entity bean container of EJB server portlet
[ https://issues.apache.org/jira/browse/GERONIMO-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670319#action_12670319 ] Manu T George commented on GERONIMO-4511: - Tried with daytrader 1.1 and it works as expected > Daytrader entity beans are not listed in the entity bean container of EJB > server portlet > > > Key: GERONIMO-4511 > URL: https://issues.apache.org/jira/browse/GERONIMO-4511 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: JDK 1.6 > Ubuntu 8.04 > Firefox 3.0.3 >Reporter: Forrest Xia >Assignee: Manu T George > > Deploy daytrader application to geronimo, and check if those entity beans are > listed there. Found out that there are no entity beans in there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4511) Daytrader entity beans are not listed in the entity bean container of EJB server portlet
[ https://issues.apache.org/jira/browse/GERONIMO-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670318#action_12670318 ] Manu T George commented on GERONIMO-4511: - There are no entity beans in Daytrader as far as I know. There are only JPA entities. These entities are actually not entity beans and they should probably be shown in an openjpa specific portlet. The EJB portlet only shows ejbs. Please verify this and close the issue. > Daytrader entity beans are not listed in the entity bean container of EJB > server portlet > > > Key: GERONIMO-4511 > URL: https://issues.apache.org/jira/browse/GERONIMO-4511 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: JDK 1.6 > Ubuntu 8.04 > Firefox 3.0.3 >Reporter: Forrest Xia >Assignee: Manu T George > > Deploy daytrader application to geronimo, and check if those entity beans are > listed there. Found out that there are no entity beans in there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSHELL] Timeframe ?
That should be fine. --jason On Feb 4, 2009, at 3:40 PM, Guillaume Nodet wrote: I've just build gshell using maven-project-2.1.0-M1 and it builds and starts correctly. Maybe we sould use that one instead ? or does r72 includes other mandatory fixes ? On Wed, Feb 4, 2009 at 09:07, Jason Dillon wrote: maven-project-2.1.0-r72 is on the nexus instance on our zone, but looks like its not running, not sure why... will take a look in a bit. --jason On Feb 4, 2009, at 2:47 PM, Guillaume Nodet wrote: Done. I still have a problem with the dependency on maven-project-2.1.0-r72 which I can't found anymore. I will try to upgrade to 3.0-alpha-1 and see what it gives. On Wed, Feb 4, 2009 at 04:47, Jason Dillon wrote: Yes, go ahead. --jason On Feb 4, 2009, at 3:04 AM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel before this month. Do you want me to roll back to genesis 1.6 ? On Mon, Jan 12, 2009 at 06:14, Jason Dillon wrote: Well, I think its mostly Genesis 2.0 that is causing the lag on GShell's release. I'm going to see about fixing that this week, otherwise rolling back to the Genesis 1.6 stuff for the alpha-2. --jason On Jan 7, 2009, at 5:52 PM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel in the near future. What are the missing bits to release GShell soon ? On Fri, Oct 17, 2008 at 08:25, Jason Dillon > wrote: The GShell APIs are getting closer and closer to stability. The major changes have all been committed, and I don't have any plans to make any other significant changes to the core APIs. What I am doing now is trying to slim down the core dependencies and speed up the boot time... and sorting out some of the many HACK/TODO comments which I've littered the codebase with. As for an alpha-2 release, I imagine that will be on the horizon soon. I don't plan on having all of the little things fixed before that, though I hope to sort out a few of the more significant ones before releasing. If I had to guess I'd say that the codebase should be in a position to be released in 2-4 weeks at present change velocity. --jason On Oct 16, 2008, at 2:23 PM, Guillaume Nodet wrote: In ServiceMix, we are considering upgrading to the latest trunk of GShell and I've already done the bigger part of the upgrade locally on my HD. Btw, I've committed a few small changes for that yesterday. However, I'm worried about the stability of gshell. We currently use an old and unreleased version of gshell, but I'd like to avoid such issue and having to rewrite this integration once more. Jason, what's your feeling about gshell's stability (in terms of APIs) and a possible ETA for a new release (be it alpha-2 or whatever) ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: js-localization-openejb.patch patch for openejb > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-console.patch, > js-localization-core.patch, js-localization-openejb.patch, > js-localization-sysdb.patch, screenshot-1.jpg, screenshot-2.jpg, > screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: js-localization-sysdb.patch patch for sysdb > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-console.patch, > js-localization-core.patch, js-localization-sysdb.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: js-localization-console.patch patch for console-base > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-console.patch, > js-localization-core.patch, screenshot-1.jpg, screenshot-2.jpg, > screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670285#action_12670285 ] Gang Yin commented on GERONIMO-4517: hi, Donald I have updated my patches, please help to review and commit them, thanks. I have localized all the javascript messages and adapted the messages in alert boxes to use the same style used to display backend messages. and I used dojo dialogs to replace the confirm boxes whose user experience is not so good. I have submitted the screenshots of both kinds of javascript messages. > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: screenshot-1.jpg > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: screenshot-3.jpg > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: screenshot-2.jpg > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: (was: screenshot-2.jpg) > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: (was: js-localization-logmanager.patch) > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: (was: screenshot-1.jpg) > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: (was: js-localization-core_v2.patch) > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: (was: js-localization-sysdb.patch) > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: (was: js-localization-openejb.patch) > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-core.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4475) Improve JMS portlet for AMQ 5.3 Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4475: --- Attachment: G4475-activemq-broker-00.patch A slight modification about the activemq.xml file, specify a location for temp folder for the broker. Please help to review it ! > Improve JMS portlet for AMQ 5.3 Borker configuration > > > Key: GERONIMO-4475 > URL: https://issues.apache.org/jira/browse/GERONIMO-4475 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Ivan >Assignee: Donald Woods > Fix For: 2.2 > > Attachments: G4475-activemq-broker-00.patch, > G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch, > G4475-geronimo-activemq.patch, G4475-geronimo-management.patch > > > Currently in the administrator console, the users could not add another embed > broker. Also, they could not edit the broker through administrator console. > I list the features that I could see : > 1. While creating the broker, let the use upload a configuration file. > 2. While editing the broker, show a text area, so that the user could edit > the spring XML file in it. Shall we give the user a more friendly interface, > so that they do not need the edit the XML file directly. I am not sure how it > should look like. > 3. Update the connector port let, so that while creating a new connector, > the user could specify the broker that it belongs to. > Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSHELL] Timeframe ?
I've just build gshell using maven-project-2.1.0-M1 and it builds and starts correctly. Maybe we sould use that one instead ? or does r72 includes other mandatory fixes ? On Wed, Feb 4, 2009 at 09:07, Jason Dillon wrote: > maven-project-2.1.0-r72 is on the nexus instance on our zone, but looks > like its not running, not sure why... will take a look in a bit. > > --jason > > > On Feb 4, 2009, at 2:47 PM, Guillaume Nodet wrote: > >> Done. I still have a problem with the dependency on >> maven-project-2.1.0-r72 which I can't found anymore. >> I will try to upgrade to 3.0-alpha-1 and see what it gives. >> >> On Wed, Feb 4, 2009 at 04:47, Jason Dillon wrote: >>> >>> Yes, go ahead. >>> >>> --jason >>> >>> >>> On Feb 4, 2009, at 3:04 AM, Guillaume Nodet wrote: >>> We are planning a release of ServiceMix Kernel before this month. Do you want me to roll back to genesis 1.6 ? On Mon, Jan 12, 2009 at 06:14, Jason Dillon wrote: > > Well, I think its mostly Genesis 2.0 that is causing the lag on > GShell's > release. I'm going to see about fixing that this week, otherwise > rolling > back to the Genesis 1.6 stuff for the alpha-2. > > --jason > > > On Jan 7, 2009, at 5:52 PM, Guillaume Nodet wrote: > >> We are planning a release of ServiceMix Kernel in the near future. >> What are the missing bits to release GShell soon ? >> >> On Fri, Oct 17, 2008 at 08:25, Jason Dillon >> wrote: >>> >>> The GShell APIs are getting closer and closer to stability. The >>> major >>> changes have all been committed, and I don't have any plans to make >>> any >>> other significant changes to the core APIs. What I am doing now is >>> trying >>> to slim down the core dependencies and speed up the boot time... and >>> sorting >>> out some of the many HACK/TODO comments which I've littered the >>> codebase >>> with. >>> >>> As for an alpha-2 release, I imagine that will be on the horizon >>> soon. >>> I >>> don't plan on having all of the little things fixed before that, >>> though >>> I >>> hope to sort out a few of the more significant ones before releasing. >>> If >>> I >>> had to guess I'd say that the codebase should be in a position to be >>> released in 2-4 weeks at present change velocity. >>> >>> --jason >>> >>> >>> On Oct 16, 2008, at 2:23 PM, Guillaume Nodet wrote: >>> In ServiceMix, we are considering upgrading to the latest trunk of GShell and I've already done the bigger part of the upgrade locally on my HD. Btw, I've committed a few small changes for that yesterday. However, I'm worried about the stability of gshell. We currently use an old and unreleased version of gshell, but I'd like to avoid such issue and having to rewrite this integration once more. Jason, what's your feeling about gshell's stability (in terms of APIs) and a possible ETA for a new release (be it alpha-2 or whatever) ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [GSHELL] Timeframe ?
maven-project-2.1.0-r72 is on the nexus instance on our zone, but looks like its not running, not sure why... will take a look in a bit. --jason On Feb 4, 2009, at 2:47 PM, Guillaume Nodet wrote: Done. I still have a problem with the dependency on maven-project-2.1.0-r72 which I can't found anymore. I will try to upgrade to 3.0-alpha-1 and see what it gives. On Wed, Feb 4, 2009 at 04:47, Jason Dillon wrote: Yes, go ahead. --jason On Feb 4, 2009, at 3:04 AM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel before this month. Do you want me to roll back to genesis 1.6 ? On Mon, Jan 12, 2009 at 06:14, Jason Dillon wrote: Well, I think its mostly Genesis 2.0 that is causing the lag on GShell's release. I'm going to see about fixing that this week, otherwise rolling back to the Genesis 1.6 stuff for the alpha-2. --jason On Jan 7, 2009, at 5:52 PM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel in the near future. What are the missing bits to release GShell soon ? On Fri, Oct 17, 2008 at 08:25, Jason Dillon > wrote: The GShell APIs are getting closer and closer to stability. The major changes have all been committed, and I don't have any plans to make any other significant changes to the core APIs. What I am doing now is trying to slim down the core dependencies and speed up the boot time... and sorting out some of the many HACK/TODO comments which I've littered the codebase with. As for an alpha-2 release, I imagine that will be on the horizon soon. I don't plan on having all of the little things fixed before that, though I hope to sort out a few of the more significant ones before releasing. If I had to guess I'd say that the codebase should be in a position to be released in 2-4 weeks at present change velocity. --jason On Oct 16, 2008, at 2:23 PM, Guillaume Nodet wrote: In ServiceMix, we are considering upgrading to the latest trunk of GShell and I've already done the bigger part of the upgrade locally on my HD. Btw, I've committed a few small changes for that yesterday. However, I'm worried about the stability of gshell. We currently use an old and unreleased version of gshell, but I'd like to avoid such issue and having to rewrite this integration once more. Jason, what's your feeling about gshell's stability (in terms of APIs) and a possible ETA for a new release (be it alpha-2 or whatever) ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
