[jira] Updated: (GERONIMO-4081) Accessibility issue: Webking scan errors against Check Web Accessibility(Section 508) rules
[ https://issues.apache.org/jira/browse/GERONIMO-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4081: --- Attachment: screenshot-1.jpg please see the errs in red line, the problems are from the files in repository\org\dojotoolkit\dojo-ajax\0.4.3\dojo-ajax-0.4.3.zip, whether or not should we modify the files in repository? Accessibility issue: Webking scan errors against Check Web Accessibility(Section 508) rules - Key: GERONIMO-4081 URL: https://issues.apache.org/jira/browse/GERONIMO-4081 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.1 Environment: Windows XP SP2, IE 6.0 Webking 5.5 Reporter: Xia Ming Attachments: screenshot-1.jpg, webking_scan_results.csv, webking_scan_results_src.csv Lots of instances are violated from the accessibility rules of section 508, see the attachment for details. thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 663842
Geronimo Revision: 663842 built with tests included
See the full build-0300.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080606/build-0300.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080606
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 31 minutes 53 seconds
[INFO] Finished at: Fri Jun 06 03:35:34 EDT 2008
[INFO] Final Memory: 384M/895M
[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/20080606/logs-0300-tomcat/test.log
Assembly: jetty
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080606/logs-0300-jetty/test.log
[INFO] [site:attach-descriptor]
[INFO] [selenium:start-server {execution: start}]
Launching Selenium Server
Waiting for Selenium Server...
[INFO] Including display properties from:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/display.properties
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/server.log
[INFO] User extensions:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/user-extensions.js
Selenium Server started
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: jetty
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-jetty6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty6-javaee5/2.2-SNAPSHOT/geronimo-jetty6-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:55.631
[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 27 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:01:34.298) Java
returned: 1
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:49.670)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:49.188)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:51.663)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:46.325)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:32.144)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:36.265)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:30.291)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00
[jira] Commented: (GERONIMO-3933) Getting an Exception while creating JMS deployment plan through console.
[ https://issues.apache.org/jira/browse/GERONIMO-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602968#action_12602968 ] Phani Balaji Madgula commented on GERONIMO-3933: Hi Kevan, Today, I was able successfully recreate the problem on both AG2.1 and AG2.1.1. The steps are as follows. 1. Click on Console Navigation == Services == JMS Resources 2. Click on For ActiveMQ link on JMS Resources portlet 3. Give a name in Resource Group Name textbox and click on the Next button 4. Click on the Add Connection Factory button 5. Select javax.jms.QueueConnectionFactory in the combo box and click on the Next button. 6. Give a name in Connection Factory Name textbox and click on the Next Button. 7. On the next screen click on the Add Destination button 8. Select javax.jms.Queue in the combo box and click on the next button. 9. Give a name in Message Destination Name and PhysicalName textboxes and click on the Next button. 10. You will get a message like Internet Explorer cannot display the webpage on the browser. 11. The URl we see on the browser window is ==. http://9.184.236.99:8080/console/portal//Services/JMS%20Resources/__ac0x3activemq0x2JMSWizard!1082939780%7C0/__pm0x3activemq0x2JMSWizard!1082939780%7C0_view I have tested this both with IE6 and IE7 on WinXP. Thanks Phani B Madgula Getting an Exception while creating JMS deployment plan through console. Key: GERONIMO-3933 URL: https://issues.apache.org/jira/browse/GERONIMO-3933 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Apache Geronimo 2.1 on WindowsXP with Mozilla FireFox Browser while using admin console Reporter: Phani Balaji Madgula Priority: Minor Fix For: 2.1.x, 2.2 Hi I am using AG2.1 for creating deploying a JMS resource plan using admin console. I am using WinXP SP2. First I tried to create the plan using IE 7 but hit the problem mentioned in the JIRA --GERONIMO-3599. Then I switched to FireFox and I was able to get past the error. However after adding a ConnectionFactory a Destination, when I click on the Show Deployment plan, I get the following error as below ** java.lang.IllegalArgumentException: can't parse argument number rarURL at java.text.MessageFormat.makeFormat(MessageFormat.java:1350) at java.text.MessageFormat.applyPattern(MessageFormat.java:470) at org.apache.taglibs.standard.tag.common.fmt.MessageSupport.doEndTag(MessageSupport.java:199) at jsp.WEB_002dINF.view.jmswizard.plan_jsp._jspx_meth_fmt_005fmessage_005f6(plan_jsp.java:673) at jsp.WEB_002dINF.view.jmswizard.plan_jsp._jspService(plan_jsp.java:169) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) at org.apache.pluto.internal.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:106) at org.apache.geronimo.console.MultiPagePortlet.doView(MultiPagePortlet.java:151) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at
[jira] Closed: (GERONIMO-3933) Getting an Exception while creating JMS deployment plan through console.
[ https://issues.apache.org/jira/browse/GERONIMO-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-3933. -- Resolution: Duplicate Doh... I must have been using Firefox... This is the POST length problem on IE (max length is 2084). See https://issues.apache.org/jira/browse/GERONIMO-3599 Getting an Exception while creating JMS deployment plan through console. Key: GERONIMO-3933 URL: https://issues.apache.org/jira/browse/GERONIMO-3933 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Apache Geronimo 2.1 on WindowsXP with Mozilla FireFox Browser while using admin console Reporter: Phani Balaji Madgula Priority: Minor Fix For: 2.1.x, 2.2 Hi I am using AG2.1 for creating deploying a JMS resource plan using admin console. I am using WinXP SP2. First I tried to create the plan using IE 7 but hit the problem mentioned in the JIRA --GERONIMO-3599. Then I switched to FireFox and I was able to get past the error. However after adding a ConnectionFactory a Destination, when I click on the Show Deployment plan, I get the following error as below ** java.lang.IllegalArgumentException: can't parse argument number rarURL at java.text.MessageFormat.makeFormat(MessageFormat.java:1350) at java.text.MessageFormat.applyPattern(MessageFormat.java:470) at org.apache.taglibs.standard.tag.common.fmt.MessageSupport.doEndTag(MessageSupport.java:199) at jsp.WEB_002dINF.view.jmswizard.plan_jsp._jspx_meth_fmt_005fmessage_005f6(plan_jsp.java:673) at jsp.WEB_002dINF.view.jmswizard.plan_jsp._jspService(plan_jsp.java:169) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) at org.apache.pluto.internal.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:106) at org.apache.geronimo.console.MultiPagePortlet.doView(MultiPagePortlet.java:151) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) at org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) at jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) at
[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 ] Kevan Miller updated GERONIMO-3599: --- Fix Version/s: 2.2 2.1.x 2.1.2 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 Environment: WIN XP Reporter: Anish Pathadan Assignee: Joseph Leong Fix For: 2.1.2, 2.1.x, 2.2 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.
Re: [CONF] Apache Geronimo v2.1: Convert your current applications into plugins (page created)
Why reproduce the Stateless Session Bean Tutorial here? Better to refer to it, then get to the important part -- how to create a plugin... --kevan
[jira] Closed: (GERONIMO-1553) Provide commonj Timer and Work Manager.
[ https://issues.apache.org/jira/browse/GERONIMO-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-1553. -- Resolution: Won't Fix See the recent Timer/Work Manager work (e.g. concurrency) in our Sandbox. This reflects the current Timer/Work Manager support being defined for JSR 236/237. I don't see us implementing the commonj spec. Provide commonj Timer and Work Manager. --- Key: GERONIMO-1553 URL: https://issues.apache.org/jira/browse/GERONIMO-1553 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: general Affects Versions: Wish List Environment: na Reporter: Seth White Assignee: Kevan Miller Attachments: commonj.jar, commonj_spec.jar, commonj_timer.jar It would be nice if Geronimo provided an implementation of the Timer and Work Manager APIs specified by commonj. More information on these features can be found here: http://dev2dev.bea.com/wlplatform/commonj/twm.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3930) IllegalArgumentException reading Transaction Log
[ https://issues.apache.org/jira/browse/GERONIMO-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-3930. -- Resolution: Fixed Assignee: Kevan Miller The tran logs cannot exceed 2 gigabytes in size. We were configuring the max size to be 32K * Integer.MAX_VALUE 32K byte buffers is pretty large. There'd be a lot of wasted space... 4K should be a reasonable value... The default max size is now 2 megs (4k buffers * 512). IllegalArgumentException reading Transaction Log Key: GERONIMO-3930 URL: https://issues.apache.org/jira/browse/GERONIMO-3930 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Kevan Miller Assignee: Kevan Miller Priority: Critical Fix For: 2.0.x, 2.1.x, 2.2 Beniamin has reported the following problem on [EMAIL PROTECTED] After processing 20k request to my webservice whose are translated to ~120k XA transactions (postgres + jms) Geronimo hangs up and does not respond on requests via HTTP, request to JMS engine (from HermesJMS) and ignores tries to shutdown server. I stopped Geronimo with kill -9 and tried to start it again and got exception: Module 11/69 org.apache.geronimo.configs/activemq-ra/2.1-SNAPSHOT/car 10:22:15,325 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car,j2eeType=TransactionLog,name=HOWLTransactionLog java.lang.IllegalArgumentException: Negative position at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:613) at org.objectweb.howl.log.BlockLogBuffer.read(BlockLogBuffer.java:412) at org.objectweb.howl.log.LogFileManager.read(LogFileManager.java:641) at org.objectweb.howl.log.LogBufferManager.replay(LogBufferManager.java:869) at org.objectweb.howl.log.Logger.replay(Logger.java:396) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:897) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:224) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java: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:534) 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:597) 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:830) at
Upgrading to Dojo 1.1.1
Hi everyone, I've been tossing the idea around in my head of taking the initiative to upgrade the current items written in Dojo to 1.1.1, I know we still have some Dojo 0.4.3, which isn't supported anymore, in use and there has been vast improvements with their new Dijit package for widgets among many other items. Also, with some recently reported JIRAs about accessibility compatibility being an issue in these Dojo components we can make use of the a11y available in it. Overall, i also think we might also benefit a cleaner setup from streamlining our versions in terms of future development and maintenance as well. Although I haven't looked in complete detail in each of the AG Dojo pieces, i know that the 0.4.3 transition to 1.1.1 will take some work because the widget system has been separated out to it's own pieces (diji) and so simple work arounds will not do. That is, this will be a big block change rather than an incremental one. Does anyone have any thoughts - one way or the other on this undertaking? Thanks! Joseph Leong
Re: [CONF] Apache Geronimo v2.1: Convert your current applications into plugins (page created)
Agreed, we should provide different examples of how to construct applications into plugins based sample application/tutorials we already have. Just state in that doc the tutorial is based on XYZ app and that the reader must have it installed and running (if needed) before proceeding. it will save lot of time Cheers! Hernan Kevan Miller wrote: Why reproduce the Stateless Session Bean Tutorial here? Better to refer to it, then get to the important part -- how to create a plugin... --kevan
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12603076#action_12603076 ] Joseph Leong commented on GERONIMO-3599: Continuing progress on this now, put it on the side for a little bit. I think to keep the post length below 2084 i'll go through and reduce the parameter names and see if that will keep it below 2084. If not, maybe i'll try passing it through portletsessions. -Joseph Leong 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 Environment: WIN XP Reporter: Anish Pathadan Assignee: Joseph Leong Fix For: 2.1.2, 2.1.x, 2.2 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.
Re: Upgrading to Dojo 1.1.1
My only thoughts on this are... +1 On Jun 6, 2008, at 11:04 AM, Joseph Leong [EMAIL PROTECTED] wrote: Hi everyone, I've been tossing the idea around in my head of taking the initiative to upgrade the current items written in Dojo to 1.1.1, I know we still have some Dojo 0.4.3, which isn't supported anymore, in use and there has been vast improvements with their new Dijit package for widgets among many other items. Also, with some recently reported JIRAs about accessibility compatibility being an issue in these Dojo components we can make use of the a11y available in it. Overall, i also think we might also benefit a cleaner setup from streamlining our versions in terms of future development and maintenance as well. Although I haven't looked in complete detail in each of the AG Dojo pieces, i know that the 0.4.3 transition to 1.1.1 will take some work because the widget system has been separated out to it's own pieces (diji) and so simple work arounds will not do. That is, this will be a big block change rather than an incremental one. Does anyone have any thoughts - one way or the other on this undertaking? Thanks! Joseph Leong
Re: Upgrading to Dojo 1.1.1
Would this let us remove Dojo 0.4.3 from the server or would we keep it there for users who might still be using it? If so, how long are we going to do that for? My vote would be to yank it out after we're no longer dependent on it, but I'm not sure what the community at large would think of that. Regardless, I like your idea, Joe. +1 On Fri, Jun 6, 2008 at 11:04 AM, Joseph Leong [EMAIL PROTECTED] wrote: Hi everyone, I've been tossing the idea around in my head of taking the initiative to upgrade the current items written in Dojo to 1.1.1, I know we still have some Dojo 0.4.3, which isn't supported anymore, in use and there has been vast improvements with their new Dijit package for widgets among many other items. Also, with some recently reported JIRAs about accessibility compatibility being an issue in these Dojo components we can make use of the a11y available in it. Overall, i also think we might also benefit a cleaner setup from streamlining our versions in terms of future development and maintenance as well. Although I haven't looked in complete detail in each of the AG Dojo pieces, i know that the 0.4.3 transition to 1.1.1 will take some work because the widget system has been separated out to it's own pieces (diji) and so simple work arounds will not do. That is, this will be a big block change rather than an incremental one. Does anyone have any thoughts - one way or the other on this undertaking? Thanks! Joseph Leong -- ~Jason Warner
Re: svn commit: r663897 - /geronimo/server/trunk/pom.xml
Can we also upgrade the 2.1 branch to he released WADI level, or does it
require any server changes?
-Donald
[EMAIL PROTECTED] wrote:
Author: gdamour
Date: Fri Jun 6 04:26:57 2008
New Revision: 663897
URL: http://svn.apache.org/viewvc?rev=663897view=rev
Log:
Upgrade to 2.0 version
Modified:
geronimo/server/trunk/pom.xml
Modified: geronimo/server/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=663897r1=663896r2=663897view=diff
==
--- geronimo/server/trunk/pom.xml (original)
+++ geronimo/server/trunk/pom.xml Fri Jun 6 04:26:57 2008
@@ -82,7 +82,7 @@
plutoVersion1.1.6-G643117/plutoVersion
openjpaVersion1.0.2/openjpaVersion
xbeanVersion3.3/xbeanVersion
-wadiVersion2.0-SNAPSHOT/wadiVersion
+wadiVersion2.0/wadiVersion
!-- Deployers --
gbeanDeployerBootstraporg.apache.geronimo.framework/geronimo-gbean-deployer-bootstrap/${version}/car/gbeanDeployerBootstrap
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Upgrading to Dojo 1.1.1
On Jun 6, 2008, at 11:52 AM, Jason Warner wrote: Would this let us remove Dojo 0.4.3 from the server or would we keep it there for users who might still be using it? If so, how long are we going to do that for? My vote would be to yank it out after we're no longer dependent on it, but I'm not sure what the community at large would think of that. Regardless, I like your idea, Joe. IMO, we would drop 0.4.3. I don't think we maintained for backward compatibility reasons, more because we didn't want to update the admin console code, at that point in time. I think it would be good to upgrade to 1.1.1. I also assume it would replace the current 1.0.2 version? Perhaps we should consider encoding the dojo version in the dojo path name. I'd prefer to see this work broken down into reasonable chunks (where possible), so that we can track progress (and others can participate). First add /dojo-1.1.1 and start incrementally moving code over to use new dojo. I don't know the internals of the admin console. So, not sure how well that work breaks down into manageable chunks. --kevan +1 On Fri, Jun 6, 2008 at 11:04 AM, Joseph Leong [EMAIL PROTECTED] wrote: Hi everyone, I've been tossing the idea around in my head of taking the initiative to upgrade the current items written in Dojo to 1.1.1, I know we still have some Dojo 0.4.3, which isn't supported anymore, in use and there has been vast improvements with their new Dijit package for widgets among many other items. Also, with some recently reported JIRAs about accessibility compatibility being an issue in these Dojo components we can make use of the a11y available in it. Overall, i also think we might also benefit a cleaner setup from streamlining our versions in terms of future development and maintenance as well. Although I haven't looked in complete detail in each of the AG Dojo pieces, i know that the 0.4.3 transition to 1.1.1 will take some work because the widget system has been separated out to it's own pieces (diji) and so simple work arounds will not do. That is, this will be a big block change rather than an incremental one. Does anyone have any thoughts - one way or the other on this undertaking? Thanks! Joseph Leong -- ~Jason Warner
Re: Upgrading to Dojo 1.1.1
+1 for trunk. Can you also move the older versions out of trunk and into the geronimo/plugins branch, so people can optionally install them if their app still needs them? If you're wanting to also do this in branches/2.1, then we need to keep the older version in the server images, so we don't break existing apps that may need them and so we can warn users that we will be removing them in the next release (2.2.) -Donald Joseph Leong wrote: Hi everyone, I've been tossing the idea around in my head of taking the initiative to upgrade the current items written in Dojo to 1.1.1, I know we still have some Dojo 0.4.3, which isn't supported anymore, in use and there has been vast improvements with their new Dijit package for widgets among many other items. Also, with some recently reported JIRAs about accessibility compatibility being an issue in these Dojo components we can make use of the a11y available in it. Overall, i also think we might also benefit a cleaner setup from streamlining our versions in terms of future development and maintenance as well. Although I haven't looked in complete detail in each of the AG Dojo pieces, i know that the 0.4.3 transition to 1.1.1 will take some work because the widget system has been separated out to it's own pieces (diji) and so simple work arounds will not do. That is, this will be a big block change rather than an incremental one. Does anyone have any thoughts - one way or the other on this undertaking? Thanks! Joseph Leong smime.p7s Description: S/MIME Cryptographic Signature
Re: Upgrading to Dojo 1.1.1
+1 for trunk too. I agree w/ Kevan that we should use versions for dojo. Maybe we could collect a list of portlets/pages that are using dojo and migrate each of them gradually to track the progress? Lin On Fri, Jun 6, 2008 at 12:19 PM, Donald Woods [EMAIL PROTECTED] wrote: +1 for trunk. Can you also move the older versions out of trunk and into the geronimo/plugins branch, so people can optionally install them if their app still needs them? If you're wanting to also do this in branches/2.1, then we need to keep the older version in the server images, so we don't break existing apps that may need them and so we can warn users that we will be removing them in the next release (2.2.) -Donald Joseph Leong wrote: Hi everyone, I've been tossing the idea around in my head of taking the initiative to upgrade the current items written in Dojo to 1.1.1, I know we still have some Dojo 0.4.3, which isn't supported anymore, in use and there has been vast improvements with their new Dijit package for widgets among many other items. Also, with some recently reported JIRAs about accessibility compatibility being an issue in these Dojo components we can make use of the a11y available in it. Overall, i also think we might also benefit a cleaner setup from streamlining our versions in terms of future development and maintenance as well. Although I haven't looked in complete detail in each of the AG Dojo pieces, i know that the 0.4.3 transition to 1.1.1 will take some work because the widget system has been separated out to it's own pieces (diji) and so simple work arounds will not do. That is, this will be a big block change rather than an incremental one. Does anyone have any thoughts - one way or the other on this undertaking? Thanks! Joseph Leong
[jira] Commented: (GERONIMO-3930) IllegalArgumentException reading Transaction Log
[ https://issues.apache.org/jira/browse/GERONIMO-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603091#action_12603091 ] Donald Woods commented on GERONIMO-3930: also merged into branches/2.0 as Rev664019. IllegalArgumentException reading Transaction Log Key: GERONIMO-3930 URL: https://issues.apache.org/jira/browse/GERONIMO-3930 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Kevan Miller Assignee: Kevan Miller Priority: Critical Fix For: 2.0.x, 2.1.2, 2.2 Beniamin has reported the following problem on [EMAIL PROTECTED] After processing 20k request to my webservice whose are translated to ~120k XA transactions (postgres + jms) Geronimo hangs up and does not respond on requests via HTTP, request to JMS engine (from HermesJMS) and ignores tries to shutdown server. I stopped Geronimo with kill -9 and tried to start it again and got exception: Module 11/69 org.apache.geronimo.configs/activemq-ra/2.1-SNAPSHOT/car 10:22:15,325 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car,j2eeType=TransactionLog,name=HOWLTransactionLog java.lang.IllegalArgumentException: Negative position at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:613) at org.objectweb.howl.log.BlockLogBuffer.read(BlockLogBuffer.java:412) at org.objectweb.howl.log.LogFileManager.read(LogFileManager.java:641) at org.objectweb.howl.log.LogBufferManager.replay(LogBufferManager.java:869) at org.objectweb.howl.log.Logger.replay(Logger.java:396) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:897) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:224) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java: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:534) 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:597) 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:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at
[jira] Updated: (GERONIMO-3930) IllegalArgumentException reading Transaction Log
[ https://issues.apache.org/jira/browse/GERONIMO-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3930: --- Fix Version/s: (was: 2.1.x) 2.1.2 IllegalArgumentException reading Transaction Log Key: GERONIMO-3930 URL: https://issues.apache.org/jira/browse/GERONIMO-3930 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Kevan Miller Assignee: Kevan Miller Priority: Critical Fix For: 2.0.x, 2.1.2, 2.2 Beniamin has reported the following problem on [EMAIL PROTECTED] After processing 20k request to my webservice whose are translated to ~120k XA transactions (postgres + jms) Geronimo hangs up and does not respond on requests via HTTP, request to JMS engine (from HermesJMS) and ignores tries to shutdown server. I stopped Geronimo with kill -9 and tried to start it again and got exception: Module 11/69 org.apache.geronimo.configs/activemq-ra/2.1-SNAPSHOT/car 10:22:15,325 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car,j2eeType=TransactionLog,name=HOWLTransactionLog java.lang.IllegalArgumentException: Negative position at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:613) at org.objectweb.howl.log.BlockLogBuffer.read(BlockLogBuffer.java:412) at org.objectweb.howl.log.LogFileManager.read(LogFileManager.java:641) at org.objectweb.howl.log.LogBufferManager.replay(LogBufferManager.java:869) at org.objectweb.howl.log.Logger.replay(Logger.java:396) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:897) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:224) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java: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:534) 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:597) 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: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)
Re: Upgrading to Dojo 1.1.1
Kevan, Actually I think the current 1.x version in trunk is 1.1.0, which is fully compatible with 1.1.1... as a result of this, it can just be upgraded in the 'dojo' plugin and be kept at the path of just /dojo On Fri, Jun 6, 2008 at 12:14 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Jun 6, 2008, at 11:52 AM, Jason Warner wrote: Would this let us remove Dojo 0.4.3 from the server or would we keep it there for users who might still be using it? If so, how long are we going to do that for? My vote would be to yank it out after we're no longer dependent on it, but I'm not sure what the community at large would think of that. Regardless, I like your idea, Joe. IMO, we would drop 0.4.3. I don't think we maintained for backward compatibility reasons, more because we didn't want to update the admin console code, at that point in time. I think it would be good to upgrade to 1.1.1. I also assume it would replace the current 1.0.2 version? Perhaps we should consider encoding the dojo version in the dojo path name. I'd prefer to see this work broken down into reasonable chunks (where possible), so that we can track progress (and others can participate). First add /dojo-1.1.1 and start incrementally moving code over to use new dojo. I don't know the internals of the admin console. So, not sure how well that work breaks down into manageable chunks. --kevan +1 On Fri, Jun 6, 2008 at 11:04 AM, Joseph Leong [EMAIL PROTECTED] wrote: Hi everyone, I've been tossing the idea around in my head of taking the initiative to upgrade the current items written in Dojo to 1.1.1, I know we still have some Dojo 0.4.3, which isn't supported anymore, in use and there has been vast improvements with their new Dijit package for widgets among many other items. Also, with some recently reported JIRAs about accessibility compatibility being an issue in these Dojo components we can make use of the a11y available in it. Overall, i also think we might also benefit a cleaner setup from streamlining our versions in terms of future development and maintenance as well. Although I haven't looked in complete detail in each of the AG Dojo pieces, i know that the 0.4.3 transition to 1.1.1 will take some work because the widget system has been separated out to it's own pieces (diji) and so simple work arounds will not do. That is, this will be a big block change rather than an incremental one. Does anyone have any thoughts - one way or the other on this undertaking? Thanks! Joseph Leong -- ~Jason Warner -- Erik B. Craig
Re: Upgrading to Dojo 1.1.1
And, erm... To further expand... I think having different versions of dojo in our plugins repository would be a good idea, at least having 0.4.x branch as well as the 1.x branch, with the latest being at /dojo, and any other (legacy) versions being installed would have a path of /dojo-x.x or /dojo/x.x (as is currently with dojo 0.4.3) On Fri, Jun 6, 2008 at 12:29 PM, Erik B. Craig [EMAIL PROTECTED] wrote: Kevan, Actually I think the current 1.x version in trunk is 1.1.0, which is fully compatible with 1.1.1... as a result of this, it can just be upgraded in the 'dojo' plugin and be kept at the path of just /dojo On Fri, Jun 6, 2008 at 12:14 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Jun 6, 2008, at 11:52 AM, Jason Warner wrote: Would this let us remove Dojo 0.4.3 from the server or would we keep it there for users who might still be using it? If so, how long are we going to do that for? My vote would be to yank it out after we're no longer dependent on it, but I'm not sure what the community at large would think of that. Regardless, I like your idea, Joe. IMO, we would drop 0.4.3. I don't think we maintained for backward compatibility reasons, more because we didn't want to update the admin console code, at that point in time. I think it would be good to upgrade to 1.1.1. I also assume it would replace the current 1.0.2 version? Perhaps we should consider encoding the dojo version in the dojo path name. I'd prefer to see this work broken down into reasonable chunks (where possible), so that we can track progress (and others can participate). First add /dojo-1.1.1 and start incrementally moving code over to use new dojo. I don't know the internals of the admin console. So, not sure how well that work breaks down into manageable chunks. --kevan +1 On Fri, Jun 6, 2008 at 11:04 AM, Joseph Leong [EMAIL PROTECTED] wrote: Hi everyone, I've been tossing the idea around in my head of taking the initiative to upgrade the current items written in Dojo to 1.1.1, I know we still have some Dojo 0.4.3, which isn't supported anymore, in use and there has been vast improvements with their new Dijit package for widgets among many other items. Also, with some recently reported JIRAs about accessibility compatibility being an issue in these Dojo components we can make use of the a11y available in it. Overall, i also think we might also benefit a cleaner setup from streamlining our versions in terms of future development and maintenance as well. Although I haven't looked in complete detail in each of the AG Dojo pieces, i know that the 0.4.3 transition to 1.1.1 will take some work because the widget system has been separated out to it's own pieces (diji) and so simple work arounds will not do. That is, this will be a big block change rather than an incremental one. Does anyone have any thoughts - one way or the other on this undertaking? Thanks! Joseph Leong -- ~Jason Warner -- Erik B. Craig -- Erik B. Craig
Re: Upgrading to Dojo 1.1.1
On Jun 6, 2008, at 12:19 PM, Donald Woods wrote: +1 for trunk. I was assuming trunk in my discussion. Can you also move the older versions out of trunk and into the geronimo/plugins branch, so people can optionally install them if their app still needs them? If you're wanting to also do this in branches/2.1, then we need to keep the older version in the server images, so we don't break existing apps that may need them and so we can warn users that we will be removing them in the next release (2.2.) I was thinking that we could release older versions of dojo as separate plugins. So, if somebody wanted a legacy level, they could install the appropriate legacy dojo plugin. No reason, however, not to release the dojo plugin separately (rather than have the latest version included in server...). --kevan
Re: Upgrading to Dojo 1.1.1
Ok great, so now there's a starting point. Seems the community is in favor, so i'll start going through and inventorying what we have currently running in what parts of AG and see if i can propose a plan for changes so the work can be parallelize should others want to jump in. Also, to track progress as you were all saying. Thanks for the input! -Joseph Leong On Fri, Jun 6, 2008 at 12:35 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Jun 6, 2008, at 12:19 PM, Donald Woods wrote: +1 for trunk. I was assuming trunk in my discussion. Can you also move the older versions out of trunk and into the geronimo/plugins branch, so people can optionally install them if their app still needs them? If you're wanting to also do this in branches/2.1, then we need to keep the older version in the server images, so we don't break existing apps that may need them and so we can warn users that we will be removing them in the next release (2.2.) I was thinking that we could release older versions of dojo as separate plugins. So, if somebody wanted a legacy level, they could install the appropriate legacy dojo plugin. No reason, however, not to release the dojo plugin separately (rather than have the latest version included in server...). --kevan
[jira] Resolved: (GERONIMO-4100) Allow users to use jaxws-tools.bat/sh when SUN SAAJ impl is not provided in the assembly
[ https://issues.apache.org/jira/browse/GERONIMO-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4100. --- Resolution: Fixed Fix Version/s: 2.1.x resolved in trunk (rev 664055) and branch 2.1 (rev 664053) Allow users to use jaxws-tools.bat/sh when SUN SAAJ impl is not provided in the assembly Key: GERONIMO-4100 URL: https://issues.apache.org/jira/browse/GERONIMO-4100 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.1.1 Reporter: Lin Sun Assignee: Lin Sun Priority: Minor Fix For: 2.1.x, 2.2 In JAXWSToolsCLI.java, the code default to always use SUN's Saaj impl (tools.setUseSunSAAJ()). This can be an issue for vendors who brand geronimo and choose to not include the SUN's saaj impl in the assembly, as the code would just throw an exception like below when jaxws-tools.bat wsgen is issued: Exception in thread main java.lang.Exception: Missing artifact in repositories : com.sun.xml.messaging.saaj/saaj-impl//jar at org.apache.geronimo.jaxws.builder.JAXWSTools.getLocati on(JAXWSTools.java:141) at org.apache.geronimo.jaxws.builder.JAXWSTools.getClassp ath(JAXWSTools.java:116) at org.apache.geronimo.jaxws.builder.JAXWSToolsCLI.run(JA XWSToolsCLI.java:75) at org.apache.geronimo.jaxws.builder.JAXWSToolsCLI.main(J AXWSToolsCLI.java:61) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4100) Allow users to use jaxws-tools.bat/sh when SUN SAAJ impl is not provided in the assembly
[ https://issues.apache.org/jira/browse/GERONIMO-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMO-4100. - Able to test this when repo only has Axis2 saaj impl and able to generate wsdl from SEI. Allow users to use jaxws-tools.bat/sh when SUN SAAJ impl is not provided in the assembly Key: GERONIMO-4100 URL: https://issues.apache.org/jira/browse/GERONIMO-4100 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.1.1 Reporter: Lin Sun Assignee: Lin Sun Priority: Minor Fix For: 2.1.x, 2.2 In JAXWSToolsCLI.java, the code default to always use SUN's Saaj impl (tools.setUseSunSAAJ()). This can be an issue for vendors who brand geronimo and choose to not include the SUN's saaj impl in the assembly, as the code would just throw an exception like below when jaxws-tools.bat wsgen is issued: Exception in thread main java.lang.Exception: Missing artifact in repositories : com.sun.xml.messaging.saaj/saaj-impl//jar at org.apache.geronimo.jaxws.builder.JAXWSTools.getLocati on(JAXWSTools.java:141) at org.apache.geronimo.jaxws.builder.JAXWSTools.getClassp ath(JAXWSTools.java:116) at org.apache.geronimo.jaxws.builder.JAXWSToolsCLI.run(JA XWSToolsCLI.java:75) at org.apache.geronimo.jaxws.builder.JAXWSToolsCLI.main(J AXWSToolsCLI.java:61) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r664055 - /geronimo/server/trunk/plugins/jaxws/geronimo-jaxws-builder/src/main/java/org/apache/geronimo/jaxws/builder/JAXWSToolsCLI.java
[EMAIL PROTECTED] wrote: Author: linsun Date: Fri Jun 6 10:42:59 2008 New Revision: 664055 URL: http://svn.apache.org/viewvc?rev=664055view=rev Log: G4100 - Allow users to use jaxws-tools.bat/sh when SUN SAAJ impl is not provided in the assembly Lin, If you include GERONIMO-4100 instead of G4100 in your change description the Subversion Commits section of the referenced JIRA will be automatically updated with the change details. This is preferred over manually entering the change details in the JIRA. Joe
[jira] Created: (GERONIMO-4104) Tomcat logging is broken
Tomcat logging is broken Key: GERONIMO-4104 URL: https://issues.apache.org/jira/browse/GERONIMO-4104 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1.1 Reporter: Kevan Miller Priority: Critical Fix For: 2.1.2 Tomcat logging seems to be broken. When deployment errors occur, the root causes aren't being logged. This makes problems hard to diagnose. I suspect that the problem is being caused by Tomcat's use of Log4JLogger from juli-adapters: repository/org/apache/tomcat/extras/juli-adapters/6.0.16/juli-adapters-6.0.16.jar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r664055 - /geronimo/server/trunk/plugins/jaxws/geronimo-jaxws-builder/src/main/java/org/apache/geronimo/jaxws/builder/JAXWSToolsCLI.java
Cool - thanks for the tip! I've been wondering how some jiras and commits are linked. Lin On Fri, Jun 6, 2008 at 1:54 PM, Joe Bohn [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Author: linsun Date: Fri Jun 6 10:42:59 2008 New Revision: 664055 URL: http://svn.apache.org/viewvc?rev=664055view=rev Log: G4100 - Allow users to use jaxws-tools.bat/sh when SUN SAAJ impl is not provided in the assembly Lin, If you include GERONIMO-4100 instead of G4100 in your change description the Subversion Commits section of the referenced JIRA will be automatically updated with the change details. This is preferred over manually entering the change details in the JIRA. Joe
[jira] Created: (GERONIMO-4105) input in gshell gets corrupted after starting server in background
input in gshell gets corrupted after starting server in background -- Key: GERONIMO-4105 URL: https://issues.apache.org/jira/browse/GERONIMO-4105 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: commands Affects Versions: 2.2 Reporter: Jarek Gawor Priority: Critical Using ghsell, once the server is started in background (geronimo/start-server -b), the command line input gets corrupted somehow and every other letter typed is eaten. For example, to actaully perform exit command I had to type eexxiitt. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (GERONIMO-4105) input in gshell gets corrupted after starting server in background
I ran into this today too - the workaround i can find is not to start server in the background. On Fri, Jun 6, 2008 at 2:34 PM, Jarek Gawor (JIRA) [EMAIL PROTECTED] wrote: input in gshell gets corrupted after starting server in background -- Key: GERONIMO-4105 URL: https://issues.apache.org/jira/browse/GERONIMO-4105 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: commands Affects Versions: 2.2 Reporter: Jarek Gawor Priority: Critical Using ghsell, once the server is started in background (geronimo/start-server -b), the command line input gets corrupted somehow and every other letter typed is eaten. For example, to actaully perform exit command I had to type eexxiitt. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4106) Gshell - unable to deploy modules with absolute path on windows
Gshell - unable to deploy modules with absolute path on windows --- Key: GERONIMO-4106 URL: https://issues.apache.org/jira/browse/GERONIMO-4106 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: commands Affects Versions: 2.1.1 Environment: winxp + sun jdk 1.5 14 Reporter: Lin Sun Using gshell to deploy a war file with its absolute path resulting the failure below - [EMAIL PROTECTED]:/ deploy/deploy C:\working\server\branches\samples\applications\jaxws-calculator\target\jaxws-calculator-axis2-2.1.0.0.war ERROR TokenMgrError: Lexical error at line 1, column 18. Encountered: w (119), after : \\ Workaround is to copy the war file to current dir so I don't have to specify a path: [EMAIL PROTECTED]:/ deploy/deploy jaxws-calculator-axis2-2.1.0.0.war Connecting to Geronimo server: localhost:1099 Username: system Password: *** Connection established Deployed org.apache.geronimo.samples.jws/Calculator/1.0/car @ /jaxws-calculator-1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r663607 - in /geronimo/server/trunk/plugins/debugviews/debugviews-portlets/src/main/webapp: TreeDocIcon.css WEB-INF/view/classloaderview/view.jsp WEB-INF/view/dependencyview/view.jsp W
Lin,
When we commit code that was provided to us in a patch, we should
provide an attribution within the commit message. In this case,
something like:
GERONIMO-4027 Patch from Joe Leong. Thanks Joe! Accessibility issue:
Tree icons in high contrast mode cannot be seen
I may be a bit pedantic, but if you could revert your changes to 2.1
and trunk and recommit, that would be great...
I would guess that our wiki doesn't document this...
--kevan
On Jun 5, 2008, at 9:36 AM, [EMAIL PROTECTED] wrote:
Author: linsun
Date: Thu Jun 5 06:36:46 2008
New Revision: 663607
URL: http://svn.apache.org/viewvc?rev=663607view=rev
Log:
GERONIMO-4027 Accessibility issue: Tree icons in high contrast mode
cannot be seen
Modified:
geronimo/server/trunk/plugins/debugviews/debugviews-portlets/src/
main/webapp/TreeDocIcon.css
geronimo/server/trunk/plugins/debugviews/debugviews-portlets/src/
main/webapp/WEB-INF/view/classloaderview/view.jsp
geronimo/server/trunk/plugins/debugviews/debugviews-portlets/src/
main/webapp/WEB-INF/view/dependencyview/view.jsp
geronimo/server/trunk/plugins/debugviews/debugviews-portlets/src/
main/webapp/WEB-INF/view/jndiview/view.jsp
Modified: geronimo/server/trunk/plugins/debugviews/debugviews-
portlets/src/main/webapp/TreeDocIcon.css
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/debugviews/debugviews-portlets/src/main/webapp/TreeDocIcon.css?rev=663607r1=663606r2=663607view=diff
=
=
=
=
=
=
=
=
==
--- geronimo/server/trunk/plugins/debugviews/debugviews-portlets/src/
main/webapp/TreeDocIcon.css (original)
+++ geronimo/server/trunk/plugins/debugviews/debugviews-portlets/src/
main/webapp/TreeDocIcon.css Thu Jun 5 06:36:46 2008
@@ -14,12 +14,21 @@
* See the License for the specific language governing permissions
and
* limitations under the License.
=
=
*/
[EMAIL PROTECTED] url(../dojo/src/widget/templates/TreeDocIcon.css);
+
+/*
+File Not Used. The Widget Has Problems Referencing Using the
templateCssPath
+
[EMAIL PROTECTED] url(http://localhost:8080/dojo/0.4/src/widget/templates/TreeDocIcon.css
);
+
+.TreeIconDocument {
+ background-image: url(http://localhost:8080/debug-views/ico_filetree_16x16.gif
);
+}
.TreeExpandOpen .TreeIconFolder {
-background-image: url('./images/ico_filetree_16x16.gif');
+ background-image: url(http://localhost:8080/debug-views/ico_filetree_16x16.gif
);
}
.TreeExpandClosed .TreeIconFolder {
-background-image: url('./images/ico_filetree_16x16.gif');
+ background-image: url(http://localhost:8080/debug-views/ico_filetree_16x16.gif
);
}
+*/
Modified: geronimo/server/trunk/plugins/debugviews/debugviews-
portlets/src/main/webapp/WEB-INF/view/classloaderview/view.jsp
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/debugviews/debugviews-portlets/src/main/webapp/WEB-INF/view/classloaderview/view.jsp?rev=663607r1=663606r2=663607view=diff
=
=
=
=
=
=
=
=
==
--- geronimo/server/trunk/plugins/debugviews/debugviews-portlets/src/
main/webapp/WEB-INF/view/classloaderview/view.jsp (original)
+++ geronimo/server/trunk/plugins/debugviews/debugviews-portlets/src/
main/webapp/WEB-INF/view/classloaderview/view.jsp Thu Jun 5
06:36:46 2008
@@ -332,16 +332,58 @@
/table
input type=submit value='fmt:message
key=classloaderview.view.invertTree/' /
br /
-
div dojoType=TreeBasicControllerV3 widgetId=controller/div
div dojoType=TreeSelectorV3 widgetId=selector/div
div dojoType=TreeEmphasizeOnSelect selector=selector/div
-div dojoType=TreeToggleOnSelect selector=selector
- controller=controller/div
-div dojoType=TreeDocIconExtension widgetId=iconcontroller
- templateCssPath=%=
renderResponse.encodeURL(renderRequest.getContextPath() + /
TreeDocIcon.css) %/div
-div dojoType=TreeV3 listeners=controller;selector;iconcontroller
- widgetId='tree' allowedMulti='false'/div
+div dojoType=TreeToggleOnSelect selector=selector
controller=controller/div
+div dojoType=TreeDocIconExtension widgetId=iconcontroller
templateCssString=
+.TreeStateChildrenYes-ExpandOpen .TreeIconContent {
+background-image : url('../templates/images/TreeV3/i_long.gif');
+background-repeat : no-repeat;
+background-position: 18px 9px;
+}
+
+.TreeStateChildrenYes-ExpandClosed .TreeIconContent {
+background-image : url();
+}
+
+.TreeStateChildrenNo-ExpandLeaf .TreeIconContent {
+background-image : url();
+}
+
+.TreeStateChildrenNo-ExpandClosed .TreeIconContent {
+background-image : url();
+}
+
+.TreeStateChildrenNo-ExpandOpen .TreeIconContent {
+background-image : url();
+}
+
+.TreeIconDocument {
+background-image: url(%=
renderResponse.encodeURL(renderRequest.getContextPath() + /
ico_filetree_16x16.gif) %);
+}
+
+.TreeExpandOpen .TreeIconFolder {
+background-image:
[jira] Created: (GERONIMO-4107) Update wiki on committing patches
Update wiki on committing patches - Key: GERONIMO-4107 URL: https://issues.apache.org/jira/browse/GERONIMO-4107 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: website Reporter: Kevan Miller The documentation in http://cwiki.apache.org/GMOxDEV/committing-patches-to-the-subversion-repository.html needs to be updated. We should also create documentation on creating patches. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4107) Update wiki on committing patches
[ https://issues.apache.org/jira/browse/GERONIMO-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reassigned GERONIMO-4107: -- Assignee: Kevan Miller Update wiki on committing patches - Key: GERONIMO-4107 URL: https://issues.apache.org/jira/browse/GERONIMO-4107 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: website Reporter: Kevan Miller Assignee: Kevan Miller The documentation in http://cwiki.apache.org/GMOxDEV/committing-patches-to-the-subversion-repository.html needs to be updated. We should also create documentation on creating patches. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4102) Can't start server assembly with jaxws-calculator
[ https://issues.apache.org/jira/browse/GERONIMO-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603184#action_12603184 ] Lin Sun commented on GERONIMO-4102: --- Hi, can you provide detailed steps on how to create this? When I am at step 3, I don't see calculator module on the list ( i did deploy it first) Thx, Lin Can't start server assembly with jaxws-calculator - Key: GERONIMO-4102 URL: https://issues.apache.org/jira/browse/GERONIMO-4102 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.2 Environment: Configuration: SW: 1. OS: RHEL 5.2 Snapshot 3 2. JDK: ibm jdk 5.0 SR6(embedded in build) HW: Intel x86 32bit Reporter: viola.lu Priority: Minor Steps: 1. Start server 2. Deploy jaxws-calculator and verify jaxws-calculator works fine 3. Assembly a server via gshell and select the following plugins com.ibm.wasce.assemblies/wasce-boilerplate-minimal/x.x.x.x/jar org.apache.geronimo.samples.jws/Calculator/x.x.x.x/car 4. Unzip the server assembly 5. Start the server assembly Problems: can't start server assembly,pls check server.log 6:37:19,156 INFO [Log4jService] -- 16:37:19,157 INFO [Log4jService] Started Logging Service 16:37:19,157 INFO [Log4jService] Runtime Information: 16:37:19,157 INFO [Log4jService] IBM WebSphere Application Server Community Edition V2.1.0.0 16:37:19,157 INFO [Log4jService] Copyright (C) 2005-2008, IBM Corporation. All Rights Reserved. 16:37:19,158 INFO [Log4jService] Powered by Apache Geronimo V2.1.1 16:37:19,158 INFO [Log4jService] Install Directory = /opt/IBM/WebSphere/AppServerCommunityEdition/var/temp/test/sample-jaxwscal-1.0 16:37:19,158 INFO [Log4jService] Build = 2.1.0.0-20080527 16:37:19,159 INFO [JvmVendor] IBM JVM 1.5.0 16:37:19,159 INFO [Log4jService] JVM in use = IBM JVM 1.5.0 16:37:19,160 INFO [Log4jService] Java Information: 16:37:19,160 INFO [Log4jService] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 16:37:19,160 INFO [Log4jService] System property [java.runtime.version] = pxi32devifx-20071025 (SR6b) 16:37:19,160 INFO [Log4jService] System property [os.name] = Linux 16:37:19,160 INFO [Log4jService] System property [os.version] = 2.6.18-87.el5 16:37:19,160 INFO [Log4jService] System property [sun.os.patch.level] = null 16:37:19,160 INFO [Log4jService] System property [os.arch] = x86 16:37:19,160 INFO [Log4jService] System property [java.class.version] = 49.0 16:37:19,160 INFO [Log4jService] System property [locale] = en_US 16:37:19,160 INFO [Log4jService] System property [unicode.encoding]= UnicodeLittle 16:37:19,161 INFO [Log4jService] System property [file.encoding] = UTF-8 16:37:19,161 INFO [Log4jService] System property [java.vm.name]= IBM J9 VM 16:37:19,161 INFO [Log4jService] System property [java.vm.vendor] = IBM Corporation 16:37:19,161 INFO [Log4jService] System property [java.vm.version] = 2.3 16:37:19,161 INFO [Log4jService] System property [java.vm.info]= J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20071005 (JIT enabled) J9VM - 20071004_14218_lHdSMR JIT - 20070820_1846ifx1_r8 GC - 200708_10 16:37:19,161 INFO [Log4jService] System property [java.home] = /opt/ibm/java2-i386-50/jre 16:37:19,161 INFO [Log4jService] System property [java.classpath] = null 16:37:19,161 INFO [Log4jService] System property [java.library.path] = /opt/ibm/java2-i386-50/jre/bin:/usr/local/apr/lib:/usr/lib 16:37:19,161 INFO [Log4jService] System property [java.endorsed.dirs] = /opt/IBM/WebSphere/AppServerCommunityEdition/var/temp/test/sample-jaxwscal-1.0/lib/endorsed:/opt/ibm/java2-i386-50/jre/lib/endorsed 16:37:19,162 INFO [Log4jService] System property [java.ext.dirs] = /opt/IBM/WebSphere/AppServerCommunityEdition/var/temp/test/sample-jaxwscal-1.0/lib/ext:/opt/ibm/java2-i386-50/jre/lib/ext 16:37:19,162 INFO [Log4jService] System property [sun.boot.class.path] =
Jaxen 1.1.1
Hello all, Does anyone know of a reason that we should not upgrade from the beta version of jaxen that we are currently using to the 1.1.1 version that is available now? Jay
[jira] Created: (GERONIMO-4108) Upgrade Dojo to version 1.1.1
Upgrade Dojo to version 1.1.1 - Key: GERONIMO-4108 URL: https://issues.apache.org/jira/browse/GERONIMO-4108 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Dojo version 1.1.1 has been released. It is completely backwards compatible with the current 1.1.0 version Geronimo is currently using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Jaxen 1.1.1
Looks like Axis2 only has a dependency on this library. So as long as all web services related TCK tests pass, it should be ok to upgrade. Jarek On Fri, Jun 6, 2008 at 6:02 PM, Jay D. McHugh [EMAIL PROTECTED] wrote: Hello all, Does anyone know of a reason that we should not upgrade from the beta version of jaxen that we are currently using to the 1.1.1 version that is available now? Jay
EditableConfigurationManager.removeGBeanFromConfiguration()
Hi, Does anybody know why the EditableKernelConfigurationManager.removeGBeanFromConfiguration() marks the gbean with load=false instead of actaully deleting it from the config store? I was adding and removing network connectors using the console and I saw the gbean added to the config.xml when I added a new connector. However, when I deleted the connector via the console, the gbean in the config.xml just got marked with load=false attribute. So, I was wondering if there is a reason for it. And on a related note, when I stopped the connector the gbean for it got stopped but that information was not persisted in config.xml and on server restart the stopped connector started again. Thanks, Jarek
[jira] Created: (GERONIMO-4109) Relationship between engine and host is wrong direction
Relationship between engine and host is wrong direction --- Key: GERONIMO-4109 URL: https://issues.apache.org/jira/browse/GERONIMO-4109 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.1.x, 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 EngineGBean has a collection of hosts which results in the possiblity of a host getting associated with many engines. However when a host is added to an engine it sets the parent property of the host. This is used to determine for instance the realm. This basically causes the wrong default realm when there are more than one engine configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: EditableConfigurationManager.removeGBeanFromConfiguration()
On Jun 6, 2008, at 3:38 PM, Jarek Gawor wrote: Hi, Does anybody know why the EditableKernelConfigurationManager.removeGBeanFromConfiguration() marks the gbean with load=false instead of actaully deleting it from the config store? I think the (possibly fuzzy) thinking behind this was that there might be configuration you didn't want to erase, you just didn't want the gbean to be running. I'm not a fan of adding/removing gbeans from existing configs, so I don't think I'd object if you changed this behavior. I was adding and removing network connectors using the console and I saw the gbean added to the config.xml when I added a new connector. However, when I deleted the connector via the console, the gbean in the config.xml just got marked with load=false attribute. So, I was wondering if there is a reason for it. And on a related note, when I stopped the connector the gbean for it got stopped but that information was not persisted in config.xml and on server restart the stopped connector started again. this doesn't sound right. thanks david jencks Thanks, Jarek
[jira] Closed: (GERONIMO-4109) Relationship between engine and host is wrong direction
[ https://issues.apache.org/jira/browse/GERONIMO-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4109. -- Resolution: Fixed rev 664198 samples/trunk rev 664199 This might cause problems if running tomcat jaas security with a 2nd container. I don't think there are likely to be any other problems so since I hope no one does this I don't think it needs to be ported to 2.1. Relationship between engine and host is wrong direction --- Key: GERONIMO-4109 URL: https://issues.apache.org/jira/browse/GERONIMO-4109 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1.x, 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 EngineGBean has a collection of hosts which results in the possiblity of a host getting associated with many engines. However when a host is added to an engine it sets the parent property of the host. This is used to determine for instance the realm. This basically causes the wrong default realm when there are more than one engine configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Jaxen 1.1.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Strictly even Axis2 does not need it. It's only used if you try the xpath support in Axiom. If you yank the jar out, everything else should work. - -- dims Jarek Gawor wrote: | Looks like Axis2 only has a dependency on this library. So as long as | all web services related TCK tests pass, it should be ok to upgrade. | | Jarek | | On Fri, Jun 6, 2008 at 6:02 PM, Jay D. McHugh [EMAIL PROTECTED] wrote: | Hello all, | | Does anyone know of a reason that we should not upgrade from the beta | version of jaxen that we are currently using to the 1.1.1 version that is | available now? | | Jay | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFISexWgNg6eWEDv1kRAjreAKC27RVpO/MifklzVY4tVZvp2Ax1pQCfdyEM bYSZffHckr7gJBSMs/phInA= =uT40 -END PGP SIGNATURE-
[jira] Updated: (GERONIMO-4036) Warning message after running gsh geronimo/stop-server
[
https://issues.apache.org/jira/browse/GERONIMO-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner updated GERONIMO-4036:
---
Fix Version/s: 2.2
Warning message after running gsh geronimo/stop-server
--
Key: GERONIMO-4036
URL: https://issues.apache.org/jira/browse/GERONIMO-4036
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.2, 2.1.x, 2.2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Warner
Fix For: 2.1.2, 2.2
About 10 seconds after running geronimo/stop-server successfully, got the
following warning messages in the gsh console:
{noformat}
[EMAIL PROTECTED]:/ 2008-5-20 13:51:12 ClientCommunicatorAdmin restart
Warning: Failed to restart: java.io.IOException: Failed to get a RMI stub:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is:
java.net.ConnectException: Connection refused: connect]
2008-5-20 13:51:13 RMIConnector RMIClientCommunicatorAdmin-doStop
Warning: Failed to call the method close():java.rmi.ConnectException:
Connection refused to host: 9.186.117.32; nested exception is:
java.net.ConnectException: Connection refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: Failed to check connection: java.net.ConnectException: Connection
refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: stopping
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4036) Warning message after running gsh geronimo/stop-server
[
https://issues.apache.org/jira/browse/GERONIMO-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner resolved GERONIMO-4036.
Resolution: Fixed
rev. 664148 in branches/2.1
rev. 664243 in trunk
Many thanks to Jarek for his incredibly helpful suggestions.
Warning message after running gsh geronimo/stop-server
--
Key: GERONIMO-4036
URL: https://issues.apache.org/jira/browse/GERONIMO-4036
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.2, 2.1.x, 2.2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Warner
Fix For: 2.1.2, 2.2
About 10 seconds after running geronimo/stop-server successfully, got the
following warning messages in the gsh console:
{noformat}
[EMAIL PROTECTED]:/ 2008-5-20 13:51:12 ClientCommunicatorAdmin restart
Warning: Failed to restart: java.io.IOException: Failed to get a RMI stub:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is:
java.net.ConnectException: Connection refused: connect]
2008-5-20 13:51:13 RMIConnector RMIClientCommunicatorAdmin-doStop
Warning: Failed to call the method close():java.rmi.ConnectException:
Connection refused to host: 9.186.117.32; nested exception is:
java.net.ConnectException: Connection refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: Failed to check connection: java.net.ConnectException: Connection
refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: stopping
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 664229
Geronimo Revision: 664229 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080606/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080606
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 30 minutes 28 seconds
[INFO] Finished at: Fri Jun 06 21:33:45 EDT 2008
[INFO] Final Memory: 388M/1010M
[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/20080606/logs-2100-tomcat/test.log
[INFO] [site:attach-descriptor]
[INFO] [selenium:start-server {execution: start}]
Launching Selenium Server
Waiting for Selenium Server...
[INFO] Including display properties from:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/display.properties
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/server.log
[INFO] User extensions:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/user-extensions.js
Selenium Server started
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:40.746
[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 27 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:38.588)
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:39.853)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:47.664)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:42.085)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:43.485)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:29.400)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:28.358)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:29.211)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:35.962)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:44.139)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[jira] Commented: (GERONIMODEVTOOLS-353) Support remote deployment
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603282#action_12603282 ] Tim McConnell commented on GERONIMODEVTOOLS-353: Hi Yun Feng, yes I'll review early next week. Thanks much for working on this. Support remote deployment - Key: GERONIMODEVTOOLS-353 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-353 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: YunFeng Ma Assignee: Tim McConnell Fix For: 2.1.1 Attachments: GERONIMODEVTOOLS-353.patch The user should be able to: 1. Define a remote server 2. Deploy/undeploy an application to the remote server -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
