Re: JPA Plugin patch
On Sep 1, 2006, at 4:07 AM, Jacek Laskowski wrote: Also, recall that the main point of plugins is to facilitate the development of value-added features outside the Geronimo community. There's little point to creating a plugin architecture and then insisting that everyone working on plugins do so in the Geronimo sandbox. Noone's said so (or I've been misunderstood because of my (copy of) English). You're *a Geronimo committer* and you ought to keep development of Geronimo bits as close as possible. How can we explain our users that Geronimo committers develop their code outside when it's permissible to do so in the Geronimo tree? You can't simply wear Geronimo hat and do things as Aaron wished to (I hope I've got it right). You're a teammate and as a Geronimo committer you're supposed to play by Geronimo nor your rules. It's also disruptive to the community as they need to look it up in their notes where the plugin comes from rather than download it from a Geronimo space. More troublesome. Another factor to take into account. I would also like to see this plugin developed inside Geronimo, but I disagree with the argument above. This effort does not undermine G. community in any way and I don't feel like anything has to be explained to the users. So let's rephrase it instead of saying that Aaron did something wrong (which he did not). Since there is interest inside G. community to develop this plugin, what would it take to bring this code to Geronimo? Plugin development is not disruptive to the core engine work (as it can be done entirely in parallel), so it doesn't have to follow RTC. Andrus
Geronimo and Cargo
Does not appear that Cargo can start the G 1.2 server, it barfs with: org.codehaus.cargo.container.ContainerException: Failed to create a Geronimo 1.x standalone configuration at org.codehaus.cargo.container.spi.configuration.AbstractLocalConfiguratio n.configure(AbstractLocalConfiguration.java:165) at org.codehaus.cargo.container.spi.AbstractLocalContainer.start (AbstractLocalContainer.java:144) at org.codehaus.cargo.maven2.ContainerStartMojo.execute (ContainerStartMojo.java:62) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:324) 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: /Users/jason/ws/geronimo/server/testsuite/console- testsuite/target/geronimo-jetty-j2ee-1.2-SNAPSHOT-bin/geronimo-jetty- j2ee-1.2-SNAPSHOT/config-store not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner (AbstractFileSet.java:369) at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:355) at org.codehaus.cargo.container.geronimo.Geronimo1xStandaloneLocalConfigura tion.copyExtraStuffTemporarily (Geronimo1xStandaloneLocalConfiguration.java:160) at org.codehaus.cargo.container.geronimo.Geronimo1xStandaloneLocalConfigura tion.doConfigure(Geronimo1xStandaloneLocalConfiguration.java:110) at org.codehaus.cargo.container.spi.configuration.AbstractLocalConfiguratio n.configure(AbstractLocalConfiguration.java:161) ... 20 more /Users/jason/ws/geronimo/server/testsuite/console-testsuite/target/ geronimo-jetty-j2ee-1.2-SNAPSHOT-bin/geronimo-jetty-j2ee-1.2-SNAPSHOT/ config-store not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner (AbstractFileSet.java:369) at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:355) at org.codehaus.cargo.container.geronimo.Geronimo1xStandaloneLocalConfigura tion.copyExtraStuffTemporarily (Geronimo1xStandaloneLocalConfiguration.java:160) at org.codehaus.cargo.container.geronimo.Geronimo1xStandaloneLocalConfigura tion.doConfigure(Geronimo1xStandaloneLocalConfiguration.java:110) at org.codehaus.cargo.container.spi.configuration.AbstractLocalConfiguratio n.configure(AbstractLocalConfiguration.java:161) at org.codehaus.cargo.container.spi.AbstractLocalContainer.start (AbstractLocalContainer.java:144) at org.codehaus.cargo.maven2.ContainerStartMojo.execute (ContainerStartMojo.java:62) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.ap
[jira] Commented: (AMQ-907) Make the ActiveIO dependency and optional dependency.
[ https://issues.apache.org/activemq/browse/AMQ-907?page=comments#action_36890 ] Hiram Chirino commented on AMQ-907: --- Moved the activeio transport to a seperate module and placed it in the sandbox. The tcp/ssl/stomp and vm transports do the equivalent and perform better and are much better tested. We might want to consider trashing this transport if no one finds a need for it. > Make the ActiveIO dependency and optional dependency. > - > > Key: AMQ-907 > URL: https://issues.apache.org/activemq/browse/AMQ-907 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: Hiram Chirino > Assigned To: Hiram Chirino > Fix For: 4.1 > > > Need to move some core classes that are in activeio to activemq > so that it is not needed to run. Right now the only real > functionality that it provides that is optional is the journal > implementation. > Everything else that is use from activeio are just abstract interfaces, and I > think > those need to be moved/copied to ActiveMQ. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-907) Make the ActiveIO dependency and optional dependency.
[ https://issues.apache.org/activemq/browse/AMQ-907?page=comments#action_36891 ] Hiram Chirino commented on AMQ-907: --- activeio transport moved in trunk revision 439204. > Make the ActiveIO dependency and optional dependency. > - > > Key: AMQ-907 > URL: https://issues.apache.org/activemq/browse/AMQ-907 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: Hiram Chirino > Assigned To: Hiram Chirino > Fix For: 4.1 > > > Need to move some core classes that are in activeio to activemq > so that it is not needed to run. Right now the only real > functionality that it provides that is optional is the journal > implementation. > Everything else that is use from activeio are just abstract interfaces, and I > think > those need to be moved/copied to ActiveMQ. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2372) Build failure on branches/1.1.1
Build failure on branches/1.1.1 --- Key: GERONIMO-2372 URL: http://issues.apache.org/jira/browse/GERONIMO-2372 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.1.1 Environment: Win XP, Sun JDK 1.4.2_08, Maven 1.1-beta-2 Reporter: Vamsavardhana Reddy Fix For: 1.1.1 Build is failing due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar unavailable in the repository. Console output given below. + | geronimo and geronimo-plugins Geronimo :: Security | Memory: 17M/29M + DEPRECATED: the default goal should be specified in the section of proje ct.xml instead of maven.xml DEPRECATED: the default goal should be specified in the section of proje ct.xml instead of maven.xml build:end: Attempting to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. WARNING: Failed to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. BUILD FAILED File.. C:\g111\maven.xml Element... maven:reactor Line.. 43 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-j2ee-jacc_1.0_spec-1.1.1.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-907) Make the ActiveIO dependency and optional dependency.
[ https://issues.apache.org/activemq/browse/AMQ-907?page=comments#action_36889 ] Hiram Chirino commented on AMQ-907: --- Applied changes in trunk rev 439108 and 439111.. > Make the ActiveIO dependency and optional dependency. > - > > Key: AMQ-907 > URL: https://issues.apache.org/activemq/browse/AMQ-907 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: Hiram Chirino > Assigned To: Hiram Chirino > Fix For: 4.1 > > > Need to move some core classes that are in activeio to activemq > so that it is not needed to run. Right now the only real > functionality that it provides that is optional is the journal > implementation. > Everything else that is use from activeio are just abstract interfaces, and I > think > those need to be moved/copied to ActiveMQ. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release car-maven-plugin 1.1
All of the plugins from the maven project are named maven-xxx-plugin... and most plugins outside of the maven project use xxx-maven-plugin.--jasonOn Aug 31, 2006, at 11:21 PM, Guillaume Nodet wrote:I guess it depends.All maven plugins are named maven-xxx-plugin (ex: maven-surefire-plugin)but all mojo plugins are named xxx-maven-pluginSo On 9/1/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 9/1/06, Jason Dillon <[EMAIL PROTECTED]> wrote:> Most plugins outside of the Maven project use -maven-> plugin... not maven--plugin... and I'd prefer to keep it > that way.Ah, so maven-xbean-plugin turns out to slip the rule then, doesn't it?> I don't think we need to add geronimo to the name... the groupId> should be enough.Thanks for explanation. Had to ask in case I might've been right ;-) Jacek--Jacek Laskowskihttp://www.laskowski.net.pl-- Cheers,Guillaume Nodet
Re: Is jetty broken in latest snapshots? (Solved!)
Thx, I will increase the log level and try to have more detailed messages. On 9/1/06, jsolderitsch <[EMAIL PROTECTED]> wrote: jsolderitsch wrote: > > > gnodet wrote: >> >> I do not see any reasons. >> I have tested the samples and they work. >> Could you paste the content of your SU and the console log ? >> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6086662 >>> Sent from the ServiceMix - Dev forum at Nabble.com. >>> >>> >> -- >> Cheers, >> Guillaume Nodet >> >> > > I am sending the xbean and jbi xml files via private email. > > I hope they can suggest what my problem could be? > > There is a change from 3.0M2 that is rather severe. > > Could this be a platform issue -- are you using Windows XP to test this? > > I am not using Windows here. > > Jim > I want to thank Mr. Nodet for taking the time via e-mail to help me realize the problem. It turns out that there is a new installer zip in the snapshot releases called servicemix-shared and this one must be "installed" if you want most (if not all) of the other installer zips to install successfully. It is certainly needed for the http and eip installers to be initialized and the successful initialization does cause jetty to start up. A little more attention to detail would have alerted me to the existence of this but since this installer was not part of the last milestone release, I was not looking for it. Also the INFO messages that are written to the console were not sufficiently clear for the novice user and so once I was told where to look, I did eventually see the error of my ways. I recommend that perhaps this one installer zip actually be positioned in the release to be already in the install folder at the root of the servicemix installation rather than in the components folder. Glad to report a resolution of this issue. Jim -- View this message in context: http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6091698 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
Re: [VOTE] Release car-maven-plugin 1.1
I guess it depends.All maven plugins are named maven-xxx-plugin (ex: maven-surefire-plugin)but all mojo plugins are named xxx-maven-pluginSo On 9/1/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 9/1/06, Jason Dillon <[EMAIL PROTECTED]> wrote:> Most plugins outside of the Maven project use -maven-> plugin... not maven--plugin... and I'd prefer to keep it > that way.Ah, so maven-xbean-plugin turns out to slip the rule then, doesn't it?> I don't think we need to add geronimo to the name... the groupId> should be enough.Thanks for explanation. Had to ask in case I might've been right ;-) Jacek--Jacek Laskowskihttp://www.laskowski.net.pl-- Cheers,Guillaume Nodet
[jira] Commented: (GERONIMO-2370) Add serialVersionUID to all classes implementing Serializable
[ http://issues.apache.org/jira/browse/GERONIMO-2370?page=comments#action_12432069 ] Jason Dillon commented on GERONIMO-2370: Do you have a list of serialzables which would be affected by this change? > Add serialVersionUID to all classes implementing Serializable > - > > Key: GERONIMO-2370 > URL: http://issues.apache.org/jira/browse/GERONIMO-2370 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Environment: All >Reporter: Heinz Drews >Priority: Minor > > A number of serializable classes don't have a serialVersionUID specified. > This introduces the risk that the generated uid might be diferent between > different versions or vendors of JVMs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-903) Update Log4J usage from 1.2.8 to latest maintenance version of 1.2.13
[ http://issues.apache.org/jira/browse/GERONIMO-903?page=all ] Jason Dillon updated GERONIMO-903: -- Attachment: GERONIMO-903.diff Another 1 line, 2 char patch to update log4j to the latest release 1.2.13. > Update Log4J usage from 1.2.8 to latest maintenance version of 1.2.13 > - > > Key: GERONIMO-903 > URL: http://issues.apache.org/jira/browse/GERONIMO-903 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: common >Affects Versions: 1.0-M5, 1.1, 1.0, 1.1.1, 1.1.x, 1.2 > Environment: All >Reporter: Donald Woods > Assigned To: Jason Dillon >Priority: Trivial > Fix For: 1.2 > > Attachments: GERONIMO-903.diff > > > Upgrade to the latest log4j maintenance version, which is 1.2.11and is > available to maven on ibiblio - > http://www.ibiblio.org/maven/log4j/jars/log4j-1.2.11.jar > Updates required in project.properties for Geronimo and OpenEJB and any > project.xml which is currently hardcoded to use log4j-1.2.8 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Are the new activemq gbean modules complete?
Anyone else want to vote on this? --jason On Aug 29, 2006, at 1:02 PM, Hiram Chirino wrote: Hey Folks.. Here's a patch that update geronimo to run against amq 4: http://issues.apache.org/jira/browse/GERONIMO-2364 Some small little issues are left like the DLQ admin portlet is not updated to use the new amq APIS. Also a small exception is barfed at shutdown. But I want to move on to bigger issues like CTS testing. Anybody have a link to doco on how to get the cts tests going with the trunk version of Geronimo? It's been too long since I last did that. On 7/2/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: Hi David.. That's still work that I've got on my plate to do. The # of gbeans have changed for activemq 4. So before we switch to amq 4 and the new gbean modules, I'll have to update lots of plans. Including the ones in the CTS I imagine. Regards, Hiram On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > I got the new amq gbean modules to compile under m2 and tried to use > them in the activemq-broker plan but there seem to be a lot more > gbean classes in the plan than in the modules. What's going on? Is > there a new way to configure all this stuff? > > thanks > david jencks > > -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Resolved: (GERONIMO-851) Move Geronimo Build to M2 (Maven 2)
[ http://issues.apache.org/jira/browse/GERONIMO-851?page=all ] Jason Dillon resolved GERONIMO-851. --- Fix Version/s: 1.2 (was: 1.x) Resolution: Fixed This is done for the most part... only a few pending items tracked by other issues. > Move Geronimo Build to M2 (Maven 2) > --- > > Key: GERONIMO-851 > URL: http://issues.apache.org/jira/browse/GERONIMO-851 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) > Components: buildsystem >Reporter: John Sisson > Assigned To: Jason Dillon > Fix For: 1.2 > > Attachments: modules.patch, modules.patch, parentpom.patch, > pom.patch, pom.patch > > > Created this issue to keep track of the status of work to move the Geronimo > build to Maven 2. Does anyone know the status of this effort? I believe some > work was done in OpenEJB? When is the move to M2 planned for? 1.0 or 1.1 > FYI.. In June I attempted to use Maven 1.1 beta 1 to build geronimo and got > some parse exceptions in maven. As a result, some small changes were made to > some project.xml files by David Jencks, which fixed the parse problem, but we > then ran into another problem where we were getting a > java.lang.NoSuchMethodError in maven. This should now be fixed using an > updated artifact plugin, see http://jira.codehaus.org/browse/MAVEN-1625 (but > I have not verified this). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1654) Itests in M2 (for openejb and others too)
[ http://issues.apache.org/jira/browse/GERONIMO-1654?page=all ] Jason Dillon reassigned GERONIMO-1654: -- Assignee: Prasad Kashyap (was: Jacek Laskowski) > Itests in M2 (for openejb and others too) > - > > Key: GERONIMO-1654 > URL: http://issues.apache.org/jira/browse/GERONIMO-1654 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: buildsystem >Reporter: Prasad Kashyap > Assigned To: Prasad Kashyap > Attachments: itests.zip > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12432059 ] Jason Dillon commented on GERONIMO-2352: Bill, if you can will you craft patches to add the naked modules, as well as the alt-dd modules and the fully unpacked modules... only for 1.4. Let me know, if you can't I will cook them up. Thanks :-) > j2ee-builder test deployment modules won't actually deploy > -- > > Key: GERONIMO-2352 > URL: http://issues.apache.org/jira/browse/GERONIMO-2352 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 >Reporter: Bill Dudney > Assigned To: Jason Dillon > Fix For: 1.2 > > Attachments: GERONIMO-2352.bdudney.patch > > > The ear/war/ejb-jar/rar files wont actually deploy to the server. > I have a partial patch avalible but I'd like to get some discussion going on > how to fix some of the problems, that is happening in the dev list. > I will post the complete patch here when that discussion is wrapped up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2331) Remove Maven 1 Artificats from Trunk and Reorganize Directories to Conform to Maven 2 Layouts
[ http://issues.apache.org/jira/browse/GERONIMO-2331?page=all ] Jason Dillon closed GERONIMO-2331. -- Fix Version/s: 1.2 Resolution: Fixed All modules now using the standard m2 layout. > Remove Maven 1 Artificats from Trunk and Reorganize Directories to Conform to > Maven 2 Layouts > - > > Key: GERONIMO-2331 > URL: http://issues.apache.org/jira/browse/GERONIMO-2331 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) >Affects Versions: 1.2 >Reporter: Matt Hogstrom > Assigned To: Jason Dillon > Fix For: 1.2 > > > Pending vote on Dev list -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12432057 ] Jason Dillon commented on GERONIMO-2352: This is mostly done... we still need a few more deployments for alt dd, and modules that build up full unpacked deployments... looks like we only tested those for 1.4, so can probably ignore 1.3 for these tests. I'm using the existing unpacked (which are semi-unpacked) at the moment... need to clean that up tot actually test the scenarios. > j2ee-builder test deployment modules won't actually deploy > -- > > Key: GERONIMO-2352 > URL: http://issues.apache.org/jira/browse/GERONIMO-2352 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 >Reporter: Bill Dudney > Assigned To: Jason Dillon > Fix For: 1.2 > > Attachments: GERONIMO-2352.bdudney.patch > > > The ear/war/ejb-jar/rar files wont actually deploy to the server. > I have a partial patch avalible but I'd like to get some discussion going on > how to fix some of the problems, that is happening in the dev list. > I will post the complete patch here when that discussion is wrapped up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Tests for Console
Hi All, I'm planning on doing a proof of concept for selenium over the weekend to test the console (esp the datasource deployment :-). I will post a patch when i have something meaningful (hopefully by monday). TTFN, -bd- On Aug 31, 2006, at 9:25 PM, Jason Dillon wrote: Cool... I think Bill Dundney expressed some interest in this as well. :-) I think to start antrun should work fine... and then after we get a POC working, then we can craft an m2 plugin. --jason On Aug 31, 2006, at 7:15 PM, Gianny Damour wrote: I support that. If Selenium is chosen as the tool to automate the integration testing of the Admin console, then I am happy to bootstrap the effort. On my current project, we are using Selenium with script generation via Ruby and it rocks. Our build system is Ant, thought, I think that I should be able to make it work with m2. Thanks, Gianny On 01/09/2006, at 9:46 AM, Jason Dillon wrote: selenium looks very promising... I've not tried it, but from the docs it looks good... I like the IDE to record. I would love to see a proof of concept for how this could be hooked up to the build for integration tests of the console :-) --jason On 8/8/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Canoo is quite good; http://webtest.canoo.com/webtest/manual/WebTestHome.html It uses Ant to execute its tests and AFAIK there is not maven plugin to invoke it but should be straight forward to do with maven. Its license appears to (this non-lawyer at least) be compatible. Also the Struts folks are using Selenium from M2 AFAIK. TTFN, -bd On Aug 8, 2006, at 12:14 PM, Prasad Kashyap wrote: > Does anybody know of any good open source tests for the console ? > There are quite a few of those out there, most of them GPL. I have > never used any of them. So please share your valuable experiences, > comments and thoughts. > > The itests would be a good place to stage and run any such tests. > > jWebUnit: > -- > http://jwebunit.sourceforge.net/ > http://htmlunit.sourceforge.net/ > http://httpunit.sourceforge.net/ > > License: GPL > > jWebUnit provides a high-level API for navigating a web application > combined with a set of assertions to verify the application's > correctness. This includes navigation via links, form entry and > submission, validation of table contents, and other typical business > web application features. This code try to stay independent of the > libraries behind the scenes. The simple navigation methods and > ready-to-use assertions allow for more rapid test creation than using > only JUnit and HtmlUnit. And if you want to switch from HtmlUnit to > the other soon available plugins, no need to rewrite your tests. > > jWebUnit also builds with maven 2. So it will be much easier for us to > integrate it into our project. > > > Enterprise Web Test > - > http://sourceforge.net/projects/webunitproj/ > License: Common Public License (can we still use it ?) > > Enterprise Web Test allows Java programmers to write re-usable tests > for web applications that, unlike HttpUnit, "drive" the actual web > browser on the actual platform they intend to support. Tests can be > leveraged for functional, stress, reliability. > > Cheers > Prasad
[jira] Commented: (GERONIMO-2359) Itests for Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2359?page=comments#action_12432037 ] Prasad Kashyap commented on GERONIMO-2359: -- http://mail-archives.apache.org/mod_mbox/geronimo-dev/200608.mbox/[EMAIL PROTECTED] > Itests for Geronimo > --- > > Key: GERONIMO-2359 > URL: http://issues.apache.org/jira/browse/GERONIMO-2359 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 >Reporter: Prasad Kashyap > Fix For: 1.2 > > Attachments: itests-1.0.patch > > > The openejb itests which we had for a few releases now have been dead for a > while. Here's an effort to revive them and expand it's scope for all of > Geronimo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: YABE (yet another build error)?
I'm starting to loose faith in Mavens portability across operating systems... needless to say, I do not nor did not see this error on my local workspace. Java is living up to the write once debug everywhere myth... :-( --jason On Aug 31, 2006, at 5:24 PM, Jacek Laskowski wrote: Hi, Seems it's not been mentioned yet. I'm getting the following build error while building Geronimo. Anyone know what's up? [INFO] Using ra.xml C:\oss\geronimo\testsupport\test-deployment-j2ee_1.3\test-rar- j2ee_1.3\src\main\rar\META-INF\ra.xml [INFO] Could not find manifest file: C:\oss\geronimo\testsupport\test-deployment-j2ee_1.3\test-rar- j2ee_1.3\src\main\rar \META-INF\MANIFEST.MF - Generating one [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Error assembling RAR Embedded error: Neither a file nor a directory: C:\oss\geronimo\testsupport\test-deployment-j2ee_1.3\test-rar- j2ee_1.3\t arget\test-rar-j2ee_1.3-1.2-SNAPSHOT\META-INF\.svn\tmp\ra.xml.tmp [INFO] -- -- [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling RAR at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif ecycle(DefaultLifecycleExecutor.java:47 5) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand leFailures(DefaultLifecycleExecutor.jav a:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment s(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:324) 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.plugin.MojoExecutionException: Error assembling RAR at org.apache.maven.plugin.rar.RarMojo.execute(RarMojo.java: 233) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.codehaus.plexus.archiver.ArchiverException: Neither a file nor a directory: C:\oss\geronimo\testsupport\t est-deployment-j2ee_1.3\test-rar-j2ee_1.3\target\test-rar- j2ee_1.3-1.2-SNAPSHOT\META-INF\.svn\tmp\ra.xml.tmp at org.codehaus.plexus.archiver.ArchiveEntry.createEntry (ArchiveEntry.java:140) at org.codehaus.plexus.archiver.AbstractArchiver.addDirectory (AbstractArchiver.java:156) at org.codehaus.plexus.archiver.AbstractArchiver.addDirectory (AbstractArchiver.java:99) at org.codehaus.plexus.archiver.AbstractArchiver.addDirectory (AbstractArchiver.java:93) at org.apache.maven.plugin.rar.RarMojo.execute(RarMojo.java: 226) ... 18 more [INFO] -- -- [INFO] Total time: 17 seconds [INFO] Finished at: Fri Sep 01 02:20:59 CEST 2006 [INFO] Final Memory: 31M/56M [INFO] -- -- Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: YABE (yet another build error)?
Yikes... that rar plugin again looking into .svn directories erg! --jason On Aug 31, 2006, at 5:24 PM, Jacek Laskowski wrote: Hi, Seems it's not been mentioned yet. I'm getting the following build error while building Geronimo. Anyone know what's up? [INFO] Using ra.xml C:\oss\geronimo\testsupport\test-deployment-j2ee_1.3\test-rar- j2ee_1.3\src\main\rar\META-INF\ra.xml [INFO] Could not find manifest file: C:\oss\geronimo\testsupport\test-deployment-j2ee_1.3\test-rar- j2ee_1.3\src\main\rar \META-INF\MANIFEST.MF - Generating one [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Error assembling RAR Embedded error: Neither a file nor a directory: C:\oss\geronimo\testsupport\test-deployment-j2ee_1.3\test-rar- j2ee_1.3\t arget\test-rar-j2ee_1.3-1.2-SNAPSHOT\META-INF\.svn\tmp\ra.xml.tmp [INFO] -- -- [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling RAR at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif ecycle(DefaultLifecycleExecutor.java:47 5) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand leFailures(DefaultLifecycleExecutor.jav a:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment s(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:324) 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.plugin.MojoExecutionException: Error assembling RAR at org.apache.maven.plugin.rar.RarMojo.execute(RarMojo.java: 233) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.codehaus.plexus.archiver.ArchiverException: Neither a file nor a directory: C:\oss\geronimo\testsupport\t est-deployment-j2ee_1.3\test-rar-j2ee_1.3\target\test-rar- j2ee_1.3-1.2-SNAPSHOT\META-INF\.svn\tmp\ra.xml.tmp at org.codehaus.plexus.archiver.ArchiveEntry.createEntry (ArchiveEntry.java:140) at org.codehaus.plexus.archiver.AbstractArchiver.addDirectory (AbstractArchiver.java:156) at org.codehaus.plexus.archiver.AbstractArchiver.addDirectory (AbstractArchiver.java:99) at org.codehaus.plexus.archiver.AbstractArchiver.addDirectory (AbstractArchiver.java:93) at org.apache.maven.plugin.rar.RarMojo.execute(RarMojo.java: 226) ... 18 more [INFO] -- -- [INFO] Total time: 17 seconds [INFO] Finished at: Fri Sep 01 02:20:59 CEST 2006 [INFO] Final Memory: 31M/56M [INFO] -- -- Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Tests for Console
Cool... I think Bill Dundney expressed some interest in this as well. :-) I think to start antrun should work fine... and then after we get a POC working, then we can craft an m2 plugin. --jason On Aug 31, 2006, at 7:15 PM, Gianny Damour wrote: I support that. If Selenium is chosen as the tool to automate the integration testing of the Admin console, then I am happy to bootstrap the effort. On my current project, we are using Selenium with script generation via Ruby and it rocks. Our build system is Ant, thought, I think that I should be able to make it work with m2. Thanks, Gianny On 01/09/2006, at 9:46 AM, Jason Dillon wrote: selenium looks very promising... I've not tried it, but from the docs it looks good... I like the IDE to record. I would love to see a proof of concept for how this could be hooked up to the build for integration tests of the console :-) --jason On 8/8/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Canoo is quite good; http://webtest.canoo.com/webtest/manual/WebTestHome.html It uses Ant to execute its tests and AFAIK there is not maven plugin to invoke it but should be straight forward to do with maven. Its license appears to (this non-lawyer at least) be compatible. Also the Struts folks are using Selenium from M2 AFAIK. TTFN, -bd On Aug 8, 2006, at 12:14 PM, Prasad Kashyap wrote: > Does anybody know of any good open source tests for the console ? > There are quite a few of those out there, most of them GPL. I have > never used any of them. So please share your valuable experiences, > comments and thoughts. > > The itests would be a good place to stage and run any such tests. > > jWebUnit: > -- > http://jwebunit.sourceforge.net/ > http://htmlunit.sourceforge.net/ > http://httpunit.sourceforge.net/ > > License: GPL > > jWebUnit provides a high-level API for navigating a web application > combined with a set of assertions to verify the application's > correctness. This includes navigation via links, form entry and > submission, validation of table contents, and other typical business > web application features. This code try to stay independent of the > libraries behind the scenes. The simple navigation methods and > ready-to-use assertions allow for more rapid test creation than using > only JUnit and HtmlUnit. And if you want to switch from HtmlUnit to > the other soon available plugins, no need to rewrite your tests. > > jWebUnit also builds with maven 2. So it will be much easier for us to > integrate it into our project. > > > Enterprise Web Test > - > http://sourceforge.net/projects/webunitproj/ > License: Common Public License (can we still use it ?) > > Enterprise Web Test allows Java programmers to write re-usable tests > for web applications that, unlike HttpUnit, "drive" the actual web > browser on the actual platform they intend to support. Tests can be > leveraged for functional, stress, reliability. > > Cheers > Prasad
Re: Tests for Console
Cool.. Selenium then. You may monitor this jira http://issues.apache.org/jira/browse/GERONIMO-2359 as I start building the integration tests for the server. I'll soon have another patch out there. Please provide suggestions as to how the framework can be made to accomodate Selenium too. Cheers Prasad On 8/31/06, Gianny Damour <[EMAIL PROTECTED]> wrote: I support that. If Selenium is chosen as the tool to automate the integration testing of the Admin console, then I am happy to bootstrap the effort. On my current project, we are using Selenium with script generation via Ruby and it rocks. Our build system is Ant, thought, I think that I should be able to make it work with m2. Thanks, Gianny On 01/09/2006, at 9:46 AM, Jason Dillon wrote: > selenium looks very promising... I've not tried it, but from the docs > it looks good... I like the IDE to record. > > I would love to see a proof of concept for how this could be hooked up > to the build for integration tests of the console :-) > > --jason > > > On 8/8/06, Bill Dudney <[EMAIL PROTECTED]> wrote: >> Canoo is quite good; >> >> http://webtest.canoo.com/webtest/manual/WebTestHome.html >> >> It uses Ant to execute its tests and AFAIK there is not maven plugin >> to invoke it but should be straight forward to do with maven. >> >> Its license appears to (this non-lawyer at least) be compatible. >> >> Also the Struts folks are using Selenium from M2 AFAIK. >> >> TTFN, >> >> -bd >> On Aug 8, 2006, at 12:14 PM, Prasad Kashyap wrote: >> >> > Does anybody know of any good open source tests for the console ? >> > There are quite a few of those out there, most of them GPL. I have >> > never used any of them. So please share your valuable experiences, >> > comments and thoughts. >> > >> > The itests would be a good place to stage and run any such tests. >> > >> > jWebUnit: >> > -- >> > http://jwebunit.sourceforge.net/ >> > http://htmlunit.sourceforge.net/ >> > http://httpunit.sourceforge.net/ >> > >> > License: GPL >> > >> > jWebUnit provides a high-level API for navigating a web application >> > combined with a set of assertions to verify the application's >> > correctness. This includes navigation via links, form entry and >> > submission, validation of table contents, and other typical >> business >> > web application features. This code try to stay independent of the >> > libraries behind the scenes. The simple navigation methods and >> > ready-to-use assertions allow for more rapid test creation than >> using >> > only JUnit and HtmlUnit. And if you want to switch from HtmlUnit to >> > the other soon available plugins, no need to rewrite your tests. >> > >> > jWebUnit also builds with maven 2. So it will be much easier for >> us to >> > integrate it into our project. >> > >> > >> > Enterprise Web Test >> > - >> > http://sourceforge.net/projects/webunitproj/ >> > License: Common Public License (can we still use it ?) >> > >> > Enterprise Web Test allows Java programmers to write re-usable >> tests >> > for web applications that, unlike HttpUnit, "drive" the actual web >> > browser on the actual platform they intend to support. Tests can be >> > leveraged for functional, stress, reliability. >> > >> > Cheers >> > Prasad >> >>
Re: Tests for Console
I support that. If Selenium is chosen as the tool to automate the integration testing of the Admin console, then I am happy to bootstrap the effort. On my current project, we are using Selenium with script generation via Ruby and it rocks. Our build system is Ant, thought, I think that I should be able to make it work with m2. Thanks, Gianny On 01/09/2006, at 9:46 AM, Jason Dillon wrote: selenium looks very promising... I've not tried it, but from the docs it looks good... I like the IDE to record. I would love to see a proof of concept for how this could be hooked up to the build for integration tests of the console :-) --jason On 8/8/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Canoo is quite good; http://webtest.canoo.com/webtest/manual/WebTestHome.html It uses Ant to execute its tests and AFAIK there is not maven plugin to invoke it but should be straight forward to do with maven. Its license appears to (this non-lawyer at least) be compatible. Also the Struts folks are using Selenium from M2 AFAIK. TTFN, -bd On Aug 8, 2006, at 12:14 PM, Prasad Kashyap wrote: > Does anybody know of any good open source tests for the console ? > There are quite a few of those out there, most of them GPL. I have > never used any of them. So please share your valuable experiences, > comments and thoughts. > > The itests would be a good place to stage and run any such tests. > > jWebUnit: > -- > http://jwebunit.sourceforge.net/ > http://htmlunit.sourceforge.net/ > http://httpunit.sourceforge.net/ > > License: GPL > > jWebUnit provides a high-level API for navigating a web application > combined with a set of assertions to verify the application's > correctness. This includes navigation via links, form entry and > submission, validation of table contents, and other typical business > web application features. This code try to stay independent of the > libraries behind the scenes. The simple navigation methods and > ready-to-use assertions allow for more rapid test creation than using > only JUnit and HtmlUnit. And if you want to switch from HtmlUnit to > the other soon available plugins, no need to rewrite your tests. > > jWebUnit also builds with maven 2. So it will be much easier for us to > integrate it into our project. > > > Enterprise Web Test > - > http://sourceforge.net/projects/webunitproj/ > License: Common Public License (can we still use it ?) > > Enterprise Web Test allows Java programmers to write re-usable tests > for web applications that, unlike HttpUnit, "drive" the actual web > browser on the actual platform they intend to support. Tests can be > leveraged for functional, stress, reliability. > > Cheers > Prasad
Re: Is jetty broken in latest snapshots? (Solved!)
jsolderitsch wrote: > > > gnodet wrote: >> >> I do not see any reasons. >> I have tested the samples and they work. >> Could you paste the content of your SU and the console log ? >> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6086662 >>> Sent from the ServiceMix - Dev forum at Nabble.com. >>> >>> >> -- >> Cheers, >> Guillaume Nodet >> >> > > I am sending the xbean and jbi xml files via private email. > > I hope they can suggest what my problem could be? > > There is a change from 3.0M2 that is rather severe. > > Could this be a platform issue -- are you using Windows XP to test this? > > I am not using Windows here. > > Jim > I want to thank Mr. Nodet for taking the time via e-mail to help me realize the problem. It turns out that there is a new installer zip in the snapshot releases called servicemix-shared and this one must be "installed" if you want most (if not all) of the other installer zips to install successfully. It is certainly needed for the http and eip installers to be initialized and the successful initialization does cause jetty to start up. A little more attention to detail would have alerted me to the existence of this but since this installer was not part of the last milestone release, I was not looking for it. Also the INFO messages that are written to the console were not sufficiently clear for the novice user and so once I was told where to look, I did eventually see the error of my ways. I recommend that perhaps this one installer zip actually be positioned in the release to be already in the install folder at the root of the servicemix installation rather than in the components folder. Glad to report a resolution of this issue. Jim -- View this message in context: http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6091698 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: [VOTE] Release XBean 2.6 (retry)
+4 (remainder to be spread out over the next three retries :) -David On Aug 30, 2006, at 10:34 AM, Guillaume Nodet wrote: +1 On 8/30/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: I have uploaded new binaries of xbean. They are available at http://people.apache.org/~gnodet/xbean-2.6/ The changes from the last cut includes a fix for spring 2.0-rc3, and the Genesis dependency which has been removed. I will sign and upload these artifacts to the official m2 repo, once the vote is over. -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
YABE (yet another build error)?
Hi, Seems it's not been mentioned yet. I'm getting the following build error while building Geronimo. Anyone know what's up? [INFO] Using ra.xml C:\oss\geronimo\testsupport\test-deployment-j2ee_1.3\test-rar-j2ee_1.3\src\main\rar\META-INF\ra.xml [INFO] Could not find manifest file: C:\oss\geronimo\testsupport\test-deployment-j2ee_1.3\test-rar-j2ee_1.3\src\main\rar \META-INF\MANIFEST.MF - Generating one [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error assembling RAR Embedded error: Neither a file nor a directory: C:\oss\geronimo\testsupport\test-deployment-j2ee_1.3\test-rar-j2ee_1.3\t arget\test-rar-j2ee_1.3-1.2-SNAPSHOT\META-INF\.svn\tmp\ra.xml.tmp [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling RAR at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47 5) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:324) 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.plugin.MojoExecutionException: Error assembling RAR at org.apache.maven.plugin.rar.RarMojo.execute(RarMojo.java:233) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.codehaus.plexus.archiver.ArchiverException: Neither a file nor a directory: C:\oss\geronimo\testsupport\t est-deployment-j2ee_1.3\test-rar-j2ee_1.3\target\test-rar-j2ee_1.3-1.2-SNAPSHOT\META-INF\.svn\tmp\ra.xml.tmp at org.codehaus.plexus.archiver.ArchiveEntry.createEntry(ArchiveEntry.java:140) at org.codehaus.plexus.archiver.AbstractArchiver.addDirectory(AbstractArchiver.java:156) at org.codehaus.plexus.archiver.AbstractArchiver.addDirectory(AbstractArchiver.java:99) at org.codehaus.plexus.archiver.AbstractArchiver.addDirectory(AbstractArchiver.java:93) at org.apache.maven.plugin.rar.RarMojo.execute(RarMojo.java:226) ... 18 more [INFO] [INFO] Total time: 17 seconds [INFO] Finished at: Fri Sep 01 02:20:59 CEST 2006 [INFO] Final Memory: 31M/56M [INFO] Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] Release car-maven-plugin 1.1
On 9/1/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Most plugins outside of the Maven project use -maven- plugin... not maven--plugin... and I'd prefer to keep it that way. Ah, so maven-xbean-plugin turns out to slip the rule then, doesn't it? I don't think we need to add geronimo to the name... the groupId should be enough. Thanks for explanation. Had to ask in case I might've been right ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: JPA Plugin patch
On 9/1/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: The main developers who produced the plugin were not Geronimo committers, and I had the space available. You still have here, in the Geronimo repo. You're a Geronimo committer and you can get as much "as you wish"[*] No need to go outside in this particular case. The TopLink and Hibernate implementation plugins could not be developed at Apache, but the core JPA plugin could otherwise have been. That's what I've been asking to be moved here. Also, Dave B's asked about a similar thing. However, I'm not convinced that the sandbox is the right place to develop plugins in any case, because I plan to actually release them, and I would be skeptical about releasing anything from the sandbox -- seems like that would be a cheesy end run around RTC. So, let's create a Geronimo subproject - plugins - and have them released under the very same rules as devtools is - at the time plugins wished to. Also, recall that the main point of plugins is to facilitate the development of value-added features outside the Geronimo community. There's little point to creating a plugin architecture and then insisting that everyone working on plugins do so in the Geronimo sandbox. Noone's said so (or I've been misunderstood because of my (copy of) English). You're *a Geronimo committer* and you ought to keep development of Geronimo bits as close as possible. How can we explain our users that Geronimo committers develop their code outside when it's permissible to do so in the Geronimo tree? You can't simply wear Geronimo hat and do things as Aaron wished to (I hope I've got it right). You're a teammate and as a Geronimo committer you're supposed to play by Geronimo nor your rules. It's also disruptive to the community as they need to look it up in their notes where the plugin comes from rather than download it from a Geronimo space. More troublesome. Another factor to take into account. Jacek [*] Remember the movie - "The Pricess Bride" you had told me in this semi-Italian and semi-Polish restaurant in Barcelona? ;-) I could watch and love it! -- Jacek Laskowski http://www.laskowski.net.pl
Re: JPA Plugin patch
On 8/31/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: Hi Aaron and Andrus, The patch caught my attention and got me thinking about the plugin and where it's being developed. The first time I read it I thought why Andrus was asking that question here (yet complaining about SF issue tracker) since the plugin itself has been developed outside the project? (well, it's for the project, but it's not part of it, right?). I meant to have asked the question to Andrus, but then thought it's not him I should ask about it, but Aaron who *seem* to have made it hard(er) to understand where people should collaborate about stuff being developed outside, but still relevant to Geronimo. For me, it should've been asked in the used mailing list at most if not in the space it's being developed (in this case, it's SF). I think the question's already been asked, but will ask again since the plugin has drawn more attention. Aaron, why can't the plugin development be conducted here, in sandbox? Does it use a code not allowed to be in the Geronimo repo? The main developers who produced the plugin were not Geronimo committers, and I had the space available. The TopLink and Hibernate implementation plugins could not be developed at Apache, but the core JPA plugin could otherwise have been. However, I'm not convinced that the sandbox is the right place to develop plugins in any case, because I plan to actually release them, and I would be skeptical about releasing anything from the sandbox -- seems like that would be a cheesy end run around RTC. Also, recall that the main point of plugins is to facilitate the development of value-added features outside the Geronimo community. There's little point to creating a plugin architecture and then insisting that everyone working on plugins do so in the Geronimo sandbox. Thanks, Aaron
Re: Re: Tests for Console
selenium looks very promising... I've not tried it, but from the docs it looks good... I like the IDE to record. I would love to see a proof of concept for how this could be hooked up to the build for integration tests of the console :-) --jason On 8/8/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Canoo is quite good; http://webtest.canoo.com/webtest/manual/WebTestHome.html It uses Ant to execute its tests and AFAIK there is not maven plugin to invoke it but should be straight forward to do with maven. Its license appears to (this non-lawyer at least) be compatible. Also the Struts folks are using Selenium from M2 AFAIK. TTFN, -bd On Aug 8, 2006, at 12:14 PM, Prasad Kashyap wrote: > Does anybody know of any good open source tests for the console ? > There are quite a few of those out there, most of them GPL. I have > never used any of them. So please share your valuable experiences, > comments and thoughts. > > The itests would be a good place to stage and run any such tests. > > jWebUnit: > -- > http://jwebunit.sourceforge.net/ > http://htmlunit.sourceforge.net/ > http://httpunit.sourceforge.net/ > > License: GPL > > jWebUnit provides a high-level API for navigating a web application > combined with a set of assertions to verify the application's > correctness. This includes navigation via links, form entry and > submission, validation of table contents, and other typical business > web application features. This code try to stay independent of the > libraries behind the scenes. The simple navigation methods and > ready-to-use assertions allow for more rapid test creation than using > only JUnit and HtmlUnit. And if you want to switch from HtmlUnit to > the other soon available plugins, no need to rewrite your tests. > > jWebUnit also builds with maven 2. So it will be much easier for us to > integrate it into our project. > > > Enterprise Web Test > - > http://sourceforge.net/projects/webunitproj/ > License: Common Public License (can we still use it ?) > > Enterprise Web Test allows Java programmers to write re-usable tests > for web applications that, unlike HttpUnit, "drive" the actual web > browser on the actual platform they intend to support. Tests can be > leveraged for functional, stress, reliability. > > Cheers > Prasad
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
ya... more issues :-P Thanks :-) --jason On Aug 31, 2006, at 4:40 PM, Jacek Laskowski wrote: On 9/1/06, Jason Dillon <[EMAIL PROTECTED]> wrote: No issue... http://issues.apache.org/jira/browse/GERONIMO-2371 "bootstrap script removed as build helper tool" Assignee: Jason Dillon :-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Updated: (GERONIMO-2371) bootstrap script removed as build helper tool
[ http://issues.apache.org/jira/browse/GERONIMO-2371?page=all ] Jason Dillon updated GERONIMO-2371: --- Affects Version/s: 1.2 (was: 1.x) > bootstrap script removed as build helper tool > - > > Key: GERONIMO-2371 > URL: http://issues.apache.org/jira/browse/GERONIMO-2371 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 >Reporter: Jacek Laskowski > Assigned To: Jason Dillon > > > You most certainly do not need to use it to build Geronimo. It is > > only an attempt to automate several steps together. As I have said > > before, and I will undoubtedly say again, bootstrap is temporary and > > will be removed as soon as we have all of the dependency artifacts > > published and have a few maven bugs resolved. > Before it gets whacked these steps need to be done: > * OpenEJB2 snaps need to be published by CI (needs G below) > * G snaps to be published by CI (needs OpenEJB2 above) > * specs/trunk need to be published > * Maven needs to get MNG-1911 fixed > And then at that point bootstrap will not be needed for normal use... > may still want to keep it in to allow the clean repo bits to ensure > that G still builds correctly and downloads artifacts though. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2371) bootstrap script removed as build helper tool
bootstrap script removed as build helper tool - Key: GERONIMO-2371 URL: http://issues.apache.org/jira/browse/GERONIMO-2371 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.x Reporter: Jacek Laskowski Assigned To: Jason Dillon > You most certainly do not need to use it to build Geronimo. It is > only an attempt to automate several steps together. As I have said > before, and I will undoubtedly say again, bootstrap is temporary and > will be removed as soon as we have all of the dependency artifacts > published and have a few maven bugs resolved. Before it gets whacked these steps need to be done: * OpenEJB2 snaps need to be published by CI (needs G below) * G snaps to be published by CI (needs OpenEJB2 above) * specs/trunk need to be published * Maven needs to get MNG-1911 fixed And then at that point bootstrap will not be needed for normal use... may still want to keep it in to allow the clean repo bits to ensure that G still builds correctly and downloads artifacts though. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Classes in trunk
Maybe we can make this builder use the testsupport deployables... or maybe we need to make a new test deployment for it. Or if all of the tomcat support was under a geronimo-tomcat module of type pom, then it could define its own test deployments as normal modules. --jason On Aug 31, 2006, at 2:55 PM, Jacek Laskowski wrote: On 8/29/06, Sergey Elin <[EMAIL PROTECTED]> wrote: there is a number of class files in trunk. Any reasons for it? Other than there're there for the tests? No. Seriously, there're in trunk as they're simply resources for tests (am I repeating myself?). [EMAIL PROTECTED] /cygdrive/c/oss/geronimo/modules/geronimo-tomcat- builder/src/test/resources/deployables/war4/WEB-INF/classes/org/ apache/geronimo/tomcat/app $ svn log Servlet1.class ... -- -- r164651 | jgenender | 2005-04-25 23:09:26 +0200 (Mon, 25 Apr 2005) | 1 line New tomcat-builder -- -- Jeff added them likely to not have bothered to script their compilation and proper inclusion in the resources directories of these tests (Jeff? Are you reading this? ;-) ). I think you can go and improve it a little. Create a JIRA task and get rid of them. Let's fix it by creating their java sources and let Maven know about the change. Ready to give it a spin? Ask when in trouble. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
On 9/1/06, Jason Dillon <[EMAIL PROTECTED]> wrote: No issue... http://issues.apache.org/jira/browse/GERONIMO-2371 "bootstrap script removed as build helper tool" Assignee: Jason Dillon :-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] Release car-maven-plugin 1.1
Most plugins outside of the Maven project use -maven- plugin... not maven--plugin... and I'd prefer to keep it that way. I don't think we need to add geronimo to the name... the groupId should be enough. --jason On Aug 31, 2006, at 4:35 PM, Jacek Laskowski wrote: On 8/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: This release goal is to provide a m2 plugin to create Geronimo 1.1 plugins. By the way, just finished reviewing some XBean bits (and came across maven-xbean-plugin) and wonder why the plugin's name's car-maven-plugin not maven-car-plugin or even maven-geronimo-car-plugin? It seems it's sort of a naming standard, doesn't it? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Upgrade Derby to 10.1.3.1?
Okay, you win :-P Patch is attached now to: https://issues.apache.org/jira/browse/GERONIMO-2365 --jason On Aug 31, 2006, at 4:31 PM, Jacek Laskowski wrote: On 9/1/06, Jason Dillon <[EMAIL PROTECTED]> wrote: You really want a diff of the root pom that changes the version to 10.1.3.1 to review? Yes. I can do that, but it seems like a waste of time... and abuse of the RTC concept. As far as RTC rules' are concerned, each and every change needs to be reviewed before being committed and such a small change is no exception. Of course, a change != a fix. If no one objects to it, then why don't we just do it? Unless we decide how many lines are good to be committed without voting I'm THE one who objects. Its a whopping 1 line change... which affects only 2 chars :-P Do it and we're done. (I'm kicking myself for having myself involved in the thread ;-)) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Updated: (GERONIMO-2365) Upgrade Derby to 10.1.3.1
[ http://issues.apache.org/jira/browse/GERONIMO-2365?page=all ] Jason Dillon updated GERONIMO-2365: --- Attachment: GERONIMO-2365.diff Attaching 1 line 2 char diff for review. > Upgrade Derby to 10.1.3.1 > - > > Key: GERONIMO-2365 > URL: http://issues.apache.org/jira/browse/GERONIMO-2365 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 1.2 >Reporter: Jason Dillon > Assigned To: Jason Dillon >Priority: Minor > Fix For: 1.2 > > Attachments: GERONIMO-2365.diff > > > The latest release appears to run fine. We should upgrade our dependencies > to use 10.1.3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release car-maven-plugin 1.1
On 8/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: This release goal is to provide a m2 plugin to create Geronimo 1.1 plugins. By the way, just finished reviewing some XBean bits (and came across maven-xbean-plugin) and wonder why the plugin's name's car-maven-plugin not maven-car-plugin or even maven-geronimo-car-plugin? It seems it's sort of a naming standard, doesn't it? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Upgrade Derby to 10.1.3.1?
On 9/1/06, Jason Dillon <[EMAIL PROTECTED]> wrote: You really want a diff of the root pom that changes the version to 10.1.3.1 to review? Yes. I can do that, but it seems like a waste of time... and abuse of the RTC concept. As far as RTC rules' are concerned, each and every change needs to be reviewed before being committed and such a small change is no exception. Of course, a change != a fix. If no one objects to it, then why don't we just do it? Unless we decide how many lines are good to be committed without voting I'm THE one who objects. Its a whopping 1 line change... which affects only 2 chars :-P Do it and we're done. (I'm kicking myself for having myself involved in the thread ;-)) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] Release car-maven-plugin 1.1
I'll upgrade my vote to a +1... I'd rather not see this code move outside of the G tree. --jason On Aug 31, 2006, at 4:17 PM, Jacek Laskowski wrote: On 8/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: This release goal is to provide a m2 plugin to create Geronimo 1.1 plugins. +0 (fortunatelly, Dave's in favor of it and there won't be a discussion about double +0's and no +1's) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: RTC: Move java ee 5 specs into specs trunk (GERONIMO-2358)
On 8/31/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: Btw, is there any plan to write jsr181 and jaxws api ? Quoted from http://cwiki.apache.org/GMOxPMGT/geronimo-jee-50-report-card.html: JAX-WS 2.0 - An Axis 2.0 subproject has an implementation of JAX-WS. CeltiXfire has an implementation of JAX-WS. WS Metadata 2.0 (Annotations) (jsr181) - Axis 2 is using WS Metadata 2.0 originally from the Beehive project. CeltiXFire contains an implementation of WS Metadata 2.0. or to borrow them from another project ? Axis2 and CeltiXFire spring to my mind ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: JPA Plugin patch
On 8/31/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote: Hi Aaron, finally got time to start poking around JPA plugin. I can compile it now, but it requires a patch below to build against the latest JPA spec. Not a big fan of SF issue tracker, so I simply put it on the web: http://people.apache.org/~aadamchik/jpa-plugin-patch.txt Hi Aaron and Andrus, The patch caught my attention and got me thinking about the plugin and where it's being developed. The first time I read it I thought why Andrus was asking that question here (yet complaining about SF issue tracker) since the plugin itself has been developed outside the project? (well, it's for the project, but it's not part of it, right?). I meant to have asked the question to Andrus, but then thought it's not him I should ask about it, but Aaron who *seem* to have made it hard(er) to understand where people should collaborate about stuff being developed outside, but still relevant to Geronimo. For me, it should've been asked in the used mailing list at most if not in the space it's being developed (in this case, it's SF). I think the question's already been asked, but will ask again since the plugin has drawn more attention. Aaron, why can't the plugin development be conducted here, in sandbox? Does it use a code not allowed to be in the Geronimo repo? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12432001 ] Jason Dillon commented on GERONIMO-2352: Okay, the test deployments are now hooked up to the main build. I'm going to apply the remaining changes from your patch to geronimo-j2ee-builder with some modifications to apply the m2 std layout, and to use the updated artifactIds for the deployment modules. > j2ee-builder test deployment modules won't actually deploy > -- > > Key: GERONIMO-2352 > URL: http://issues.apache.org/jira/browse/GERONIMO-2352 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 >Reporter: Bill Dudney > Assigned To: Jason Dillon > Fix For: 1.2 > > Attachments: GERONIMO-2352.bdudney.patch > > > The ear/war/ejb-jar/rar files wont actually deploy to the server. > I have a partial patch avalible but I'd like to get some discussion going on > how to fix some of the problems, that is happening in the dev list. > I will post the complete patch here when that discussion is wrapped up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: RTC: Move java ee 5 specs into specs trunk (GERONIMO-2358)
+1 Jacek On 8/29/06, David Blevins <[EMAIL PROTECTED]> wrote: http://issues.apache.org/jira/browse/GERONIMO-2358 Back in I think March, I created a branch for implementing the Java EE 5 specs while the specs were still being defined. The specs went final in May and several projects need these specs. We need to get them out of the experimental branch and into trunk. The attached patch moves the required specs from branches/jee5_exp to trunk/ and fixes their poms to be consistent with the rest of the poms. Please note: patch files created with svn cannot express 'svn move' commands, in order to apply this patch you must first do the following moves: svn mv branches/jee5_exp/geronimo-jta_1.1_spec trunk/geronimo- jta_1.1_spec svn mv branches/jee5_exp/geronimo-spec-annotation trunk/geronimo- annotation_1.0_spec svn mv branches/jee5_exp/geronimo-spec-ejb trunk/geronimo-ejb_3.0_spec svn mv branches/jee5_exp/geronimo-spec-interceptor trunk/geronimo- interceptor_3.0_spec svn mv branches/jee5_exp/geronimo-spec-jpa trunk/geronimo-jpa_3.0_spec -David -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] Release car-maven-plugin 1.1
On 8/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: This release goal is to provide a m2 plugin to create Geronimo 1.1 plugins. +0 (fortunatelly, Dave's in favor of it and there won't be a discussion about double +0's and no +1's) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] Release XBean 2.6 (retry)
On 8/30/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: I have uploaded new binaries of xbean. They are available at http://people.apache.org/~gnodet/xbean-2.6/ The changes from the last cut includes a fix for spring 2.0-rc3, and the Genesis dependency which has been removed. +1 Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Updated: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=all ] Jason Dillon updated GERONIMO-2352: --- Component/s: buildsystem Fix Version/s: 1.2 Affects Version/s: 1.2 > j2ee-builder test deployment modules won't actually deploy > -- > > Key: GERONIMO-2352 > URL: http://issues.apache.org/jira/browse/GERONIMO-2352 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 >Reporter: Bill Dudney > Assigned To: Jason Dillon > Fix For: 1.2 > > Attachments: GERONIMO-2352.bdudney.patch > > > The ear/war/ejb-jar/rar files wont actually deploy to the server. > I have a partial patch avalible but I'd like to get some discussion going on > how to fix some of the problems, that is happening in the dev list. > I will post the complete patch here when that discussion is wrapped up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
No issue... * OpenEJB2 snaps need to be published by CI (needs G below) * G snaps to be published by CI (needs OpenEJB2 above) * specs/trunk need to be published * Maven needs to get MNG-1911 fixed And then at that point bootstrap will not be needed for normal use... may still want to keep it in to allow the clean repo bits to ensure that G still builds correctly and downloads artifacts though. --jason On Aug 31, 2006, at 3:24 PM, Jacek Laskowski wrote: On 8/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: You most certainly do not need to use it to build Geronimo. It is only an attempt to automate several steps together. As I have said before, and I will undoubtedly say again, bootstrap is temporary and will be removed as soon as we have all of the dependency artifacts published and have a few maven bugs resolved. It may already have been answered, but can't find it and thus the question goes. Is there a JIRA issue that would let us track where we're at in the process of removing bootstrap? I mean, you seem to imply a bunch of steps before bootstrap itself gets whacked. They are subtasks for the main task - bootstrap removed as a build helper tool (no, I won't repeat the mantra about these tasks being helpful for others to track the status *and* help you out where/if possible ;-)) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Created: (GERONIMO-2370) Add serialVersionUID to all classes implementing Serializable
Add serialVersionUID to all classes implementing Serializable - Key: GERONIMO-2370 URL: http://issues.apache.org/jira/browse/GERONIMO-2370 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Environment: All Reporter: Heinz Drews Priority: Minor A number of serializable classes don't have a serialVersionUID specified. This introduces the risk that the generated uid might be diferent between different versions or vendors of JVMs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Upgrade Derby to 10.1.3.1?
You really want a diff of the root pom that changes the version to 10.1.3.1 to review? I can do that, but it seems like a waste of time... and abuse of the RTC concept. If no one objects to it, then why don't we just do it? Its a whopping 1 line change... which affects only 2 chars :-P --jason On Aug 31, 2006, at 3:31 PM, Jacek Laskowski wrote: On 9/1/06, Jason Dillon <[EMAIL PROTECTED]> wrote: A formal RTC... don't think that is needed... my plan was to post the topic to the list, and if no one objected, to create a tracker JIRA and the commit. I think that follows lazy-consensus... and IMO is all that is needed for a minor change like this. Well, we're still in the RTC hug and until it changes we need to obey the rules. On the other hand, if it's a trivial change, RTC is going to happen very quickly. Come on Jason, you did a great job of pushing the m2 changes out of the door (i.e. having applied them to trunk) and was profoundly patient and now you say you can't manage such a small change?! Can't be! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Upgrade Derby to 10.1.3.1?
On 9/1/06, Jason Dillon <[EMAIL PROTECTED]> wrote: A formal RTC... don't think that is needed... my plan was to post the topic to the list, and if no one objected, to create a tracker JIRA and the commit. I think that follows lazy-consensus... and IMO is all that is needed for a minor change like this. Well, we're still in the RTC hug and until it changes we need to obey the rules. On the other hand, if it's a trivial change, RTC is going to happen very quickly. Come on Jason, you did a great job of pushing the m2 changes out of the door (i.e. having applied them to trunk) and was profoundly patient and now you say you can't manage such a small change?! Can't be! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
On 8/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: You most certainly do not need to use it to build Geronimo. It is only an attempt to automate several steps together. As I have said before, and I will undoubtedly say again, bootstrap is temporary and will be removed as soon as we have all of the dependency artifacts published and have a few maven bugs resolved. It may already have been answered, but can't find it and thus the question goes. Is there a JIRA issue that would let us track where we're at in the process of removing bootstrap? I mean, you seem to imply a bunch of steps before bootstrap itself gets whacked. They are subtasks for the main task - bootstrap removed as a build helper tool (no, I won't repeat the mantra about these tasks being helpful for others to track the status *and* help you out where/if possible ;-)) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Standard for serialVersionUID
Eh... probably. --jason On Aug 31, 2006, at 3:17 PM, Heinz Drews wrote: I will create a jira. Should there be a vote about the format of the uid? --heinz On 8/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: On Aug 31, 2006, at 7:01 AM, Zakharov, Vasily M wrote: > Note however, that small values like 1 or 2 are traditionally used as > serialVersionUIDs for synthetic and other system classes, like > Enums and > RMI Stubs, that are serialized in a special way. So using such > values in > "normal" classes may confuse the future readers of the code and make > them wonder if that particular class is serialized in a special > way. So > I'm suggesting using traditional (20-digit or so) values for > serialVersionUIDs. I think that using the short versions... 1, 2, 3, 4... is fine for any serializable. Its much easier to manage too and much easier to debug when mismatch problems arise, since you can see which version is older and how old... using the generated longass versions just shows you they are different, not which is older. --jason
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
On 8/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Um... then what does Perm stand for? Permanent - it's not for GC to take care of. Once it's occupied, it will stay as such forever, once jvm stops. @see https://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html (I think I've read something nicer lately at java.sun.com, but can't find it now) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Standard for serialVersionUID
I will create a jira. Should there be a vote about the format of the uid? --heinz On 8/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: On Aug 31, 2006, at 7:01 AM, Zakharov, Vasily M wrote: > Note however, that small values like 1 or 2 are traditionally used as > serialVersionUIDs for synthetic and other system classes, like > Enums and > RMI Stubs, that are serialized in a special way. So using such > values in > "normal" classes may confuse the future readers of the code and make > them wonder if that particular class is serialized in a special > way. So > I'm suggesting using traditional (20-digit or so) values for > serialVersionUIDs. I think that using the short versions... 1, 2, 3, 4... is fine for any serializable. Its much easier to manage too and much easier to debug when mismatch problems arise, since you can see which version is older and how old... using the generated longass versions just shows you they are different, not which is older. --jason
Re: Build failure on branches/1.1.1 due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar
On 8/31/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: Build is failing due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar unavailable in the repository. Has anyone else hit this error? Console output given below. Haven't checked it out, but seems that you need to co https://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and built it. It should've worked with no additional steps, though, I guess. I'd wait for Matt to comment on it. Perhaps we may need to publish them if they're not available anywhere. Don't know what Geronimo version the JIRA task to put in, though, when it's fixed (you will report the JIRA item, will you? ;-) ) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Upgrade Derby to 10.1.3.1?
A formal RTC... don't think that is needed... my plan was to post the topic to the list, and if no one objected, to create a tracker JIRA and the commit. I think that follows lazy-consensus... and IMO is all that is needed for a minor change like this. --jason On Aug 31, 2006, at 2:59 PM, Jacek Laskowski wrote: On 8/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I was going to create an issue and the commit the change if there were no objections. Don't give us a chance to RTC it? ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Upgrade Derby to 10.1.3.1?
On 8/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I was going to create an issue and the commit the change if there were no objections. Don't give us a chance to RTC it? ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Classes in trunk
On 8/29/06, Sergey Elin <[EMAIL PROTECTED]> wrote: there is a number of class files in trunk. Any reasons for it? Other than there're there for the tests? No. Seriously, there're in trunk as they're simply resources for tests (am I repeating myself?). [EMAIL PROTECTED] /cygdrive/c/oss/geronimo/modules/geronimo-tomcat-builder/src/test/resources/deployables/war4/WEB-INF/classes/org/apache/geronimo/tomcat/app $ svn log Servlet1.class ... r164651 | jgenender | 2005-04-25 23:09:26 +0200 (Mon, 25 Apr 2005) | 1 line New tomcat-builder Jeff added them likely to not have bothered to script their compilation and proper inclusion in the resources directories of these tests (Jeff? Are you reading this? ;-) ). I think you can go and improve it a little. Create a JIRA task and get rid of them. Let's fix it by creating their java sources and let Maven know about the change. Ready to give it a spin? Ask when in trouble. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431991 ] Bill Dudney commented on GERONIMO-2352: --- Hi Jason, That is the question I was asking about in question 2 here; http://www.nabble.com/j2ee-builder-tests--tf2155494.html#a6032026 Basically the tests expect an ear without a geronimo-application.xml I did not know of an easy way to get maven to strip a file from a jar. The ant build file took the content, jar'd it once with geronimo-application.xml and once with out. > j2ee-builder test deployment modules won't actually deploy > -- > > Key: GERONIMO-2352 > URL: http://issues.apache.org/jira/browse/GERONIMO-2352 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Bill Dudney > Assigned To: Jason Dillon > Attachments: GERONIMO-2352.bdudney.patch > > > The ear/war/ejb-jar/rar files wont actually deploy to the server. > I have a partial patch avalible but I'd like to get some discussion going on > how to fix some of the problems, that is happening in the dev list. > I will post the complete patch here when that discussion is wrapped up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[
http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431988
]
Jason Dillon commented on GERONIMO-2352:
What is up with the comments in {{geronimo-j2e-builder/pom.xml}}:
{quote}
need to remove the geronimo-application.xml file from this ear
{quote}
> j2ee-builder test deployment modules won't actually deploy
> --
>
> Key: GERONIMO-2352
> URL: http://issues.apache.org/jira/browse/GERONIMO-2352
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Bill Dudney
> Assigned To: Jason Dillon
> Attachments: GERONIMO-2352.bdudney.patch
>
>
> The ear/war/ejb-jar/rar files wont actually deploy to the server.
> I have a partial patch avalible but I'd like to get some discussion going on
> how to fix some of the problems, that is happening in the dev list.
> I will post the complete patch here when that discussion is wrapped up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release XBean 2.6 (retry)
On 8/30/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: I have uploaded new binaries of xbean. They are available at http://people.apache.org/~gnodet/xbean-2.6/ The changes from the last cut includes a fix for spring 2.0-rc3, and the Genesis dependency which has been removed. Hey Guillaume, I assume it's still tagged as xbean-2.6? Just updating and am about to build and find a couple of examples to give it a try. Asking in case it has changed. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Are the new activemq gbean modules complete?
Has anyone else looked at this patch? I'd really like to get this committed... and we need some other peeps to review. --jason On Aug 29, 2006, at 1:02 PM, Hiram Chirino wrote: Hey Folks.. Here's a patch that update geronimo to run against amq 4: http://issues.apache.org/jira/browse/GERONIMO-2364 Some small little issues are left like the DLQ admin portlet is not updated to use the new amq APIS. Also a small exception is barfed at shutdown. But I want to move on to bigger issues like CTS testing. Anybody have a link to doco on how to get the cts tests going with the trunk version of Geronimo? It's been too long since I last did that. On 7/2/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: Hi David.. That's still work that I've got on my plate to do. The # of gbeans have changed for activemq 4. So before we switch to amq 4 and the new gbean modules, I'll have to update lots of plans. Including the ones in the CTS I imagine. Regards, Hiram On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > I got the new amq gbean modules to compile under m2 and tried to use > them in the activemq-broker plan but there seem to be a lot more > gbean classes in the plan than in the modules. What's going on? Is > there a new way to configure all this stuff? > > thanks > david jencks > > -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: Standard for serialVersionUID
On Aug 31, 2006, at 7:01 AM, Zakharov, Vasily M wrote: Note however, that small values like 1 or 2 are traditionally used as serialVersionUIDs for synthetic and other system classes, like Enums and RMI Stubs, that are serialized in a special way. So using such values in "normal" classes may confuse the future readers of the code and make them wonder if that particular class is serialized in a special way. So I'm suggesting using traditional (20-digit or so) values for serialVersionUIDs. I think that using the short versions... 1, 2, 3, 4... is fine for any serializable. Its much easier to manage too and much easier to debug when mismatch problems arise, since you can see which version is older and how old... using the generated longass versions just shows you they are different, not which is older. --jason
Re: RTC: Move java ee 5 specs into specs trunk (GERONIMO-2358)
+1, the patch seems good.Btw, is there any plan to write jsr181 and jaxws api ?or to borrow them from another project ?On 8/31/06, David Blevins <[EMAIL PROTECTED]> wrote: Need more +1s please :)-DavidOn Aug 28, 2006, at 5:34 PM, David Blevins wrote:> http://issues.apache.org/jira/browse/GERONIMO-2358 >> Back in I think March, I created a branch for implementing the Java> EE 5 specs while the specs were still being defined. The specs went> final in May and several projects need these specs. We need to get > them out of the experimental branch and into trunk.>> The attached patch moves the required specs from branches/jee5_exp> to trunk/ and fixes their poms to be consistent with the rest of> the poms. >> Please note: patch files created with svn cannot express 'svn move'> commands, in order to apply this patch you must first do the> following moves:>> svn mv branches/jee5_exp/geronimo-jta_1.1_spec trunk/geronimo- > jta_1.1_spec> svn mv branches/jee5_exp/geronimo-spec-annotation trunk/geronimo-> annotation_1.0_spec> svn mv branches/jee5_exp/geronimo-spec-ejb trunk/geronimo-ejb_3.0_spec> svn mv branches/jee5_exp/geronimo-spec-interceptor trunk/geronimo- > interceptor_3.0_spec> svn mv branches/jee5_exp/geronimo-spec-jpa trunk/geronimo-jpa_3.0_spec -David>>-- Cheers,Guillaume Nodet
Re: Classes in trunk
I agree... though they may be used by those tests... I am not sure, have not checked. And don't have time to do so at the moment. My guess is that if they are needed that we could either reuse one of the test-deployables (soon to be commited) or maybe we need to and a new one to fit the needs of that test.--jasonOn Aug 31, 2006, at 1:54 AM, Sergey Elin wrote:I think it should be removed from trunk...2006/8/30, Jason Dillon <[EMAIL PROTECTED]>: I dunno... but seems like a bad idea.--jasonOn Aug 29, 2006, at 12:13 AM, Sergey Elin wrote:> Hi,>> there is a number of class files in trunk. Any reasons for it?>> ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ > war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Servlet1.class> ./modules/geronimo-tomcat-builder/src/test/resources/deployables/> war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Filter1.class > ./modules/geronimo-tomcat-builder/src/test/resources/deployables/> war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Servlet2.class> ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ > war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Filter2.class> ./modules/geronimo-tomcat-builder/src/test/resources/deployables/> cltest/mx4j/MBeanDescription.class> ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ > cltest/javax/foo/Foo.class> ./modules/geronimo-tomcat-builder/src/test/resources/deployables/> cltest/javax/servlet/Servlet.class> ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ > war5/WEB-INF/classes/org/apache/geronimo/ws/HelloWorld.class> ./modules/geronimo-tomcat-builder/src/test/resources/deployables/> war5/WEB-INF/classes/org/apache/geronimo/ws/HelloWorldWS.class> ./modules/geronimo-jetty-builder/src/test/resources/deployables/ > cltest/mx4j/MBeanDescription.class> ./modules/geronimo-jetty-builder/src/test/resources/deployables/> cltest/javax/foo/Foo.class> ./modules/geronimo-jetty-builder/src/test/resources/deployables/ > cltest/javax/servlet/Servlet.class> ./modules/geronimo-jetty/src/test/resources/deployables/cltest/mx4j/> MBeanDescription.class> ./modules/geronimo-jetty/src/test/resources/deployables/cltest/ > javax/foo/Foo.class> ./modules/geronimo-jetty/src/test/resources/deployables/cltest/> javax/servlet/Servlet.class>
[jira] Commented: (GERONIMO-2349) jta 1.1 support with container manager jpa support in transaction module
[ http://issues.apache.org/jira/browse/GERONIMO-2349?page=comments#action_12431976 ] Jacek Laskowski commented on GERONIMO-2349: --- Hey Dave, I'm lost. I was about to +1 it, but then thought to give it a try and make it to the trunk. But I don't know what to apply. Would you care to comment on it a bit? > jta 1.1 support with container manager jpa support in transaction module > > > Key: GERONIMO-2349 > URL: http://issues.apache.org/jira/browse/GERONIMO-2349 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2 > > Attachments: GERONIMO-2349-1.patch, GERONIMO-2349-2.patch, > GERONIMO-2349-3.patch, GERONIMO-2349-v4-plus-2163-openejb.patch, > GERONIMO-2349-v4-plus-2163.patch, persistencecontextref.zip > > > We need a strategy for supporting jta 1.1 and parts of jpa in the transaction > module while still passing the j2ee 1.4 signature tests. Here's a proposal: > - put the basis for support into the current transaction module, but don't > use any jee5 interfaces > - add an additional transaction-jta11 module that uses the new interfaces and > extends the appropriate classes in transaction. > I've started along this path. I'll put the new module in sandbox and supply > a patch for the changes to the existing transaction module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Restructuring trunk, then next steps
Ok ... take a deep breath. This proposal was *not* just to work around windows. It was to offer what I thought were constructive ideas and avoid exasperating a known problem unnecessarily. I understand your hesitation to bundle the builders and deployers together (which is why I had a note there). What do you think about the rest of the proposal? - Type based groupings in addition to functional groupings. - One level deep. While I love hierarchy, I think it's overkill here. - Elimination of redundancy in names as much as possible. (BTW, I know your post was a "crude stab" so I thought this was the type of input you were requesting to refine it). - "server" in place of "system" - "features" in place of "plugins" - Consistent naming of artifacts when the type is included in the name (such as with builder and deployer). Joe Jason Dillon wrote: On Aug 31, 2006, at 7:26 AM, Joe Bohn wrote: I'd like to propose that we keep things simple and eliminate redundancy where possible. I'd also like to keep things as brief as possible to prevent current or future issues with the windows pathlength issue. I don't think the proposed changes will cause immediate problems but I'd like to prevent/reduce the possibility of problems. I really, really, really don't like to be restricted by the limitations of a certain lame operating system... in fact it fills me with rage. If windows still had 8.3 file name limitations... would we have to make ever class conform to that naming system?! Windows is also case insensitive, so should we use all UPPER CASE FILES TO AVOID conflicting files? Windows stuff crashed all of the time... do we add some hooks to cause the server to crash just to fit in?!? I am sorry your OS is retarded... but I see no reason to design the build structure based on its limitations... especially if a different layout make more sense to group logical modules together. Do I understand correctly that with this proposal what is currently "modules/geronimo-j2ee-builder" would become "system/geronimo-j2ee/geronimo-j2ee-builder" and what is currently "modules/geronimo-j2ee" would become "system/geronimo-j2ee/geronimo-j2ee"? If so, then I think we are introducing some unnecessary redundancy once again. No, we would not end up with system/geronimo-j2ee/geronimo-j2ee. As I mentioned this was a "crude stab" meaning that I did not take much time to clean up, just put out the basic high level organization groups and filled in the current modules. BTW, do I understand correctly that you're proposing the removal of "modules" or is this presumed to be prior to each of the new names? Yes, modules is to be removed. I wondering if it might be better to have more types and less subtypes (perhaps deciding to have only a single collection of types with no subtypes at all). Perhaps something like: builders/ (not sure yet if I like this myself :-) ) geronimo-j2ee-builder geronimo-service-builder geronimo-axis-builder geronimo-tomcat-builder geronimo-jetty-builder geronimo-security-builder geronimo-service-builder geronimo-connector-builder geronimo-naming-builder geronimo-client-builder geronimo-j2ee-builder geronimo-web-builder I had thought about grouping the builders together... though I'm still drawn about if these should be closer to their code modules or not. Generally I'd like to have all of the tomcat integration code together, all the jetty code together and so on... --jason ** Note, the way we name builders and the way we name deployers is inconsistent. I think we need to decide if we want the descriptive type first or last in these names and use the pattern consistently. deployers/ geronimo-deploy-core (was geronimo-deployment) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-deploy-hot (was geronimo-hot-deploy ... just to be consistent with other deployers but see note above) ? framework/ geronimo-testsupport geronimo-test-ddbean (not sure what this is either) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel server/ geronimo-management geronimo-security geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-jmx-remoting geronimo-naming geronimo-client geronimo-j2ee geronimo-j2ee-schema features/ geronimo-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-derby geronimo-directory geronimo-tomcat geronimo-jetty geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter Joe Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chu
Re: Restructuring trunk, then next steps
wow, nice rant ;) To be correct it is an API problem in windows that path names are restricted to 254 or 260 chars (Win2k), it's not an NTFS problem. You can create pathes with more characters when using UNC names. The limitation should be 32767 chars. If you have already a base path for the sources, you can share this path e.g. d:\home\tweety\wrk\java\geronimo as windows share and map it as drive p: for example. Now change to the mapped drive and do what you want with the path until he is 254 chars long. With that path example you save about 30 characters. Thanks, Mario Jason Dillon wrote: On Aug 31, 2006, at 7:26 AM, Joe Bohn wrote: I'd like to propose that we keep things simple and eliminate redundancy where possible. I'd also like to keep things as brief as possible to prevent current or future issues with the windows pathlength issue. I don't think the proposed changes will cause immediate problems but I'd like to prevent/reduce the possibility of problems. I really, really, really don't like to be restricted by the limitations of a certain lame operating system... in fact it fills me with rage. If windows still had 8.3 file name limitations... would we have to make ever class conform to that naming system?! Windows is also case insensitive, so should we use all UPPER CASE FILES TO AVOID conflicting files? Windows stuff crashed all of the time... do we add some hooks to cause the server to crash just to fit in?!? I am sorry your OS is retarded... but I see no reason to design the build structure based on its limitations... especially if a different layout make more sense to group logical modules together. Do I understand correctly that with this proposal what is currently "modules/geronimo-j2ee-builder" would become "system/geronimo-j2ee/geronimo-j2ee-builder" and what is currently "modules/geronimo-j2ee" would become "system/geronimo-j2ee/geronimo-j2ee"? If so, then I think we are introducing some unnecessary redundancy once again. No, we would not end up with system/geronimo-j2ee/geronimo-j2ee. As I mentioned this was a "crude stab" meaning that I did not take much time to clean up, just put out the basic high level organization groups and filled in the current modules. BTW, do I understand correctly that you're proposing the removal of "modules" or is this presumed to be prior to each of the new names? Yes, modules is to be removed. I wondering if it might be better to have more types and less subtypes (perhaps deciding to have only a single collection of types with no subtypes at all). Perhaps something like: builders/ (not sure yet if I like this myself :-) ) geronimo-j2ee-builder geronimo-service-builder geronimo-axis-builder geronimo-tomcat-builder geronimo-jetty-builder geronimo-security-builder geronimo-service-builder geronimo-connector-builder geronimo-naming-builder geronimo-client-builder geronimo-j2ee-builder geronimo-web-builder I had thought about grouping the builders together... though I'm still drawn about if these should be closer to their code modules or not. Generally I'd like to have all of the tomcat integration code together, all the jetty code together and so on... --jason ** Note, the way we name builders and the way we name deployers is inconsistent. I think we need to decide if we want the descriptive type first or last in these names and use the pattern consistently. deployers/ geronimo-deploy-core (was geronimo-deployment) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-deploy-hot (was geronimo-hot-deploy ... just to be consistent with other deployers but see note above) ? framework/ geronimo-testsupport geronimo-test-ddbean (not sure what this is either) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel server/ geronimo-management geronimo-security geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-jmx-remoting geronimo-naming geronimo-client geronimo-j2ee geronimo-j2ee-schema features/ geronimo-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-derby geronimo-directory geronimo-tomcat geronimo-jetty geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter Joe Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the ser
Re: [jira] Closed: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
FYI, I'd rather add a resolveFile() and resolvePath() to TestSupport
so that tests don't need to muck with File().getPath() and such.
--jason
On Aug 31, 2006, at 12:48 PM, Jason Dillon wrote:
No, the BASEDIR rooting is important, as we can not always control
the basedir that the tests are executed from. Tests are not just
run from maven, but also from IDE's.
It is a good practice to always root your files in tests... and
this is why I changed them to use BASEDIR.
--jason
On Aug 31, 2006, at 6:00 AM, anita kulshreshtha wrote:
I have always wondered why we need to do this:
File auditlog = new File(BASEDIR, "target/login-audit.log");
instead of
File auditlog = new File("target/login-audit.log");
The relative file references in java are resolved using the
current
user dir, given by the system property user.dir, and is typically the
directory in which the Java virtual machine was invoked.
The specifies the dir the jvm is forked
from. If
it is set to {basedir}/target by default, then all the tests should
just use:
File auditlog = new File("login-audit.log");
This is the most natural way. WDYT?
Thanks
Anita
--- "Jason Dillon (JIRA)" wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2211?page=all ]
Jason Dillon closed GERONIMO-2211.
--
Resolution: Fixed
Thanks Anita for pointing out that it works with basedir, the
reference to the login-audit.log was not being rooted with BASEDIR.
Looks okay now, so I'm enabling this test again.
Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL:
http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2 build.
Need someone who knows these tests better to inspect, resolve and
enable the test (remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from starting to
running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from stopped to
starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed
from
stopped to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242
clients can connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed
from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
stopped to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
starting to running
DEBUG [main] Added Application Configuration Entry
properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from
stopped to starting
DEBUG [main] Waiting to start
test/foo/1/car?name=PropertiesSecurityRealm because no targets are
running for reference LoginModuleConfiguration matching the patterns
test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModuleUse State changed from
stopped to
starting
DEBUG [main] Waiting to start
test/foo/1/car?name=AuditLoginModuleUse because no targets are
running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from stopped
to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=
Re: windows build hell
Dain has already tried adding getName() and he reports it works... though I am not sure what value he returned. Try changing it to return "foo"; and see if it works. Or ping Dain... this issue has been broke for far too long, why doesn't someone from openejb just add this method... Dain?!?! --jason On Aug 31, 2006, at 8:51 AM, Joe Bohn wrote: Jason, I'm not sure just adding getName() will fix the openejb test problem. See my earlier post: http://marc.theaimsgroup.com/?l=geronimo-dev&m=115680051431478&w=2 Joe Jason Dillon wrote: If using 1.4.5-SNAPSHOT fixes things... then lets just use it. Can someone with openejb2 commit privs add a getName() to get past that other error too? --jason On Aug 30, 2006, at 8:46 AM, Jeff Genender wrote: Joe Bohn wrote: 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5- SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. Its not a red herring. It gets you around the problem because in 1.4.5 I actually hunt down the tools.jar file...in a similar fashion as done in Ant when running the jspc complier from there. i.e.: ... I have to duplicate that in code. That's why 1.4.5 works. The release is under vote. So far no -1s. I think I will be able to release it today as the 72 hours is up. I'll let this list know when I have released it. Jeff
Re: Standard for serialVersionUID
On Aug 31, 2006, at 8:34 AM, Heinz Drews wrote: Just as clarification, in the approach with the version number it was not changed with each modification. Only if a change was causing an impact to the serialized version. I think that is the general point... only change the version when the serialized form changes... else it does not change. --jason
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[
http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431957
]
Jason Dillon commented on GERONIMO-2352:
These war's don't need jspc... the problem you saw was because the root pom
configures war's to assume that they are to be used with jspc by default... and
I even have some comments to remove that.
The fix is simiple though...
{code:xml}
org.apache.maven.plugins
maven-war-plugin
${pom.basedir}/src/main/webapp/WEB-INF/web.xml
{code}
I will eventually reconfigure the default war plugin to not assume its being
used with jspc.
> j2ee-builder test deployment modules won't actually deploy
> --
>
> Key: GERONIMO-2352
> URL: http://issues.apache.org/jira/browse/GERONIMO-2352
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Bill Dudney
> Assigned To: Jason Dillon
> Attachments: GERONIMO-2352.bdudney.patch
>
>
> The ear/war/ejb-jar/rar files wont actually deploy to the server.
> I have a partial patch avalible but I'd like to get some discussion going on
> how to fix some of the problems, that is happening in the dev list.
> I will post the complete patch here when that discussion is wrapped up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2369) Need to set db2 port to 50000 in the ra.xml for tranql db2 xa wrapper
[ http://issues.apache.org/jira/browse/GERONIMO-2369?page=all ] Lin Sun updated GERONIMO-2369: -- Attachment: G2369.patch > Need to set db2 port to 5 in the ra.xml for tranql db2 xa wrapper > - > > Key: GERONIMO-2369 > URL: http://issues.apache.org/jira/browse/GERONIMO-2369 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector >Affects Versions: 1.1 > Environment: winxp >Reporter: Lin Sun >Priority: Minor > Attachments: G2369.patch > > > In the ra.xml for the tranql db2 xa wrapper. it has: > > >Specifies the port number the remote database server is >listening on for incoming connections. The default > for a >DB2 server is 5. > > PortNumber > > java.lang.Integer > > Since the default port for db2 server is 5, we should add the following > line above the line. > 5 > If this isn't added, and someone forgot to put a port when creating a db2 xa > database pool, the pool will be unusable as it is defaulted to port 446. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Restructuring trunk, then next steps
On Aug 31, 2006, at 7:26 AM, Joe Bohn wrote: I'd like to propose that we keep things simple and eliminate redundancy where possible. I'd also like to keep things as brief as possible to prevent current or future issues with the windows pathlength issue. I don't think the proposed changes will cause immediate problems but I'd like to prevent/reduce the possibility of problems. I really, really, really don't like to be restricted by the limitations of a certain lame operating system... in fact it fills me with rage. If windows still had 8.3 file name limitations... would we have to make ever class conform to that naming system?! Windows is also case insensitive, so should we use all UPPER CASE FILES TO AVOID conflicting files? Windows stuff crashed all of the time... do we add some hooks to cause the server to crash just to fit in?!? I am sorry your OS is retarded... but I see no reason to design the build structure based on its limitations... especially if a different layout make more sense to group logical modules together. Do I understand correctly that with this proposal what is currently "modules/geronimo-j2ee-builder" would become "system/geronimo-j2ee/geronimo-j2ee-builder" and what is currently "modules/geronimo-j2ee" would become "system/geronimo-j2ee/geronimo-j2ee"? If so, then I think we are introducing some unnecessary redundancy once again. No, we would not end up with system/geronimo-j2ee/geronimo-j2ee. As I mentioned this was a "crude stab" meaning that I did not take much time to clean up, just put out the basic high level organization groups and filled in the current modules. BTW, do I understand correctly that you're proposing the removal of "modules" or is this presumed to be prior to each of the new names? Yes, modules is to be removed. I wondering if it might be better to have more types and less subtypes (perhaps deciding to have only a single collection of types with no subtypes at all). Perhaps something like: builders/ (not sure yet if I like this myself :-) ) geronimo-j2ee-builder geronimo-service-builder geronimo-axis-builder geronimo-tomcat-builder geronimo-jetty-builder geronimo-security-builder geronimo-service-builder geronimo-connector-builder geronimo-naming-builder geronimo-client-builder geronimo-j2ee-builder geronimo-web-builder I had thought about grouping the builders together... though I'm still drawn about if these should be closer to their code modules or not. Generally I'd like to have all of the tomcat integration code together, all the jetty code together and so on... --jason ** Note, the way we name builders and the way we name deployers is inconsistent. I think we need to decide if we want the descriptive type first or last in these names and use the pattern consistently. deployers/ geronimo-deploy-core (was geronimo-deployment) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-deploy-hot (was geronimo-hot-deploy ... just to be consistent with other deployers but see note above) ? framework/ geronimo-testsupport geronimo-test-ddbean (not sure what this is either) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel server/ geronimo-management geronimo-security geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-jmx-remoting geronimo-naming geronimo-client geronimo-j2ee geronimo-j2ee-schema features/ geronimo-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-derby geronimo-directory geronimo-tomcat geronimo-jetty geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter Joe Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-
[jira] Created: (GERONIMO-2369) Need to set db2 port to 50000 in the ra.xml for tranql db2 xa wrapper
Need to set db2 port to 5 in the ra.xml for tranql db2 xa wrapper - Key: GERONIMO-2369 URL: http://issues.apache.org/jira/browse/GERONIMO-2369 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector Affects Versions: 1.1 Environment: winxp Reporter: Lin Sun Priority: Minor In the ra.xml for the tranql db2 xa wrapper. it has: Specifies the port number the remote database server is listening on for incoming connections. The default for a DB2 server is 5. PortNumber java.lang.Integer Since the default port for db2 server is 5, we should add the following line above the line. 5 If this isn't added, and someone forgot to put a port when creating a db2 xa database pool, the pool will be unusable as it is defaulted to port 446. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Is jetty broken in latest snapshots?
gnodet wrote: > > I do not see any reasons. > I have tested the samples and they work. > Could you paste the content of your SU and the console log ? > > On 8/31/06, jsolderitsch <[EMAIL PROTECTED]> wrote: >> >> >> >> jsolderitsch wrote: >> > >> >> I really need some advice here. >> >> I saw in another post that jetty is supposed to start automatically if >> you >> use an http su. >> >> My service assembly DOES include such an su. >> >> With 3.0M2, deploying my sa causes jetty to start as expected. >> >> With the last 3 days snapshots, this is NOT the case. A deployment that >> works just fine with 3.0M2 now fails to work. >> >> I learned that you can force jetty to start with the proper servicemix >> configuration entry. >> >> But I need an example of the syntax I need to add to servicemix.xml or >> servicemix.conf to make this happen. >> >> Any reason why the startup behavior with the snapshots is different than >> the >> last milestone? >> >> Jim >> >> -- >> View this message in context: >> http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6086662 >> Sent from the ServiceMix - Dev forum at Nabble.com. >> >> > > > -- > Cheers, > Guillaume Nodet > > I am sending the xbean and jbi xml files via private email. I hope they can suggest what my problem could be? There is a change from 3.0M2 that is rather severe. Could this be a platform issue -- are you using Windows XP to test this? I am not using Windows here. Jim -- View this message in context: http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6086959 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: [jira] Closed: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
No, the BASEDIR rooting is important, as we can not always control
the basedir that the tests are executed from. Tests are not just run
from maven, but also from IDE's.
It is a good practice to always root your files in tests... and this
is why I changed them to use BASEDIR.
--jason
On Aug 31, 2006, at 6:00 AM, anita kulshreshtha wrote:
I have always wondered why we need to do this:
File auditlog = new File(BASEDIR, "target/login-audit.log");
instead of
File auditlog = new File("target/login-audit.log");
The relative file references in java are resolved using the current
user dir, given by the system property user.dir, and is typically the
directory in which the Java virtual machine was invoked.
The specifies the dir the jvm is forked from. If
it is set to {basedir}/target by default, then all the tests should
just use:
File auditlog = new File("login-audit.log");
This is the most natural way. WDYT?
Thanks
Anita
--- "Jason Dillon (JIRA)" wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2211?page=all ]
Jason Dillon closed GERONIMO-2211.
--
Resolution: Fixed
Thanks Anita for pointing out that it works with basedir, the
reference to the login-audit.log was not being rooted with BASEDIR.
Looks okay now, so I'm enabling this test again.
Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL:
http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2 build.
Need someone who knows these tests better to inspect, resolve and
enable the test (remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from starting to
running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from stopped to
starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from
stopped to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242
clients can connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
stopped to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
starting to running
DEBUG [main] Added Application Configuration Entry
properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from
stopped to starting
DEBUG [main] Waiting to start
test/foo/1/car?name=PropertiesSecurityRealm because no targets are
running for reference LoginModuleConfiguration matching the patterns
test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModuleUse State changed from stopped to
starting
DEBUG [main] Waiting to start
test/foo/1/car?name=AuditLoginModuleUse because no targets are
running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from stopped
to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from starting
to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModuleUse State changed from
stopped to starting
DEBUG [main] Waiting to s
Re: [jira] Closed: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
Yes I know that, and I changed it to ${basedir}/target on purpose.
--jason
On Aug 31, 2006, at 6:49 AM, anita kulshreshtha wrote:
One more thing..
In m1 the jvm was forked from basedir, hence we have all the file
references as target/
http://maven.apache.org/maven-1.x/plugins/test/properties.html
So we should modify all the tests to not used target!
Thanks
Anita
--- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
I have always wondered why we need to do this:
File auditlog = new File(BASEDIR, "target/login-audit.log");
instead of
File auditlog = new File("target/login-audit.log");
The relative file references in java are resolved using the
current
user dir, given by the system property user.dir, and is typically the
directory in which the Java virtual machine was invoked.
The specifies the dir the jvm is forked from.
If
it is set to {basedir}/target by default, then all the tests should
just use:
File auditlog = new File("login-audit.log");
This is the most natural way. WDYT?
Thanks
Anita
--- "Jason Dillon (JIRA)" wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2211?page=all
]
Jason Dillon closed GERONIMO-2211.
--
Resolution: Fixed
Thanks Anita for pointing out that it works with basedir, the
reference to the login-audit.log was not being rooted with BASEDIR.
Looks okay now, so I'm enabling this test again.
Enable tests (geronimo-security ::
**/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL:
http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2
build.
Need someone who knows these tests better to inspect, resolve and
enable the test (remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from starting to
running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=ServerInfo
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=ServerInfo
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from stopped to
starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from starting
to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed
from
stopped to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242
clients can connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed
from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
stopped to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
starting to running
DEBUG [main] Added Application Configuration Entry
properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from
stopped to starting
DEBUG [main] Waiting to start
test/foo/1/car?name=PropertiesSecurityRealm because no targets are
running for reference LoginModuleConfiguration matching the
patterns
test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModuleUse State changed from stopped
to
starting
DEBUG [main] Waiting to start
test/foo/1/car?name=AuditLoginModuleUse because no targets are
running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from
stopped
to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from
starting
to running
DEBUG [main] GBeanInstanceState for:
test/
Re: Anyone know how to make the kernel tests be quiet?
Ya, I'm not sure that surefire has support for that :-( --jason On Aug 31, 2006, at 6:35 AM, anita kulshreshtha wrote: In M1 there was a way to say swallow ouput. I can not find a reference to it. But trying.. Thanks Anita --- Jason Dillon <[EMAIL PROTECTED]> wrote: I'm not sure how they were quiet before m2 with code like above in setUp(). --jason On Aug 28, 2006, at 4:29 PM, Jason Dillon wrote: Thats odd, because the default logging config is set to only allow WARN and ERROR to go to console, not DEBUG. Do these tests need to: GeronimoLogging.initialize(GeronimoLogging.INFO); Or something? --jason On Aug 28, 2006, at 10:14 AM, Dain Sundstrom wrote: Not me. They were quiet before the m2 change but it looks like logging got turned up. -dain On Aug 28, 2006, at 2:26 AM, Jason Dillon wrote: These tests make way... way to much noise. Anyone know how to make them shut up? --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Is jetty broken in latest snapshots?
I do not see any reasons. I have tested the samples and they work. Could you paste the content of your SU and the console log ? On 8/31/06, jsolderitsch <[EMAIL PROTECTED]> wrote: jsolderitsch wrote: > > I have tried both the August 29 and August 30 binary snapshots. > > With 3.0M2, I see a log message reporting jetty starting up. I can reach a > port 8192 url as expected. > > With the snapshots, I see no such messages, and any attempt to reach a url > on my servicemix machine with port 8192 results in a can't conect to > server message. > > If this is a known issue, which snapshot has a working jetty integration? > > Jim > I really need some advice here. I saw in another post that jetty is supposed to start automatically if you use an http su. My service assembly DOES include such an su. With 3.0M2, deploying my sa causes jetty to start as expected. With the last 3 days snapshots, this is NOT the case. A deployment that works just fine with 3.0M2 now fails to work. I learned that you can force jetty to start with the proper servicemix configuration entry. But I need an example of the syntax I need to add to servicemix.xml or servicemix.conf to make this happen. Any reason why the startup behavior with the snapshots is different than the last milestone? Jim -- View this message in context: http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6086662 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
Re: Is jetty broken in latest snapshots?
jsolderitsch wrote: > > I have tried both the August 29 and August 30 binary snapshots. > > With 3.0M2, I see a log message reporting jetty starting up. I can reach a > port 8192 url as expected. > > With the snapshots, I see no such messages, and any attempt to reach a url > on my servicemix machine with port 8192 results in a can't conect to > server message. > > If this is a known issue, which snapshot has a working jetty integration? > > Jim > I really need some advice here. I saw in another post that jetty is supposed to start automatically if you use an http su. My service assembly DOES include such an su. With 3.0M2, deploying my sa causes jetty to start as expected. With the last 3 days snapshots, this is NOT the case. A deployment that works just fine with 3.0M2 now fails to work. I learned that you can force jetty to start with the proper servicemix configuration entry. But I need an example of the syntax I need to add to servicemix.xml or servicemix.conf to make this happen. Any reason why the startup behavior with the snapshots is different than the last milestone? Jim -- View this message in context: http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6086662 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Resolved: (SM-563) service unite declaration orderi in jbi.xml does not correspond to the service assembly pom
[ https://issues.apache.org/activemq/browse/SM-563?page=all ] Philip Dodds resolved SM-563. - Fix Version/s: 3.0-M3 Resolution: Fixed Fix for SM-563 - its not pretty but it does work - basically the maven-project is not maintaining the order of the dependencies on the model - therefore we re-parse the model to get it back to its original state and thus back in the correct order. This issue with Maven has been fixed and should be available in 2.0.5 (commented the code to note this). > service unite declaration orderi in jbi.xml does not correspond to the > service assembly pom > --- > > Key: SM-563 > URL: https://issues.apache.org/activemq/browse/SM-563 > Project: ServiceMix > Issue Type: Bug > Components: tooling >Affects Versions: incubation >Reporter: Raffaele Spazzoli > Fix For: 3.0-M3 > > Attachments: sample-sa.zip > > > I declare the following ordering in service assembly pom: > 1,2,3,4 > and the generated jbi.xml has the following order > 1,4,3,2 > This is a problem when there are dependencies between service unit. > I think the jbi maven plugin can be fixed to preserve the order, nevertheless > I suggest to use maven dependency mechanism to deduct the right order. > So if su2 depends on su1 in its pom there should be dependency to su1 just > there is a dependcy to its component. > I attach the example that gives the error to me. Note that: > 1. you'll find a referred component that I'm developing so the project is non > deployable. Should not be necessary to debug. > 2. I don't use the dependecy form su to component, but the property > declaration. The dependency give me problems that I still don't understand. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: servicemix-http and normalization
Guillaume Nodet wrote: The binding model should only be built on top of the wsdl for the current HttpEndpoint (either consumer or provider). This WSDL can be explicitely set, or may be auto-generated using the target endpoint WSDL. If the WSDL is provided, there is nothing to do, but if the WSDL is generated, we have to: * check if there is any existing binding infos (for example, if the target endpoint is a soap provider). In this case, we should use the binding informations * else, we need a flag on the http endpoint to set the binding style (rpc / doc). If the user need to provide a more detailed binding, then he has to provide it in the wsdl. Ok, that clarifies it. I'm trying to abstract the SoapBindingModel a bit more to be able to easily handle a plain HTTP binding. WSDL 2.0 bindings will require another reformat later i guess. Cool! I might be able to help with WSDL 2.0 as well. thanks, alex
[jira] Resolved: (SM-562) Unable to start due to missing lib/optional directory
[ https://issues.apache.org/activemq/browse/SM-562?page=all ] Guillaume Nodet resolved SM-562. Fix Version/s: 3.0-M3 Resolution: Fixed Assignee: Guillaume Nodet > Unable to start due to missing lib/optional directory > - > > Key: SM-562 > URL: https://issues.apache.org/activemq/browse/SM-562 > Project: ServiceMix > Issue Type: Bug >Affects Versions: 3.0-M2 > Environment: Window 2000 >Reporter: Bruce Appleton > Assigned To: Guillaume Nodet >Priority: Minor > Fix For: 3.0-M3 > > Attachments: servicemixbug.txt > > > Installing as per directions in > http://incubator.apache.org/servicemix/getting-started.html#GettingStarted-StartingServiceMix > When starting the servicemix batch file from cd [servicemix_install_dir]\bin > I get a FileNotFoundException for the \lib\optional directory (see > attachment). > When I add the optional directory from servicemix-1.0-M1 servicemix does > start up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release car-maven-plugin 1.1
+1 -David On Aug 29, 2006, at 2:22 AM, Guillaume Nodet wrote: This release goal is to provide a m2 plugin to create Geronimo 1.1 plugins. As stated in a previous proposal, I have forked the car-maven- plugin from trunk to branches/1.1 and updated it to use 1.1 binaries and to generate 1.1 plugins. Hence, I start this vote to publish the 1.1 version of this plugin. The binaries are available at http://people.apache.org/~gnodet/car-maven-plugin-1.1/org/apache/ geronimo/plugins/car-maven-plugin/1.1/ and the site has been deployed at http://geronimo.apache.org/maven/car-maven-plugin-1.1/ I will upload and sign these binaries on the m2-ibiblio-rsync- repository, once this vote is over. Btw, I have uploaded the site at people.apache.org:/www/ geronimo.apache.org/maven/car-maven-plugin-1.1/ but I have been unable to browse it and I did make sure the permissions were ok. If someone has any hints on how to make it accessible ... -- Cheers, Guillaume Nodet
Re: RTC: Move java ee 5 specs into specs trunk (GERONIMO-2358)
Need more +1s please :) -David On Aug 28, 2006, at 5:34 PM, David Blevins wrote: http://issues.apache.org/jira/browse/GERONIMO-2358 Back in I think March, I created a branch for implementing the Java EE 5 specs while the specs were still being defined. The specs went final in May and several projects need these specs. We need to get them out of the experimental branch and into trunk. The attached patch moves the required specs from branches/jee5_exp to trunk/ and fixes their poms to be consistent with the rest of the poms. Please note: patch files created with svn cannot express 'svn move' commands, in order to apply this patch you must first do the following moves: svn mv branches/jee5_exp/geronimo-jta_1.1_spec trunk/geronimo- jta_1.1_spec svn mv branches/jee5_exp/geronimo-spec-annotation trunk/geronimo- annotation_1.0_spec svn mv branches/jee5_exp/geronimo-spec-ejb trunk/geronimo-ejb_3.0_spec svn mv branches/jee5_exp/geronimo-spec-interceptor trunk/geronimo- interceptor_3.0_spec svn mv branches/jee5_exp/geronimo-spec-jpa trunk/geronimo-jpa_3.0_spec -David
Re: Where to put new Callback and CallbackHandler classes
+1 to that! On 31 Aug 2006, at 18:25, Hiram Chirino wrote: I'm 100% behind making activeio an optional module. I'll start working on moving some core classes that are in activeio to activemq so that it is not needed to run. Right now the only real functionality that it provides that is optional is the journal implementation. Everything else that is use are just abstract interfaces, and I think those need to be moved/copied to ActiveMQ. On 8/25/06, James Strachan <[EMAIL PROTECTED]> wrote: On 8/25/06, Sepand M <[EMAIL PROTECTED]> wrote: > It does since the CertificateAuthenticationBroker I'm making will need > to use the CertificateCallbacks. > I have put the classes in jaas (core already has a dependancy on jaas > so that's not a problem). I do think the other callbacks should go in > jass now, but I don't want to touch your stuff since I'm not sure > when/if you will accept my patch. Since its all JAAS/security related and to avoid recursive dependencies, how about putting the CertificateAuthenticationBroker in the activemq-jaas module too? The idea behind activemq-core is that it has as few dependencies as possible. Which reminds me - it might be nice to remove the dependency on activeio and make that an optional module. -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
Re: Where to put new Callback and CallbackHandler classes
I've created http://issues.apache.org/activemq/browse/AMQ-907 to track this. On 8/31/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: I'm 100% behind making activeio an optional module. I'll start working on moving some core classes that are in activeio to activemq so that it is not needed to run. Right now the only real functionality that it provides that is optional is the journal implementation. Everything else that is use are just abstract interfaces, and I think those need to be moved/copied to ActiveMQ. On 8/25/06, James Strachan <[EMAIL PROTECTED]> wrote: > On 8/25/06, Sepand M <[EMAIL PROTECTED]> wrote: > > It does since the CertificateAuthenticationBroker I'm making will need > > to use the CertificateCallbacks. > > I have put the classes in jaas (core already has a dependancy on jaas > > so that's not a problem). I do think the other callbacks should go in > > jass now, but I don't want to touch your stuff since I'm not sure > > when/if you will accept my patch. > > Since its all JAAS/security related and to avoid recursive > dependencies, how about putting the CertificateAuthenticationBroker in > the activemq-jaas module too? The idea behind activemq-core is that it > has as few dependencies as possible. > > Which reminds me - it might be nice to remove the dependency on > activeio and make that an optional module. > -- > > James > --- > http://radio.weblogs.com/0112098/ > -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Created: (AMQ-907) Make the ActiveIO dependency and optional dependency.
Make the ActiveIO dependency and optional dependency. --- Key: AMQ-907 URL: https://issues.apache.org/activemq/browse/AMQ-907 Project: ActiveMQ Issue Type: Improvement Components: Broker Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1 Need to move some core classes that are in activeio to activemq so that it is not needed to run. Right now the only real functionality that it provides that is optional is the journal implementation. Everything else that is use from activeio are just abstract interfaces, and I think those need to be moved/copied to ActiveMQ. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Where to put new Callback and CallbackHandler classes
I'm 100% behind making activeio an optional module. I'll start working on moving some core classes that are in activeio to activemq so that it is not needed to run. Right now the only real functionality that it provides that is optional is the journal implementation. Everything else that is use are just abstract interfaces, and I think those need to be moved/copied to ActiveMQ. On 8/25/06, James Strachan <[EMAIL PROTECTED]> wrote: On 8/25/06, Sepand M <[EMAIL PROTECTED]> wrote: > It does since the CertificateAuthenticationBroker I'm making will need > to use the CertificateCallbacks. > I have put the classes in jaas (core already has a dependancy on jaas > so that's not a problem). I do think the other callbacks should go in > jass now, but I don't want to touch your stuff since I'm not sure > when/if you will accept my patch. Since its all JAAS/security related and to avoid recursive dependencies, how about putting the CertificateAuthenticationBroker in the activemq-jaas module too? The idea behind activemq-core is that it has as few dependencies as possible. Which reminds me - it might be nice to remove the dependency on activeio and make that an optional module. -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Assigned: (GERONIMO-2368) Unable to create a (MySQL) database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2368?page=all ] Alan Cabrera reassigned GERONIMO-2368: -- Assignee: Alan Cabrera > Unable to create a (MySQL) database pool > > > Key: GERONIMO-2368 > URL: http://issues.apache.org/jira/browse/GERONIMO-2368 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: databases >Affects Versions: 1.1.1 > Environment: Fedora Core 5 > MySQL 5.0.22 >Reporter: Jay D. McHugh > Assigned To: Alan Cabrera > > I tried to install the MySQL JDBC driver (installation worked) and define my > datasource. > Trying to create the datasource using the wizard locked up the browser and > resulted in the following log file (I tried twice - that is why the error > appears two times): > Copying into repository > mysql-connector-java-3.1.13/mysql-connector-java-3.1.13/bin/jar... Finished. > 08:41:52,551 ERROR [CoyoteAdapter] An exception or error occurred in the > container during the request processing > java.lang.IllegalArgumentException: Qualifier patterns must be present when > first URLPattern is an exact pattern >at javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:98) >at > javax.security.jacc.WebResourcePermission.(WebResourcePermission.java:47) >at > org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200) >at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) >at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) >at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) >at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) >at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) >at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) >at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) >at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) >at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) >at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) >at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) >at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) >at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) >at java.lang.Thread.run(Thread.java:534) > 08:42:50,280 ERROR [CoyoteAdapter] An exception or error occurred in the > container during the request processing > java.lang.IllegalArgumentException: Qualifier patterns must be present when > first URLPattern is an exact pattern >at javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:98) >at > javax.security.jacc.WebResourcePermission.(WebResourcePermission.java:47) >at > org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200) >at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) >at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) >at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) >at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) >at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) >at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) >at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) >at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) >at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) >at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) >at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) >at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) >at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) >at java.lang.Thread.run(Thread.java:534) > I was only able to get through the first page of the wizard before it locked > up. Here are the values that I entered: > Name of Database Pool: plc >
Re: [VOTE] 1.1.1-rc1 for Release
I did. Let me take a look. Regards, Alan Aaron Mulder wrote: Alan, I thought you fixed this in 1.1.1? Thanks, Aaron On 8/31/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Hi Matt, Sorry to say but I'm experiencing similar problems with trying to deploy a derby embedded datasource; I attached this stack trace to the JIRA that Jay filed (thanks Jay!) http://issues.apache.org/jira/browse/GERONIMO-2368 Geronimo Application Server started 09:19:47,792 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec. (URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission. (WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermissi on(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext $SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke (GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke (AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol $Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket (PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt (LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool $ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) On Aug 31, 2006, at 8:22 AM, Jay D. McHugh wrote: > Matt Hogstrom wrote: >> CTS is complete and here is the RC1 for your reviewing pleasure. >> Please send your comments to the dev@geronimo.apache.org list. >> >> If there are no negative comments after Monday, September 5th at >> 0900 ET. We'll move this to be the final and release it. >> >> If there are issues, they will be addressed and another e-mail >> will be issued resetting for an rc2 vote. >> >> Thanks. >> >> *Source* >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1- >> src.tar.gz >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1- >> src.zip >> >> *Specifications* >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-j2ee- >> jacc_1.0_spec-1.1.1.jar >> >> *Schemas* >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema- >> j2ee_1.4-1.0-src.jar >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema- >> j2ee_1.4-1.0.jar >> >> *Distributions* >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- >> j2ee-1.1.1-rc1.tar.gz >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- >> j2ee-1.1.1-rc1.zip >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- >> minimal-1.1.1-rc1.tar.gz >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- >> minimal-1.1.1-rc1.zip >> >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- >> j2ee-1.1.1-rc1.tar.gz >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- >> j2ee-1.1.1-rc1.zip >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- >> minimal-1.1.1-rc1.tar.gz >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- >> minimal-1.1.1-rc1.zip >> >> If you want to build you will need these jars also (will be >> released simultaneously with Geronimo) and these need to be placed >> in your local Maven repository. >> >> *OpenEJB Jars* >> http://people.apache.org/~hogstrom/1.1.1-rc1/openejb- >> builder-2.1.1.jar >> http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-core-2.1.1.jar >> http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-pkgen- >> builder-2.1.1.jar >> >> >> . >> > Hello, > > I tried to install the MySQL JDBC driver (installation worked) and > define my datasource. > > Trying to create the datasource using the wizard locked up the > browser and resulted in the following log file (I tried twice - > that is why the error appears two times): > > Copying into repository mysql-connector-java-3.1.13/mysql-connector- > java-3.1.13/bin/jar... Finished. > 08:41:52,551 ERROR [CoyoteAdapter] An exception or error occurred > in the container during the request processing > java.lang.IllegalArgumentException: Qualifier pattern
Re: Declarative Exception Handling in ServiceMix
You could try to take the EIP WireTap pattern as a basis, or the StaticRoutingSlip. I think of the following pattern: * the pattern receive an exchange A * it copy it and send it to the main target B * if B answers with a DONE, send back DONE to A * if B answers with ACTIVE (out or fault), send back to A * if B answers with ERROR, resend the same exchange to C * send back the answer from C to A I' m not quite sure if we should support some routing here on the Exception reported by B. I guess it should be easy to define sereral classes/target combinations, and the first one that match (the exception inherit the configured one) wins. It would give something like This example would route all IOException to flow1, and other exceptions to default. I also think that the exception should be put in a property on the new exchange, so that the target could use if if necessary. Makes sense ? On 8/31/06, jpuro <[EMAIL PROTECTED]> wrote: So, how would I go about adding this new EIP pattern for handling exceptions? Anybody have any suggestions on what and how it gets configured and how it actually catches the exceptions? I'm guessing it has to be some sort of endpoint that allows you to specify the type of exception to catch and where to route the exception where it is caught, but I'm not sure how this will actually work on the code level. -Jeff jpuro wrote: > > I hear these arguments. My use case may not have been the best example, > but I have run into many other situations where the business requires that > we handle runtime exceptions more gracefully and allow for smarter > routing. Perhaps just adding a new EIP pattern that specifically can > handle exceptions would do the trick. > > -Jeff > > > Philip Dodds-2 wrote: >> >> I Agree that I'm not sure you should build in exception routing when it >> is >> better placed as another component that handles the Call and return of an >> exception. It would seem that when building up services you should be >> handling exceptions and returning faults/exceptions in a clean fashion >> and >> that the routing of exceptions is better placed since I can see there >> becoming increasing details rquired for the routing. Just thinking of a >> SQLException and then needing the sqlCode in order to determine the >> "meaning" of the exception before routing. >> >> Philip >> >> On 8/25/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >>> >>> I guess that if you want to handle exceptions in a JBI compliant way, >>> you should put in the flow some specific components to do that. >>> >>> First, we need to make a distinction between faults and errors. >>> Imho, faults are unrecoverable problems, due to the message itself. >>> Errors are runtime problems, which may be able to be solved at >>> a later time. >>> >>> In your example, depending on the reason why the data could not be >>> stored in the database, the component should return a fault >>> (if the data is corrupted) or an error (the database is down). >>> >>> In your use case, the error should be catched by a simple component >>> (an EIP pattern) between the http component and the business >>> component which would act as a normal proxy when no errors are >>> reported, and redirect the flow elsewhere when an error occurs. >>> >>> Also, I don't really understand the "friendly error" concept ;) >>> The http component is not designed to be a jsp server, so you >>> won't have any nice interface there. The output should be an xml. >>> If you want a nice interface, you should deploy a web app which >>> would call the jbi bus and return a nice html page when an error >>> occurs. >>> >>> Last, while I think declarative transactions may be really useful >>> for POJO based components (servicemix-jsr181, or the yet to be >>> defined new component, see other threads on the list), >>> it would be difficult to apply it in a real JBI world. >>> >>> Let's discuss it, it' s just my thoughts. >>> >>> On 8/25/06, jpuro <[EMAIL PROTECTED]> wrote: >>> > >>> > >>> > I think it would be useful to add declarative exception handling to >>> > ServiceMix. The usefullness of such a feature can be seen from the >>> > following simple use case involving a client submitting an order to a >>> > fulfillment company: >>> > >>> > 1) The use case starts when the client sends an order to an HTTP >>> endpoint >>> > exposed in ServiceMix. The message representing the order is routed >>> to >>> a >>> > business service component. >>> > >>> > 2) The business service component attempts to process the Order and >>> save >>> > it >>> > to a database. However, an exception occurs during this process and >>> gets >>> > bubbled up. The fulfillment company would like to be notified via >>> email >>> > when an order fails to be processed. Since we have configured the >>> > business >>> > service component to pass all exceptions to an email component, the >>> flow >>> > moves to step 3. >>> > >>> > 3) Th
Re: JPA Plugin patch
Just installed the following pieces from G 1.1 download: geronimo/geronimo-gbean-deployer/1.1/geronimo-gbean-deployer-1.1.car geronimo/geronimo-system/1.1/geronimo-system-1.1.jar geronimo/geronimo-deployment/1.1/geronimo-deployment-1.1.jar geronimo/geronimo-management/1.1/geronimo-management-1.1.jar geronimo/geronimo-service-builder/1.1/geronimo-service-builder-1.1.jar The new build attempt fails with this error: [[INFO] [car:prepare-plan] [INFO] Generated: /Users/andrus/work/jpa-misc/gplugins-jpa/plugins/ common/target/plan/plan.xml [INFO] [car:package] [INFO] Packaging module configuration: /Users/andrus/work/jpa-misc/ gplugins-jpa/plugins/common/target/plan/plan.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] start of geronimo/geronimo-gbean-deployer/1.1/car failed Target does not have specified method (declared in a GBeanInfo operation): name=addGBeans methodName=addGBeans targetClass=org.apache.geronimo.deployment.service.ServiceConfigBuilder Any ideas? Andrus On Aug 31, 2006, at 7:34 PM, Aaron Mulder wrote: You need to manually install the Geronimo 1.1 CARs into your local M2 repo. Unfortunately, the only way to do this is to build the Geronimo 1.1 tag from source or to create them by JARring up the right directories in a Geronimo 1.1 installation. Matt Hogstrom has a todo to put all the Geronimo 1.1 CARs and WARs into a Maven repository, but it doesn't seem to be real high on his list Matt, any ETA? Thanks, Aaron On 8/31/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote: This one (which to the best of my knowledge corresponds to the final release of the spec) http://people.apache.org/repo/m2-snapshot-repository/org/apache/ geronimo/specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/ BTW, are you able to build a functioning plugin? I am getting stuck here: # cd plugins/common # mvn install [ERROR] BUILD ERROR [INFO] - --- [INFO] load of geronimo/geronimo-gbean-deployer/1.1/car failed Andrus On Aug 31, 2006, at 7:22 PM, Aaron Mulder wrote: > OK, but which JPA spec JAR are you using? I want to make sure I'm > building against "the latest". > > Thanks, > Aaron > > On 8/31/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote: >> Hi Aaron, >> >> finally got time to start poking around JPA plugin. I can compile it >> now, but it requires a patch below to build against the latest JPA >> spec. Not a big fan of SF issue tracker, so I simply put it on the >> web: >> >> http://people.apache.org/~aadamchik/jpa-plugin-patch.txt >> >> Andrus >> >
Re: Declarative Exception Handling in ServiceMix
So, how would I go about adding this new EIP pattern for handling exceptions? Anybody have any suggestions on what and how it gets configured and how it actually catches the exceptions? I'm guessing it has to be some sort of endpoint that allows you to specify the type of exception to catch and where to route the exception where it is caught, but I'm not sure how this will actually work on the code level. -Jeff jpuro wrote: > > I hear these arguments. My use case may not have been the best example, > but I have run into many other situations where the business requires that > we handle runtime exceptions more gracefully and allow for smarter > routing. Perhaps just adding a new EIP pattern that specifically can > handle exceptions would do the trick. > > -Jeff > > > Philip Dodds-2 wrote: >> >> I Agree that I'm not sure you should build in exception routing when it >> is >> better placed as another component that handles the Call and return of an >> exception. It would seem that when building up services you should be >> handling exceptions and returning faults/exceptions in a clean fashion >> and >> that the routing of exceptions is better placed since I can see there >> becoming increasing details rquired for the routing. Just thinking of a >> SQLException and then needing the sqlCode in order to determine the >> "meaning" of the exception before routing. >> >> Philip >> >> On 8/25/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >>> >>> I guess that if you want to handle exceptions in a JBI compliant way, >>> you should put in the flow some specific components to do that. >>> >>> First, we need to make a distinction between faults and errors. >>> Imho, faults are unrecoverable problems, due to the message itself. >>> Errors are runtime problems, which may be able to be solved at >>> a later time. >>> >>> In your example, depending on the reason why the data could not be >>> stored in the database, the component should return a fault >>> (if the data is corrupted) or an error (the database is down). >>> >>> In your use case, the error should be catched by a simple component >>> (an EIP pattern) between the http component and the business >>> component which would act as a normal proxy when no errors are >>> reported, and redirect the flow elsewhere when an error occurs. >>> >>> Also, I don't really understand the "friendly error" concept ;) >>> The http component is not designed to be a jsp server, so you >>> won't have any nice interface there. The output should be an xml. >>> If you want a nice interface, you should deploy a web app which >>> would call the jbi bus and return a nice html page when an error >>> occurs. >>> >>> Last, while I think declarative transactions may be really useful >>> for POJO based components (servicemix-jsr181, or the yet to be >>> defined new component, see other threads on the list), >>> it would be difficult to apply it in a real JBI world. >>> >>> Let's discuss it, it' s just my thoughts. >>> >>> On 8/25/06, jpuro <[EMAIL PROTECTED]> wrote: >>> > >>> > >>> > I think it would be useful to add declarative exception handling to >>> > ServiceMix. The usefullness of such a feature can be seen from the >>> > following simple use case involving a client submitting an order to a >>> > fulfillment company: >>> > >>> > 1) The use case starts when the client sends an order to an HTTP >>> endpoint >>> > exposed in ServiceMix. The message representing the order is routed >>> to >>> a >>> > business service component. >>> > >>> > 2) The business service component attempts to process the Order and >>> save >>> > it >>> > to a database. However, an exception occurs during this process and >>> gets >>> > bubbled up. The fulfillment company would like to be notified via >>> email >>> > when an order fails to be processed. Since we have configured the >>> > business >>> > service component to pass all exceptions to an email component, the >>> flow >>> > moves to step 3. >>> > >>> > 3) The email component sends out an email notification to the >>> fulfillment >>> > company indicating that an error occurred while processing the order. >>> > >>> > 4) After the email has been sent out, the flow moves to another >>> component >>> > that returns a more user friendly error message to the original HTTP >>> > endpoint. This way we do not send back a hard to read error message >>> to >>> > the >>> > client. >>> > >>> > The purpose of such a flow is that we handle exceptions more >>> gracefully >>> > than >>> > currently is supported by ServiceMix. Instead of bubbling up >>> exceptions >>> > to >>> > the calling component, we should allow components to change the flow >>> of >>> a >>> > message when an exception occurs. >>> > >>> > The configuration could look something like the following: >>> > >>> > >> > service="example:businessService" >>> > >>> > >>> exceptionDestionationService="example:emailService"> >>> >
Re: windows build hell
Jason, I'm not sure just adding getName() will fix the openejb test problem. See my earlier post: http://marc.theaimsgroup.com/?l=geronimo-dev&m=115680051431478&w=2 Joe Jason Dillon wrote: If using 1.4.5-SNAPSHOT fixes things... then lets just use it. Can someone with openejb2 commit privs add a getName() to get past that other error too? --jason On Aug 30, 2006, at 8:46 AM, Jeff Genender wrote: Joe Bohn wrote: 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5- SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. Its not a red herring. It gets you around the problem because in 1.4.5 I actually hunt down the tools.jar file...in a similar fashion as done in Ant when running the jspc complier from there. i.e.: ... I have to duplicate that in code. That's why 1.4.5 works. The release is under vote. So far no -1s. I think I will be able to release it today as the 72 hours is up. I'll let this list know when I have released it. Jeff
Re: [VOTE] 1.1.1-rc1 for Release
Alan, I thought you fixed this in 1.1.1? Thanks, Aaron On 8/31/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Hi Matt, Sorry to say but I'm experiencing similar problems with trying to deploy a derby embedded datasource; I attached this stack trace to the JIRA that Jay filed (thanks Jay!) http://issues.apache.org/jira/browse/GERONIMO-2368 Geronimo Application Server started 09:19:47,792 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec. (URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission. (WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermissi on(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext $SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke (GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke (AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol $Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket (PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt (LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool $ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) On Aug 31, 2006, at 8:22 AM, Jay D. McHugh wrote: > Matt Hogstrom wrote: >> CTS is complete and here is the RC1 for your reviewing pleasure. >> Please send your comments to the dev@geronimo.apache.org list. >> >> If there are no negative comments after Monday, September 5th at >> 0900 ET. We'll move this to be the final and release it. >> >> If there are issues, they will be addressed and another e-mail >> will be issued resetting for an rc2 vote. >> >> Thanks. >> >> *Source* >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1- >> src.tar.gz >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1- >> src.zip >> >> *Specifications* >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-j2ee- >> jacc_1.0_spec-1.1.1.jar >> >> *Schemas* >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema- >> j2ee_1.4-1.0-src.jar >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema- >> j2ee_1.4-1.0.jar >> >> *Distributions* >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- >> j2ee-1.1.1-rc1.tar.gz >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- >> j2ee-1.1.1-rc1.zip >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- >> minimal-1.1.1-rc1.tar.gz >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- >> minimal-1.1.1-rc1.zip >> >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- >> j2ee-1.1.1-rc1.tar.gz >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- >> j2ee-1.1.1-rc1.zip >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- >> minimal-1.1.1-rc1.tar.gz >> http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- >> minimal-1.1.1-rc1.zip >> >> If you want to build you will need these jars also (will be >> released simultaneously with Geronimo) and these need to be placed >> in your local Maven repository. >> >> *OpenEJB Jars* >> http://people.apache.org/~hogstrom/1.1.1-rc1/openejb- >> builder-2.1.1.jar >> http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-core-2.1.1.jar >> http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-pkgen- >> builder-2.1.1.jar >> >> >> . >> > Hello, > > I tried to install the MySQL JDBC driver (installation worked) and > define my datasource. > > Trying to create the datasource using the wizard locked up the > browser and resulted in the following log file (I tried twice - > that is why the error appears two times): > > Copying into repository mysql-connector-java-3.1.13/mysql-connector- > java-3.1.13/bin/jar... Finished. > 08:41:52,551 ERROR [CoyoteAdapter] An exception or error occurred > in the container during the request processing > java.lang.IllegalArgumentException: Qualifier patterns must be > present when first URLPattern is an exact pattern >
