[jira] Closed: (GERONIMO-3748) system-database-console-jetty is too long for windows
[ https://issues.apache.org/jira/browse/GERONIMO-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3748. -- Resolution: Fixed rev 611733. system-database-console-jetty is too long for windows - Key: GERONIMO-3748 URL: https://issues.apache.org/jira/browse/GERONIMO-3748 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 proposal is to use sysdb-console-jetty etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Could not scan module for TLD files: Filename too long
OK, fixed rev 611733, GERONIMO-3748
david jencks
On Jan 13, 2008, at 7:07 AM, Anita Kulshreshtha wrote:
yup..
Thanks!
Anita
--- David Jencks [EMAIL PROTECTED] wrote:
So maybe sysdb-console-tomcat would be sufficiently windows friendly?
thanks
david jencks
On Jan 12, 2008, at 5:06 PM, Anita Kulshreshtha wrote:
I have not done a build recently but expect to see this error.
IIUC,
The following jar will be scanned for tlds. This name is 256+14
chars
long. The old name, without 'console', was shorter by 3x7.
Thanks
Anita
D:\SVN\G\server\trunk\plugins\system-database\system-database-
console-tomcat\target\repository\org\apache\geronimo\plugins\system-
database-console-tomcat-\2.1-SNAPSHOT\system-database-console-
tomcat-2.1-SNAPSHOT.car\WEB-INF\lib\system-database-portlet-2.1-
SNAPSHOT.jar
--- Tim McConnell [EMAIL PROTECTED] wrote:
Hi, is anyone else getting this error when building trunk on
Windows
?? And what
if anything can be done to get past the problem ?? It's not
obvious
to me which
file it is complaining about.
[INFO]
--
--
[INFO] Building Geronimo Plugins :: System Database - Jetty
[INFO]task-segment: [install]
[INFO]
--
--
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
D:\SVN\G\server\trunk\plugins\system-database\system-database-
console-jetty\target\classes\META-INF
[INFO] Copying 2 files to
D:\SVN\G\server\trunk\plugins\system-database\system-database-
console-jetty\target\classes\META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
D:\SVN\G\server\trunk\plugins\system-database\system-database-
console-jetty\target\resources\META-INF\plan.xml
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
D:\SVN\G\server\trunk\plugins\system-database\system-database-
console-jetty\target\resources\META-INF\plan.xml
[INFO]
--
--
[ERROR] BUILD ERROR
[INFO]
--
--
[INFO] Could not scan module for TLD files:
org.apache.geronimo.plugins/system-database-console-jetty/2.1-
SNAPSHOT/car
Filename too long
--
Thanks,
Tim McConnell
__
__
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/
newsearch/category.php?category=shopping
__
__
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
Re: [BUILD] 2.1: Failed for Revision: 611733
Is there any chance of seeing the test failure output? This test is
passing when I run it which makes it a bit hard to diagnose.
thanks
david jencks
On Jan 14, 2008, at 12:16 AM, [EMAIL PROTECTED] wrote:
OpenEJB trunk at 61
Geronimo Revision: 611733 built with tests included
See the full build-0300.log file at http://people.apache.org/
~prasad/binaries/trunk/20080114/build-0300.log
Running
org.apache.geronimo.system.configuration.condition.JexlConditionParser
Test
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.046 sec
Running
org.apache.geronimo.system.configuration.InPlaceConfigurationUtilTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.028 sec
Running org.apache.geronimo.system.logging.log4j.XLevelTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.005 sec
Running
org.apache.geronimo.system.configuration.ConfigurationStoreUtilTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.319 sec
Running
org.apache.geronimo.system.configuration.LocalAttributeManagerTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.058 sec
Running org.apache.geronimo.system.configuration.GBeanOverrideTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.02 sec
Running org.apache.geronimo.system.configuration.ServerOverrideTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.048 sec
Running
org.apache.geronimo.system.configuration.condition.JexlExpressionParse
rTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.007 sec
Results :
Tests run: 58, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar: /home/prasad/geronimo/trunk/framework/modules/
geronimo-system/target/geronimo-system-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-system-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing /home/prasad/geronimo/trunk/framework/modules/
geronimo-system/target/geronimo-system-2.1-SNAPSHOT.jar to /home/
prasad/.m2/repository/org/apache/geronimo/modules/geronimo-system/
2.1-SNAPSHOT/geronimo-system-2.1-SNAPSHOT.jar
[INFO]
--
--
[INFO] Building geronimo-plugin
[INFO]task-segment: [install]
[INFO]
--
--
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /home/prasad/geronimo/trunk/framework/modules/
geronimo-plugin/target/classes/META-INF
[INFO] Copying 2 files to /home/prasad/geronimo/trunk/framework/
modules/geronimo-plugin/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 21 source files to /home/prasad/geronimo/trunk/
framework/modules/geronimo-plugin/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 4 source files to /home/prasad/geronimo/trunk/
framework/modules/geronimo-plugin/target/test-classes
[INFO] [surefire:test]
[WARNING] Component returned which is not the same manager.
Ignored.
[EMAIL PROTECTED]
282428
[INFO] Surefire report directory: /home/prasad/geronimo/trunk/
framework/modules/geronimo-plugin/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.system.plugin.ArchiverGBeanTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.143 sec
Running org.apache.geronimo.system.plugin.CopyConfigTest
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
1.348 sec FAILURE!
Running org.apache.geronimo.system.plugin.CopyFileTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.185 sec
Running org.apache.geronimo.system.plugin.PluginInstallerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.045 sec
Results :
Failed tests:
testCopyConfig(org.apache.geronimo.system.plugin.CopyConfigTest)
Tests run: 10, Failures: 1, Errors: 0, Skipped: 0
[INFO]
--
--
[ERROR] BUILD FAILURE
[INFO]
--
--
[INFO] There are test failures.
[INFO]
--
--
[INFO] Trace
org.apache.maven.BuildFailureException: There are test failures.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(DefaultLifecycleExecutor.java:560)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif
ecycle(DefaultLifecycleExecutor.java:480
[BUILD] 2.1: Failed for Revision: 611733
OpenEJB trunk at 61
Geronimo Revision: 611733 built with tests included
See the full build-0300.log file at
http://people.apache.org/~prasad/binaries/trunk/20080114/build-0300.log
Running
org.apache.geronimo.system.configuration.condition.JexlConditionParserTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec
Running org.apache.geronimo.system.configuration.InPlaceConfigurationUtilTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec
Running org.apache.geronimo.system.logging.log4j.XLevelTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running org.apache.geronimo.system.configuration.ConfigurationStoreUtilTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.319 sec
Running org.apache.geronimo.system.configuration.LocalAttributeManagerTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.058 sec
Running org.apache.geronimo.system.configuration.GBeanOverrideTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec
Running org.apache.geronimo.system.configuration.ServerOverrideTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.048 sec
Running
org.apache.geronimo.system.configuration.condition.JexlExpressionParserTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Results :
Tests run: 58, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/prasad/geronimo/trunk/framework/modules/geronimo-system/target/geronimo-system-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-system-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/framework/modules/geronimo-system/target/geronimo-system-2.1-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-system/2.1-SNAPSHOT/geronimo-system-2.1-SNAPSHOT.jar
[INFO]
[INFO] Building geronimo-plugin
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/framework/modules/geronimo-plugin/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/framework/modules/geronimo-plugin/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 21 source files to
/home/prasad/geronimo/trunk/framework/modules/geronimo-plugin/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 4 source files to
/home/prasad/geronimo/trunk/framework/modules/geronimo-plugin/target/test-classes
[INFO] [surefire:test]
[WARNING] Component returned which is not the same manager. Ignored. [EMAIL
PROTECTED]
[INFO] Surefire report directory:
/home/prasad/geronimo/trunk/framework/modules/geronimo-plugin/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.system.plugin.ArchiverGBeanTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.143 sec
Running org.apache.geronimo.system.plugin.CopyConfigTest
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.348 sec
FAILURE!
Running org.apache.geronimo.system.plugin.CopyFileTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.185 sec
Running org.apache.geronimo.system.plugin.PluginInstallerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.045 sec
Results :
Failed tests:
testCopyConfig(org.apache.geronimo.system.plugin.CopyConfigTest)
Tests run: 10, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] There are test failures.
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: There are test failures.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments
Re: Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
Anyone still getting this? On the first startup the server starts fine but every following startup after a shutdown (or even reboot of comp) fails. I have had this problem for some time now (2 weeks I think) and to get around it I keep reinstalling the server but that's getting a bit boring :). This is happening for me on new builds of 2.1. The only thing I have done in between is installing the roller plugin. I have also tried startup with load=false in config.xml on the roller modules before startup (just in case the plugin would be causing the startup problem) but it dose not help. Any clues on what may causing this ? thanks Peter P 09:05:33,865 INFO [Log4jService] -- 09:05:33,865 INFO [Log4jService] Started Logging Service 09:05:33,865 INFO [Log4jService] Runtime Information: 09:05:33,865 INFO [Log4jService] Install Directory = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT 09:05:33,865 INFO [Log4jService] JVM in use = Sun Microsystems Inc. Java 1.5.0_13 09:05:33,865 INFO [Log4jService] Java Information: 09:05:33,865 INFO [Log4jService] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 09:05:33,865 INFO [Log4jService] System property [java.runtime.version] = 1.5.0_13-b05 09:05:33,865 INFO [Log4jService] System property [os.name] = Linux 09:05:33,865 INFO [Log4jService] System property [os.version] = 2.6.22-14-generic 09:05:33,871 INFO [Log4jService] System property [sun.os.patch.level] = unknown 09:05:33,871 INFO [Log4jService] System property [os.arch] = i386 09:05:33,871 INFO [Log4jService] System property [java.class.version] = 49.0 09:05:33,871 INFO [Log4jService] System property [locale] = sv_SE 09:05:33,871 INFO [Log4jService] System property [unicode.encoding]= UnicodeLittle 09:05:33,871 INFO [Log4jService] System property [file.encoding] = UTF-8 09:05:33,871 INFO [Log4jService] System property [java.vm.name]= Java HotSpot(TM) Server VM 09:05:33,871 INFO [Log4jService] System property [java.vm.vendor] = Sun Microsystems Inc. 09:05:33,871 INFO [Log4jService] System property [java.vm.version] = 1.5.0_13-b05 09:05:33,871 INFO [Log4jService] System property [java.vm.info]= mixed mode 09:05:33,871 INFO [Log4jService] System property [java.home] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre 09:05:33,871 INFO [Log4jService] System property [java.classpath] = null 09:05:33,871 INFO [Log4jService] System property [java.library.path] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i386/server:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i386:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/../lib/i386 09:05:33,871 INFO [Log4jService] System property [java.endorsed.dirs] = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT/lib/endorsed:/usr/lib/jvm/java-1.5.0-sun/jre/lib/endorsed 09:05:33,871 INFO [Log4jService] System property [java.ext.dirs] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/ext 09:05:33,871 INFO [Log4jService] System property [sun.boot.class.path] = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT/lib/endorsed/yoko-rmi-spec-1.0-incubating-r602900.jar:/usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT/lib/endorsed/yoko-spec-corba-1.0-incubating-r602900.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/rt.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i18n.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/jsse.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/jce.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/charsets.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/classes 09:05:33,871 INFO [Log4jService] -- 09:05:37,561 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/plugin/2.1-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/plugin/2.1-SNAPSHOT/car java.lang.IllegalStateException: Cannot load property editor [org.apache.xbean.propertyeditor.LinkedListEditor] at org.apache.geronimo.system.configuration.GBeanOverride.loadPropertyEditor(GBeanOverride.java:412) at org.apache.geronimo.system.configuration.GBeanOverride.getValue(GBeanOverride.java:387) at org.apache.geronimo.system.configuration.GBeanOverride.applyOverrides(GBeanOverride.java:347) at org.apache.geronimo.system.configuration.LocalAttributeManager.setAttributes(LocalAttributeManager.java:210) at org.apache.geronimo.system.configuration.LocalAttributeManager.applyOverrides(LocalAttributeManager.java:179) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:280) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at
Re: [jira] Updated: (GERONIMO-1775) Internationalization of the Admin Console
Thanks a lot, David. Of course, I'll double check the patch, including the new plugin console, :) -Yun Feng David Jencks wrote: I applied it, could you check for problems? Also I'd appreciate it if you could check what I did for the new plugin console plugin (in console with the main console stuff). thanks david jencks On Jan 13, 2008, at 6:06 PM, YunFeng Ma wrote: Could one of you review this patch? I'd like this feature shipped with v2.1. Thanks a lot. -Yun Feng YunFeng Ma (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YunFeng Ma updated GERONIMO-1775: - Attachment: GERONIMO-1775-1.patch New patch GERONIMO-1775-1 provides the following contents: 1. Some fixes for console-base-portlets 2. i18n support for activemq-portlets 3. i18n support for debugviews-portlets 4. i18n support for system-database-portlets The console testsuite still failed, but I believe it's because of the changes of other components, I've opened a JIRA for this: https://issues.apache.org/jira/browse/GERONIMO-3737 Internationalization of the Admin Console - Key: GERONIMO-1775 URL: https://issues.apache.org/jira/browse/GERONIMO-1775 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Reporter: Yeray Cabrera Santana Assignee: Donald Woods Priority: Minor Fix For: 2.1 Attachments: chinese_console.JPG, GERONIMO-1775-1.patch, GERONIMO-1775.patch Provide the internationalization of the administration console so it can be translated to different languages. This is a feature I would like to contribute with. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: Could not scan module for TLD files: Filename too long
Wonderful !! Thanks much David
David Jencks wrote:
OK, fixed rev 611733, GERONIMO-3748
david jencks
On Jan 13, 2008, at 7:07 AM, Anita Kulshreshtha wrote:
yup..
Thanks!
Anita
--- David Jencks [EMAIL PROTECTED] wrote:
So maybe sysdb-console-tomcat would be sufficiently windows friendly?
thanks
david jencks
On Jan 12, 2008, at 5:06 PM, Anita Kulshreshtha wrote:
I have not done a build recently but expect to see this error.
IIUC,
The following jar will be scanned for tlds. This name is 256+14
chars
long. The old name, without 'console', was shorter by 3x7.
Thanks
Anita
D:\SVN\G\server\trunk\plugins\system-database\system-database-
console-tomcat\target\repository\org\apache\geronimo\plugins\system-
database-console-tomcat-\2.1-SNAPSHOT\system-database-console-
tomcat-2.1-SNAPSHOT.car\WEB-INF\lib\system-database-portlet-2.1-
SNAPSHOT.jar
--- Tim McConnell [EMAIL PROTECTED] wrote:
Hi, is anyone else getting this error when building trunk on
Windows
?? And what
if anything can be done to get past the problem ?? It's not
obvious
to me which
file it is complaining about.
[INFO]
--
--
[INFO] Building Geronimo Plugins :: System Database - Jetty
[INFO]task-segment: [install]
[INFO]
--
--
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
D:\SVN\G\server\trunk\plugins\system-database\system-database-
console-jetty\target\classes\META-INF
[INFO] Copying 2 files to
D:\SVN\G\server\trunk\plugins\system-database\system-database-
console-jetty\target\classes\META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
D:\SVN\G\server\trunk\plugins\system-database\system-database-
console-jetty\target\resources\META-INF\plan.xml
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
D:\SVN\G\server\trunk\plugins\system-database\system-database-
console-jetty\target\resources\META-INF\plan.xml
[INFO]
--
--
[ERROR] BUILD ERROR
[INFO]
--
--
[INFO] Could not scan module for TLD files:
org.apache.geronimo.plugins/system-database-console-jetty/2.1-
SNAPSHOT/car
Filename too long
-- Thanks,
Tim McConnell
__
__
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/
newsearch/category.php?category=shopping
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
--
Thanks,
Tim McConnell
[YOKO]
What cleanup steps need to be taken with the yoko code now that it's been made a subproject in Geronimo? The first obvious one would be to remove the non-core components from the trunk. The second would be to remove the incubating from the version names. Does the code need to be repackaged so that is org.apache.geronimo.yoko.* I see that this is not the case with XBEAN, so perhaps we're ok there. Same basic question about the generated artifacts. The current code was never made into an official Yoko release. Should we attempt to get this out as an official v1 release as soon as the basic cleanup is completed? Rick
Board Report for January 2008
Please accept this report from the Geronimo PMC for January 2008. Apache Geronimo Board Report The Apache Geronimo Project has released Geronimo 2.0.2 in October. Currently we are working on the 2.1 release for January 2008 (or so). Geronimo voted to accept project Yoko as a sub-project in Geronimo from Incubator. There are no community issues for the Board's attention. Details follow. Releases - Geronimo 2.0.2 was released in October - Release Manager - Kevan Miller. 2.1 is in process Subprojects *Components* - Transaction manager and connector framework 2.0.2 including bug fixes was released in October. *Javamail* - 1.2 with IMAP client support and rewritten POP3 cllient was released on December. - The javamail provider jars 1.3 were released in December with new IMAP functionality, improved POP3 functionality, OSGI packaging, and bug fixes. *DayTrader* - Draft performance report for Apache Geronimo 2.0.2 was made available in early December. Final version is pending. *Genesis* - Genesis 1.3 was released in December suppporting some legal files generation. *GShell* - The first GShell release, 1.0-alpha-1, was in December. *XBean* - XBean 3.2 incorporating bug fixes and some new functionality was released in October. *Specs* - Several specs were released including bug fixes and OSGI packaging info, including Activation, Javamail, Servlet-2.5 and stax-api. *JUGs and Conferences* * Ireland Java Users Group was attended by Jeff Genender * EclipseWorld 2007 was attended by Tim McConnell, where he presented two courses related to the Geronimo Eclipse plugin *New Committers* - Erik Craig - Alexey Petrenko - Lars Kuhne *PMC Additions / Changes* - Jay McHugh - Voted Kevan Miller as new PMC chair as a recommendation to the Board
Re: Integrating Jetspeed with Geronimo
David, this is exactly what I see. This is caused by the fragments in the web-inf/pages/default-page.psml. It tries to load fragments from jetspeed-layouts and j2-admin portlet apps. Now jetspeed-layouts is hot-deployed by including it in the web-inf/deploy dir. So that is not the actual problem even though it shows up in the stack trace below. The actual problem is with the j2-admin portlet app which gets deployed as a peer of jetspeed portal app. I verified this by commenting out the j2-admin fragments from default-page.psml but leaving the jetspeed-layout fragments as is. Now you get a blank page on the browser and no apparent stacktrace. Cheers Prasad On Jan 12, 2008 3:55 AM, David Jencks [EMAIL PROTECTED] wrote: Hi Prasad, You've been busy here :-). Its great to see progress on integrating jetspeed. I couldn't get it to work as well as you did and made a few changes: 1. update to released jetspeed 2.1.3 2. use the derby datasource in the JetspeedSeriaiizerGBean (this required adjusting the gbean startup order so it starts after the tomcat web app context, thus after spring is initialized) 3. add a simple tomcat assembly including jetspeed so its easy to see what we get :-). For me the server starts up without apparent errors. When I visit http://localhost:8080/jetspeed/portal/ the browser shows: Failed to retrieve Portlet Definition for jetspeed-layouts::VelocityTwoColumns and I get stuff like this on the console: 00:16:10,306 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for j2-admin::LocaleSelector 00:16:10,318 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for j2-admin::LoginPortlet 00:16:10,323 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for j2-admin::ForgottenPasswordPortlet 00:16:10,326 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for j2-admin::UserRegistrationPortlet 00:16:10,328 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::WeatherPortlet 00:16:10,331 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::PickANumberPortlet 00:16:10,333 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::RoleSecurityTest 00:16:10,336 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::IFramePortlet 00:16:10,339 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::IFramePortlet 00:16:10,341 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::UserInfoTest 00:16:10,343 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::BookmarkPortlet 00:16:10,344 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for jetspeed-layouts::VelocityTwoColumns 00:16:10,347 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for j2-admin::LocaleSelector 00:16:10,349 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for j2-admin::LoginPortlet 00:16:10,351 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for j2-admin::ForgottenPasswordPortlet 00:16:10,355 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for j2-admin::UserRegistrationPortlet 00:16:10,358 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::WeatherPortlet 00:16:10,363 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::PickANumberPortlet 00:16:10,371 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::RoleSecurityTest 00:16:10,376 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::IFramePortlet 00:16:10,381 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::IFramePortlet 00:16:10,383 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::UserInfoTest 00:16:10,386 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for demo::BookmarkPortlet 00:16:10,390 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for j2-admin::LocaleSelector 00:16:10,421 WARN [JetspeedPortletContainerWrapper] Could not render PortletWindowdp-3 as it has no PortletDefintion defined. 00:16:10,427 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition for j2-admin::LoginPortlet 00:16:10,429 WARN [JetspeedPortletContainerWrapper] Could not render PortletWindowdp-12 as it has no PortletDefintion defined. 00:16:10,446 WARN [PersistenceBrokerPortletEntityAccess] Failed to retrieve Portlet Definition
[jira] Assigned: (GSHELL-48) Add file/URL support to the script command
[
https://issues.apache.org/jira/browse/GSHELL-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GSHELL-48:
--
Assignee: Jason Warner
Add file/URL support to the script command
--
Key: GSHELL-48
URL: https://issues.apache.org/jira/browse/GSHELL-48
Project: GShell
Issue Type: New Feature
Security Level: public(Regular issues)
Components: Commands - BSF
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Warner
Priority: Minor
Fix For: 1.0-alpha-2
Should be able to give the BSF {{script}} command a file or URL to execute.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-49) When --language is not given and we have a file/URL try and figure out the lang to use
[ https://issues.apache.org/jira/browse/GSHELL-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner reassigned GSHELL-49: -- Assignee: Jason Warner When --language is not given and we have a file/URL try and figure out the lang to use -- Key: GSHELL-49 URL: https://issues.apache.org/jira/browse/GSHELL-49 Project: GShell Issue Type: Sub-task Security Level: public(Regular issues) Components: Commands - BSF Reporter: Jason Dillon Assignee: Jason Warner Priority: Trivial Fix For: 1.0-alpha-2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [BUILD] 2.1: Failed for Revision: 611733
David,
No, not right now with the unit tests. But I will try to figure
something out to provide that info.
Please keep in mind that this 3am trunk test is with IBM JDK. The
weird thing is that I'm unable to replicate the problem with the same
JDK on another machine. But my guess is that this test is failing
becuase it compares two xml documents as strings and not as DOM
objects.
Jarek
On 1/14/08, David Jencks [EMAIL PROTECTED] wrote:
Is there any chance of seeing the test failure output? This test is
passing when I run it which makes it a bit hard to diagnose.
thanks
david jencks
On Jan 14, 2008, at 12:16 AM, [EMAIL PROTECTED] wrote:
OpenEJB trunk at 61
Geronimo Revision: 611733 built with tests included
See the full build-0300.log file at http://people.apache.org/
~prasad/binaries/trunk/20080114/build-0300.log
Running
org.apache.geronimo.system.configuration.condition.JexlConditionParser
Test
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.046 sec
Running
org.apache.geronimo.system.configuration.InPlaceConfigurationUtilTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.028 sec
Running org.apache.geronimo.system.logging.log4j.XLevelTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.005 sec
Running
org.apache.geronimo.system.configuration.ConfigurationStoreUtilTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.319 sec
Running
org.apache.geronimo.system.configuration.LocalAttributeManagerTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.058 sec
Running org.apache.geronimo.system.configuration.GBeanOverrideTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.02 sec
Running org.apache.geronimo.system.configuration.ServerOverrideTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.048 sec
Running
org.apache.geronimo.system.configuration.condition.JexlExpressionParse
rTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.007 sec
Results :
Tests run: 58, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar: /home/prasad/geronimo/trunk/framework/modules/
geronimo-system/target/geronimo-system-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-system-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing /home/prasad/geronimo/trunk/framework/modules/
geronimo-system/target/geronimo-system-2.1-SNAPSHOT.jar to /home/
prasad/.m2/repository/org/apache/geronimo/modules/geronimo-system/
2.1-SNAPSHOT/geronimo-system-2.1-SNAPSHOT.jar
[INFO]
--
--
[INFO] Building geronimo-plugin
[INFO]task-segment: [install]
[INFO]
--
--
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /home/prasad/geronimo/trunk/framework/modules/
geronimo-plugin/target/classes/META-INF
[INFO] Copying 2 files to /home/prasad/geronimo/trunk/framework/
modules/geronimo-plugin/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 21 source files to /home/prasad/geronimo/trunk/
framework/modules/geronimo-plugin/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 4 source files to /home/prasad/geronimo/trunk/
framework/modules/geronimo-plugin/target/test-classes
[INFO] [surefire:test]
[WARNING] Component returned which is not the same manager.
Ignored.
[EMAIL PROTECTED]
282428
[INFO] Surefire report directory: /home/prasad/geronimo/trunk/
framework/modules/geronimo-plugin/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.system.plugin.ArchiverGBeanTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.143 sec
Running org.apache.geronimo.system.plugin.CopyConfigTest
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
1.348 sec FAILURE!
Running org.apache.geronimo.system.plugin.CopyFileTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.185 sec
Running org.apache.geronimo.system.plugin.PluginInstallerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.045 sec
Results :
Failed tests:
testCopyConfig(org.apache.geronimo.system.plugin.CopyConfigTest)
Tests run: 10, Failures: 1, Errors: 0, Skipped: 0
[INFO
Re: Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
I finally got around to applying your roller plugin patch but I can't reproduce this either on jetty or tomcat. I'm on osx I wonder if its due to the different os thanks david jencks On Jan 14, 2008, at 2:28 AM, Peter Petersson wrote: Anyone still getting this? On the first startup the server starts fine but every following startup after a shutdown (or even reboot of comp) fails. I have had this problem for some time now (2 weeks I think) and to get around it I keep reinstalling the server but that's getting a bit boring :). This is happening for me on new builds of 2.1. The only thing I have done in between is installing the roller plugin. I have also tried startup with load=false in config.xml on the roller modules before startup (just in case the plugin would be causing the startup problem) but it dose not help. Any clues on what may causing this ? thanks Peter P 09:05:33,865 INFO [Log4jService] -- 09:05:33,865 INFO [Log4jService] Started Logging Service 09:05:33,865 INFO [Log4jService] Runtime Information: 09:05:33,865 INFO [Log4jService] Install Directory = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT 09:05:33,865 INFO [Log4jService] JVM in use = Sun Microsystems Inc. Java 1.5.0_13 09:05:33,865 INFO [Log4jService] Java Information: 09:05:33,865 INFO [Log4jService] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 09:05:33,865 INFO [Log4jService] System property [java.runtime.version] = 1.5.0_13-b05 09:05:33,865 INFO [Log4jService] System property [os.name] = Linux 09:05:33,865 INFO [Log4jService] System property [os.version] = 2.6.22-14-generic 09:05:33,871 INFO [Log4jService] System property [sun.os.patch.level] = unknown 09:05:33,871 INFO [Log4jService] System property [os.arch] = i386 09:05:33,871 INFO [Log4jService] System property [java.class.version] = 49.0 09:05:33,871 INFO [Log4jService] System property [locale] = sv_SE 09:05:33,871 INFO [Log4jService] System property [unicode.encoding]= UnicodeLittle 09:05:33,871 INFO [Log4jService] System property [file.encoding] = UTF-8 09:05:33,871 INFO [Log4jService] System property [java.vm.name]= Java HotSpot(TM) Server VM 09:05:33,871 INFO [Log4jService] System property [java.vm.vendor] = Sun Microsystems Inc. 09:05:33,871 INFO [Log4jService] System property [java.vm.version] = 1.5.0_13-b05 09:05:33,871 INFO [Log4jService] System property [java.vm.info]= mixed mode 09:05:33,871 INFO [Log4jService] System property [java.home] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre 09:05:33,871 INFO [Log4jService] System property [java.classpath] = null 09:05:33,871 INFO [Log4jService] System property [java.library.path] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i386/server:/usr/lib/ jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i386:/usr/lib/jvm/java-1.5.0- sun-1.5.0.13/jre/../lib/i386 09:05:33,871 INFO [Log4jService] System property [java.endorsed.dirs] = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT/lib/endorsed:/usr/ lib/jvm/java-1.5.0-sun/jre/lib/endorsed 09:05:33,871 INFO [Log4jService] System property [java.ext.dirs] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/ lib/ext 09:05:33,871 INFO [Log4jService] System property [sun.boot.class.path] = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT/lib/endorsed/yoko- rmi-spec-1.0-incubating-r602900.jar:/usr/local/geronimo-tomcat6- javaee5-2.1-SNAPSHOT/lib/endorsed/yoko-spec-corba-1.0-incubating- r602900.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/rt.jar:/ usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i18n.jar:/usr/lib/jvm/ java-1.5.0-sun-1.5.0.13/jre/lib/sunrsasign.jar:/usr/lib/jvm/ java-1.5.0-sun-1.5.0.13/jre/lib/jsse.jar:/usr/lib/jvm/java-1.5.0- sun-1.5.0.13/jre/lib/jce.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/ jre/lib/charsets.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/classes 09:05:33,871 INFO [Log4jService] -- 09:05:37,561 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/plugin/2.1-SNAPSHOT/car? configurationName=org.apache.geronimo.configs/plugin/2.1-SNAPSHOT/car java.lang.IllegalStateException: Cannot load property editor [org.apache.xbean.propertyeditor.LinkedListEditor] at org.apache.geronimo.system.configuration.GBeanOverride.loadPropertyEdi tor(GBeanOverride.java:412) at org.apache.geronimo.system.configuration.GBeanOverride.getValue (GBeanOverride.java:387) at org.apache.geronimo.system.configuration.GBeanOverride.applyOverrides( GBeanOverride.java:347) at org.apache.geronimo.system.configuration.LocalAttributeManager.setAttr ibutes(LocalAttributeManager.java:210) at
[jira] Commented: (GERONIMO-2994) Apache Roller plugin
[ https://issues.apache.org/jira/browse/GERONIMO-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558711#action_12558711 ] David Jencks commented on GERONIMO-2994: Applied roller_4_0_plugin_080103.patch in rev 611873. I removed the plugin prerequisites since I don't think they are appropriate when the prereq can be installed as a normal dependency. I think prereqs should only be used when the user has to create a configuration themselves for some reason Apache Roller plugin - Key: GERONIMO-2994 URL: https://issues.apache.org/jira/browse/GERONIMO-2994 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.2 Reporter: Peter Petersson Assignee: David Jencks Priority: Minor Attachments: geronimo-plugins.xml, geronimo-plugins.xml, geronimo-plugins_070602.xml, geronimo-web.xml, geronimo-web.xml, plan.xml, PluginInstallerGBean.patch, pom.xml, pom.xml, roller-custom.properties, roller-custom.properties, roller-custom.properties, roller-derbydb-plan-g1_2.xml, roller-mysql-db-plan-1-2.xml, roller070409.patch, roller12_070602.zip, roller_4_0_plugin_080103.patch, roller_g20_svn_070602.patch, roller_maven_ant_task_070902_0.patch, roller_maven_ant_task_070918_0.patch, roller_plugin.patch, roller_plugin_070717.patch, roller_plugin_070803.patch, roller_plugin_070918.patch, roller_plugin_070921.patch, roller_plugin_patch_070724.txt Have been working on getting Apache Roller running under Geronimo I finally got to the point where the roller application seems to be running smoothly in Geronimo v1.2 (current snapshot). It would be great to eventually see this application as a plugin in G so here are pointers to resources and attached plans. Apache Roller v3.1 Resources (soon to be released) Apache roller home: http://rollerweblogger.org/project/ The bundle: http://people.apache.org/~snoopdave/apache-roller-3.1/ (until it will be available directly via roller home) Required jars: https://roller.dev.java.net/servlets/ProjectDocumentList?expandFolder=6959folderID=0 Path to database create scripts can be found in the bundle above under: apache-roller-3.1/webapp/roller/WEB-INF/dbscripts/ I have tested with the derby database and mysql 5. There is currently a issue with G v1.2 and hibernates v3.1 (used by roller 3.1) property loader that gets a FATAL [HibernateRollerImpl] Error initializing Hibernate java.lang.ClassCastException: java.util.HashSet at org.hibernate.util.PropertiesHelper.resolvePlaceHolders(PropertiesHelper.java:88) Hibernate is expecting a String value (This issue is fixed in hibernate 3.2 with a instanceOf check) Fortunately David Jencks hit this problem in trunk and suggested turning off the activemq and activemq-broker modules in config.xml, to test things out, and after that everything was running smothly :). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Is there a problem with AsyncHttpClient connection reuse?
I haven't convinced myself that this is a problem yet, but it's worth asking the question. The AsyncHttpClient has support for connection reuse when making repeated connections to sites. Since these connnections persist between instantiations of AsyncHttpClient instances, there's a single static cache of the reusable connections that is maintained. Selection from the session cache is made using the host/port combination only, which means it's possible that a connection that is reused by a client will get processed using the thread pool configuration of the original connection client and not the current requesting client. I suspect this is not an issue that can be that can be easily detected or protected against, so the fix might just be a word of caution added to the documentation on enabling connection reuse. rick
Re: [YOKO]
On Jan 14, 2008, at 4:35 AM, Rick McGuire wrote: What cleanup steps need to be taken with the yoko code now that it's been made a subproject in Geronimo? The first obvious one would be to remove the non-core components from the trunk. The second would be to remove the incubating from the version names. Agreed Does the code need to be repackaged so that is org.apache.geronimo.yoko.* I see that this is not the case with XBEAN, so perhaps we're ok there. Same basic question about the generated artifacts. I don't think that this needs to, or should be, done. Let's keep it at org.apache.yoko. The current code was never made into an official Yoko release. Should we attempt to get this out as an official v1 release as soon as the basic cleanup is completed? I think that some people had some concerns about a release but I think that they were more focused on proper documentation and releasing a well rounded product. It's my opinion that it's ok to release so long as the code is good enough. With that said, I would like to make a 1.0 release. Regards, Alan
Re: Shouldn't subprojects use their file system parents as maven parents?
My thinking on this was to leave it as is for 2.1. We fix this right for 2.2, when we split the trunk into different svn trees. Moving the c-m-p configuration settings from configs parent pom to the root pom is not a problem. It is the boatload of property settings that will cause Jason good grief :-) Cheers Prasad On Jan 11, 2008 1:12 AM, David Jencks [EMAIL PROTECTED] wrote: After the reorganization into plugins most everything still has its old pom parent, either o.a.g.modules/modules or o.a.g.plugins/ plugins. This seems to me like a bad idea. I don't see any problem fixing this for jars, but cars would need the car plugin setup moved to perhaps the root pom I don't know if that will work. I opened GERONIMO-2747 about this. Anyone else think this should be fixed before 2.1 goes out? thanks david jencks
Problems with full assembly of GShell
Hello all, Has anyone else played around with the full assembly of gshell recently? I can't seem to get any of the extra commands that make it the full assembly to work (wait, sleep, script, etc...). I get Not Found Exception from the DefaultLayoutManager when I try. Is anyone else seeing this? Thanks, ~Jason Warner
[SECURITY] Potential vulnerability in Jetty servlet container
The Geronimo project has learned of a security vulnerability in the Jetty servlet container (6.1.5) included in Geronimo. If you use a Jetty configuration of Geronimo you may be affected by the vulnerability. This vulnerability impacts Jetty configurations of Geronimo 2.0.1 and 2.0.2. For specific information regarding the Jetty vulnerability, see http://www.kb.cert.org/vuls/id/553235 The problem is related to the processing of URLs which contain multiple consecutive forward slash (/) characters that are handled incorrectly (for example . http://foo//../bar). If your system is susceptible to attacks using such URLs we recommend that you filter these URLs using an application firewall or reverse proxy server. Alternatively, you can upgrade your Geronimo Jetty server image to utilize the corrected Jetty 6.1.7 jar: - Obtain a jetty-6.1.7.jar from http://repository.codehaus.org/org/mortbay/jetty/jetty/6.1.7/ - Stop your Geronimo Jetty server image - copy jetty-6.1.7.jar to geronimo-root/repository/org/mortbay/jetty/jetty/6.1.7/jetty-6.1.7.jar - remove the jetty 6.1.5 jar: geronimo-root/repository/org/mortbay/jetty/jetty/6.1.5/jetty-6.1.5.jar - start the Geronimo Jetty server. The server will now be using the 6.1.7 Jetty jar. This vulnerability will be fixed in the next release of Geronimo (2.0.3 and/or 2.1) which will include Jetty 6.1.7 correcting the vulnerability.
Re: Problems with full assembly of GShell
It seems to be a problem with parsing the layout.xml when searching for commands. I removed the groups from the xml so it's just one big list and those commands work now. I'll open a jira and see if I can fix it. ~Jason Warner On Jan 14, 2008 2:44 PM, Jason Warner [EMAIL PROTECTED] wrote: Hello all, Has anyone else played around with the full assembly of gshell recently? I can't seem to get any of the extra commands that make it the full assembly to work (wait, sleep, script, etc...). I get Not Found Exception from the DefaultLayoutManager when I try. Is anyone else seeing this? Thanks, ~Jason Warner
Re: Is there a problem with AsyncHttpClient connection reuse?
It's a good point... Currently the session cache is global, and all AsyncHttpClient instances are forced to share it. The main thing that concerns me is that as a result the connections will retain all the socket properties that came from the AsyncHttpClient instance that opened the connection. This might not be intuitive to say the least. For example, one AsyncHttpClient instance opens a connection with TCP delay disabled, and then another instance (this time with TCP delay enabled) comes along and picks up this connection for reuse. Contrary to what it expects, it would get a connection with TCP delay disabled. I see a couple of options: - Relax the current SessionCache implementation so it's no longer a singleton. - Make each AsyncHttpClient create its own SessionCache or make it an option of using the default session cache or its own I am thinking we want to give it an option of using a default session cache or its own. What do you think? Thanks, Sangjin On 1/14/08, Rick McGuire [EMAIL PROTECTED] wrote: I haven't convinced myself that this is a problem yet, but it's worth asking the question. The AsyncHttpClient has support for connection reuse when making repeated connections to sites. Since these connnections persist between instantiations of AsyncHttpClient instances, there's a single static cache of the reusable connections that is maintained. Selection from the session cache is made using the host/port combination only, which means it's possible that a connection that is reused by a client will get processed using the thread pool configuration of the original connection client and not the current requesting client. I suspect this is not an issue that can be that can be easily detected or protected against, so the fix might just be a word of caution added to the documentation on enabling connection reuse. rick
[jira] Created: (GSHELL-98) NotFoundException when trying to use non-builtin commands in full assembly
NotFoundException when trying to use non-builtin commands in full assembly -- Key: GSHELL-98 URL: https://issues.apache.org/jira/browse/GSHELL-98 Project: GShell Issue Type: Bug Security Level: public (Regular issues) Components: Core Affects Versions: 1.0-alpha-2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 1.0-alpha-2 The full assembly of gshell includes all the available commands by default. When trying to use one of the commands included outside of builtins, a NotFoundException is received. This seems to be caused by the groupings in the layout.xml file. When the groupings were removed, all the commands could be used successfully. Ideally, we'd like to be able to keep the groupings, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
David Jencks wrote: I finally got around to applying your roller plugin patch but I can't reproduce this either on jetty or tomcat. I'm on osx I wonder if its due to the different os Nice :) hmmm well I am on Linux and Hernan got this on a Windows XP box and maybe osx is spared but there is clearly something wrong with my environment or else the server is getting into a faulty state due to the plugin modules I install (roller-tomcat, roller-themes) although I doubt the later is the case ;), I will try investigate this a bit more, will post my findings (if any) here but If you or anyone else have some suggestions or hints on what may cause this let me know. I will do a svn update; mvn clean install; and go make some coffee and try out the new build with different setups. regards Peter P thanks david jencks On Jan 14, 2008, at 2:28 AM, Peter Petersson wrote: Anyone still getting this? On the first startup the server starts fine but every following startup after a shutdown (or even reboot of comp) fails. I have had this problem for some time now (2 weeks I think) and to get around it I keep reinstalling the server but that's getting a bit boring :). This is happening for me on new builds of 2.1. The only thing I have done in between is installing the roller plugin. I have also tried startup with load=false in config.xml on the roller modules before startup (just in case the plugin would be causing the startup problem) but it dose not help. Any clues on what may causing this ? thanks Peter P 09:05:33,865 INFO [Log4jService] -- 09:05:33,865 INFO [Log4jService] Started Logging Service 09:05:33,865 INFO [Log4jService] Runtime Information: 09:05:33,865 INFO [Log4jService] Install Directory = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT 09:05:33,865 INFO [Log4jService] JVM in use = Sun Microsystems Inc. Java 1.5.0_13 09:05:33,865 INFO [Log4jService] Java Information: 09:05:33,865 INFO [Log4jService] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 09:05:33,865 INFO [Log4jService] System property [java.runtime.version] = 1.5.0_13-b05 09:05:33,865 INFO [Log4jService] System property [os.name] = Linux 09:05:33,865 INFO [Log4jService] System property [os.version] = 2.6.22-14-generic 09:05:33,871 INFO [Log4jService] System property [sun.os.patch.level] = unknown 09:05:33,871 INFO [Log4jService] System property [os.arch] = i386 09:05:33,871 INFO [Log4jService] System property [java.class.version] = 49.0 09:05:33,871 INFO [Log4jService] System property [locale] = sv_SE 09:05:33,871 INFO [Log4jService] System property [unicode.encoding]= UnicodeLittle 09:05:33,871 INFO [Log4jService] System property [file.encoding] = UTF-8 09:05:33,871 INFO [Log4jService] System property [java.vm.name]= Java HotSpot(TM) Server VM 09:05:33,871 INFO [Log4jService] System property [java.vm.vendor] = Sun Microsystems Inc. 09:05:33,871 INFO [Log4jService] System property [java.vm.version] = 1.5.0_13-b05 09:05:33,871 INFO [Log4jService] System property [java.vm.info]= mixed mode 09:05:33,871 INFO [Log4jService] System property [java.home] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre 09:05:33,871 INFO [Log4jService] System property [java.classpath] = null 09:05:33,871 INFO [Log4jService] System property [java.library.path] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i386/server:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i386:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/../lib/i386 09:05:33,871 INFO [Log4jService] System property [java.endorsed.dirs] = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT/lib/endorsed:/usr/lib/jvm/java-1.5.0-sun/jre/lib/endorsed 09:05:33,871 INFO [Log4jService] System property [java.ext.dirs] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/ext 09:05:33,871 INFO [Log4jService] System property [sun.boot.class.path] = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT/lib/endorsed/yoko-rmi-spec-1.0-incubating-r602900.jar:/usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT/lib/endorsed/yoko-spec-corba-1.0-incubating-r602900.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/rt.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i18n.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/jsse.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/jce.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/charsets.jar:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/classes 09:05:33,871 INFO [Log4jService] -- 09:05:37,561 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/plugin/2.1-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/plugin/2.1-SNAPSHOT/car
Re: Is there a problem with AsyncHttpClient connection reuse?
On 1/14/08, Sangjin Lee [EMAIL PROTECTED] wrote: It's a good point... Currently the session cache is global, and all AsyncHttpClient instances are forced to share it. The main thing that concerns me is that as a result the connections will retain all the socket properties that came from the AsyncHttpClient instance that opened the connection. This might not be intuitive to say the least. For example, one AsyncHttpClient instance opens a connection with TCP delay disabled, and then another instance (this time with TCP delay enabled) comes along and picks up this connection for reuse. Contrary to what it expects, it would get a connection with TCP delay disabled. Right and this might be a bigger issue for SSL connections where you might need to distinguish between cached connections based on the client certs, CA certs, or enabled cipher suites (but I'm not sure if these options can be set on the AsyncHttpClient). Jarek
[BUILD] 2.1: Failed for Revision: 611913
OpenEJB trunk at 61
Geronimo Revision: 611913 built with tests included
See the full build-1500.log file at
http://people.apache.org/~prasad/binaries/trunk/20080114/build-1500.log
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/maven/maven-profile/2.0/maven-profile-2.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-profile/2.0/maven-profile-2.0.jar
29K downloaded
[INFO] [enforcer:enforce {execution: default}]
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/mojo/shitty-maven-plugin/1.0-alpha-1-SNAPSHOT/shitty-maven-plugin-1.0-alpha-1-20071025.222447-23.pom
Downloading:
http://snapshots.repository.codehaus.org/org/codehaus/mojo/shitty-maven-plugin/1.0-alpha-1-SNAPSHOT/shitty-maven-plugin-1.0-alpha-1-20071025.222447-23.pom
11K downloaded
Downloading:
http://repo1.maven.org/maven2/backport-util-concurrent/backport-util-concurrent/3.0/backport-util-concurrent-3.0.pom
909b downloaded
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime-default:1.0-beta-3-SNAPSHOT:
checking for updates from apache-snapshots
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime-default:1.0-beta-3-SNAPSHOT:
checking for updates from codehaus-snapshots
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime-default:1.0-beta-3-SNAPSHOT:
checking for updates from codehaus.org
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime-default:1.0-beta-3-SNAPSHOT:
checking for updates from apache.snapshots
Downloading:
http://snapshots.repository.codehaus.org/org/codehaus/mojo/groovy/runtime/groovy-runtime-default/1.0-beta-3-SNAPSHOT/groovy-runtime-default-1.0-beta-3-20071206.003319-3.pom
1K downloaded
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime:1.0-beta-3-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime:1.0-beta-3-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime:1.0-beta-3-SNAPSHOT: checking
for updates from codehaus.org
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime:1.0-beta-3-SNAPSHOT: checking
for updates from apache.snapshots
Downloading:
http://snapshots.repository.codehaus.org/org/codehaus/mojo/groovy/runtime/groovy-runtime/1.0-beta-3-SNAPSHOT/groovy-runtime-1.0-beta-3-20071206.003319-3.pom
2K downloaded
[INFO] snapshot org.codehaus.mojo.groovy:groovy:1.0-beta-3-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot org.codehaus.mojo.groovy:groovy:1.0-beta-3-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot org.codehaus.mojo.groovy:groovy:1.0-beta-3-SNAPSHOT: checking
for updates from codehaus.org
[INFO] snapshot org.codehaus.mojo.groovy:groovy:1.0-beta-3-SNAPSHOT: checking
for updates from apache.snapshots
Downloading:
http://snapshots.repository.codehaus.org/org/codehaus/mojo/groovy/groovy/1.0-beta-3-SNAPSHOT/groovy-1.0-beta-3-20071206.003319-8.pom
22K downloaded
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/mojo/16/mojo-16.pom
8K downloaded
Downloading:
http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.4.3/slf4j-api-1.4.3.pom
2K downloaded
Downloading:
http://repo1.maven.org/maven2/org/slf4j/slf4j-parent/1.4.3/slf4j-parent-1.4.3.pom
7K downloaded
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime-1.1:1.0-beta-3-SNAPSHOT:
checking for updates from apache-snapshots
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime-1.1:1.0-beta-3-SNAPSHOT:
checking for updates from codehaus-snapshots
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime-1.1:1.0-beta-3-SNAPSHOT:
checking for updates from codehaus.org
[INFO] snapshot
org.codehaus.mojo.groovy.runtime:groovy-runtime-1.1:1.0-beta-3-SNAPSHOT:
checking for updates from apache.snapshots
Downloading:
http://snapshots.repository.codehaus.org/org/codehaus/mojo/groovy/runtime/groovy-runtime-1.1/1.0-beta-3-SNAPSHOT/groovy-runtime-1.1-1.0-beta-3-20071206.003319-3.pom
2K downloaded
[INFO] snapshot
org.codehaus.mojo.groovy.feature:groovy-feature-support:1.0-beta-3-SNAPSHOT:
checking for updates from apache-snapshots
[INFO] snapshot
org.codehaus.mojo.groovy.feature:groovy-feature-support:1.0-beta-3-SNAPSHOT:
checking for updates from codehaus-snapshots
[INFO] snapshot
org.codehaus.mojo.groovy.feature:groovy-feature-support:1.0-beta-3-SNAPSHOT:
checking for updates from codehaus.org
[INFO] snapshot
org.codehaus.mojo.groovy.feature:groovy-feature-support:1.0-beta-3-SNAPSHOT:
checking for updates from apache.snapshots
Downloading:
http://snapshots.repository.codehaus.org/org/codehaus/mojo/groovy/feature/groovy-feature-support/1.0-beta-3-SNAPSHOT/groovy-feature-support-1.0-beta-3-20071206.003319-3.pom
1K downloaded
[INFO] snapshot
org.codehaus.mojo.groovy.feature:groovy-feature:1.0-beta-3-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
Re: Is there a problem with AsyncHttpClient connection reuse?
Yes, if you used a different configuration for the SSL, then it would be another issue. The questions are: - Do we want to even allow an option for using a shared connection cache? The benefit of a shared connection cache is ... just that; connection reuse will be maximized for the given process. However, the drawback is that you may run into unexpected socket configuration/SSL configuration behavior when you hand the connections to a different client instance. - If we do allow it, what should be the default? I think *not* sharing the connection cache might be a better default behavior. Thanks, Sangjin On 1/14/08, Jarek Gawor [EMAIL PROTECTED] wrote: On 1/14/08, Sangjin Lee [EMAIL PROTECTED] wrote: It's a good point... Currently the session cache is global, and all AsyncHttpClient instances are forced to share it. The main thing that concerns me is that as a result the connections will retain all the socket properties that came from the AsyncHttpClient instance that opened the connection. This might not be intuitive to say the least. For example, one AsyncHttpClient instance opens a connection with TCP delay disabled, and then another instance (this time with TCP delay enabled) comes along and picks up this connection for reuse. Contrary to what it expects, it would get a connection with TCP delay disabled. Right and this might be a bigger issue for SSL connections where you might need to distinguish between cached connections based on the client certs, CA certs, or enabled cipher suites (but I'm not sure if these options can be set on the AsyncHttpClient). Jarek
Re: Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
Things seems to be in a flux right now as I get a parse exception on 'geronimo-plugin-list' so I guess I have to wait with testing out plugins on a fresh build. I get back to you when this is out of the way. regards Peter P 23:44:02,710 INFO [PluginInstallerGBean] Attempting to download file:/home/ppe/.m2/repository/geronimo-plugins.xml 23:44:02,860 ERROR [PluginInstallerGBean] Unable to load repository configuration data org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'geronimo-plugin-list'. at org.apache.geronimo.system.plugin.PluginInstallerGBean$3.error(PluginInstallerGBean.java:1440) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) Peter Petersson wrote: David Jencks wrote: I finally got around to applying your roller plugin patch but I can't reproduce this either on jetty or tomcat. I'm on osx I wonder if its due to the different os Nice :) hmmm well I am on Linux and Hernan got this on a Windows XP box and maybe osx is spared but there is clearly something wrong with my environment or else the server is getting into a faulty state due to the plugin modules I install (roller-tomcat, roller-themes) although I doubt the later is the case ;), I will try investigate this a bit more, will post my findings (if any) here but If you or anyone else have some suggestions or hints on what may cause this let me know. I will do a svn update; mvn clean install; and go make some coffee and try out the new build with different setups. regards Peter P thanks david jencks On Jan 14, 2008, at 2:28 AM, Peter Petersson wrote: Anyone still getting this? On the first startup the server starts fine but every following startup after a shutdown (or even reboot of comp) fails. I have had this problem for some time now (2 weeks I think) and to get around it I keep reinstalling the server but that's getting a bit boring :). This is happening for me on new builds of 2.1. The only thing I have done in between is installing the roller plugin. I have also tried startup with load=false in config.xml on the roller modules before startup (just in case the plugin would be causing the startup problem) but it dose not help. Any clues on what may causing this ? thanks Peter P 09:05:33,865 INFO [Log4jService] -- 09:05:33,865 INFO [Log4jService] Started Logging Service 09:05:33,865 INFO [Log4jService] Runtime Information: 09:05:33,865 INFO [Log4jService] Install Directory = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT 09:05:33,865 INFO [Log4jService] JVM in use = Sun Microsystems Inc. Java 1.5.0_13 09:05:33,865 INFO [Log4jService] Java Information: 09:05:33,865 INFO [Log4jService] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 09:05:33,865 INFO [Log4jService] System property [java.runtime.version] = 1.5.0_13-b05 09:05:33,865 INFO [Log4jService] System property [os.name] = Linux 09:05:33,865 INFO [Log4jService] System property [os.version] = 2.6.22-14-generic 09:05:33,871 INFO [Log4jService] System property [sun.os.patch.level] = unknown 09:05:33,871 INFO [Log4jService] System property [os.arch] = i386 09:05:33,871 INFO [Log4jService] System property [java.class.version] = 49.0 09:05:33,871 INFO [Log4jService] System property [locale] = sv_SE 09:05:33,871 INFO [Log4jService] System property [unicode.encoding]= UnicodeLittle 09:05:33,871 INFO [Log4jService] System property [file.encoding] = UTF-8 09:05:33,871 INFO [Log4jService] System property [java.vm.name]= Java HotSpot(TM) Server VM 09:05:33,871 INFO [Log4jService] System property [java.vm.vendor] = Sun Microsystems Inc. 09:05:33,871 INFO [Log4jService] System property [java.vm.version] = 1.5.0_13-b05 09:05:33,871 INFO [Log4jService] System property [java.vm.info]= mixed mode 09:05:33,871 INFO [Log4jService] System property [java.home] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre 09:05:33,871 INFO [Log4jService] System property [java.classpath] = null 09:05:33,871 INFO [Log4jService] System property [java.library.path] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i386/server:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i386:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/../lib/i386 09:05:33,871 INFO [Log4jService] System property [java.endorsed.dirs] = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT/lib/endorsed:/usr/lib/jvm/java-1.5.0-sun/jre/lib/endorsed 09:05:33,871 INFO [Log4jService] System property [java.ext.dirs] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/ext 09:05:33,871 INFO [Log4jService] System property [sun.boot.class.path] =
Re: [YOKO]
On Jan 14, 2008 8:05 PM, Alan D. Cabrera wrote: On Jan 14, 2008, at 4:35 AM, Rick McGuire wrote: What cleanup steps need to be taken with the yoko code now that it's been made a subproject in Geronimo? The first obvious one would be to remove the non-core components from the trunk. The second would be to remove the incubating from the version names. Agreed +1 Is JDK 1.4 still a given or has geronimo upgraded it's JDK dependency to 1.5 since yoko entered the incubator? We shouldn't change the required JDK in a point release, so this seems like a good time to revisit this decision. The current code was never made into an official Yoko release. Should we attempt to get this out as an official v1 release as soon as the basic cleanup is completed? I think that some people had some concerns about a release but I think that they were more focused on proper documentation and releasing a well rounded product. That was me. My concern wasn't so much about user docs but developer level documentation, see the Answer this question... yoko issues in jira. Those questions mostly about being able to attract new developers. It's my opinion that it's ok to release so long as the code is good enough. With that said, I would like to make a 1.0 release. Yes, the code could use some cleanup but it does pass certification and we can always improve things later, in another release. This of course assumes that we don't have to pay too much attention to backward compatibility. Does each follow-up version have to be a drop-in replacement of the first 1.0 release? Or is it OK to change ORB properties and such, as long as the changes are documented in the release notes (which is what I hope, but I don't know the requirements of Geronimo and Harmony)? Regards, Lars
Re: Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
In the men time I resorted to the assembly I pulled together yesterday and just doing a ./startup.sh; ./shutdown.sh; ./startup.sh fails on the second startup with the error indicated bellow. Its getting late here so I will look in to this again tomorrow hopefully with a fresh build. regards Peter Petersson Peter Petersson wrote: Things seems to be in a flux right now as I get a parse exception on 'geronimo-plugin-list' so I guess I have to wait with testing out plugins on a fresh build. I get back to you when this is out of the way. regards Peter P 23:44:02,710 INFO [PluginInstallerGBean] Attempting to download file:/home/ppe/.m2/repository/geronimo-plugins.xml 23:44:02,860 ERROR [PluginInstallerGBean] Unable to load repository configuration data org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'geronimo-plugin-list'. at org.apache.geronimo.system.plugin.PluginInstallerGBean$3.error(PluginInstallerGBean.java:1440) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) Peter Petersson wrote: David Jencks wrote: I finally got around to applying your roller plugin patch but I can't reproduce this either on jetty or tomcat. I'm on osx I wonder if its due to the different os Nice :) hmmm well I am on Linux and Hernan got this on a Windows XP box and maybe osx is spared but there is clearly something wrong with my environment or else the server is getting into a faulty state due to the plugin modules I install (roller-tomcat, roller-themes) although I doubt the later is the case ;), I will try investigate this a bit more, will post my findings (if any) here but If you or anyone else have some suggestions or hints on what may cause this let me know. I will do a svn update; mvn clean install; and go make some coffee and try out the new build with different setups. regards Peter P thanks david jencks On Jan 14, 2008, at 2:28 AM, Peter Petersson wrote: Anyone still getting this? On the first startup the server starts fine but every following startup after a shutdown (or even reboot of comp) fails. I have had this problem for some time now (2 weeks I think) and to get around it I keep reinstalling the server but that's getting a bit boring :). This is happening for me on new builds of 2.1. The only thing I have done in between is installing the roller plugin. I have also tried startup with load=false in config.xml on the roller modules before startup (just in case the plugin would be causing the startup problem) but it dose not help. Any clues on what may causing this ? thanks Peter P 09:05:33,865 INFO [Log4jService] -- 09:05:33,865 INFO [Log4jService] Started Logging Service 09:05:33,865 INFO [Log4jService] Runtime Information: 09:05:33,865 INFO [Log4jService] Install Directory = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT 09:05:33,865 INFO [Log4jService] JVM in use = Sun Microsystems Inc. Java 1.5.0_13 09:05:33,865 INFO [Log4jService] Java Information: 09:05:33,865 INFO [Log4jService] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 09:05:33,865 INFO [Log4jService] System property [java.runtime.version] = 1.5.0_13-b05 09:05:33,865 INFO [Log4jService] System property [os.name] = Linux 09:05:33,865 INFO [Log4jService] System property [os.version] = 2.6.22-14-generic 09:05:33,871 INFO [Log4jService] System property [sun.os.patch.level] = unknown 09:05:33,871 INFO [Log4jService] System property [os.arch] = i386 09:05:33,871 INFO [Log4jService] System property [java.class.version] = 49.0 09:05:33,871 INFO [Log4jService] System property [locale] = sv_SE 09:05:33,871 INFO [Log4jService] System property [unicode.encoding]= UnicodeLittle 09:05:33,871 INFO [Log4jService] System property [file.encoding] = UTF-8 09:05:33,871 INFO [Log4jService] System property [java.vm.name]= Java HotSpot(TM) Server VM 09:05:33,871 INFO [Log4jService] System property [java.vm.vendor] = Sun Microsystems Inc. 09:05:33,871 INFO [Log4jService] System property [java.vm.version] = 1.5.0_13-b05 09:05:33,871 INFO [Log4jService] System property [java.vm.info]= mixed mode 09:05:33,871 INFO [Log4jService] System property [java.home] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre 09:05:33,871 INFO [Log4jService] System property [java.classpath] = null 09:05:33,871 INFO [Log4jService] System property [java.library.path] = /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i386/server:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/lib/i386:/usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/../lib/i386 09:05:33,871 INFO [Log4jService] System property
Clustering inadvertently invoked from Eclipse plugin
Hi, when I deploy a web project from the Geronimo Eclipse plugin via JMX it appears that the clustering code is getting invoked even though I do not explicitly include the tomcat-clustering-wadi / tag in my Geronimo deployment plan (which is what I thought was required for clustering). As a result, the web project gets deployed into the cluster-repository (with the G_SLAVE suffix), the master-repository (also with the G_SLAVE suffix), and the repository subdirectories, resulting in the DeploymentException below. The same project deploys fine from the command line (with nothing getting deployed into the cluster/master repositories). Does anyone have any idea why this might be happening and if there is something I can do to prevent this behavior. Or do I need to disable the clustering mechanism somehow ?? Thanks for any assistance Deployer operation failed: Module default/test3/1.0/car already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module default/test3/1.0/car already exists in the server. Try to undeploy it first or use the redeploy command. -- Thanks, Tim McConnell
Re: Clustering inadvertently invoked from Eclipse plugin
Hello Tim, I am pretty sure the Eclipse plugin is deploying to all the Targets returned by DeploymentManager.getTargets(). It should instead deploy to the first returned Targets. By convention, this first Target is the default Configuration store, which is explicitly configured by users. Also, there is no relationships between the existence or not of tomcat-clustering-wadi/ and the cluster/master repositories. When the tomcat-clustering-wadi/ element is present, this triggers a build of a clustered Web-application, i.e. with the necessary clustering components. When you deploy to the Target corresponding to the master repository, then you build the application the usual way (versus with the necessary clustering components) but you cascade the resulting configuration to all the declared nodes. I hope it helps. Thanks, Gianny On 15/01/2008, at 12:27 PM, Tim McConnell wrote: Hi, when I deploy a web project from the Geronimo Eclipse plugin via JMX it appears that the clustering code is getting invoked even though I do not explicitly include the tomcat-clustering-wadi / tag in my Geronimo deployment plan (which is what I thought was required for clustering). As a result, the web project gets deployed into the cluster-repository (with the G_SLAVE suffix), the master-repository (also with the G_SLAVE suffix), and the repository subdirectories, resulting in the DeploymentException below. The same project deploys fine from the command line (with nothing getting deployed into the cluster/master repositories). Does anyone have any idea why this might be happening and if there is something I can do to prevent this behavior. Or do I need to disable the clustering mechanism somehow ?? Thanks for any assistance Deployer operation failed: Module default/test3/1.0/car already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module default/ test3/1.0/car already exists in the server. Try to undeploy it first or use the redeploy command. -- Thanks, Tim McConnell
Re: Clustering inadvertently invoked from Eclipse plugin
Hi Gianny, yes that does help. Thanks very much !! Gianny Damour wrote: Hello Tim, I am pretty sure the Eclipse plugin is deploying to all the Targets returned by DeploymentManager.getTargets(). It should instead deploy to the first returned Targets. By convention, this first Target is the default Configuration store, which is explicitly configured by users. Also, there is no relationships between the existence or not of tomcat-clustering-wadi/ and the cluster/master repositories. When the tomcat-clustering-wadi/ element is present, this triggers a build of a clustered Web-application, i.e. with the necessary clustering components. When you deploy to the Target corresponding to the master repository, then you build the application the usual way (versus with the necessary clustering components) but you cascade the resulting configuration to all the declared nodes. I hope it helps. Thanks, Gianny On 15/01/2008, at 12:27 PM, Tim McConnell wrote: Hi, when I deploy a web project from the Geronimo Eclipse plugin via JMX it appears that the clustering code is getting invoked even though I do not explicitly include the tomcat-clustering-wadi / tag in my Geronimo deployment plan (which is what I thought was required for clustering). As a result, the web project gets deployed into the cluster-repository (with the G_SLAVE suffix), the master-repository (also with the G_SLAVE suffix), and the repository subdirectories, resulting in the DeploymentException below. The same project deploys fine from the command line (with nothing getting deployed into the cluster/master repositories). Does anyone have any idea why this might be happening and if there is something I can do to prevent this behavior. Or do I need to disable the clustering mechanism somehow ?? Thanks for any assistance Deployer operation failed: Module default/test3/1.0/car already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module default/test3/1.0/car already exists in the server. Try to undeploy it first or use the redeploy command. -- Thanks, Tim McConnell -- Thanks, Tim McConnell
