[jira] Created: (GERONIMO-3631) Move to OpenJPA 1.0.1
Move to OpenJPA 1.0.1 - Key: GERONIMO-3631 URL: https://issues.apache.org/jira/browse/GERONIMO-3631 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Reporter: Joe Bohn Assignee: Joe Bohn Priority: Minor Need to upgrade OpenJPA from 1.0.0 to 1.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3631) Move to OpenJPA 1.0.1
[ https://issues.apache.org/jira/browse/GERONIMO-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn updated GERONIMO-3631: --- Affects Version/s: 2.1 Move to OpenJPA 1.0.1 - Key: GERONIMO-3631 URL: https://issues.apache.org/jira/browse/GERONIMO-3631 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Joe Bohn Assignee: Joe Bohn Priority: Minor Need to upgrade OpenJPA from 1.0.0 to 1.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3595) Tomcat*StatsImpl and Jetty*StatsImpl to return generic StatsImpl object
[ https://issues.apache.org/jira/browse/GERONIMO-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen closed GERONIMO-3595. -- Resolution: Invalid Fix Version/s: 2.1 This violates the JSR 77 spec. There must be a getXYZ() for each XYZ stats. By using the generic object, the client will not be able to use getXYZ(). Tomcat*StatsImpl and Jetty*StatsImpl to return generic StatsImpl object --- Key: GERONIMO-3595 URL: https://issues.apache.org/jira/browse/GERONIMO-3595 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Jetty, management, Tomcat Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Fix For: 2.1 Attachments: geronimo-3595.patch Recently, there has been a discussion to make the getStats() operation return the generic StatsImpl object instead of the container specific object. The advantage of having a generic Stats object returned is that clients who wish to view the jsr77 statistics do not need the container specific statsimpl classes in their classloader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JNDI lookup problem in Jetty portlet
Does anybody have thoughts on this or know how this should work? Jarek On Nov 19, 2007 11:07 PM, Jarek Gawor [EMAIL PROTECTED] wrote: I've looked at this a bit and here's my current understanding of the problem. First, we are dealing with two different web application contexts (/console and /MonitoringPortlet) and both web app contexts have different JNDI trees with different resources. The console is basically forwarding a request from /console to /MonitoringPortlet. It looks like on Jetty when a request is forwarded from one context to another, the JNDI tree associated with the current thread does NOT change for the duration of the call. That means, when a monitoring portlet looks for resources in JNDI it actaully gets /console JNDI tree instead of its own. Your portlet works on Tomcat as Tomcat appears to be properly switching the JNDI trees during the call. So this seems like a bug in Jetty but I couldn't really find much info on how this should work in the specs. Does anybody know? For now I opened a bug to track this issue: https://issues.apache.org/jira/browse/GERONIMO-3609 Jarek On Nov 16, 2007 11:03 AM, Viet Nguyen [EMAIL PROTECTED] wrote: Hi All, I am having trouble looking up a DataSource from an EAR containing a WAR (which is where the lookup takes place) using JNDI. I find it to be really weird, because I can look up the DataSource fine if I do it through a JSP page or a servlet. However, when I try to look it up in portlet code, the jndi name does not seem to be visible, although it is visible in the JNDI viewer. Additionally, I have successfully looked it up through jsp and servlets. This is only a problem in Jetty, because the same code works fine for Tomcat. Is this possibly a Geronimo/XBean bug in how we bind JNDI names? I am not familiar with the jndi binding process, so any expertise in that area or the portlet area will be much appreciated. Thanks, Viet
[BUILD] 2.1: Failed for Revision: 594541
Geronimo Revision: 597960 built with tests included See the full build-0300.log file at http://people.apache.org/~prasad/binaries/2.0/20071125/build-0300.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071125 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 23 minutes 42 seconds [INFO] Finished at: Sun Nov 25 03:28:54 EST 2007 [INFO] Final Memory: 200M/1003M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071125/logs-0300/test.log [INFO] Running console-testsuite.basic-console [INFO] Tests run: 38, Failures: 38, Errors: 0, Skipped: 0, Time elapsed: 0.34 sec FAILURE! [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 0.194 sec FAILURE! -- [INFO] Running corba-testsuite.corba-mytime [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.045 sec FAILURE! [INFO] Running deployment-testsuite.deployment [INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.052 sec FAILURE! [INFO] Running deployment-testsuite.jca-cms [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec FAILURE! [INFO] Running enterprise-testsuite.jms [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.041 sec FAILURE! [INFO] Running jpa-testsuite.jpa [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec FAILURE! [INFO] Running sec-testsuite.security [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec FAILURE! [INFO] Running web-testsuite.jsps [INFO] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec FAILURE! [INFO] Running web-testsuite.myfaces [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec FAILURE! -- [INFO] Running web-testsuite.security [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec FAILURE! [INFO] Running web-testsuite.references [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec FAILURE! [INFO] Running web-testsuite.servlets [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.058 sec FAILURE!
Re: svn: Can't move source to dest on Windows
Thanks Kevan, can checkout content again, though found out the comma is actually accepted (I guess I need a bigger keyboard ;-) ) Cheers! Hernan Kevan Miller wrote: On Nov 20, 2007, at 1:48 PM, Hernan Cunico wrote: yeah, the comma is also a problem. Cheers! Hernan Vamsavardhana Reddy wrote: There is also a comma in the filename!! Should that be got rid of too? ++Vamsi On Nov 20, 2007 1:27 AM, Jarek Gawor [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: SVN checkout on Windows is failing for me becuase recently a file was renamed to have : in the name. That's not supported on Windows. Can we change this back? Here's the change: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/ http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/ Here's the error I'm seeing: svn: In directory 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d' svn: Can't move source to dest svn: Can't move 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/tmp/prop-base/geronimo-commands:start-server, default.groovy.svn-base' to 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/prop-base/geronimo-commands:start-server,default.groovy.svn-base': No such file or directory Jarek OK. I've svn mv'ed the file to a filename format that won't break windows users, but won't work also. At least Windows users can svn co/up our source, now. Gianny or Jason, Something that one of you can resolve? Here's what I did: svn ci --message temporary hack. : and , are not supported by windows in a filename. so windows users aren't able to checkout code. Need a more portable filename solution Deleting rc.d/geronimo-commands:start-server,default.groovy Adding rc.d/geronimo-commandsCOLONstart-serverCOMMAdefault.groovy Committed revision 597170. --kevan
Re: svn: Can't move source to dest on Windows
Thanks Kevan, can checkout content again, though found out the comma is actually accepted (I guess I need a bigger keyboard ;-) ) Cheers! Hernan Kevan Miller wrote: On Nov 20, 2007, at 1:48 PM, Hernan Cunico wrote: yeah, the comma is also a problem. Cheers! Hernan Vamsavardhana Reddy wrote: There is also a comma in the filename!! Should that be got rid of too? ++Vamsi On Nov 20, 2007 1:27 AM, Jarek Gawor [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: SVN checkout on Windows is failing for me becuase recently a file was renamed to have : in the name. That's not supported on Windows. Can we change this back? Here's the change: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/ http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/ Here's the error I'm seeing: svn: In directory 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d' svn: Can't move source to dest svn: Can't move 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/tmp/prop-base/geronimo-commands:start-server, default.groovy.svn-base' to 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/prop-base/geronimo-commands:start-server,default.groovy.svn-base': No such file or directory Jarek OK. I've svn mv'ed the file to a filename format that won't break windows users, but won't work also. At least Windows users can svn co/up our source, now. Gianny or Jason, Something that one of you can resolve? Here's what I did: svn ci --message temporary hack. : and , are not supported by windows in a filename. so windows users aren't able to checkout code. Need a more portable filename solution Deleting rc.d/geronimo-commands:start-server,default.groovy Adding rc.d/geronimo-commandsCOLONstart-serverCOMMAdefault.groovy Committed revision 597170. --kevan
Geronimo 2.1 dependencies on SNAPSHOTs
I was just looking in the root pom. It seems there are a number of snapshot dependencies that we would need to eliminate prior to a 2.1 release (or make private builds). I'll start working my way through those that have released. We'll need to start pushing for some releases of those that are not yet available ... and of course some are our own specs. OpenEJB3.0.0-SNAPSHOT Pluto 1.2.0-SNAPSHOT geronimo-jaspi_1.0_spec1.0-SNAPSHOT geronimo-javamail_1.4_mail 1.3-SNAPSHOT commons-dbcp 1.3-SNAPSHOT yoko 1.0-incubating-SNAPSHOT myfaces1.2.1-SNAPSHOT gshell 1.0-alpha-1-SNAPSHOT jspc_compiler_tomcat6 2.0-SNAPSHOT Are there other components that we should upgrade as well? BTW, I just upgraded our dep on OpenJPA 1.0.0 to 1.0.1 after verifying that it didn't create any TCK issues. Joe
Re: Geronimo 2.1 dependencies on SNAPSHOTs
I'd like to find some time to test the geronimo trunk with the latest set of specs that i've modified to make them OSGi friendly, but I doubt I will have much time this week. It would be a good test to make sure there is no regression caused by the change in the packaging mechanism... On Nov 26, 2007 5:29 PM, Joe Bohn [EMAIL PROTECTED] wrote: I was just looking in the root pom. It seems there are a number of snapshot dependencies that we would need to eliminate prior to a 2.1 release (or make private builds). I'll start working my way through those that have released. We'll need to start pushing for some releases of those that are not yet available ... and of course some are our own specs. OpenEJB3.0.0-SNAPSHOT Pluto 1.2.0-SNAPSHOT geronimo-jaspi_1.0_spec1.0-SNAPSHOT geronimo-javamail_1.4_mail 1.3-SNAPSHOT commons-dbcp 1.3-SNAPSHOT yoko 1.0-incubating-SNAPSHOT myfaces1.2.1-SNAPSHOT gshell 1.0-alpha-1-SNAPSHOT jspc_compiler_tomcat6 2.0-SNAPSHOT Are there other components that we should upgrade as well? BTW, I just upgraded our dep on OpenJPA 1.0.0 to 1.0.1 after verifying that it didn't create any TCK issues. Joe -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo 2.1 dependencies on SNAPSHOTs
The javamail version can be made into a release. It has a dependency on the latest spec version, so we'd need to release that one too. For yoko, I suspect we'll just need to do what we did for 2.0 and have a known version in the Geronimo repository. Rick Joe Bohn wrote: I was just looking in the root pom. It seems there are a number of snapshot dependencies that we would need to eliminate prior to a 2.1 release (or make private builds). I'll start working my way through those that have released. We'll need to start pushing for some releases of those that are not yet available ... and of course some are our own specs. OpenEJB3.0.0-SNAPSHOT Pluto 1.2.0-SNAPSHOT geronimo-jaspi_1.0_spec1.0-SNAPSHOT geronimo-javamail_1.4_mail 1.3-SNAPSHOT commons-dbcp 1.3-SNAPSHOT yoko 1.0-incubating-SNAPSHOT myfaces1.2.1-SNAPSHOT gshell 1.0-alpha-1-SNAPSHOT jspc_compiler_tomcat6 2.0-SNAPSHOT Are there other components that we should upgrade as well? BTW, I just upgraded our dep on OpenJPA 1.0.0 to 1.0.1 after verifying that it didn't create any TCK issues. Joe
[jira] Created: (GERONIMO-3632) monitoring client needs to have jetty and tomcat plugin
monitoring client needs to have jetty and tomcat plugin --- Key: GERONIMO-3632 URL: https://issues.apache.org/jira/browse/GERONIMO-3632 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen The client side of the monitoring tool needs to be pluginized. Specifically, it should be split into a jetty and tomcat plugin because of the dependency onto dojo-jetty and dojo-tomcat. Additionally, the datasource itself should be packaged as a plugin too, so that future users who wish to use a different database can do so more easily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3632) monitoring client needs to have jetty and tomcat plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3632: --- Attachment: geronimo-3632.patch monitoring client needs to have jetty and tomcat plugin --- Key: GERONIMO-3632 URL: https://issues.apache.org/jira/browse/GERONIMO-3632 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Attachments: geronimo-3632.patch The client side of the monitoring tool needs to be pluginized. Specifically, it should be split into a jetty and tomcat plugin because of the dependency onto dojo-jetty and dojo-tomcat. Additionally, the datasource itself should be packaged as a plugin too, so that future users who wish to use a different database can do so more easily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3609) JNDI lookup problem on fowarded calls in Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-3609: -- Assignee: David Jencks JNDI lookup problem on fowarded calls in Jetty -- Key: GERONIMO-3609 URL: https://issues.apache.org/jira/browse/GERONIMO-3609 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x, 2.1 Reporter: Jarek Gawor Assignee: David Jencks Attachments: GERONIMO-3609.patch I am having trouble looking up a DataSource from an EAR containing a WAR (which is where the lookup takes place) using JNDI. I find it to be really weird, because I can look up the DataSource fine if I do it through a JSP page or a servlet. However, when I try to look it up in portlet code, the jndi name does not seem to be visible, although it is visible in the JNDI viewer. Additionally, I have successfully looked it up through jsp and servlets. This is only a problem in Jetty, because the same code works fine for Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3609) JNDI lookup problem on fowarded calls in Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545548 ] David Jencks commented on GERONIMO-3609: Proposed fix will work but I think it introduces duplication that we can remove checking it out. JNDI lookup problem on fowarded calls in Jetty -- Key: GERONIMO-3609 URL: https://issues.apache.org/jira/browse/GERONIMO-3609 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x, 2.1 Reporter: Jarek Gawor Assignee: David Jencks Attachments: GERONIMO-3609.patch I am having trouble looking up a DataSource from an EAR containing a WAR (which is where the lookup takes place) using JNDI. I find it to be really weird, because I can look up the DataSource fine if I do it through a JSP page or a servlet. However, when I try to look it up in portlet code, the jndi name does not seem to be visible, although it is visible in the JNDI viewer. Additionally, I have successfully looked it up through jsp and servlets. This is only a problem in Jetty, because the same code works fine for Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3632) monitoring client needs to have jetty and tomcat plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545565 ] Erik B. Craig commented on GERONIMO-3632: - Applied in rev 598392. Thanks viet. monitoring client needs to have jetty and tomcat plugin --- Key: GERONIMO-3632 URL: https://issues.apache.org/jira/browse/GERONIMO-3632 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Attachments: geronimo-3632.patch The client side of the monitoring tool needs to be pluginized. Specifically, it should be split into a jetty and tomcat plugin because of the dependency onto dojo-jetty and dojo-tomcat. Additionally, the datasource itself should be packaged as a plugin too, so that future users who wish to use a different database can do so more easily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo 2.1 dependencies on SNAPSHOTs
On Nov 26, 2007, at 11:29 AM, Joe Bohn wrote: I was just looking in the root pom. It seems there are a number of snapshot dependencies that we would need to eliminate prior to a 2.1 release (or make private builds). I'll start working my way through those that have released. We'll need to start pushing for some releases of those that are not yet available ... and of course some are our own specs. OpenEJB3.0.0-SNAPSHOT I started release discussion on [EMAIL PROTECTED], over the weekend. Pluto 1.2.0-SNAPSHOT Has anybody pinged their list? geronimo-jaspi_1.0_spec1.0-SNAPSHOT Do we have any real uses of jaspi? Perhaps we should move jaspi out to post-2.1? geronimo-javamail_1.4_mail 1.3-SNAPSHOT Rick, are we ready to start release proceedings? commons-dbcp 1.3-SNAPSHOT This looks like an openejb server dependency (i.e. not a container dependency). Why would we need it? yoko 1.0-incubating-SNAPSHOT Rick, do we need a new yoko version? Or reuse the version used by G 2.0.x? myfaces1.2.1-SNAPSHOT Has anybody pinged their list? gshell 1.0-alpha-1-SNAPSHOT Given early stages of gshell development, we may want to release this concurrent with a 2.1 release... jspc_compiler_tomcat6 2.0-SNAPSHOT I think this should be 2.0-alpha-1 looks like only half of an update was merged from branches/2.0. --kevan
[BUILD] 2.0: Failed for Revision: 598385
Geronimo Revision: 598385 built with tests included See the full build-1500.log file at http://people.apache.org/~prasad/binaries/2.0/20071126/build-1500.log apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) jtidy:jtidy:jar:8.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=jtidy -DartifactId=jtidy \ -Dversion=8.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=jtidy -DartifactId=jtidy \ -Dversion=8.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.plugins:testsuite-maven-plugin:maven-plugin:2.0.3-SNAPSHOT 2) jtidy:jtidy:jar:8.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.plugins:testsuite-maven-plugin:maven-plugin:2.0.3-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), jtidy.sourceforge (http://jtidy.sourceforge.net/snapshots), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) 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(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) jtidy:jtidy:jar:8.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=jtidy -DartifactId=jtidy \ -Dversion=8.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=jtidy -DartifactId=jtidy \ -Dversion=8.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.plugins:testsuite-maven-plugin:maven-plugin:2.0.3-SNAPSHOT 2) jtidy:jtidy:jar:8.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.plugins:testsuite-maven-plugin:maven-plugin:2.0.3-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), jtidy.sourceforge (http://jtidy.sourceforge.net/snapshots), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively
Re: Geronimo 2.1 dependencies on SNAPSHOTs
On Nov 26, 2007, at 2:36 PM, Kevan Miller wrote: On Nov 26, 2007, at 11:29 AM, Joe Bohn wrote: Pluto 1.2.0-SNAPSHOT Has anybody pinged their list? Joe and I have pinged their list, no response yet. myfaces1.2.1-SNAPSHOT Has anybody pinged their list? Matthias indicated that he would be willing to push a MyFaces release when JSF TCK is 100% passing. But I would recommend that we postpone making that request until all JEE tests are passing in Geronimo since JSF is very susceptible to lower level changes in the servlet engine, deployment code, application classloader, etc. Best wishes, Paul
Re: Geronimo 2.1 dependencies on SNAPSHOTs
Kevan Miller wrote: On Nov 26, 2007, at 11:29 AM, Joe Bohn wrote: I was just looking in the root pom. It seems there are a number of snapshot dependencies that we would need to eliminate prior to a 2.1 release (or make private builds). I'll start working my way through those that have released. So ... when I actually looked I learned that there are no releases for these snapshots yet. We'll need to start pushing for some releases of those that are not yet available ... and of course some are our own specs. OpenEJB3.0.0-SNAPSHOT I started release discussion on [EMAIL PROTECTED], over the weekend. Pluto 1.2.0-SNAPSHOT Has anybody pinged their list? I pinged the pluto list earlier today. geronimo-jaspi_1.0_spec1.0-SNAPSHOT Do we have any real uses of jaspi? Perhaps we should move jaspi out to post-2.1? geronimo-javamail_1.4_mail 1.3-SNAPSHOT Rick, are we ready to start release proceedings? commons-dbcp 1.3-SNAPSHOT This looks like an openejb server dependency (i.e. not a container dependency). Why would we need it? I was wondering that myself ... yoko 1.0-incubating-SNAPSHOT Rick, do we need a new yoko version? Or reuse the version used by G 2.0.x? myfaces1.2.1-SNAPSHOT Has anybody pinged their list? gshell 1.0-alpha-1-SNAPSHOT Given early stages of gshell development, we may want to release this concurrent with a 2.1 release... jspc_compiler_tomcat6 2.0-SNAPSHOT I think this should be 2.0-alpha-1 looks like only half of an update was merged from branches/2.0. Ok, I'll look into it. --kevan
[jira] Commented: (GERONIMO-3609) JNDI lookup problem on fowarded calls in Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545572 ] Jarek Gawor commented on GERONIMO-3609: --- Ok, thanks. I just checked in a test case for this issue under testsuite/web-testsuite/test-web-forward (revision 598396). Will hook it up to the rest of the testsuite later. JNDI lookup problem on fowarded calls in Jetty -- Key: GERONIMO-3609 URL: https://issues.apache.org/jira/browse/GERONIMO-3609 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x, 2.1 Reporter: Jarek Gawor Assignee: David Jencks Attachments: GERONIMO-3609.patch I am having trouble looking up a DataSource from an EAR containing a WAR (which is where the lookup takes place) using JNDI. I find it to be really weird, because I can look up the DataSource fine if I do it through a JSP page or a servlet. However, when I try to look it up in portlet code, the jndi name does not seem to be visible, although it is visible in the JNDI viewer. Additionally, I have successfully looked it up through jsp and servlets. This is only a problem in Jetty, because the same code works fine for Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo 2.1 dependencies on SNAPSHOTs
Kevan Miller wrote: On Nov 26, 2007, at 11:29 AM, Joe Bohn wrote: I was just looking in the root pom. It seems there are a number of snapshot dependencies that we would need to eliminate prior to a 2.1 release (or make private builds). I'll start working my way through those that have released. We'll need to start pushing for some releases of those that are not yet available ... and of course some are our own specs. OpenEJB3.0.0-SNAPSHOT I started release discussion on [EMAIL PROTECTED], over the weekend. Pluto 1.2.0-SNAPSHOT Has anybody pinged their list? geronimo-jaspi_1.0_spec1.0-SNAPSHOT Do we have any real uses of jaspi? Perhaps we should move jaspi out to post-2.1? geronimo-javamail_1.4_mail 1.3-SNAPSHOT Rick, are we ready to start release proceedings? Yes, I think this can be started any any time. commons-dbcp 1.3-SNAPSHOT This looks like an openejb server dependency (i.e. not a container dependency). Why would we need it? yoko 1.0-incubating-SNAPSHOT Rick, do we need a new yoko version? Or reuse the version used by G 2.0.x? Picking up the new version is probably a good idea. There are a couple of fixes in there, plus lots more logging done by the core ORB. The current snapshot is the one we've been testing with. myfaces1.2.1-SNAPSHOT Has anybody pinged their list? gshell 1.0-alpha-1-SNAPSHOT Given early stages of gshell development, we may want to release this concurrent with a 2.1 release... jspc_compiler_tomcat6 2.0-SNAPSHOT I think this should be 2.0-alpha-1 looks like only half of an update was merged from branches/2.0. --kevan
[jira] Closed: (GERONIMO-3609) JNDI lookup problem on fowarded calls in Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3609. -- Resolution: Fixed Fix Version/s: 2.1 Fixed in rev 598410 with solution from patch but also removing duplicate context handler. We should keep our eyes open for problems this might cause... JNDI lookup problem on fowarded calls in Jetty -- Key: GERONIMO-3609 URL: https://issues.apache.org/jira/browse/GERONIMO-3609 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x, 2.1 Reporter: Jarek Gawor Assignee: David Jencks Fix For: 2.1 Attachments: GERONIMO-3609.patch I am having trouble looking up a DataSource from an EAR containing a WAR (which is where the lookup takes place) using JNDI. I find it to be really weird, because I can look up the DataSource fine if I do it through a JSP page or a servlet. However, when I try to look it up in portlet code, the jndi name does not seem to be visible, although it is visible in the JNDI viewer. Additionally, I have successfully looked it up through jsp and servlets. This is only a problem in Jetty, because the same code works fine for Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JNDI lookup problem in Jetty portlet
On Nov 26, 2007, at 7:13 AM, Jarek Gawor wrote: Does anybody have thoughts on this or know how this should work? Your proposed fix in GERONIMO-3609 is basically correct but it results in duplicating the jndi setting during a normal request. I eliminated this and committed the change. I've done a little tck testing and don't see any problems but wonder why I originally didn't just add the jndi handler to the chain I can't remember but maybe we should keep our eyes open for problems. thanks david jencks Jarek On Nov 19, 2007 11:07 PM, Jarek Gawor [EMAIL PROTECTED] wrote: I've looked at this a bit and here's my current understanding of the problem. First, we are dealing with two different web application contexts (/console and /MonitoringPortlet) and both web app contexts have different JNDI trees with different resources. The console is basically forwarding a request from /console to / MonitoringPortlet. It looks like on Jetty when a request is forwarded from one context to another, the JNDI tree associated with the current thread does NOT change for the duration of the call. That means, when a monitoring portlet looks for resources in JNDI it actaully gets /console JNDI tree instead of its own. Your portlet works on Tomcat as Tomcat appears to be properly switching the JNDI trees during the call. So this seems like a bug in Jetty but I couldn't really find much info on how this should work in the specs. Does anybody know? For now I opened a bug to track this issue: https://issues.apache.org/jira/browse/GERONIMO-3609 Jarek On Nov 16, 2007 11:03 AM, Viet Nguyen [EMAIL PROTECTED] wrote: Hi All, I am having trouble looking up a DataSource from an EAR containing a WAR (which is where the lookup takes place) using JNDI. I find it to be really weird, because I can look up the DataSource fine if I do it through a JSP page or a servlet. However, when I try to look it up in portlet code, the jndi name does not seem to be visible, although it is visible in the JNDI viewer. Additionally, I have successfully looked it up through jsp and servlets. This is only a problem in Jetty, because the same code works fine for Tomcat. Is this possibly a Geronimo/XBean bug in how we bind JNDI names? I am not familiar with the jndi binding process, so any expertise in that area or the portlet area will be much appreciated. Thanks, Viet
XStream/Harmony problem
Hi, all, Geronimo v2.0.2 uses XStream 1.1.3, while the latest version is 1.2.2. I'd like to ask, are there any plans for moving to a newer version? I'm trying to run Geronimo Unit Test v2.0.2 on Apache Harmony, and encounter errors like these: http://jira.codehaus.org/browse/XSTR-189, http://jira.codehaus.org/browse/XSTR-379 Investigations show that the problems are caused by old XStream version - I've tried the latest XStream 1.2.2, and it seems both problems are resolved there. So moving to the latest XStream would ease making Geronimo run on Harmony. What do you think? Thanks! Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: XStream/Harmony problem
Zakharov, Vasily M wrote: Hi, all, Geronimo v2.0.2 uses XStream 1.1.3, while the latest version is 1.2.2. I'd like to ask, are there any plans for moving to a newer version? Yes, Geronimo trunk (2.1-SNAPSHOT) is currently using XStream 1.2.2. Joe
Re: Geronimo 2.1 dependencies on SNAPSHOTs
Joe Bohn wrote: Are there other components that we should upgrade as well? I recall hearing some discussion about moving to Dojo 1.0. Has anybody looked into this further? Is this something we should do for Geronimo 2.1? Joe
[jira] Created: (GERONIMODEVTOOLS-252) VM arguments are reverted to default ones after starting the server
VM arguments are reverted to default ones after starting the server --- Key: GERONIMODEVTOOLS-252 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-252 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Reporter: Piotr Szczepanik Priority: Critical If you change VM arguments in the Run Dialog for Apache Geronimo (ie. adding -XX:MaxPermSize=128m which is needed on my platform) they are reverted back to default value after you successfully the server. What is worse they are not applied to the server that has just started. Steps to reproduce: 1. Change VM arguments 2. Start the server 3. Wait for the start of the server 4. Check the VM arguments 5. They are reverted back to default one -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-252) VM arguments are reverted to default ones after starting the server
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Szczepanik updated GERONIMODEVTOOLS-252: -- Environment: Ubuntu Linux 7.10 (i386), Eclipse 3.3.1, Java 1.6.0_03-b05 VM arguments are reverted to default ones after starting the server --- Key: GERONIMODEVTOOLS-252 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-252 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Environment: Ubuntu Linux 7.10 (i386), Eclipse 3.3.1, Java 1.6.0_03-b05 Reporter: Piotr Szczepanik Priority: Critical If you change VM arguments in the Run Dialog for Apache Geronimo (ie. adding -XX:MaxPermSize=128m which is needed on my platform) they are reverted back to default value after you successfully the server. What is worse they are not applied to the server that has just started. Steps to reproduce: 1. Change VM arguments 2. Start the server 3. Wait for the start of the server 4. Check the VM arguments 5. They are reverted back to default one -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: XStream/Harmony problem
Great, thanks! Vasily -Original Message- From: Joe Bohn [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 27, 2007 12:08 AM To: dev@geronimo.apache.org Subject: Re: XStream/Harmony problem Zakharov, Vasily M wrote: Hi, all, Geronimo v2.0.2 uses XStream 1.1.3, while the latest version is 1.2.2. I'd like to ask, are there any plans for moving to a newer version? Yes, Geronimo trunk (2.1-SNAPSHOT) is currently using XStream 1.2.2. Joe Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[jira] Commented: (GERONIMODEVTOOLS-252) VM arguments are reverted to default ones after starting the server
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545657 ] Kan Ogawa commented on GERONIMODEVTOOLS-252: Piotr, Set VM arguments value to the Server VM Arguments field in Geronimo server overview page, and start the server. ( See my attached screen shot. ) VM arguments are reverted to default ones after starting the server --- Key: GERONIMODEVTOOLS-252 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-252 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Environment: Ubuntu Linux 7.10 (i386), Eclipse 3.3.1, Java 1.6.0_03-b05 Reporter: Piotr Szczepanik Priority: Critical Attachments: ServerVMArguments.jpg If you change VM arguments in the Run Dialog for Apache Geronimo (ie. adding -XX:MaxPermSize=128m which is needed on my platform) they are reverted back to default value after you successfully the server. What is worse they are not applied to the server that has just started. Steps to reproduce: 1. Change VM arguments 2. Start the server 3. Wait for the start of the server 4. Check the VM arguments 5. They are reverted back to default one -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-252) VM arguments are reverted to default ones after starting the server
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMODEVTOOLS-252: --- Attachment: ServerVMArguments.jpg VM arguments are reverted to default ones after starting the server --- Key: GERONIMODEVTOOLS-252 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-252 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Environment: Ubuntu Linux 7.10 (i386), Eclipse 3.3.1, Java 1.6.0_03-b05 Reporter: Piotr Szczepanik Priority: Critical Attachments: ServerVMArguments.jpg If you change VM arguments in the Run Dialog for Apache Geronimo (ie. adding -XX:MaxPermSize=128m which is needed on my platform) they are reverted back to default value after you successfully the server. What is worse they are not applied to the server that has just started. Steps to reproduce: 1. Change VM arguments 2. Start the server 3. Wait for the start of the server 4. Check the VM arguments 5. They are reverted back to default one -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3615) AsyncHttpClient.sendRequest() should return a future
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545673 ] Sangjin Lee commented on GERONIMO-3615: --- I am working on code changes that achieves this and also aids the batch invocation (3616). I'll share it with you once it's reasonably complete. AsyncHttpClient.sendRequest() should return a future Key: GERONIMO-3615 URL: https://issues.apache.org/jira/browse/GERONIMO-3615 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once. I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future. Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion). In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.FutureHttpResponseMessage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Fwd: openejb-2.1 schemalocation
Hey Geronimos, How did we do the xsd schemas that they're available at the shorter URL? I'd like to introduce it to openejb, but am wondering how I shall do it. Was it a one-shot task? Jacek -- Forwarded message -- From: Jacek Laskowski [EMAIL PROTECTED] Date: Nov 27, 2007 8:02 AM Subject: Re: openejb-2.1 schemalocation To: [EMAIL PROTECTED] On Nov 27, 2007 2:26 AM, Titi Wangsa [EMAIL PROTECTED] wrote: http://www.openejb.org/xml/ns/openejb-jar-2.1 has a schema location located in http://svn.apache.org/repos/asf/geronimo/site/tags/pre-confluence/docs/schemas-1.1/openejb-jar-2.1.xsd while all the other schema locations starts nicely with http://geronimo.apache.org/xml will this be the permanent location? Probably not that long. Reported as https://issues.apache.org/jira/browse/OPENEJB-729 - Schemas available at shorter URLs. I'll ask people from Geronimo how they did the URLs nicer. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl -- Jacek Laskowski http://www.JacekLaskowski.pl
