[jira] Updated: (GERONIMO-2512) gcache client api's
[ http://issues.apache.org/jira/browse/GERONIMO-2512?page=all ] Bill Dudney updated GERONIMO-2512: -- Attachment: GERONIMO-2512-bdudney.patch could not attach the file last night - not sure whey gcache client api's --- Key: GERONIMO-2512 URL: http://issues.apache.org/jira/browse/GERONIMO-2512 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Attachments: GERONIMO-2512-bdudney.patch apply from the gcache root I had to add the mina version (1.0.0) to the server pom And I updated a comment in the server code in light of pending changes for config work -- 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-2457) javadoc additions and a few code changes for gcache
javadoc additions and a few code changes for gcache --- Key: GERONIMO-2457 URL: http://issues.apache.org/jira/browse/GERONIMO-2457 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Reporter: Bill Dudney -- 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-2457) javadoc additions and a few code changes for gcache
[ http://issues.apache.org/jira/browse/GERONIMO-2457?page=all ] Bill Dudney updated GERONIMO-2457: -- Attachment: GERONIMO-2457-bdudney.patch apply from the gcache root javadoc additions and a few code changes for gcache --- Key: GERONIMO-2457 URL: http://issues.apache.org/jira/browse/GERONIMO-2457 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Reporter: Bill Dudney Attachments: GERONIMO-2457-bdudney.patch -- 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-2418) gcache improvements to the nio impl
gcache improvements to the nio impl --- Key: GERONIMO-2418 URL: http://issues.apache.org/jira/browse/GERONIMO-2418 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Bill Dudney Attachments: GERONIMO-2418-bdudney.patch this adds a first cut reading command objects from the socket checksums are not implemnted yet a first cut at the marshaling is done and there is a test for that -- 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-2418) gcache improvements to the nio impl
[ http://issues.apache.org/jira/browse/GERONIMO-2418?page=all ] Bill Dudney updated GERONIMO-2418: -- Attachment: GERONIMO-2418-bdudney.patch apply from server directory gcache improvements to the nio impl --- Key: GERONIMO-2418 URL: http://issues.apache.org/jira/browse/GERONIMO-2418 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Attachments: GERONIMO-2418-bdudney.patch this adds a first cut reading command objects from the socket checksums are not implemnted yet a first cut at the marshaling is done and there is a test for that -- 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: Goals for 1.2 - Thoughts
Hey Matt, I'm all for this, we can do 1.1.2 if need be to fix outstanding bugs etc but leave the 1.1.x branch to be our 1.4 certified releases and trunk/1.2 can move towards the JEE 5 mark (which might be boiling the ocean :-) TTFN, -bd- On Sep 19, 2006, at 11:56 AM, Matt Hogstrom wrote: All, I'm not sure I've seen this question asked directly so if I'm repeating please forgive me. What if we focus 1.2 not on a release (certified release) but go to milestones, switch to J2SE 1.5 and focus on JEE 5. This means that we make 1.1.1 our last 1.4 certified release. I'd prefer this as we can focus on the next big goal and not try to boil the ocean. Sacrilege ? Matt Hogstrom [EMAIL PROTECTED]
Re: openwire dependency for GERONIMO-2410
Cool, Not sure where that came from but now that its gone its all good. TTFN, -bd- On Sep 17, 2006, at 6:47 AM, Jeff Genender wrote: Ahh...never mind. I removed it and there are no dependencies ;-) Jeff Jeff Genender wrote: Hey Bill, I noticed that the pom in openwire now includes a dependency to gcache-server. I think we want it the other way around. We want gcache-server to depend on openwire. Can we remove this dependency? Jeff
[jira] Created: (GERONIMO-2412) add testng to gcache
add testng to gcache Key: GERONIMO-2412 URL: http://issues.apache.org/jira/browse/GERONIMO-2412 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Bill Dudney Assigned To: Bill Dudney Attachments: GERONIMO-2412-bdudney.patch several changes including the addition of testng tests -- 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-2412) add testng to gcache
[ http://issues.apache.org/jira/browse/GERONIMO-2412?page=all ] Bill Dudney updated GERONIMO-2412: -- Attachment: GERONIMO-2412-bdudney.patch apply at root of gcache add testng to gcache Key: GERONIMO-2412 URL: http://issues.apache.org/jira/browse/GERONIMO-2412 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Assigned To: Bill Dudney Attachments: GERONIMO-2412-bdudney.patch several changes including the addition of testng tests -- 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-2410) add discovery api to the openwire module for gcache
add discovery api to the openwire module for gcache --- Key: GERONIMO-2410 URL: http://issues.apache.org/jira/browse/GERONIMO-2410 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Bill Dudney patch adds the discovery api to the openwire module apply the patch from the openwire module directory -- 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-2410) add discovery api to the openwire module for gcache
[ http://issues.apache.org/jira/browse/GERONIMO-2410?page=all ] Bill Dudney updated GERONIMO-2410: -- Attachment: GERONIMO-2410-bdudney.patch sorry jeff, i hit submit and went to bed, it never got attached... add discovery api to the openwire module for gcache --- Key: GERONIMO-2410 URL: http://issues.apache.org/jira/browse/GERONIMO-2410 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Bill Dudney Attachments: GERONIMO-2410-bdudney.patch patch adds the discovery api to the openwire module apply the patch from the openwire module directory -- 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-2407) openwire impl in gcache won't compile
openwire impl in gcache won't compile - Key: GERONIMO-2407 URL: http://issues.apache.org/jira/browse/GERONIMO-2407 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Bill Dudney Attachments: openwire.patch patch provides 3 things; 1) orgainze imports 2) format code to 'standard' format (no tabs etc) 3) adds standard header -- 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-2407) openwire impl in gcache won't compile
[ http://issues.apache.org/jira/browse/GERONIMO-2407?page=all ] Bill Dudney updated GERONIMO-2407: -- Attachment: openwire.patch rather large patch openwire impl in gcache won't compile - Key: GERONIMO-2407 URL: http://issues.apache.org/jira/browse/GERONIMO-2407 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Bill Dudney Attachments: openwire.patch patch provides 3 things; 1) orgainze imports 2) format code to 'standard' format (no tabs etc) 3) adds standard header -- 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-2407) openwire impl in gcache won't compile
[ http://issues.apache.org/jira/browse/GERONIMO-2407?page=comments#action_12434904 ] Bill Dudney commented on GERONIMO-2407: --- forgot to mention that this patch also makes it so the code will compile there are a couple of new classes interface I implemnted specifically I added NodeInfo and NodeId classs and changed everything that said BrokerId or BrokerInfo to NodeId and NodeInfo respectively. Need input on that... Also moved the wire format negotioation stuff into the interface - need input Made the TCPTransportServer use the ObjectStreamWireFormatFactory instead of the openwire. openwire impl in gcache won't compile - Key: GERONIMO-2407 URL: http://issues.apache.org/jira/browse/GERONIMO-2407 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Bill Dudney Attachments: openwire.patch patch provides 3 things; 1) orgainze imports 2) format code to 'standard' format (no tabs etc) 3) adds standard header -- 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-2407) openwire impl in gcache won't compile
[ http://issues.apache.org/jira/browse/GERONIMO-2407?page=comments#action_12434992 ] Bill Dudney commented on GERONIMO-2407: --- hey jeff, sorry for the hunk failures, looks like svn diff is getting confused by the way I redid the comments (I tried to apply to a fresh check out and got the several failures). I am cooking a new patch now (essentially backing out anything that was not related to the compile problems) openwire impl in gcache won't compile - Key: GERONIMO-2407 URL: http://issues.apache.org/jira/browse/GERONIMO-2407 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Bill Dudney Attachments: openwire.patch patch provides 3 things; 1) orgainze imports 2) format code to 'standard' format (no tabs etc) 3) adds standard header -- 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-2407) openwire impl in gcache won't compile
[ http://issues.apache.org/jira/browse/GERONIMO-2407?page=all ] Bill Dudney updated GERONIMO-2407: -- Attachment: GERONIMO-2407-bdudney.patch droped the formatting and consistent leagal stuff openwire impl in gcache won't compile - Key: GERONIMO-2407 URL: http://issues.apache.org/jira/browse/GERONIMO-2407 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Bill Dudney Attachments: GERONIMO-2407-bdudney.patch, openwire.patch patch provides 3 things; 1) orgainze imports 2) format code to 'standard' format (no tabs etc) 3) adds standard header -- 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-2375) console has invalid XHTML in the db bool
[ http://issues.apache.org/jira/browse/GERONIMO-2375?page=all ] Bill Dudney updated GERONIMO-2375: -- Attachment: GERONIMO-2375-bdudney-v2.patch GERONIMO-2375-bdudney-v2.patch use this patch instead of the previous on - still not 100% but getting closer... console has invalid XHTML in the db bool Key: GERONIMO-2375 URL: http://issues.apache.org/jira/browse/GERONIMO-2375 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Attachments: GERONIMO-2375-bdudney-v2.patch, GERONIMO-2375.bdudney.patch the invalid XHTML prevevents automated tests from deploying a db pool -- 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-2385) server does not update any state when persistent configuration is loaded and ready to serve applications
[ http://issues.apache.org/jira/browse/GERONIMO-2385?page=all ] Bill Dudney reassigned GERONIMO-2385: - Assignee: Bill Dudney server does not update any state when persistent configuration is loaded and ready to serve applications Key: GERONIMO-2385 URL: http://issues.apache.org/jira/browse/GERONIMO-2385 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Bill Dudney Attachments: GERONIMO-2385.bdudney.patch see this thread http://www.nabble.com/When-has-the-server-started--tf2205476.html for reference -- 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-2344) Tomcat Console can't find TomcatManagerImpl class during display of ServerLogs
[ http://issues.apache.org/jira/browse/GERONIMO-2344?page=all ] Bill Dudney reassigned GERONIMO-2344: - Assignee: Bill Dudney Tomcat Console can't find TomcatManagerImpl class during display of ServerLogs -- Key: GERONIMO-2344 URL: http://issues.apache.org/jira/browse/GERONIMO-2344 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Bill Dudney Attachments: GERONIMO-2344.bdudney-2.patch, GERONIMO-2344.bdudney.patch Console classpath problems prevent the class from being found. Here are the error messages; 10:12:39,240 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatManagerImpl in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebManager 10:12:39,298 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 10:12:39,305 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatContainer in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer The patch simply removes the scopeprovided/scope from the tomcat-deployer dependency. -- 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-2375) console has invalid XHTML in the db bool
[ http://issues.apache.org/jira/browse/GERONIMO-2375?page=all ] Bill Dudney reassigned GERONIMO-2375: - Assignee: Bill Dudney console has invalid XHTML in the db bool Key: GERONIMO-2375 URL: http://issues.apache.org/jira/browse/GERONIMO-2375 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Assigned To: Bill Dudney Attachments: GERONIMO-2375-bdudney-v2.patch, GERONIMO-2375.bdudney.patch the invalid XHTML prevevents automated tests from deploying a db pool -- 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 Yoo-Hoo Wake Up Please and Review the Wadi Integration Patch
Hi Gianny, I applied the patch and got a few simple to fix hunks failing. Got them fixed and it built until the failure to find the wadi-group artifact. Any chance that could get uploaded so I can be lazy and not build it myself? If I understand things correctly geronimo-clustering is an alternative to the geronimo-session module we had/have in the 1.2- dead branch. Am I correct? Just trying to make sure I understand things correctly. And one last thing, I to would like to see some more docs at least in the geronimo-clustering module. Thanks! -bd- On Sep 13, 2006, at 9:34 AM, Gianny Damour wrote: Many thanks David for this wake-up call :) I do agree: the NamespaceDrivenBuilder change is a great improvement. If I am entitled to vote for this patch, even if I am one of the reporters, then we now have 3 +1. Having said that, I would appreciate if Greg could have a quick scan prior to commit. Thanks, Gianny On 13/09/2006, at 1:59 AM, David Jencks wrote: I'd like to thank the PMC members who promptly reviewed my jta 1.1 and jndi refactoring patches and point them to an at least equally deserving patch that has been quietly mouldering for lack of attention http://issues.apache.org/jira/browse/GERONIMO-2163 Aside from - Integrating WADI in an architecturally appropriate way (finally!) - Providing a clustering api as a basis for discussion and further development this also now includes a big improvement to the NamespaceDrivenBuilder interface that lets these builders add stuff to the environment. We should be able to leverage this to e.g. only include axis when you are actually using a web service and/or switch webservices implementations. thanks david jencks
Re: java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode
Hi Anita, This is almost certianly from not cleaning everything out before doing a build. You have to nuke all the m2 repo bits related to geronimo and openejb 2 to get rid of all the old code that was using the EDU.oswego classes as well as mvn clean everything (i.e. a bootstrap :-) HTH, -bd- On Sep 14, 2006, at 10:06 AM, anita kulshreshtha wrote: I am seeing this error on trunk (rev 443034) during shutdown: 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerService$2$1 at org.apache.activemq.broker.BrokerService$2.stop(BrokerService.java: 1137) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:442) at org.apache.activemq.broker.BrokerService.containerShutdown (BrokerService.java:1311) at org.apache.activemq.broker.BrokerService$3.run(BrokerService.java: 1288) java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode at EDU.oswego.cs.dl.util.concurrent.SynchronousChannel.poll(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) Server shutdown completed Thnaks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Make bootstrap less aggressive?
Hi Aaron, Try bootstrap -Dclean-minimal=true for only nuking the pertinent stuff. HTH, -bd- On Sep 14, 2006, at 10:21 AM, Aaron Mulder wrote: Would it hurt to adjust bootstrap to whack only the Geronimo-related content from the M2 repo? Or perhaps only the SNAPSHOT artifacts? I resist using it only because I have a lot of non-Geronimo content in my local repo that I hate to lose every time. I used to be happy to do the m:cleanrepo target that only killed the pertinent stuff, though. Thanks, Aaron On 9/14/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Anita, This is almost certianly from not cleaning everything out before doing a build. You have to nuke all the m2 repo bits related to geronimo and openejb 2 to get rid of all the old code that was using the EDU.oswego classes as well as mvn clean everything (i.e. a bootstrap :-) HTH, -bd- On Sep 14, 2006, at 10:06 AM, anita kulshreshtha wrote: I am seeing this error on trunk (rev 443034) during shutdown: 11:42:10,359 INFO [TransportConnector] Connector tcp:// 0.0.0.0:61616 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector tcp:// 0.0.0.0:61616 Stopped java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerService$2$1 at org.apache.activemq.broker.BrokerService$2.stop(BrokerService.java: 1137) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java: 42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java: 442) at org.apache.activemq.broker.BrokerService.containerShutdown (BrokerService.java:1311) at org.apache.activemq.broker.BrokerService$3.run(BrokerService.java: 1288) java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode at EDU.oswego.cs.dl.util.concurrent.SynchronousChannel.poll(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) Server shutdown completed Thnaks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
j2se 5 - build successful
Hi All, After running into the jdk 1.5 building problem a couple of days ago and posting about it ; http://www.nabble.com/fail-bootstrap-early-with-wrong-jdk-tf2265472.html I decided to dig into how far away we are from being able to build with J2SE 5. So I set out to give it a shot. And to my amazement everything just worked :-). Of course 'everthing' does not include the bits that rely on the Sun ORB but the server fired up and I was able to poke around in the console. Anyway here is what I did to get everything building with JDK 1.5; 1) checkout a fresh copy of a) https://svn.apache.org/repos/asf/geronimo/server/trunk b) https://svn.apache.org/repos/asf/geronimo/genesis/trunk c) https://svn.apache.org/repos/asf/geronimo/specs/trunk 2) delete all the geronimo stuff from my local m2 repo (rm -rf ~/.m2/ repository/org/apache/geronimo) 3) set my jdk to 1.5 4) build a) genesis b) specs c) remove the check for jdk 1.4 (patch attached) build geronimo 5) start the server under 1.5 6) poke around - of course anything requiring the ORB will not work but the other stuff I tried worked, I poked around a bit with jconsole and the stuff running all looked 'normal' to me. Thoughts? TTFN, -bd- no-1.4check.patch Description: Binary data
Re: Pre-RTC look at the openejb/geronimo yoko support and request for input [long].
This is great news! Feels like we are getting very close to being able to move to J2SE 5 and Java EE 5! 1) Leave the Sun ORB code in the tree, make the yoko package a separate module that with a dependency on the openejb2 code. The existing build works ok, and the tests can be built for the Sun ORB. The build of the yoko package could then have its own versions of the tests, which would work find. 2) Replace the Sun ORB code with the yoko code and kick the Sun code into a separate module. Same things apply with the test. 3) Place both ORB adapters in outside modules, each with their own builds and tests. I prefer option 3 if I understand you correctly with this we can have an assembly that is intended to run on Sun JDK and one intended to run on Sun or anywhere else. On Issue #3 is it just a build problem? From the sound of it the code won't run if the Sun ORB code is in the bootstrap class path (as it would be on the Sun 1.4 JDK). If we go with option #3 above and completely remove our dependence on the Sun ORB then we could run just fine on the 1.4 JDK correct? If that is the case then I think dropping the Sun ORB ASAP (getting past the TCK etc.) is the way to go. I was also just looking at 2180 and noticed that the yoko dependencies are in maven, is it safe to pull them from there instead of using the attached zip file? I'm applying the patch now to play around with this, thanks again! TTFN, -bd- On Sep 14, 2006, at 12:56 PM, David Jencks wrote: Great work!!! On Sep 14, 2006, at 12:16 PM, Rick McGuire wrote: I've just attached patches for issue http://issues.apache.org/jira/ browse/GERONIMO-2180, which is to add Yoko support to Geronimo. This is really patches for this issue plus 2 other issues that are highly related: http://issues.apache.org/jira/browse/GERONIMO-2002 OPENEBJ CORBA SSL should use Keystore GBean http://issues.apache.org/jira/browse/GERONIMO-2353 Reduce the number of places where CORBA config parameters are specified. This should also be the first step toward achieving this goal: http://issues.apache.org/jira/browse/GERONIMO-433 Tolerate non- Sun JREs And should also be a step toward allowing full support of Java 5. This code works as far as being able to start and stop the j2ee- corba system module. Fuller testing is going to require getting the MagicGBall app working and then see how this works with TCK testing. There are some issues with doing either of those steps at the moment, but I decided this is a good point to show people I've done, since it will be easier to ask questions about it. Let me give the basics of what I've done, and I have a few areas I'd like community input on how I should proceed from here. The bulk of the changes are really around GERONIMO-2353. While trying to fit the Yoko ORB into this structure, I found a number of pain points: 1. The org.openejb.corba.SunNameService GBean only supported the Sun ORB, and was not generally configurable like CORBABean or CSSBean were. 2. The CORBABean and CSSBean configuration included args and props items which were passed directly through to an ORB.init() call. These attributes were used to configure things like the initial listener port, the host server name, and the initial NameServer location. In a few cases, the values set were not portable between ORB implementations, which made it more difficult to switch between ORBs. 3. The CSSBean and CORBABean declarations needed to be coded with a dependency on SystemProperties. The SystemProperties object was initializing various system properties that were needed by the ORB, and also enabled the RMI support. These properties were generally not portable between ORB implementations, since they included references to Sun specific classes. To clean this up, I reworked the ConfigAdapter interface used in the current code base. This interface now has 3 basic operations 1) create a name service, 2) create a server ORB, and 3) create a client ORB. The existing code is just configured with a ConfigAdapter class name and the CORBABean/CSSBean services instantiated an instance of the class. Now the ConfigAdapters are GBean instances, and the doStart() methods of these GBeans are encapsulate the responsibility for setting the RMI system properties. SunNameService has been replaced by a generic NameService GBean, and NameService, CORBABean, and CSSBean all take a ConfigAdapter instance in their constructors. Now, from a plan standpoint, it's possible to switch between ORBs by changing a single line in the plan. All of this work is really independent of the Yoko-specific changes, but did make it easier to write the Yoko code. This sounds great! Which brings me to ISSUE #1: I added a NameService argument to the CORBABean constructor. The ConfigAdapter would
Re: We might need aliased modules/configurations/artifactIds
This sounds a lot like OSGi. Felix might be a bit young but it seems like a big part of this functionality is covered there. Thoughts? -bd- On Sep 14, 2006, at 1:32 PM, Aaron Mulder wrote: I sure wouldn't mind if a module could say I provide javax.foo.Bar and a separate module could say I require a parent that provides javax.foo.Bar... As in, interface dependencies instead of name-based dependencies. Thanks, Aaron On 9/14/06, David Jencks [EMAIL PROTECTED] wrote: I started working on a version of geronimo that uses the jta11 transaction manager in the sandbox. So, I wrote a new transaction configuration using the new gbean and started trying to assemble a server. My new config has gbeans with exactly the same names (except for artifactId) as the old jta 1.0.1B configuration (present in GERONIMO-2398, please vote). Now it turns out that in order to swap these configs I am going to need to change almost all the other configs so they depend on my new one instead of the old one. This highlights a need for more functional-based dependencies. Conceptually we kind of want to say, this module depends on a module supplying services A, B, C One idea I had that might be pretty easy to implement would be to expand the explicit-versions resolving code a bit so that you can supply a properties file that says replace requests for artifactId X with artifactId Y and plug it in the the artifact resolver, configuration, and kernel so that when you ask for a gbean with artifactId X you get one with the same name map and interfaces but with artifactId Y. I think of this as aliasing X as Y (or maybe its vice-versa). I'm starting to try to implement this since I'm kind of blocked without something like this... but this might not be the best possible solution or even the easiest. Anyone want to comment or suggest better ideas? thanks david jencks
[jira] Created: (AMQ-925) unix src download labled with 'Source for Windows'
unix src download labled with 'Source for Windows' --- Key: AMQ-925 URL: https://issues.apache.org/activemq/browse/AMQ-925 Project: ActiveMQ Issue Type: Improvement Reporter: Bill Dudney Priority: Trivial http://incubator.apache.org/activemq/activemq-401-release.html right hand column Binary for Window Source code for Windows Binary for Unix Source code for Windows final row should say Source code for Unix -- 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: gcache imlementation ideas[long]
Hey Jeff, Good to see this stuff gaining some traction! If I could try to summarize to make sure I've got what you are saying. The intent is to rework the communication back end that ehcache is using to make it something more performant than the existing RMI impl and use the existing ehcache master-slave concept in order to keep it simple. Then we will create a thin veneer over ehcache for now and perhaps or perhaps not replace ehcache with potentially different topologies in the future but just to keep the initial impl simple we go with master- slave. Am I following you correctly here? I'm excited to get started on this, sorry i've been so late to the party, been trying to get all the other loose ends I've been doing tied up. TTFN, -bd On Sep 12, 2006, at 10:19 AM, Jeff Genender wrote: I wanted to go over a high level design on a gcache cache component and get some feedback, input and invite folks who are interested to join in. ..so here it goes... The gcache will be one of several cache/clustering offerings...but starting off with the first one... The first pass I want to go with the master/slave full replication implementation. What this means is a centralized caching server which runs a cache implementation (likely will use ehcache underneath), and this server is known as a master. My interest in ehcache is it provides the ability to persist session state from a configuration if full failure recovery is needed (no need to reinvent the wheel on a great cache). The master will communicate with N number of slave servers, also running a gcache implementation. ++ +-+ +-+ || | | | | | MASTER | | SLAVE 1 | | SLAVE 2 | ... n-slaves || | | | | ++ +-+ +-+ | || | | || | | || | || || We then have client component(s) that plugs in and communicates with the server. The configuration for the client should be very light where it will only really be concerned with the master/slave/slave/nth- slave. In other words, it communicates only with the master. The master is responsible for pushing anything it receives to its slaves and other nodes in the cluster. The slaves basically look like clients to the master. ++ +-+ +-+ || | | | | | MASTER |---| SLAVE 1 | | SLAVE 2 | || | | | | ++ +-+ +-+ | | | | +---+ | ,---. ( CLIENT ) `---' In the event the master goes down, the client notes the timeout and then automatically communicates with slave #1 as the new master. Since slave #1 is also a client of the MASTER, it can determine either by itself, or by the first request that comes in asking for data, that it is the new master. ++ +-+ +-+ | OLD | |NEW MSTER| | | | MASTER | | WAS |--| SLAVE 2 | || | SLAVE 1 | | | ++ +-+ +-+ | _,' X ,' | ,-' ,---.' ( CLIENT ) `---' I think this is a fairly simple implementation, yet fairly robust. Since we are not doing the heart beat and mcast, we cut down on a lot of network traffic. Communication will be done by TCPIP sockets and would probably like to use NIO. I would like to see this component be able to run on its own...i.e. no Geronimo needed. We can build a Geronimo gbean and deployer around it, but I would like to see this component usable in many other areas, including outside of Geronimo. Open source needs more free clustering implementations. I would like this component to be broken down into 2 major categories...server and client. After a successful implementation of master/slave, I would like to make pluggable strategies, so we can provide for more of a distributed cache, partitioning, and other types of joins, such as mcast/heart beat for those who want it. Thoughts and additional ideas? Thanks, Jeff
[jira] Created: (GERONIMO-2403) make bootstrap fail early if the wrong jdk is in use
make bootstrap fail early if the wrong jdk is in use Key: GERONIMO-2403 URL: http://issues.apache.org/jira/browse/GERONIMO-2403 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Bill Dudney fail in bootsratp early if wrong jdk to avoid wasted time -- 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
fail bootstrap early with wrong jdk
I think we should fail the bootstrap early if using jdk 1.5 as well as failing the maven build. http://issues.apache.org/jira/browse/GERONIMO-2403 has a patch attached that works, but there might be a way to reuse the mojo that Jason wrote, not sure... Thanks, -bd-
[jira] Updated: (GERONIMO-2403) make bootstrap fail early if the wrong jdk is in use
[ http://issues.apache.org/jira/browse/GERONIMO-2403?page=all ] Bill Dudney updated GERONIMO-2403: -- Attachment: GERONIMO-2403-bdudney.patch make bootstrap fail early if the wrong jdk is in use Key: GERONIMO-2403 URL: http://issues.apache.org/jira/browse/GERONIMO-2403 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Bill Dudney Attachments: GERONIMO-2403-bdudney.patch fail in bootsratp early if wrong jdk to avoid wasted time -- 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: ApacheCon Attendance
I'll be there wed to fri -bd- On Sep 13, 2006, at 3:31 PM, Matt Hogstrom wrote: Who is planning on being at ApacheCon in Austin? Matt Hogstrom [EMAIL PROTECTED]
Re: magicGBall app plans
Hi All, We do have a place to put integration test deployables now; http://svn.apache.org/repos/asf/geronimo/server/trunk/testsupport Lets move magicGBall there and it would be great if you were to put the mini-apps you are doing there too then the other module can use them as dependencies. There is an example of how to convince maven to do that in the http://svn.apache.org/repos/asf/geronimo/server/trunk/modules/ geronimo-j2ee-builder/ pom.xml file for reference in case you need/want it. TTFN, -bd- On Sep 11, 2006, at 4:29 PM, David Jencks wrote: On Sep 11, 2006, at 7:59 AM, Rick McGuire wrote: I'm trying to use the MagicGBall sample app running to test the Yoko CORBA support, and I'm a bit confused by what I'm seeing in the trunk source tree. In the 1.1.1 tree, the magicGBall sample was a single module, and it also included a pair of plan files in the source tree for deploying this app with or without transport- level security. In the 1.2 tree, the m2 build has split this into 4 modules, and the plan files don't seem to exist any more. Are the missing plan files just an omission from the restructure, or has some other mechanism replaced these plans? I doubt it very much. I think the plans were removed by mistake. There's no good place to put them, but they should be in svn IMNSHO. Other samples (e.g. the welcome app) seem to have plans that have gone missing in action. Other apps have their plans in the configs dir, but the magicGBall is really sort of an integration test, and we haven't figured out where to put those yet. I have a bunch of other mini-apps to show something works that I've been attaching to jira issues. Anyone (prasad :-) have any ideas? thanks david jencks Rick
Re: console deployer dependencies
Hi Anita,
Any luck? Any further thoughts? I'm happy to help in anyway I can to
get this resolved.
Thanks,
-bd-
On Sep 6, 2006, at 8:31 PM, anita kulshreshtha wrote:
inline..
--- Bill Dudney [EMAIL PROTECTED] wrote:
Hi Anita,
initial patch? The patch I posted had a single deleted line from each
pom.
If it does not break anything else, I am OK with it. You should
delete o/a/g/configs directory in .m2 repo, and build all the configs.
Just trying to understand the question.
On the j2ee-deployer being added; That was a result of other issues
with dependencies being missed. Starting with (I believe)
http://issues.apache.org/jira/browse/GERONIMO-2326
Thanks for the info. It is indeed a lot.. I will get back to you.
Thanks
Anita
There were many many problems solved by adding that parent config
without causing other issues. I believe the whole conversation took
place in that JIRA so hopefully there is enough info there to inform
you.
As to the #2 issue/question I'm not sure, but from my current vantage
point with more experience of car stacking perhaps getting the
tomcat-
deployer config correct would fix both 2326 this issue.
Thanks,
-bd-
On Sep 6, 2006, at 9:58 AM, anita kulshreshtha wrote:
Bill,
The webconsole-tomcat config differs from the original patch. To
answer your question correctly, I need to understand why:
1. The j2ee-deployer config was added as a parent configuration.
2. The tomcat-deployer config was changed so that tomcat config is
not
a parent of tomcat-deployer config.
I am searching the archives/jiras. I need to do some testing..
Thanks
Anita
--- Bill Dudney [EMAIL PROTECTED] wrote:
Anita,
While the jar's are not required in the class loader, without them
the warning messages are printed.
Do you have ideas about how to get rid of the warning messages and
keep the 'provided' scope?
I think I prefer pushing all the methods into the 'super
interface'
and having an UnsupportedOperationException as long as there are
good
error messages as to what has happened (i.e. 'a method was invoked
on
the Jetty container that is not supported, perhaps you wanted to
use
Tomcat instead?' or something less cheesy).
Anyway I'm not sure of the best way to handle this but I don't
like
the warning messages. I think they would look ominous to initial
users then over time users would stop worrying about warning
messages. Which is bad IMO.
TTFN,
-bd-
On Sep 5, 2006, at 8:23 AM, anita kulshreshtha wrote:
I'm not sure what the point is of listing it as provided, if
that's
what we're currently doing. I'm pretty sure it's not provided
so
we
might as well either not list it or list it as a regular
dependency.
The scope=provided is used to enforce the build order for
the
configs, i.e the console configs are not built before the
jetty/tomcat
deployer configs are built in a multi config build. These cars
are
not
required in the classloader.
Thanks
Anita
On 9/4/06, Bill Dudney [EMAIL PROTECTED] wrote:
Hi All,
The consoles (tomcat jetty) are spewing warning messages
like
this;
08:00:18,511 WARN [BasicProxyManager] Could not load
interface
org.apache.geronimo.jetty.JettyWebAppContext in provided
ClassLoader
for
org.apache.geronimo.configs/welcome-jetty/1.2-SNAPSHOT/car?
J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.conf
igs
/welcome-jetty/1.2-SNAPSHOT/car
To fix it we can simply remove the scopeprovided/scope
from
the
artifactId{jetty,tomcat}-deployer/artifactId dependencies
in
the
webconsole-{jetty,tomcat}/pom.xml.
Could someone who knows more about the console than me please
review
the patch (GERONIMO-2344.bdudney-2.patch) here;
http://issues.apache.org/jira/browse/GERONIMO-2344
And apply it if it makes sense?
Thanks!
-bd-
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: [VOTE] Geronimo Development Process
Hi Ken, General question: Why is it bad to hold a discussion in a JIRA since the whole of the discussion is archived in the issues mailing list. Seems like the JIRA is the ideal place to hold the discussion because its archived and organized for all to follow. If the JIRA magically or mysteriously disappears then we still have the issues mailing list log to look to. If we hold the discussion about a JIRA in the mail list it seems to me we'd have two places to look at to understand the JIRA, and that IMO is bad. TTFN, -bd- On Sep 12, 2006, at 8:56 AM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevan Miller wrote: 1. Relaxed RTC Geronimo follows a Review-Then-Commit (RTC) model. Patches for new function are provided by developers for review and comment by their peers. Feedback is conducted through JIRA comments. - -1 on that last sentence. You don't hold discussions in JIRA.. * Any -1 votes need to be accompanied by a reason (the parties should then attempt to reach a mutually agreed upon solution to the issue raised). - -1 on the parenthetical clause. It would be nice, but 'should' is too strong I think. That's calling for someone who vetoed a change for technical reasons to help resolve his own veto whether he likes the change or not. * If the issues can't be resolved then the PMC can be called upon to settle the dispute and make a recommendation. - -1. A veto is a veto. The above implies that the PMC can override a valid veto. It cannot. 2. RTC with Lazy Consensus Geronimo follows a Review-Then-Commit model with Lazy consensus. Patches for new function are provided by developers for review and comment by their peers. Feedback is conducted through JIRA comments. - -1 on the JIRA means again. 3. CTR with documentation guidelines * Concurrent with the commit of a significant change, the committer should document the change on the dev list. You should describe what you are doing, describe why you are doing it, and provide an overview of how you implemented it. It's useful for historical reasons for most of that to be in the commit log. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRQbKoprNPMCpn3XdAQJ+sQP/f2qsSKuQG3fv3YbD+x0n86J1FTU3g6Ej sIX24W+VreozwE/fya+nz0vD4QI3+J2QRPUUA0IAbtVQAF7NhQ1FCrtYh8T168e4 /XGgC+hd27xL3WA7eJT4b+SKCVaXjQRQnSbXMxSe0OnUj1RXumURYWOKw6+gIvhO qTKykt6U02U= =rwwV -END PGP SIGNATURE-
Re: console deployer dependencies
Hi Anita,
This patch should not effect the datasource stuff at all, you can see
the effect from the 'Server Logs' or any number of the console 'main
functions' in the menu on the left. The error in your log file looks
to me like a mysql server problem (reboot the server or something I'd
say) and has nothing to do with the console.
TTFN,
-bd-
On Sep 12, 2006, at 7:56 AM, anita kulshreshtha wrote:
Nop.. I tried deploying MYSQL DBPool using the wizard. The
deployment was successful, but I got a stack trace. There was a stack
trace during shutdown (see the attached log). So I decided to get the
latest source. I have been getting openejb (rev 2897) compile failures
due to:
http://issues.apache.org/jira/browse/GERONIMO-2354
I will give it a try again later today.
Did everything deploy cleanly for you?
Thanks
Anita
--- Bill Dudney [EMAIL PROTECTED] wrote:
Hi Anita,
Any luck? Any further thoughts? I'm happy to help in anyway I can to
get this resolved.
Thanks,
-bd-
On Sep 6, 2006, at 8:31 PM, anita kulshreshtha wrote:
inline..
--- Bill Dudney [EMAIL PROTECTED] wrote:
Hi Anita,
initial patch? The patch I posted had a single deleted line from
each
pom.
If it does not break anything else, I am OK with it. You should
delete o/a/g/configs directory in .m2 repo, and build all the
configs.
Just trying to understand the question.
On the j2ee-deployer being added; That was a result of other
issues
with dependencies being missed. Starting with (I believe)
http://issues.apache.org/jira/browse/GERONIMO-2326
Thanks for the info. It is indeed a lot.. I will get back to
you.
Thanks
Anita
There were many many problems solved by adding that parent config
without causing other issues. I believe the whole conversation
took
place in that JIRA so hopefully there is enough info there to
inform
you.
As to the #2 issue/question I'm not sure, but from my current
vantage
point with more experience of car stacking perhaps getting the
tomcat-
deployer config correct would fix both 2326 this issue.
Thanks,
-bd-
On Sep 6, 2006, at 9:58 AM, anita kulshreshtha wrote:
Bill,
The webconsole-tomcat config differs from the original patch.
To
answer your question correctly, I need to understand why:
1. The j2ee-deployer config was added as a parent configuration.
2. The tomcat-deployer config was changed so that tomcat config
is
not
a parent of tomcat-deployer config.
I am searching the archives/jiras. I need to do some testing..
Thanks
Anita
--- Bill Dudney [EMAIL PROTECTED] wrote:
Anita,
While the jar's are not required in the class loader, without
them
the warning messages are printed.
Do you have ideas about how to get rid of the warning messages
and
keep the 'provided' scope?
I think I prefer pushing all the methods into the 'super
interface'
and having an UnsupportedOperationException as long as there are
good
error messages as to what has happened (i.e. 'a method was
invoked
on
the Jetty container that is not supported, perhaps you wanted to
use
Tomcat instead?' or something less cheesy).
Anyway I'm not sure of the best way to handle this but I don't
like
the warning messages. I think they would look ominous to initial
users then over time users would stop worrying about warning
messages. Which is bad IMO.
TTFN,
-bd-
On Sep 5, 2006, at 8:23 AM, anita kulshreshtha wrote:
I'm not sure what the point is of listing it as provided, if
that's
what we're currently doing. I'm pretty sure it's not
provided
so
we
might as well either not list it or list it as a regular
dependency.
The scope=provided is used to enforce the build order for
the
configs, i.e the console configs are not built before the
jetty/tomcat
deployer configs are built in a multi config build. These cars
are
not
required in the classloader.
Thanks
Anita
On 9/4/06, Bill Dudney [EMAIL PROTECTED] wrote:
Hi All,
The consoles (tomcat jetty) are spewing warning messages
like
this;
08:00:18,511 WARN [BasicProxyManager] Could not load
interface
org.apache.geronimo.jetty.JettyWebAppContext in provided
ClassLoader
for
org.apache.geronimo.configs/welcome-jetty/1.2-SNAPSHOT/car?
J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.conf
igs
/welcome-jetty/1.2-SNAPSHOT/car
To fix it we can simply remove the scopeprovided/scope
from
the
artifactId{jetty,tomcat}-deployer/artifactId
dependencies
in
the
webconsole-{jetty,tomcat}/pom.xml.
Could someone who knows more about the console than me
please
review
the patch (GERONIMO-2344.bdudney-2.patch) here;
http://issues.apache.org/jira/browse/GERONIMO-2344
And apply it if it makes sense?
Thanks!
-bd-
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
Do You Yahoo!?
Tired of spam
[jira] Updated: (GERONIMO-2377) deploying a new datasource with the same name does not indicate any problem in the console
[ http://issues.apache.org/jira/browse/GERONIMO-2377?page=all ] Bill Dudney updated GERONIMO-2377: -- Attachment: GERONIMO-2377.bdudney.patch displays an error instead of just moving on deploying a new datasource with the same name does not indicate any problem in the console -- Key: GERONIMO-2377 URL: http://issues.apache.org/jira/browse/GERONIMO-2377 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Bill Dudney Attachments: GERONIMO-2377.bdudney.patch Console acts as if it deployeed the datasource but the console spits out an error message; Deployer operation failed: Module console.dbpool/DefaultDS/1.0/rar already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module console.dbpool/DefaultDS/1.0/rar already exists in the server. Try to undeploy it first or use the redeploy command. at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:552) -- 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] Geronimo Development Process
[ ] +1 Relaxed RTC [ ] +1 RTC with Lazy Consensus [X ] +1 CTR with documentation guidelines TTFN, -bd-
Re: [VOTE] 1.1.1-rc3 (incorporates all recent comments and issues, you need to vote again)
Hi Matt, I was able to deploy a datasource and the testsupport/1.3 ear file. +1 -bd- On Sep 9, 2006, at 2:58 AM, Matt Hogstrom wrote: I have incorporated the latest feedback on 1.1.1-rc2. Items that were identified as issues included: * 0 length files in the modules/j2ee-schema/src/j2ee*schema directories. I have removed the those directories. The remaining directories are still intact. * Updated the RELEASE-NOTES-1.1.1.txt file to clarify the installation of the console for J2EE certified versions of the server. * Released Open EJB 2.1.1 so it is available online for normal builds. These binaries are not included in this rc3 for that reason. * Changed the Specs and Schema to use -rc3 in their suffix to ensure that the correct files are available. SVN has been updated with this version number for the specs and schema so you can checkout and build for yourself. Otherwise, one can download the appropriate files and place them in their local repository (do not rename these files...use them as is). There have been no other comments on the RC2 thread so I am resetting the vote and will ask for your input for hopefully the last time. This vote will conclude at 0600 ET on Tuesday September 12th. This vote supersedes the previous RC1 and RC2 votes; you need to vote again. Please remember that only PMC votes are binding but we need all feedback we can get to ensure there are no significant unknowns. Here is the list of artifacts: *Schemas* http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-schema- j2ee_1.4-1.0-rc3-src.jar http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-schema- j2ee_1.4-1.0-rc3.jar *Specifications* http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-j2ee- jacc_1.0_spec-1.1.1-rc3.jar *Source* http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-1.1.1-rc3- src.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-1.1.1-rc3- src.zip *Distributions* http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-jetty- j2ee-1.1.1-rc3.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-jetty- j2ee-1.1.1-rc3.zip http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-jetty- minimal-1.1.1-rc3.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-jetty- minimal-1.1.1-rc3.zip http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-tomcat- j2ee-1.1.1-rc3.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-tomcat- j2ee-1.1.1-rc3.zip http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-tomcat- minimal-1.1.1-rc3.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc3/geronimo-tomcat- minimal-1.1.1-rc3.zip Note: These artifacts are uploading at the time I am sending this e- mail. They may not be available for a few hours depending on the upload speed.
lifecycle logging from server
Hi All, With my recent poking around in the startup and shutdown code for https://issues.apache.org/jira/browse/GERONIMO-2385 I figure I might be the guy to fix; http://issues.apache.org/jira/browse/GERONIMO-2387 but I can't assign it to myself. Could some one give me that permission in JIRA (user name bdudney)? Thanks, -bd-
Re: lifecycle logging from server
thanks Matt, -bd- On Sep 11, 2006, at 11:25 AM, Matt Hogstrom wrote: Done On Sep 11, 2006, at 11:50 AM, Bill Dudney wrote: Hi All, With my recent poking around in the startup and shutdown code for https://issues.apache.org/jira/browse/GERONIMO-2385 I figure I might be the guy to fix; http://issues.apache.org/jira/browse/GERONIMO-2387 but I can't assign it to myself. Could some one give me that permission in JIRA (user name bdudney)? Thanks, -bd- Matt Hogstrom [EMAIL PROTECTED]
[jira] Assigned: (GERONIMO-2377) deploying a new datasource with the same name does not indicate any problem in the console
[ http://issues.apache.org/jira/browse/GERONIMO-2377?page=all ] Bill Dudney reassigned GERONIMO-2377: - Assignee: Bill Dudney deploying a new datasource with the same name does not indicate any problem in the console -- Key: GERONIMO-2377 URL: http://issues.apache.org/jira/browse/GERONIMO-2377 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Bill Dudney Console acts as if it deployeed the datasource but the console spits out an error message; Deployer operation failed: Module console.dbpool/DefaultDS/1.0/rar already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module console.dbpool/DefaultDS/1.0/rar already exists in the server. Try to undeploy it first or use the redeploy command. at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:552) -- 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] Publish Genesis 1.0 to m2 central
Hi Jason, Did this ever get done? I'm +1 on releasing something (1.1, 1.0.1 1.0- oops whatever) since we are forced to build it after a complete bootstrap. TTFN, -bd- On Aug 30, 2006, at 7:19 PM, Jason Dillon wrote: Well... it was actually released... and then pulled back... which is my fault. But, I don't see any reason why 1.0 needs to be re-released. I've already updated the tree to use 1.1-SNAPSHOT and have been making changes to it to fix the noted problems as well as a few other enhancements... IMO it is much more confusing to look at the SVN logs and see that 1.0 was made from a 1.1-SNAPSHOT. I think that the unfortunate practice of making a release then voting on it and then possibly re-cutting the same release is very poor. I'd much rather consider 1.0 dead and release 1.1 so that there is no confusion as to which is which. In almost every other software project I have worked on, a release is cut, if there are changes, then a new revision is made and then a new release is cut for the changes. If you wanted to keep the 1.0 bits in there then 1.0-1 and then 1.0-2 is common practice for minor fix iterations. While I can understand since the time to run the tck for the Geronimo server on the release binaries and then after that has run we vote... that the server release is a bit different. I don't think this needs to be or should be the case for other projects. I believe it is much, much better to test the latest SNAPSHOT, then vote to make the release and then make the release. Anyways, I don't think that the version matters very much here. This is an internal project used to support internal builds. I don't expect anyone outside of Geronimo to even care. So, I still recommend that 1.0 is dead and next to be released w/proper oversight and vote is 1.1. --jason On Aug 30, 2006, at 6:02 PM, Alan D. Cabrera wrote: I'm confused, how do we vote for 1.1 if 1.0 was never released? We need to keep the version number the same. Regards, Alan Jason Dillon wrote: Okay, I'm canceling this vote. I've removed the clover bits from Genesis, and added headers to scripts... will start a new vote for 1.1 soonish. Thanks for all of your input. Sorry I jumped the gun and created the release before the vote. --jason On Aug 29, 2006, at 9:10 AM, Kevan Miller wrote: On Aug 28, 2006, at 11:25 PM, Jason Dillon wrote: On Aug 28, 2006, at 7:59 PM, Kevan Miller wrote: I appreciate that, I applaud your efforts, and apologize if I'm being a PITA. However, we also have a responsibility as a community when releasing software. I'm trying to be sure we are addressing that responsibility. Mmmkay. I'm taking deep breaths... :-] For instance, I see that genesis-1.0 includes a software license for Clover? News to me, but I confess that genesis has been a bit of an unknown to me... from Product: Clover License: Open Source License, 0.x, 1.x Issued: Sun May 14 2006 21:59:13 CDT Expiry: Never Maintenance Expiry: Never Key: 965016739f4031c43d67e61b0 Name: Jason Dillon Org: Apache Geronimo Clause 5 of the Clover license says The Licensee may copy the Software for back-up purposes only. The Licensee may not assign or otherwise transfer the Software to any third party. IANAL ADNWTB, however, this gives me cause for concern. Can you explain what this is about? I have no idea what IANAL ADNWTB means. But Clover grants licenses for open source projects. I used the license they granted to me to be used to run the site builds. This is shared configuration, which was checked into genesis to simplify the configuration of modules which need it to run the plugin. Sorry.. I Am Not A Lawyer And Don't Want To Be I don't think we can put this license in on ibiblio. I also don't think it should be public in our source tree... I understand that this may make things more difficult, but it sure seems to me that we're violating the terms of the license agreement... Can you convince me otherwise? --kevan
[jira] Created: (GERONIMO-2385) server does not update any state when persistent configuration is loaded and ready to serve applications
server does not update any state when persistent configuration is loaded and ready to serve applications Key: GERONIMO-2385 URL: http://issues.apache.org/jira/browse/GERONIMO-2385 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Bill Dudney see this thread http://www.nabble.com/When-has-the-server-started--tf2205476.html for reference -- 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-2385) server does not update any state when persistent configuration is loaded and ready to serve applications
[ http://issues.apache.org/jira/browse/GERONIMO-2385?page=all ] Bill Dudney updated GERONIMO-2385: -- Affects Version/s: 1.2 server does not update any state when persistent configuration is loaded and ready to serve applications Key: GERONIMO-2385 URL: http://issues.apache.org/jira/browse/GERONIMO-2385 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney see this thread http://www.nabble.com/When-has-the-server-started--tf2205476.html for reference -- 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: When has the server started?
Hi All, I have submitted a JIRA and patch to provide this GBean. http://issues.apache.org/jira/browse/GERONIMO-2385 feedback as always welcome... TTFN, -bd- On Sep 4, 2006, at 3:06 PM, David Jencks wrote: On Sep 4, 2006, at 4:54 PM, Jason Dillon wrote: On Sep 4, 2006, at 1:39 PM, David Jencks wrote: IMO this would be a perversion of the geronimo architecture. What does fully started mean anyway? If you start with say geronimo-jetty-minimal and add cars to turn it into a full j2ee server while it is running, when exactly is it started? It certainly has nothing to do with the kernel. When we thought about this last the best idea we could come up with is that it's fully started when all the modules listed in persistent configuration lists (should be persistent module lists) that are in the bootstrap or included recursively in those modules are started. Think about what happens if a module in the original PCL includes another PCL. Started (or fully started) means that the server has loaded, initialized and started all modules in the persistent configuration, such that it could then start to serve applications... and start listening on ports, etc. True there might be more modules to be loaded or configured after that, but the point is to tell when the server is ready to start accepting work. There is a period while the server is starting, when it starts listening to http, but it is not ready to serve applications which have been configured to be deployed. ya- that's a bug :-( Anyways, I don't care too much what it is called... but I think that flag should be exposed as a simple Boolean on some common MBean. That's a great idea! Maybe its not the Kernel, as the kernel might be started, but the system might not be ready to serve my webapps or whatever. Having to pull in geronimo-kernel to perform a simple remote call to fetch a boolean is overkill... especially since that module has magical logging fluff that rudely overwrites configuration. If we had a specialized MBean/GBean that just exposed the very common remote functionality via JMX directly then we would be in a very good position to keep tools (IDE plugins, maven plugins, etc) working even after we change the internals around. Such tools need an easy way to: * Detect when the server is started and ready to server applications * Shutdown Probably some other things too... yup thanks david jencks --jason
[jira] Commented: (GERONIMO-2385) server does not update any state when persistent configuration is loaded and ready to serve applications
[ http://issues.apache.org/jira/browse/GERONIMO-2385?page=comments#action_12433148 ] Bill Dudney commented on GERONIMO-2385: --- good point, probably at the beginning of the server shutdown process it should switch to false server does not update any state when persistent configuration is loaded and ready to serve applications Key: GERONIMO-2385 URL: http://issues.apache.org/jira/browse/GERONIMO-2385 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Attachments: GERONIMO-2385.bdudney.patch see this thread http://www.nabble.com/When-has-the-server-started--tf2205476.html for reference -- 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] 1.1.1-rc2 Release
Hi Matt Aaron, The fix is indeed in this version. Thanks! -bd- On Sep 6, 2006, at 12:31 AM, Matt Hogstrom wrote: The changes pointed out by Bill have been incorporated (crossing my fingers). I have not received any other comments so I'm hoping that others have looked. Please review these items and cast your votes in this thread. Thanks in advance for your time and attention. Vote ends Monday morning at 0600 Eastern Time. If there are issues in advance of that date a new RC will be spun up and a new vote started. *Source* http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-1.1.1-rc2- src.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-1.1.1-rc2- src.zip *Specifications* http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-j2ee- jacc_1.0_spec-1.1.1-rc2.jar http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-schema- j2ee_1.4-1.0-src.jar http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-schema- j2ee_1.4-1.0.jar *Distributions* http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty- j2ee-1.1.1-rc2.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty- j2ee-1.1.1-rc2.zip http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty- minimal-1.1.1-rc2.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-jetty- minimal-1.1.1-rc2.zip http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat- j2ee-1.1.1-rc2.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat- j2ee-1.1.1-rc2.zip http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat- minimal-1.1.1-rc2.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-tomcat- minimal-1.1.1-rc2.zip *Other Items* http://people.apache.org/~hogstrom/1.1.1-rc2/openejb-builder-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc2/openejb-core-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc2/openejb-pkgen- builder-2.1.1.jar
Re: console deployer dependencies
Hi Anita,
initial patch? The patch I posted had a single deleted line from each
pom. Just trying to understand the question.
On the j2ee-deployer being added; That was a result of other issues
with dependencies being missed. Starting with (I believe)
http://issues.apache.org/jira/browse/GERONIMO-2326
There were many many problems solved by adding that parent config
without causing other issues. I believe the whole conversation took
place in that JIRA so hopefully there is enough info there to inform
you.
As to the #2 issue/question I'm not sure, but from my current vantage
point with more experience of car stacking perhaps getting the tomcat-
deployer config correct would fix both 2326 this issue.
Thanks,
-bd-
On Sep 6, 2006, at 9:58 AM, anita kulshreshtha wrote:
Bill,
The webconsole-tomcat config differs from the original patch. To
answer your question correctly, I need to understand why:
1. The j2ee-deployer config was added as a parent configuration.
2. The tomcat-deployer config was changed so that tomcat config is not
a parent of tomcat-deployer config.
I am searching the archives/jiras. I need to do some testing..
Thanks
Anita
--- Bill Dudney [EMAIL PROTECTED] wrote:
Anita,
While the jar's are not required in the class loader, without them
the warning messages are printed.
Do you have ideas about how to get rid of the warning messages and
keep the 'provided' scope?
I think I prefer pushing all the methods into the 'super interface'
and having an UnsupportedOperationException as long as there are good
error messages as to what has happened (i.e. 'a method was invoked on
the Jetty container that is not supported, perhaps you wanted to use
Tomcat instead?' or something less cheesy).
Anyway I'm not sure of the best way to handle this but I don't like
the warning messages. I think they would look ominous to initial
users then over time users would stop worrying about warning
messages. Which is bad IMO.
TTFN,
-bd-
On Sep 5, 2006, at 8:23 AM, anita kulshreshtha wrote:
I'm not sure what the point is of listing it as provided, if
that's
what we're currently doing. I'm pretty sure it's not provided
so
we
might as well either not list it or list it as a regular
dependency.
The scope=provided is used to enforce the build order for the
configs, i.e the console configs are not built before the
jetty/tomcat
deployer configs are built in a multi config build. These cars are
not
required in the classloader.
Thanks
Anita
On 9/4/06, Bill Dudney [EMAIL PROTECTED] wrote:
Hi All,
The consoles (tomcat jetty) are spewing warning messages like
this;
08:00:18,511 WARN [BasicProxyManager] Could not load interface
org.apache.geronimo.jetty.JettyWebAppContext in provided
ClassLoader
for org.apache.geronimo.configs/welcome-jetty/1.2-SNAPSHOT/car?
J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.conf
igs
/welcome-jetty/1.2-SNAPSHOT/car
To fix it we can simply remove the scopeprovided/scope from
the
artifactId{jetty,tomcat}-deployer/artifactId dependencies
in
the
webconsole-{jetty,tomcat}/pom.xml.
Could someone who knows more about the console than me please
review
the patch (GERONIMO-2344.bdudney-2.patch) here;
http://issues.apache.org/jira/browse/GERONIMO-2344
And apply it if it makes sense?
Thanks!
-bd-
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: console deployer dependencies
Anita,
While the jar's are not required in the class loader, without them
the warning messages are printed.
Do you have ideas about how to get rid of the warning messages and
keep the 'provided' scope?
I think I prefer pushing all the methods into the 'super interface'
and having an UnsupportedOperationException as long as there are good
error messages as to what has happened (i.e. 'a method was invoked on
the Jetty container that is not supported, perhaps you wanted to use
Tomcat instead?' or something less cheesy).
Anyway I'm not sure of the best way to handle this but I don't like
the warning messages. I think they would look ominous to initial
users then over time users would stop worrying about warning
messages. Which is bad IMO.
TTFN,
-bd-
On Sep 5, 2006, at 8:23 AM, anita kulshreshtha wrote:
I'm not sure what the point is of listing it as provided, if that's
what we're currently doing. I'm pretty sure it's not provided so
we
might as well either not list it or list it as a regular dependency.
The scope=provided is used to enforce the build order for the
configs, i.e the console configs are not built before the jetty/tomcat
deployer configs are built in a multi config build. These cars are not
required in the classloader.
Thanks
Anita
On 9/4/06, Bill Dudney [EMAIL PROTECTED] wrote:
Hi All,
The consoles (tomcat jetty) are spewing warning messages like
this;
08:00:18,511 WARN [BasicProxyManager] Could not load interface
org.apache.geronimo.jetty.JettyWebAppContext in provided
ClassLoader
for org.apache.geronimo.configs/welcome-jetty/1.2-SNAPSHOT/car?
J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.conf
igs
/welcome-jetty/1.2-SNAPSHOT/car
To fix it we can simply remove the scopeprovided/scope from
the
artifactId{jetty,tomcat}-deployer/artifactId dependencies in
the
webconsole-{jetty,tomcat}/pom.xml.
Could someone who knows more about the console than me please
review
the patch (GERONIMO-2344.bdudney-2.patch) here;
http://issues.apache.org/jira/browse/GERONIMO-2344
And apply it if it makes sense?
Thanks!
-bd-
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[jira] Updated: (GERONIMO-2344) Tomcat Console can't find TomcatManagerImpl class during display of ServerLogs
[ http://issues.apache.org/jira/browse/GERONIMO-2344?page=all ] Bill Dudney updated GERONIMO-2344: -- Attachment: GERONIMO-2344.bdudney-2.patch Happes on Jetty as well. 08:00:18,511 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.jetty.JettyWebAppContext in provided ClassLoader for org.apache.geronimo.configs/welcome-jetty/1.2-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.configs/welcome-jetty/1.2-SNAPSHOT/car I've attached a new patch (GERONIMO-2344.bdudney-2.patch) to be applied from geronimo/configs that will fix both. Tomcat Console can't find TomcatManagerImpl class during display of ServerLogs -- Key: GERONIMO-2344 URL: http://issues.apache.org/jira/browse/GERONIMO-2344 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Attachments: GERONIMO-2344.bdudney-2.patch, GERONIMO-2344.bdudney.patch Console classpath problems prevent the class from being found. Here are the error messages; 10:12:39,240 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatManagerImpl in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebManager 10:12:39,298 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 10:12:39,305 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatContainer in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer The patch simply removes the scopeprovided/scope from the tomcat-deployer dependency. -- 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
console deployer dependencies
Hi All,
The consoles (tomcat jetty) are spewing warning messages like this;
08:00:18,511 WARN [BasicProxyManager] Could not load interface
org.apache.geronimo.jetty.JettyWebAppContext in provided ClassLoader
for org.apache.geronimo.configs/welcome-jetty/1.2-SNAPSHOT/car?
J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.configs
/welcome-jetty/1.2-SNAPSHOT/car
To fix it we can simply remove the scopeprovided/scope from the
artifactId{jetty,tomcat}-deployer/artifactId dependencies in the
webconsole-{jetty,tomcat}/pom.xml.
Could someone who knows more about the console than me please review
the patch (GERONIMO-2344.bdudney-2.patch) here;
http://issues.apache.org/jira/browse/GERONIMO-2344
And apply it if it makes sense?
Thanks!
-bd-
[jira] Created: (GERONIMO-2377) deploying a new datasource with the same name does not indicate any problem in the console
deploying a new datasource with the same name does not indicate any problem in the console -- Key: GERONIMO-2377 URL: http://issues.apache.org/jira/browse/GERONIMO-2377 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.2 Reporter: Bill Dudney Console acts as if it deployeed the datasource but the console spits out an error message; Deployer operation failed: Module console.dbpool/DefaultDS/1.0/rar already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module console.dbpool/DefaultDS/1.0/rar already exists in the server. Try to undeploy it first or use the redeploy command. at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:552) -- 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: console deployer dependencies
Hi Aaron,
Thanks for the response.
As to the question; IMO the 'right' thing to do is separate out the
interfaces. But practically speaking is that reasonable? Seems like
that is a huge task for not much gain (unless I'm missing something
from a future expected use discussion that I missed).
Now making sure I understood what you said the cause of the error
message is. Since the jetty-deployer is 'provided' scope it is not
added explicitly to the class loader for the console. The jetty-
deloyer has the interface and impl for JettyWebAppContext. Since the
jar that this interface is in is not explicitly added to the
console's class path (because of 'provided' if I understand
correctly) it barfs.
However, if we were to separate the interfaces of 'jetty-deployer'
from the implementation classes we could put an explicit reference
into the console to the interfaces and leave the implementation as
'provided'.
Please fix my lack of understanding :-)
Thanks again,
-bd-
On Sep 4, 2006, at 8:54 AM, Aaron Mulder wrote:
It's actually the proxy manager that produces those messages. It
means that the console asked for a proxy to some GBean, and some of
the interfaces implemented by that GBean weren't available in the
caller's (the console's) class loader.
It would be nice to have a larger discussion about how to handle this.
For example, do we package all management interfaces in separate JARs
from the core libraries (Jetty, Tomcat, ActiveMQ, etc.) so that the
console can add only the interfaces to its class loader? Or are we OK
with the console just adding the full implementation JARs for
everything to its class path?
Thanks,
Aaron
On 9/4/06, Bill Dudney [EMAIL PROTECTED] wrote:
Hi All,
The consoles (tomcat jetty) are spewing warning messages like this;
08:00:18,511 WARN [BasicProxyManager] Could not load interface
org.apache.geronimo.jetty.JettyWebAppContext in provided ClassLoader
for org.apache.geronimo.configs/welcome-jetty/1.2-SNAPSHOT/car?
J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.conf
igs
/welcome-jetty/1.2-SNAPSHOT/car
To fix it we can simply remove the scopeprovided/scope from the
artifactId{jetty,tomcat}-deployer/artifactId dependencies in the
webconsole-{jetty,tomcat}/pom.xml.
Could someone who knows more about the console than me please review
the patch (GERONIMO-2344.bdudney-2.patch) here;
http://issues.apache.org/jira/browse/GERONIMO-2344
And apply it if it makes sense?
Thanks!
-bd-
Re: Testsuite module, with basic/crude Selenium support
Hi All,The only down side I can see to testng is the reliance on surefire 2.8-SNAPSHOT.The whole 2.8-SNAPSHOT thing seems weird so I tried out 2.3-SNAPSHOT from http://people.apache.org/maven-snapshot-repository and everything seemed to work fine. Jason could you try that out so we can get rid of the 2.8-SNAPSHOT dependency?Apart from that I think testng is the way to go.TTFN,-bd--- begin patch ---Index: pom.xml===--- pom.xml   (revision 439918)+++ pom.xml   (working copy)@@ -93,7 +93,7 @@         plugin           groupIdorg.apache.maven.plugins/groupId           artifactIdmaven-surefire-plugin/artifactId-          version2.8-SNAPSHOT/version+          version2.3-SNAPSHOT/version         /plugin       /plugins     /pluginManagement@@ -116,14 +116,4 @@     /repository   /repositories   -  !---  NOTE: This is the repository where maven-surefire-plugin:2.8-SNAPSHOT comes from.-  ---  pluginRepositories-    pluginRepository-      idtapestry.javaforge/id-      urlhttp://howardlewisship.com/repository/url-    /pluginRepository-  /pluginRepositories- /project-- end patch--On Sep 4, 2006, at 12:01 AM, Jason Dillon wrote:Ya, I see this from time to time... not really sure why it pops up sometimes and not at others. Its easy enough to fix... but I think that its much easier with ng.Still talking to maven folks about getting a release of surefire that works with testng + jdk14, but the 2.8-SNAPSHOT works for now...--jasonOn 9/3/06, Bill Dudney [EMAIL PROTECTED] wrote: So you got around this? This was not happening for me so I'm not surewhat is going on, it appears from the next message that you got it to work.I did see an UndeclaredThrowableException a time or two but it wasalways because the selenium server was not running.I'm going to dig into your testng stuff in the am and will postthoughts. TTFN,bd-On Sep 3, 2006, at 6:03 AM, Jason Dillon wrote: FYI, I applied your patch... and surefire barfs as I thought it might: snip java.lang.reflect.UndeclaredThrowableException at $Proxy0.addError(Unknown Source) at junit.framework.TestResult.addError(TestResult.java:36) at junit.framework.TestResult.runProtected(TestResult.java: 133) at junit.extensions.TestSetup.run(TestSetup.java:23) 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.apache.maven.surefire.junit.JUnitTestSet.execute (JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest Set(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute (AbstractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess (SurefireBooter.java:262) at org.apache.maven.surefire.booter.SurefireBooter.main (SurefireBooter.java:787) Caused by: java.lang.NoSuchMethodException: org.apache.geronimo.testsuite.console.StartSeleniumDecorator.getName() at java.lang.Class.getMethod(Class.java:986) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.getStack TraceWriter(TestListenerInvocationHandler.java:171) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAd dError(TestListenerInvocationHandler.java:160) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke (TestListenerInvocationHandler.java:134) ... 18 more /snip --jason On Sep 2, 2006, at 6:28 AM, Bill Dudney wrote: Hi Jason, This is very cool indeed, thanks for putting the prototype together. I just submitted a patch that makes firefox pop up only once to run all the tests (it actually pops up twice, once during selenium.start() and then once for the test suite but the first time is for a split second). http://issues.apache.org/jira/browse/GERONIMO-2374 It uses a JUnit TestDecorator to run setup only once for the whole suite. IMO until we move to JDK 5 its not a great idea to move to TestNG, you will get some benefits for sure but the source has to be parsed at runtime to get at the meta-data ( i.e. the info about
[jira] Commented: (GERONIMO-2354) Replace concurrent with backport-concurrent-util
[ http://issues.apache.org/jira/browse/GERONIMO-2354?page=comments#action_12432528 ] Bill Dudney commented on GERONIMO-2354: --- I tried out this patch, 2 issues; 1) this patch is painful to apply (let me knowif I did something wrong, or if there is a better way); bootstrap apply the openejb patch to target/external/openejb2 apply the geronimo patch manually delete the two empty files (ClockPool.java, ThreadPool.java) rebuild modules so openejb can build (cd modules, mvn install) rebuild openejb (cd target/external/openejb2, mvn install) rebuild G (cd ../../.., mvn install) cp the tomcat assembly, unzip untar 2) The startup fails with the following exception, looks like there is still something mixed up in the dependencies; Module 1/20 org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car Exception in thread main java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/Executor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200(JarFileClassLoader.java:51) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFileClassLoader.java:275) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(JarFileClassLoader.java:227) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:243) ... Replace concurrent with backport-concurrent-util Key: GERONIMO-2354 URL: http://issues.apache.org/jira/browse/GERONIMO-2354 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Jason Dillon Attachments: GERONIMO-2354-openejb2.diff, GERONIMO-2354-openejb2.diff, GERONIMO-2354.diff, GERONIMO-2354.diff Replace usage of concurrent classes with backport-concurrent-util. Preparation for using java.util.concurrent in JDK 1.5, and reduce the need for 2 sets of concurrent classes on the boot classloader. Sill need to include concurrent, as activeio and openejb still have some dependencies upon it... but this brings us a step closer to not needing both. -- 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: Testsuite module, with basic/crude Selenium support
Hey Jason,Sorry for the false alarm, the tests don't run. Looks like 2.8-SNAPSHOT is what we will have to use until the surefire folks can do an update.TTFN,-bd-On Sep 4, 2006, at 10:34 AM, Jason Dillon wrote:Did the tests actually run? Make sure that it actually ran tests for basic/*--jasonOn Sep 4, 2006, at 9:33 AM, Bill Dudney wrote:Hi All,The only down side I can see to testng is the reliance on surefire 2.8-SNAPSHOT.The whole 2.8-SNAPSHOT thing seems weird so I tried out 2.3-SNAPSHOT from http://people.apache.org/maven-snapshot-repository and everything seemed to work fine. Jason could you try that out so we can get rid of the 2.8-SNAPSHOT dependency?Apart from that I think testng is the way to go.TTFN,-bd--- begin patch ---Index: pom.xml===--- pom.xml   (revision 439918)+++ pom.xml   (working copy)@@ -93,7 +93,7 @@         plugin           groupIdorg.apache.maven.plugins/groupId           artifactIdmaven-surefire-plugin/artifactId-          version2.8-SNAPSHOT/version+          version2.3-SNAPSHOT/version         /plugin       /plugins     /pluginManagement@@ -116,14 +116,4 @@     /repository   /repositories   -  !---  NOTE: This is the repository where maven-surefire-plugin:2.8-SNAPSHOT comes from.-  ---  pluginRepositories-    pluginRepository-      idtapestry.javaforge/id-      urlhttp://howardlewisship.com/repository/url-    /pluginRepository-  /pluginRepositories- /project-- end patch--On Sep 4, 2006, at 12:01 AM, Jason Dillon wrote:Ya, I see this from time to time... not really sure why it pops up sometimes and not at others. Its easy enough to fix... but I think that its much easier with ng.Still talking to maven folks about getting a release of surefire that works with testng + jdk14, but the 2.8-SNAPSHOT works for now...--jasonOn 9/3/06, Bill Dudney [EMAIL PROTECTED] wrote: So you got around this? This was not happening for me so I'm not surewhat is going on, it appears from the next message that you got it to work.I did see an UndeclaredThrowableException a time or two but it wasalways because the selenium server was not running.I'm going to dig into your testng stuff in the am and will postthoughts. TTFN,bd-On Sep 3, 2006, at 6:03 AM, Jason Dillon wrote: FYI, I applied your patch... and surefire barfs as I thought it might: snip java.lang.reflect.UndeclaredThrowableException at $Proxy0.addError(Unknown Source) at junit.framework.TestResult.addError(TestResult.java:36) at junit.framework.TestResult.runProtected(TestResult.java: 133) at junit.extensions.TestSetup.run(TestSetup.java:23) 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.apache.maven.surefire.junit.JUnitTestSet.execute (JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest Set(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute (AbstractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess (SurefireBooter.java:262) at org.apache.maven.surefire.booter.SurefireBooter.main (SurefireBooter.java:787) Caused by: java.lang.NoSuchMethodException: org.apache.geronimo.testsuite.console.StartSeleniumDecorator.getName() at java.lang.Class.getMethod(Class.java:986) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.getStack TraceWriter(TestListenerInvocationHandler.java:171) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAd dError(TestListenerInvocationHandler.java:160) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke (TestListenerInvocationHandler.java:134) ... 18 more /snip --jason On Sep 2, 2006, at 6:28 AM, Bill Dudney wrote: Hi Jason, This is very cool indeed, thanks for putting the prototype together. I just submitted a patch that makes firefox pop up only once to run all the tests (it actually pops up twice, once during selenium.start() and then once for the test suite but the first time
[jira] Updated: (GERONIMO-2365) Upgrade Derby to 10.1.3.1
[ http://issues.apache.org/jira/browse/GERONIMO-2365?page=all ] Bill Dudney updated GERONIMO-2365: -- Attachment: GERONIMO-2365-testsupport-bdudney.patch update the test deployables to use 10.1.3.1 too. apply from the testsupport directory. 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-testsupport-bdudney.patch, 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
[jira] Commented: (GERONIMO-2364) Update geronimo to use ActiveMQ 4.1.x
[ http://issues.apache.org/jira/browse/GERONIMO-2364?page=comments#action_12432540 ] Bill Dudney commented on GERONIMO-2364: --- not sure what the problem is but I get this stack trace; 13:16:12,467 ERROR [JMSConnectorPortlet] Unable to render portlet java.lang.IllegalArgumentException: Unable to look up connectors for ActiveMQ broker 'org.apache.geronimo.configs/activemq-broker/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/1.2-SNAPSHOT/car,j2eeType=JMSServer,name=ActiveMQ at org.apache.activemq.gbean.management.ActiveMQManagerGBean.getConnectorsForContainer(ActiveMQManagerGBean.java:152) at org.apache.activemq.gbean.management.ActiveMQManagerGBean$$FastClassByCGLIB$$3598ee3a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.activemq.gbean.ActiveMQManager$$EnhancerByCGLIB$$8950bd39.getConnectorsForContainer(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.doList(JMSConnectorPortlet.java:179) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.doView(JMSConnectorPortlet.java:166) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) . at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) Caused by: java.lang.NullPointerException at org.apache.activemq.gbean.management.ActiveMQManagerGBean.getConnectorsForContainer(ActiveMQManagerGBean.java:146) ... 94 more Update geronimo to use ActiveMQ 4.1.x - Key: GERONIMO-2364 URL: http://issues.apache.org/jira/browse/GERONIMO-2364 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 1.2 Attachments: GERONIMO-2364.patch -- 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: Patches in RTC (Geronimo - 2006-09-04)
On Sep 4, 2006, at 9:12 AM, [EMAIL PROTECTED] wrote: Geronimo - Monday, September 4, 2006 10 Patches in RTC [GERONIMO-2354] Replace concurrent with backport-concurrent-util - Assignee: Unassigned - Reporter: Jason Dillon - Created: Sun Aug 27 21:53:39 PDT 2006 - Updated: Tue Aug 29 19:39:58 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2354 -1 patch does not work for me - but it looks like a simple dependency problem from the log, I updated the issue with the stack trace [GERONIMO-903] Update Log4J usage from 1.2.8 to latest maintenance version of 1.2.13 - Assignee: Jason Dillon - Reporter: Donald Woods - Created: Tue Aug 23 16:02:38 PDT 2005 - Updated: Thu Aug 31 23:13:51 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-903 +1 - built, deployed and appeared to log just fine, I deployed a DataSource and an ear and no unexpected logs came out on the console and the ones I expected to show up did. [GERONIMO-2015] Let's replace JKS to PKCS12 key store type - Assignee: Unassigned - Reporter: Nikolay Chugunov - Created: Fri May 12 14:54:17 PDT 2006 - Updated: Thu Aug 10 10:59:06 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2015 +0 (no opinion) From the JIRA it was not clear what to do with this one for me so I did not try it. [GERONIMO-2332] RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all - Assignee: David Jencks - Reporter: David Jencks - Created: Fri Aug 18 13:13:47 PDT 2006 - Updated: Fri Aug 25 18:32:52 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2332 +0 (no opinion) was not sure what to apply on this one either. [GERONIMO-2365] Upgrade Derby to 10.1.3.1 - Assignee: Jason Dillon - Reporter: Jason Dillon - Created: Wed Aug 30 17:10:25 PDT 2006 - Updated: Thu Aug 31 16:31:44 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2365 +1 with the additional patch I attached (the test deployables still had dependency on 10.1.1.0) [GERONIMO-2163] WADI Integration for Jetty - Assignee: Gianny Damour - Reporter: Gianny Damour - Created: Sun Jul 02 14:16:35 PDT 2006 - Updated: Fri Sep 01 08:33:50 PDT 2006 - Votes: 1 1 David Jencks - http://issues.apache.org/jira/browse/GERONIMO-2163 +0 (no opinion) Looked like there was still alot of churn on what needs to be done here to test so I left it alone. [GERONIMO-2349] jta 1.1 support with container manager jpa support in transaction module - Assignee: David Jencks - Reporter: David Jencks - Created: Wed Aug 23 13:22:37 PDT 2006 - Updated: Thu Aug 31 13:49:47 PDT 2006 - Votes: 1 1 David Blevins - http://issues.apache.org/jira/browse/GERONIMO-2349 +0 not sure what to apply and do to test this patch [GERONIMO-2248] Applications portlets: List Parent and Child components against each component - Assignee: Unassigned - Reporter: Vamsavardhana Reddy - Created: Sun Jul 30 08:15:34 PDT 2006 - Updated: Sat Aug 19 10:44:11 PDT 2006 - Votes: 1 1 Donald Woods - http://issues.apache.org/jira/browse/GERONIMO-2248 +0 Not clear that Aaron's concerns were addressed [GERONIMO-2358] Move java ee 5 specs into specs trunk - Assignee: David Blevins - Reporter: David Blevins - Created: Mon Aug 28 17:21:48 PDT 2006 - Updated: Mon Aug 28 17:26:11 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2358 +1 - we should do this ASAP IMO [GERONIMO-2364] Update geronimo to use ActiveMQ 4.1.x - Assignee: Hiram Chirino - Reporter: Hiram Chirino - Created: Tue Aug 29 12:21:46 PDT 2006 - Updated: Thu Aug 31 22:46:27 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2364 -1 tried this patch and got a stack trace - I updated the jira NOTE: This email is generated and does not constitute and offical vote or vote result. All official voting is done on the dev list. If you do not see your issue here, click the Begin RTC Review link under the Available Workflow Actions of the JIRA page. If you do not see your vote here, click the Vote link under the Operations section of the JIRA page. *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE *** Template: http://svn.apache.org/repos/asf/geronimo/gbuild/ jirareports/patchesInRtc.vm
Re: Patches in RTC (Geronimo - 2006-09-04)
On Sep 4, 2006, at 1:34 PM, Jason Dillon wrote: On Sep 4, 2006, at 12:19 PM, Bill Dudney wrote: [GERONIMO-2354] Replace concurrent with backport-concurrent-util - Assignee: Unassigned - Reporter: Jason Dillon - Created: Sun Aug 27 21:53:39 PDT 2006 - Updated: Tue Aug 29 19:39:58 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2354 -1 patch does not work for me - but it looks like a simple dependency problem from the log, I updated the issue with the stack trace From your comments I don't think you fixed the configs/client/ pom.xml and/or you might have had something stale in your assembly. As I mentioned, I just re-tested the patch and there were no errors. I'll retest, is it worth posting a new patch? Would make it slightly easier for others to test the patch. [GERONIMO-2364] Update geronimo to use ActiveMQ 4.1.x - Assignee: Hiram Chirino - Reporter: Hiram Chirino - Created: Tue Aug 29 12:21:46 PDT 2006 - Updated: Thu Aug 31 22:46:27 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2364 -1 tried this patch and got a stack trace - I updated the jira From the stack you posted, it does not look like you updated ActiveMQManagerGBean as I mentioned was the fix for this exception ( its the comment right before your stack :-P ) Dooh! how about a new patch that includes the NPE fix. I'd be glad to post it if you think its worth it. I think this one is definitely worth it cause it makes it simply patch, rebuild, test instead of having to manually edit stuff. TTFN, -bd-
Re: Patches in RTC (Geronimo - 2006-09-04)
Hey Jason, Yep, time lag is an issue. My votes don't even count, I'm just trying to help get/keep the ball rolling on these patches. I won't post any new patches cause then it might appear that I'm signing up for continuos rediff duty :-) TTFN, -bd- On Sep 4, 2006, at 2:21 PM, Jason Dillon wrote: On Sep 4, 2006, at 1:09 PM, Bill Dudney wrote: From your comments I don't think you fixed the configs/client/ pom.xml and/or you might have had something stale in your assembly. As I mentioned, I just re-tested the patch and there were no errors. I'll retest, is it worth posting a new patch? Would make it slightly easier for others to test the patch. Eh... if more hunks failed I might... but the longer we wait to apply the more chances that more hunks will fail... and so I don't want to sign up to continuously rediff. :-\ From the stack you posted, it does not look like you updated ActiveMQManagerGBean as I mentioned was the fix for this exception ( its the comment right before your stack :-P ) Dooh! how about a new patch that includes the NPE fix. I'd be glad to post it if you think its worth it. I think this one is definitely worth it cause it makes it simply patch, rebuild, test instead of having to manually edit stuff. Eh... if you feel like it... though that just means that I gotta reverify it. :-\ Blah, this should just get committed. The lag from patch to verify to commit is too much, its just causing more overhead. If this keeps up I may go back to a branch in the sandbox. --jason
Re: Patches in RTC (Geronimo - 2006-09-04)
feel the power! ;-| On Sep 4, 2006, at 2:56 PM, Jason Dillon wrote: Your votes count as much as my votes count at the moment :-P --jason On Sep 4, 2006, at 1:50 PM, Bill Dudney wrote: Hey Jason, Yep, time lag is an issue. My votes don't even count, I'm just trying to help get/keep the ball rolling on these patches. I won't post any new patches cause then it might appear that I'm signing up for continuos rediff duty :-) TTFN, -bd- On Sep 4, 2006, at 2:21 PM, Jason Dillon wrote: On Sep 4, 2006, at 1:09 PM, Bill Dudney wrote: From your comments I don't think you fixed the configs/client/ pom.xml and/or you might have had something stale in your assembly. As I mentioned, I just re-tested the patch and there were no errors. I'll retest, is it worth posting a new patch? Would make it slightly easier for others to test the patch. Eh... if more hunks failed I might... but the longer we wait to apply the more chances that more hunks will fail... and so I don't want to sign up to continuously rediff. :-\ From the stack you posted, it does not look like you updated ActiveMQManagerGBean as I mentioned was the fix for this exception ( its the comment right before your stack :-P ) Dooh! how about a new patch that includes the NPE fix. I'd be glad to post it if you think its worth it. I think this one is definitely worth it cause it makes it simply patch, rebuild, test instead of having to manually edit stuff. Eh... if you feel like it... though that just means that I gotta reverify it. :-\ Blah, this should just get committed. The lag from patch to verify to commit is too much, its just causing more overhead. If this keeps up I may go back to a branch in the sandbox. --jason
Re: Testsuite module, with basic/crude Selenium support
So you got around this? This was not happening for me so I'm not sure what is going on, it appears from the next message that you got it to work. I did see an UndeclaredThrowableException a time or two but it was always because the selenium server was not running. I'm going to dig into your testng stuff in the am and will post thoughts. TTFN, bd- On Sep 3, 2006, at 6:03 AM, Jason Dillon wrote: FYI, I applied your patch... and surefire barfs as I thought it might: snip java.lang.reflect.UndeclaredThrowableException at $Proxy0.addError(Unknown Source) at junit.framework.TestResult.addError(TestResult.java:36) at junit.framework.TestResult.runProtected(TestResult.java: 133) at junit.extensions.TestSetup.run(TestSetup.java:23) 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.apache.maven.surefire.junit.JUnitTestSet.execute (JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest Set(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute (AbstractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess (SurefireBooter.java:262) at org.apache.maven.surefire.booter.SurefireBooter.main (SurefireBooter.java:787) Caused by: java.lang.NoSuchMethodException: org.apache.geronimo.testsuite.console.StartSeleniumDecorator.getName() at java.lang.Class.getMethod(Class.java:986) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.getStack TraceWriter(TestListenerInvocationHandler.java:171) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAd dError(TestListenerInvocationHandler.java:160) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke (TestListenerInvocationHandler.java:134) ... 18 more /snip --jason On Sep 2, 2006, at 6:28 AM, Bill Dudney wrote: Hi Jason, This is very cool indeed, thanks for putting the prototype together. I just submitted a patch that makes firefox pop up only once to run all the tests (it actually pops up twice, once during selenium.start() and then once for the test suite but the first time is for a split second). http://issues.apache.org/jira/browse/GERONIMO-2374 It uses a JUnit TestDecorator to run setup only once for the whole suite. IMO until we move to JDK 5 its not a great idea to move to TestNG, you will get some benefits for sure but the source has to be parsed at runtime to get at the meta-data (i.e. the info about the tests). Krufty IMO. The patch has a comment about invalid XHTML. I believe the invalid XHTML part of the console is preventing the XPath find from working. TTFN, -bd- On Sep 1, 2006, at 7:46 PM, Jason Dillon wrote: I've checked in a new top-level testsuite module and a few new plugins to support it. This is only the start and I expect it to change over the next few weeks (er maybe months) as momentum starts to pick up. I looked into Cargo, and while I think we should eventually use it to start/stop the server... asis now its broke. We need to provide a very simple and consistent way for Cargo to invoke some operations via JMX, which I hinted to in previous emails. Once that is done, we can patch Cargo and hopefully get that committed to support G... but in the mean time I whipped up a simple start stop mojo that uses Ant to start and stop the server. Its very, very crude and we need to fix stuff like logging output etc. I also played around a little with Selenium to make some tests for the console. It wants a special server process started, so I created a selenium plugin which currently only starts that server in... well an icky way, but should work for the moment. Need to ask the m2 folks how to do this better. I created a console-testsuite module, which sets up the G server and Selenium server in pre-integration-test, and then uses the maven-invoker-plugin to invoke the basic module to actually run the tests. Only one test class right now, SimpleLoginTest, which does just that... logs in, logs in and then out and then another that logs in and clicks some links. I've got it all running
[jira] Created: (GERONIMO-2374) use junit decorators with selenium
use junit decorators with selenium -- Key: GERONIMO-2374 URL: http://issues.apache.org/jira/browse/GERONIMO-2374 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Reporter: Bill Dudney use the junit decorators instead of trying to move to testng for simplification. -- 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-2374) use junit decorators with selenium
[ http://issues.apache.org/jira/browse/GERONIMO-2374?page=all ] Bill Dudney updated GERONIMO-2374: -- Attachment: GERONIMO-2374.bdudney.patch adds a decorator to the test suite use junit decorators with selenium -- Key: GERONIMO-2374 URL: http://issues.apache.org/jira/browse/GERONIMO-2374 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Reporter: Bill Dudney Attachments: GERONIMO-2374.bdudney.patch use the junit decorators instead of trying to move to testng for simplification. -- 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-2375) console has invalid XHTML in the db bool
console has invalid XHTML in the db bool Key: GERONIMO-2375 URL: http://issues.apache.org/jira/browse/GERONIMO-2375 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Bill Dudney the invalid XHTML prevevents automated tests from deploying a db pool -- 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-2375) console has invalid XHTML in the db bool
[ http://issues.apache.org/jira/browse/GERONIMO-2375?page=all ] Bill Dudney updated GERONIMO-2375: -- Attachment: GERONIMO-2375.bdudney.patch console has invalid XHTML in the db bool Key: GERONIMO-2375 URL: http://issues.apache.org/jira/browse/GERONIMO-2375 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Attachments: GERONIMO-2375.bdudney.patch the invalid XHTML prevevents automated tests from deploying a db pool -- 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-2373) build broken with the removal of geronimo-j2ee_1.4_spec from the specs
build broken with the removal of geronimo-j2ee_1.4_spec from the specs -- Key: GERONIMO-2373 URL: http://issues.apache.org/jira/browse/GERONIMO-2373 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Bill Dudney a couple of configs and applications have dependencies that are not correct as a result of the removal of geronimo-j2ee_1.4_spec. The attached patch addes the necessary dependencies. -- 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: One more build error on Windows
I think this is a bug in the build because of the removal of geronimo- j2ee_1.4_spec module. I filed a bug and will uploaded a patch shortly; http://issues.apache.org/jira/browse/GERONIMO-2373 Please try it and comment in the JIRA on success/failure. TTFN, -bd- On Sep 1, 2006, at 5:55 AM, Jacek Laskowski wrote: On 9/1/06, Deepak Srinivasa [EMAIL PROTECTED] wrote: Oops... I forgot to attach the error file. Here it is... Seems the plugin is doing a great job printing out all its details while tracing. Have you tried to compile the classes in question by hand in order to get the gist of why it's actually failed? Take a look at the attached file and at the very end of the file you'll see the exact command you can execute to pinpoint the real issue. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Build Error
Hi Lasantha, Did you run the bootsrap script in the root of the geronimo src folder? The 2.2-SNAPSHOT for openejb should be guild by the bootstrap so it appears from the errors here that you are not getting the open ejb build. http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with- maven-2.html has more complete instructions. Specifically if it fails look in server/target/openejb for the open ejb src. If its there try mvn install from that directory and see if it helps. Good luck! -bd- On Sep 1, 2006, at 7:48 AM, Lasantha Ranaweera wrote: Hi Bill, This error happened in a Linux (Kubuntu) environment. Following is the stack trace. It looks openejb-builder can't repository to download dependencies (2.2-SNAPSHOT of openejb). Following are the list of repositories visible to the maven build. I couldn't find the 2.2-SNAPSHOT of openejb either in those repositories either. central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/maven-snapshot-repository), codehaus (http://repository.codehaus.org), apache-snapshots (http://people.apache.org/repo/m2-snapshot- repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-snapshots-m1 (http://people.apache.org/repo/m1-snapshot- repository) When I search on the Internet I found following repository with openejb 2.2 snapshots. But this repository stores jars with some out of ordinary pattern. http://snapshots.dist.codehaus.org/openejb/jars/ If I can give this link in maven it might solve my problem. Anyway I am not that good at Maven. Hope somebody can help me in this matter. I have given the stack trace of the error below. Regards, Lasantha Ranaweera [ERROR] BUILD ERROR [INFO] -- -- [INFO] Failed to resolve artifact. Missing: -- 1) org.openejb:openejb-pkgen-builder:jar:2.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.openejb - DartifactId=openejb-pkgen-builder \ -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.configs:openejb-deployer:car:1.2- SNAPSHOT 2) org.openejb:openejb-pkgen-builder:jar:2.2-SNAPSHOT 2) org.openejb:openejb-builder:jar:2.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.openejb - DartifactId=openejb-builder \ -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.configs:openejb-deployer:car:1.2- SNAPSHOT 2) org.openejb:openejb-builder:jar:2.2-SNAPSHOT 3) org.openejb:openejb-core:jar:2.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.openejb - DartifactId=openejb-core \ -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.configs:openejb-deployer:car:1.2- SNAPSHOT 2) org.openejb:openejb-core:jar:2.2-SNAPSHOT -- 3 required artifacts are missing. for artifact: org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/maven-snapshot- repository), codehaus (http://repository.codehaus.org), apache-snapshots (http://people.apache.org/repo/m2-snapshot- repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-snapshots-m1 (http://people.apache.org/repo/m1-snapshot- repository) [INFO] -- -- [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.openejb:openejb-pkgen-builder:jar:2.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.openejb - DartifactId=openejb-pkgen-builder \ -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.configs:openejb-deployer:car:1.2- SNAPSHOT 2) org.openejb:openejb-pkgen-builder:jar:2.2-SNAPSHOT 2) org.openejb:openejb-builder:jar:2.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.openejb - DartifactId=openejb-builder \ -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.configs:openejb-deployer:car:1.2- SNAPSHOT 2) org.openejb:openejb-builder:jar:2.2-SNAPSHOT 3) org.openejb:openejb-core:jar:2.2-SNAPSHOT Try downloading the file
[jira] Updated: (GERONIMO-2373) build broken with the removal of geronimo-j2ee_1.4_spec from the specs
[ http://issues.apache.org/jira/browse/GERONIMO-2373?page=all ] Bill Dudney updated GERONIMO-2373: -- Attachment: GERONIMO-2373.bdudney.patch Jason, please take a look when you get a chance and make sure I'm not doing anything crazy here. build broken with the removal of geronimo-j2ee_1.4_spec from the specs -- Key: GERONIMO-2373 URL: http://issues.apache.org/jira/browse/GERONIMO-2373 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Bill Dudney Attachments: GERONIMO-2373.bdudney.patch a couple of configs and applications have dependencies that are not correct as a result of the removal of geronimo-j2ee_1.4_spec. The attached patch addes the necessary dependencies. -- 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: One more build error on Windows
Hi Jacek, Just posted it, the build is once again successful for me. Sorry about the rar problem, what a pain! If you get a chance great, if not no worries. Deepak, would be great if you could try it out and let us know if it works for you. Thanks! -bd- On Sep 1, 2006, at 8:20 AM, Jacek Laskowski wrote: On 9/1/06, Bill Dudney [EMAIL PROTECTED] wrote: I think this is a bug in the build because of the removal of geronimo- j2ee_1.4_spec module. I filed a bug and will uploaded a patch shortly; http://issues.apache.org/jira/browse/GERONIMO-2373 Please try it and comment in the JIRA on success/failure. I'm too fast today as the patch is not yet there ;-) I won't be able to test it out as I'm struggling with another issue with the rar plugin that won't let me build Geronimo successfully. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: One more build error on Windows
Hi Jacek, No I used the -e flag for mvn and got a stack trace saying that javax/ jsp/something or other could not be found, which lead me to the investigation of dependencies and I noticed that the j2ee_1.4 module was gone (with a nice comment saying why) and so I figured the other dependencies that this module used to include were now needing explicit mention. Elementary my dear Watson ;-) TTFN, -bd- FTQI: http://tinyurl.com/q67mu On Sep 1, 2006, at 8:21 AM, Jacek Laskowski wrote: On 9/1/06, Bill Dudney [EMAIL PROTECTED] wrote: I think this is a bug in the build because of the removal of geronimo- j2ee_1.4_spec module. BTW, how did you find it out? Have you tried to compile the affected jspc-generated page and it came clear? Just curious... Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Tests for Console
Hi Jason, AFAIK you have to have the selenium stuff in the web app you are deploying. But that is something I was going to play with over the weekend. My approach was mirror what shale does; http://shale.apache.org/shale-apps/selenium.html But run the tests with the selenium server. TTFN, -bd- On Sep 1, 2006, at 3:24 PM, Jason Dillon wrote: I was able to finally get the simple GoogleTest example to run in Maven... some of the online docs are bunk, but if you download selenium-rc 0.8.1 those examples work better. Still need to automate starting, stopping the selenium server, which should happen when the G server is started stopped. I briefly took a whack at this and have something... though the Ant exec task buffers some output and ends up causing evil exceptions on shutdown... which I have no idea why. I may check in some of what I have into a new top-level testsuite module, so that we have a place to apply patches to. Does anyone know if we need to modify the webapps to include some special selenium fluff? --jason On 8/31/06, Bill Dudney [EMAIL PROTECTED] wrote: 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-2352) j2ee-builder test deployment modules won't actually deploy
[
http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431875
]
Bill Dudney commented on GERONIMO-2352:
---
Hi Jason,
Thanks for taking the time to review and apply the patch!
One quick comment: the lack of inheritance from parent was because of a problem
with the jspc-maven-plugin configuration. I kept getting errors
('...geronimo/test-deployables/test-ear-j2ee-1.3/war/target/jspweb.xml' does
not exist). I tried messing with the configuration but could not quickly get
the build to work so I dropped the parent reference. I forgot to circle back
around and work through that. Is it possible to remove or block a build plugin
that was inherited from a parent pom? There are no jsp's in these war files, as
a workaround though I could add one to each and make the war look like what the
jspc plugin expects.
Thanks again!
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_12431892 ] Bill Dudney commented on GERONIMO-2352: --- Hi Jeff, Thanks for helping with this. If I don't have a reference to the plugin in my war's pom.xml file the build fails with the lack of jspweb.xml file, if I put in a reference the build works, i.e. if I put this; build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjspc-maven-plugin/artifactId /plugin /plugins /build into the war module's pom file it builds fine, without that it fails. Shouldn't this be there by default once the parent reference is in place? Thanks again! 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_12431897 ] Bill Dudney commented on GERONIMO-2352: --- AFAIK I'm not overiding the configuration. There is no intent to overide it. If I copy the whole config out of the root pom the build works fine as well. 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-2368) Unable to create a (MySQL) database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2368?page=comments#action_12431899 ] Bill Dudney commented on GERONIMO-2368: --- similar problem trying to deploy 'Derby Embeded' datasource; 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.init(URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init(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:552) 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 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.init(URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init(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
Re: [VOTE] 1.1.1-rc1 for Release
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.init (URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init (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 at javax.security.jacc.URLPatternSpec.init (URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init (WebResourcePermission.java:47) at
[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
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
Re: M2 Build Error
Hi Lasantha, Could you post some more detail (stack trace from mvn -e) and I'd be glad to try to help. Also if you could relate what platform you are on that might also provide some hints to the problem. TTFN, -bd- On Aug 30, 2006, at 7:27 AM, Lasantha Ranaweera wrote: Hi All, Last few days I have been trying to build Geronimo from source code. I have been following the document Building Apache Geronimo with Maven 2 in Geronimo documentation. Every time build has failed when it tries to build OpenEJB Deployer component. It can't find out openejb - 2.2-SNAPSHOT related dependencies. Can anyone help me on this regard? :-\ Thanks, Lasantha Ranaweera
[jira] Updated: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=all ] Bill Dudney updated GERONIMO-2352: -- Attachment: GERONIMO-2352.bdudney.patch apply from root mvn clean install if all tests pass the patch worked (effects modules/gerionmo-j2ee-builder). 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 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: j2ee-builder tests?
Hi Jason,
On Aug 29, 2006, at 3:18 PM, Jason Dillon wrote:
On Aug 29, 2006, at 12:07 PM, Bill Dudney wrote:
1) The dependency plugin version 2.0-SNAPSHOT is all that appears
to work. I could not find a functional 1.0 version of this plugin.
I guess the question here is what is the community stance on using
snapshots of plugins for the build? If this is not OK we need to
get on the maven lists and try to get a released version of the
dependency plugin. I found a couple of posts on the maven lists
that make me hope that a 2.0 release is going to happen soon but I
don't follow the maven community that closely so I'm not sure.
We are already using 1.0 of the dependency plugin...
plugin
groupIdorg.codehaus.mojo/groupId
artifactIddependency-maven-plugin/artifactId
version1.0/version
/plugin
I was using maven-dependency-plugin and following the docs here;
http://maven.apache.org/plugins/maven-dependency-plugin/
introduction.html
changed to match what is in the other poms (org.codehaus.mojo) and
works fine.
2) The j2ee-builder tests use a 'naked' ear that has been stripped
of its geronimo-application.xml file. Easy enough to do with ant
and we can do it with maven as well I'm sure but I was hoping
you'd have some ideas about how to do it more simply that what I
was thinking. Here are my two ideas;
a) adopt an approach similar to the boilerplate-{j2ee,minimal} in
the assembly build
b) use something in the dependency plugin that can strip various
elements from a jar file
c) unpack it then repack with the geronimo-application.xml file
excluded
What else is in the ear? Sounds like a normal jar module would be
fine.
ear depends on war, rar ejb, so there is virtually nothing in the
ear, just the geroinmo-application.xml and application.xml.
I'll submit the patch we can mess with these changes later.
3) There are a couple of more testing bits in the geronimo-j2ee-
builder module. I'm not sure what the best way to remove them is.
a) src/test-plan - has some bad plan files that ensure that
failure happens when expected. I think these should be moved into
src/test/resources and used from there in the tests but wanted to
get your take.
b) src/test-unpacked-ear is another set of deployment descriptors
and plans used for both positive and negative tests. Again these
could/should probably be moved into the src/test/resources
directory (when its created until then it looks like src/test is
the destination)
Um... okay... no opinion on this right now.
K - I moved them and updated the tests to use the stuff from the new
location.
You can delete modules/geronimo-j2ee-modules/{test-ear, test-ear13,
test-plan, test-unpacked-ear} after the patch is applied.
TTFN,
-bd-
--jason
Re: windows build hell
I got rid of the OOME by putting MAVEN_OPTS=-Xmx512m into my ~/.mavenrc file TTFN, -bd- On Aug 30, 2006, at 2:04 PM, Hernan Cunico wrote: I had experienced all these errors, in addition, the one I get the most is an annoying out of mem error ... [DEBUG] Trace java.lang.OutOfMemoryError [INFO] -- [INFO] Total time: 38 seconds [INFO] Finished at: Wed Aug 30 15:50:06 EDT 2006 [INFO] Final Memory: 43M/63M [INFO] -- I tried to increase the mvn heap sz by adding to the command - DMAVEN_OPTS=-Xmx512m. It does not seem to work, any suggestions? Cheers! Hernan Joe Bohn wrote: We've been struggling with build problems on windows for some time now and things just keep on getting worse. I'm composing this note to summarize the problems that I'm aware of with work-arounds and possible solutions. I'm also fishing to see if anybody else has some ideas on how to resolve these issues. 1) Windows pathlength problem. Problem: There are miscellaneous failures that can typically be tracked down to the windows pathlength problem. The nature of our repository structure and deployment make this a big problem. It also seems like we're continuing to add more intermediate elements in path names as we try to get things more organized and conform to Maven 2 conventions. Work-around: The work-around is to keep the windows root path as small as possible. I now typically build from a root path of c:\g to avoid these problems. Possible Solution: For a longer term solution I'm planning to work on a new repository implementation in 1.2 that that isn't as redundant or verbose. 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. 3) Openejb2 test failures. Problem: Caused by: java.lang.NoSuchMethodException: org.openejb.deployment.DeploymentTestSuite.getName() Work-around: After bootstrap failure cd to root\target\external\openejb2 mvn -Dmaven.test.skip=true cd back to root mvn clean install Possible solution: Dain suggested adding the getName method to the test. However, when I attempted this I hit other errors. http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2 I think it would be helpful if we could disable the openejb tests until this problem is resolved. 4) Blue screen of death (bsod) Problem: This has been reported by multiple users on various machines. When running an M1 or M2 build the user encounters a bsod due to a memory failure. PAGE_FAULT_IN_NONPAGED_AREA *** STOP: 0x0050 (0xBADDB148, 0x, 0x8056C77B, 0x) Dump of physical memory Work-around/Possible Solution: Haven't found one yet. I've tried updated drivers, replaced hardware, tried various heap size settings, etc At times this can be fairly frequent (every 3rd build attempt or so). I'm collecting bootstrap.log files from folks when this happens during a bootstrap to see if there is a common thread. So far, with the bootstrap logs, it always seems to happen at about the same place: Running tests after building a module (usually tomcat.ApplicationTest or TomcatModuleBuilderTest) and the final lines in the log are always the Creation of an MBeanServer like this: [exec] Running org.apache.geronimo.tomcat.ApplicationTest [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1 Please respond to this note if you are seeing the bsod failures on windows. At first I thought this was just me and was hardware related. However, the more I talk to folks on windows the more I hear of other folks encountering this same problem. I've updated all drivers, replaced my entire system, and several other folks have reported seeing this on completely different systems. I think that pretty much rules out a hardware problem. ideas welcome! Joe
Re: j2ee-builder tests?
Hi Jason,
I have a patch ready for this but I wanted to run a couple of things
by you before submitting it.
1) The dependency plugin version 2.0-SNAPSHOT is all that appears to
work. I could not find a functional 1.0 version of this plugin. I
guess the question here is what is the community stance on using
snapshots of plugins for the build? If this is not OK we need to get
on the maven lists and try to get a released version of the
dependency plugin. I found a couple of posts on the maven lists that
make me hope that a 2.0 release is going to happen soon but I don't
follow the maven community that closely so I'm not sure.
2) The j2ee-builder tests use a 'naked' ear that has been stripped of
its geronimo-application.xml file. Easy enough to do with ant and we
can do it with maven as well I'm sure but I was hoping you'd have
some ideas about how to do it more simply that what I was thinking.
Here are my two ideas;
a) adopt an approach similar to the boilerplate-{j2ee,minimal} in
the assembly build
b) use something in the dependency plugin that can strip various
elements from a jar file
c) unpack it then repack with the geronimo-application.xml file
excluded
3) There are a couple of more testing bits in the geronimo-j2ee-
builder module. I'm not sure what the best way to remove them is.
a) src/test-plan - has some bad plan files that ensure that failure
happens when expected. I think these should be moved into src/test/
resources and used from there in the tests but wanted to get your take.
b) src/test-unpacked-ear is another set of deployment descriptors
and plans used for both positive and negative tests. Again these
could/should probably be moved into the src/test/resources directory
(when its created until then it looks like src/test is the destination)
after discussion ends on these questions I'll post the complete patch
to;
https://issues.apache.org/jira/browse/GERONIMO-2352
Thanks again,
-bd-
On Aug 28, 2006, at 9:56 PM, Jason Dillon wrote:
That is my preference.
--jason
On Aug 28, 2006, at 7:45 PM, Bill Dudney wrote:
Hi Jason,
If we don't care about a trail then its really easy.
I can do everything via a patch then and just delete the old stuff
from the j2ee-builder at the end.
Thanks,
-bd-
On Aug 28, 2006, at 5:13 PM, Jason Dillon wrote:
Hi Bill... I don't think that will work... since as soon as I
move them the build will start failing, as those bits are still
needed to run the geronimo-j2ee-builder tests.
I'm not really concerned about the paper trail that we get with
svn mv for these. I'd rather just svn add the new tree of
modules, delete the old bits and apply a patch to hook it up to
the build. Or a zip for the new modules and a patch for the
build changes is fine too.
--jason
On Aug 28, 2006, at 8:45 AM, Bill Dudney wrote:
Hi Jason,
Yes I made some progress. Not quite done as I ran into a
redeploy bug that I spent a bit of time poking at over the
weekend. I think the thing to do is to get the test stuff moved
over and then I'll experiment more with the redeploy bug.
From past experience patches generated by svn after an svn mv
are not the best. So I was thinking that you should move the
stuff around, then I'll submit a patch against the moved
content. Does that sound OK or is there a better way?
Once the move is complete I'll generate a patch that can be
applied to these bits to make them deploy and get rid of the
j2ee-builder pom and ant stuff that uses these. There are two
other test deployables (test-plan and test-unpacked-ear) that
I'd also like to move but I was thinking it would be better to
get this done first then move the other two.
Thanks,
-bd-
Here is the list of commands that will get us to the point of an
easy patch. Again I'm totally open to a better way if there is one.
svn mkdir test-deployables
svn mv modules/j2ee-builder/src/test-ear test-deployables/test-
ear-j2ee-1.4
svn mv modules/j2ee-builder/src/test-ear13 test-deployables/test-
ear-j2ee-1.3
svn ci -m 'initial move of test stuff'
cd test-deployables/test-ear-j2ee-1.4 (repeat from here down for
the test-ear-j2ee-1.3 as well)
svn mv test-ejb-ear ejb
svn mv test-rar rar
svn mv test-war war
svn mkdir ear/src/main/resources (these have to be done one at a
time AFAIK)
svn mv META-INF ear/src/main/resources
cd ejb
svn mkdir src/main/java
svn mkdir src/main/resources
svn mv org src/main/java
svn mv META-INF src/main/resources
cd ../rar
svn mkdir src/main/resources
svn mv META-INF src/main/resources
cd ../web
svn mkdir src/main/webapp
svn mv hello.txt src/main/webapp
svn mv WEB-INF src/main/webapp
svn ci -m moving the test stuff
On Aug 27, 2006, at 11:51 PM, Jason Dillon wrote:
Hiya Bill... didya happen to make any progress on this?
--jason
On Aug 25, 2006, at 1:28 PM, Bill Dudney wrote:
Hi Jason,
I'd be happy to do this. Do you have a direction yet
Re: j2ee-builder tests?
Hi Jason,
Yes I made some progress. Not quite done as I ran into a redeploy bug
that I spent a bit of time poking at over the weekend. I think the
thing to do is to get the test stuff moved over and then I'll
experiment more with the redeploy bug.
From past experience patches generated by svn after an svn mv are
not the best. So I was thinking that you should move the stuff
around, then I'll submit a patch against the moved content. Does that
sound OK or is there a better way?
Once the move is complete I'll generate a patch that can be applied
to these bits to make them deploy and get rid of the j2ee-builder pom
and ant stuff that uses these. There are two other test deployables
(test-plan and test-unpacked-ear) that I'd also like to move but I
was thinking it would be better to get this done first then move the
other two.
Thanks,
-bd-
Here is the list of commands that will get us to the point of an easy
patch. Again I'm totally open to a better way if there is one.
svn mkdir test-deployables
svn mv modules/j2ee-builder/src/test-ear test-deployables/test-ear-
j2ee-1.4
svn mv modules/j2ee-builder/src/test-ear13 test-deployables/test-ear-
j2ee-1.3
svn ci -m 'initial move of test stuff'
cd test-deployables/test-ear-j2ee-1.4 (repeat from here down for the
test-ear-j2ee-1.3 as well)
svn mv test-ejb-ear ejb
svn mv test-rar rar
svn mv test-war war
svn mkdir ear/src/main/resources (these have to be done one at a time
AFAIK)
svn mv META-INF ear/src/main/resources
cd ejb
svn mkdir src/main/java
svn mkdir src/main/resources
svn mv org src/main/java
svn mv META-INF src/main/resources
cd ../rar
svn mkdir src/main/resources
svn mv META-INF src/main/resources
cd ../web
svn mkdir src/main/webapp
svn mv hello.txt src/main/webapp
svn mv WEB-INF src/main/webapp
svn ci -m moving the test stuff
On Aug 27, 2006, at 11:51 PM, Jason Dillon wrote:
Hiya Bill... didya happen to make any progress on this?
--jason
On Aug 25, 2006, at 1:28 PM, Bill Dudney wrote:
Hi Jason,
I'd be happy to do this. Do you have a direction yet on the
movement of modules? This would probably best fit in something like
trunk/test-deployables/${module-name}
Does that sit well, or would you rather me put it into modules?
Then you can move it around when you move everything else.
TTFN,
-bd-
On Aug 25, 2006, at 1:54 PM, Jason Dillon wrote:
I think it would be good to turn those mock test apps into a set
of real m2 modules that build the j2ee deployables, then j2ee-
deployer can depend on them and not have to hack up its build to
generate them... and then those mock apps could be reused outside
of that module too... say to test the cli deployer and more.
You want to take a whack at this?
Should be easy enough... I'd like to use these mock apps instead
of converting all of those hacks to use the m2 standard layout
for j2ee-builder.
--jason
On Aug 23, 2006, at 3:59 PM, Bill Dudney wrote:
Hi All,
The tests in the j2ee-builder do not currently have valid
deployment descriptors. While that's ok for this module because
of the mocked out deployment bits I was hoping to use them in
other tests. I have most of the stuff fixed up but there are a
few things that I don't want to do without feedback.
1) there rar is empty, no jar's no xml in the deployment
descriptors its just a place holder. Thoughts on what to do with
that? cook up a simple rar? delete it? I lean towards making a
simple rar.
2) The web.xml references a bogus bunch of ejb's with refs like
'fake-ejb-ref'. Couple of things we could do with this, make
them point to valid ejb references in the ejb jar files that are
part of this ear or delete them. I would/could add some extra
EJB's to the ejb jar to make sure we covered all the reference
types.
3) This is less important but I'd like to change the
artifactId's so they are unique (i.e. test-ear-j2ee-1.{3,4}) so
that I can deploy both of the ear files when its all said and done.
4) I'm not sure exactly how to do this with ear/war/ejb-jar but
I'd like to have this module produce a 'tests' jar (we do this
in cayenne with simple junit tests so we can reuse it across
modules) and then reuse these deployment units in other
automated tests. I'm game to poke at it but figure I might get a
few of Jason's brain cells so I can be a bit lazier :-)
I posted this jira;
https://issues.apache.org/jira/browse/GERONIMO-2352
to track this issue.
Thanks!
-bd-
Re: [VOTE] Specs organization, versioning, and releasing
+1 to releasing them all as one version #.
It will make everyones life easier (dev's and users) having one # to
remember than many.
TTFN,
-bd-
On Aug 27, 2006, at 5:50 PM, Jason Dillon wrote:
I've implemented #5, which was to restructure to use the same
directory and artifactIds... I renamed the directories to match.
I think we need to have another round of discussion on how to handle
the versioning.
I'm starting to lean heavily towards having *one* version for *all* of
the specs. I don't care too much that if spec A makes a change that
we release new versions of all of the other specs. It is actually
similar to the server, when a bugfix release is made, a bunch of
modules will have no change since the last version, but we release
them anyways because it is simpler for use to manage, and easier for
users too, since they just need to know one version number... not the
version number of each module.
IMO, less version numbers to manage is easier... and better. The side
effect is that more artifacts get released when we cut a new version.
But I don't see that we are going to be making tons of these spec
releases... so I don't see any harm in the additional artifacts.
So, my recommendation is to use one version for all of them. I
believe this will be best in the short to medium term at least, and if
we find that it not working for the long run, then we can revisit
later. But right now I'd like to get a consistent release of these
artifacts so we can remove the need for the bootstrap step to check
them out and build them.
I'd like to discus for a few days, create a new proposal, vote and
then implement in the near future.
Comments?
--jason
On 8/18/06, Jason Dillon [EMAIL PROTECTED] wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid out
as follows:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
2. Each plugin will continue to have its own version and will be
released independently.
3. The top-level will have it's own version, which will remain
independent. When there is a major configuration change in that pom,
the version will be changed and the pom will be republished.
4. Releasing will be done with the maven release plugin ('mvn
release') and should occur at a stable point after any major change
to a spec module.
5. Change all module directories to match artifactIds.
MOTIVATION:
1. one trunk allows the entire set of specs to be checked out all at
once and built all at once.
* * *
[ ] +1 Allow changes
[ ] 0 No opinion
[ ] -1 No, leave the specs asis (provide rationale)
--jason
[jira] Closed: (GERONIMO-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=all ] Bill Dudney closed GERONIMO-2326. - Data sources deploy, finally! Thanks David. unable to deploy a database pool Key: GERONIMO-2326 URL: http://issues.apache.org/jira/browse/GERONIMO-2326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 1.1.2 Reporter: Bill Dudney Assigned To: David Jencks Fix For: 1.2, 1.1.2 Attachments: 2326-deploy-datasource.patch, GERONIMO-2326.bdudney-additional.patch, GERONIMO-2326.djencks-2.patch, GERONIMO-2326.djencks.patch Trying to deploy a jdbc datasource leads to a blank screen and the following stack trace in the log. The issue appears to be that URLPatternSpec does not like the URL generated by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES array. java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) 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.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) -- 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-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=comments#action_12430792 ] Bill Dudney commented on GERONIMO-2326: --- Hi David, Agreed that the real fix would be better but the trunk is not able to deploy a data source without this patch. Its not that big of a hack to move from 1.2 to 1.1. I'd rather see that than not be able to deploy a datasource. Thoughts? unable to deploy a database pool Key: GERONIMO-2326 URL: http://issues.apache.org/jira/browse/GERONIMO-2326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 1.1.2 Reporter: Bill Dudney Assigned To: David Jencks Fix For: 1.2, 1.1.2 Attachments: 2326-deploy-datasource.patch, GERONIMO-2326.bdudney-additional.patch, GERONIMO-2326.djencks-2.patch, GERONIMO-2326.djencks.patch Trying to deploy a jdbc datasource leads to a blank screen and the following stack trace in the log. The issue appears to be that URLPatternSpec does not like the URL generated by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES array. java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) 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.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) -- 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: Strange build error on trunk
FWIW, I just finished a fresh checkout and 'mvn install' without
error. No modifications of anything (I did not run the bootstrap
though to delete my ~/.m2/repo).
TTFN,
-bd-
On Aug 25, 2006, at 8:30 AM, Jeff Genender wrote:
I just released a new version 1.4.5-SNAPSHOT of the jspc plugin (just
now). I added the jasper-compiler-jdt. Please try this version
and let
me know if all works. If so I will start a vote at Mojo to release
1.4.5.
Thanks,
Jeff
Sergey Elin wrote:
It seems there is the wrong configuration for jspc-maven-plugin
1.4.4 in
maven 2: required dependency to jasper-compiler-jdt is missing.
I just add dependency to plugin's jspc-maven-plugin-1.4.4.pom and
successfully build geronimo-jsp-examples.
2006/8/25, Jason Dillon [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Can you send me to full `mvn -X` from the
applications/geronimo-examples/geronimo-jsp-examples plz.
--jason
On Aug 25, 2006, at 12:32 AM, Sergey Elin wrote:
Yes
2006/8/25, Jason Dillon [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Does this file actually have that class
(org/eclipse/jdt/internal/compiler/env/INameEnvironment):
/home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/
5.5.15/jasper-
compiler-jdt-5.5.15.jar
--jason
On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:
Here is a bit more info:
[INFO] [jspc:compile {execution: jspc}]
[DEBUG] execute() starting for 0 pages.
[DEBUG] Parent class loader is:
[EMAIL PROTECTED]
[DEBUG] Compilation classpath initialized:
/usr/home/cruz/java/geronimo/applications/geronimo-
examples/geronimo-jsp-examples/
target/jsp-source:/usr/home/cruz/java/geronimo/
applications/geronimo-examples/geronimo-jsp-examples/target/
classes:/home/cruz
/.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/
home/cruz/.m2/repository/taglibs/standard/1.1.1/
standard-1.1.1.jar:/
home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/
jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/
jasper-com
piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/
cruz/.m2/repository/org/apache/geronimo/specs/geronimo-
jsp_2.0_spec/1.0
.1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/
repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/
1.0.1/geroni
mo-servlet_2.4_spec-1.0.1.jar:
[DEBUG] No Java compiler available
java.lang.NoClassDefFoundError :
org/eclipse/jdt/internal/compiler/env/INameEnvironment
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:141)
at
org.apache.jasper.JspCompilationContext.createCompiler
(JspCompilationContext.java:233)
at
org.apache.jasper.JspCompilationContext.createCompiler
(JspCompilationContext.java:213)
at org.apache.jasper.JspC.processFile(JspC.java:
979)
at org.apache.jasper.JspC.execute (JspC.java:1135)
at org.codehaus.mojo.jspc.AbstractJspcMojo.execute(
AbstractJspcMojo.java:180)
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.executeGoalWith
Lifecycle(DefaultLifecycleExecutor.java
:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(DefaultLifecycleExecutor.java
:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndH
andleFailures(DefaultLifecycleExecutor.java
:306
)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegm
ents
(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
Re: j2ee-builder tests?
Hi Jason,
I'd be happy to do this. Do you have a direction yet on the movement
of modules? This would probably best fit in something like
trunk/test-deployables/${module-name}
Does that sit well, or would you rather me put it into modules? Then
you can move it around when you move everything else.
TTFN,
-bd-
On Aug 25, 2006, at 1:54 PM, Jason Dillon wrote:
I think it would be good to turn those mock test apps into a set of
real m2 modules that build the j2ee deployables, then j2ee-deployer
can depend on them and not have to hack up its build to generate
them... and then those mock apps could be reused outside of that
module too... say to test the cli deployer and more.
You want to take a whack at this?
Should be easy enough... I'd like to use these mock apps instead of
converting all of those hacks to use the m2 standard layout for
j2ee-builder.
--jason
On Aug 23, 2006, at 3:59 PM, Bill Dudney wrote:
Hi All,
The tests in the j2ee-builder do not currently have valid
deployment descriptors. While that's ok for this module because of
the mocked out deployment bits I was hoping to use them in other
tests. I have most of the stuff fixed up but there are a few
things that I don't want to do without feedback.
1) there rar is empty, no jar's no xml in the deployment
descriptors its just a place holder. Thoughts on what to do with
that? cook up a simple rar? delete it? I lean towards making a
simple rar.
2) The web.xml references a bogus bunch of ejb's with refs like
'fake-ejb-ref'. Couple of things we could do with this, make them
point to valid ejb references in the ejb jar files that are part
of this ear or delete them. I would/could add some extra EJB's to
the ejb jar to make sure we covered all the reference types.
3) This is less important but I'd like to change the artifactId's
so they are unique (i.e. test-ear-j2ee-1.{3,4}) so that I can
deploy both of the ear files when its all said and done.
4) I'm not sure exactly how to do this with ear/war/ejb-jar but
I'd like to have this module produce a 'tests' jar (we do this in
cayenne with simple junit tests so we can reuse it across modules)
and then reuse these deployment units in other automated tests.
I'm game to poke at it but figure I might get a few of Jason's
brain cells so I can be a bit lazier :-)
I posted this jira;
https://issues.apache.org/jira/browse/GERONIMO-2352
to track this issue.
Thanks!
-bd-
[jira] Created: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
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 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: j2ee-builder tests?
Hi David,
Agreed, externalized would be best. SVN diff produces such poor
patches though when there are directory moves involved that I
hesitate to attempt something like that. If its palatable I could
simply copy them and make a patch that adds the copies then someone
could delete them from the j2ee-builder directory once everyone is
happy with the new layout.
The particulars of how these problems are solved don't really matter
if we move them into a separate module either (which is great IMO)
since we would probably want to have all the options implemented in
several different ear's for integration tests.
Speaking of itests: what is the current status of that work. I recall
that a couple of folks were working on that and I was going to help
but I got side tracked with the dependency problems in the console.
I'm happy to help with it now as the console is working (see other
email about that).
Thanks,
-bd-
On Aug 24, 2006, at 12:29 PM, David Jencks wrote:
On a related note I've been creating a bunch of little m2 projects
to build apps to verify defects and their fixes. Usually you have
to look at the output to see if it passed. I've been attaching
these projects to the issues in question. I think we should
consider putting these in svn somewhere and if we can get the itest
plugin to run them that would be even better.
Not exactly the same situation as you have here but it seems
somewhat related. Anyway you might consider making an m2 project
to build this sample app.
thanks
david jencks
On Aug 23, 2006, at 6:59 PM, Bill Dudney wrote:
Hi All,
The tests in the j2ee-builder do not currently have valid
deployment descriptors. While that's ok for this module because of
the mocked out deployment bits I was hoping to use them in other
tests. I have most of the stuff fixed up but there are a few
things that I don't want to do without feedback.
1) there rar is empty, no jar's no xml in the deployment
descriptors its just a place holder. Thoughts on what to do with
that? cook up a simple rar? delete it? I lean towards making a
simple rar.
2) The web.xml references a bogus bunch of ejb's with refs like
'fake-ejb-ref'. Couple of things we could do with this, make them
point to valid ejb references in the ejb jar files that are part
of this ear or delete them. I would/could add some extra EJB's to
the ejb jar to make sure we covered all the reference types.
3) This is less important but I'd like to change the artifactId's
so they are unique (i.e. test-ear-j2ee-1.{3,4}) so that I can
deploy both of the ear files when its all said and done.
4) I'm not sure exactly how to do this with ear/war/ejb-jar but
I'd like to have this module produce a 'tests' jar (we do this in
cayenne with simple junit tests so we can reuse it across modules)
and then reuse these deployment units in other automated tests.
I'm game to poke at it but figure I might get a few of Jason's
brain cells so I can be a bit lazier :-)
I posted this jira;
https://issues.apache.org/jira/browse/GERONIMO-2352
to track this issue.
Thanks!
-bd-
Re: m2 build - validating
Hi All, Update on this, 1 - 3 are done and everything I found has been patched with these JIRA's https://issues.apache.org/jira/browse/GERONIMO-2326 (final patch from djencks did the charm) https://issues.apache.org/jira/browse/GERONIMO-2344 https://issues.apache.org/jira/browse/GERONIMO-2346 https://issues.apache.org/jira/browse/GERONIMO-2347 I've not started on daytrader just yet will do that soon though. Thanks! -bd- On Aug 16, 2006, at 5:33 PM, Bill Dudney wrote: Hi All, i've been using the m2 build for several days now and I've noticed that while it works well there are several details that are still not nailed down. Particularly I've been hitting lots of dependency issues around deployment. So what I've started doing is slogging through each of them one at a time, posting a jira and a patch. It struck me that there are probably similar issues throughout the server WRT the m2 build. I'm open to other methods (and would love to hear of a silver bullet:) but seems to me that we need to basically hit everything in the console and tools and such and make sure it works so we can be sure the dependencies are correct. While I don't think I'll be able to hit 'everything' I'll try to poke on most of the console and the CLI tools and make sure that it 'works'. My plan of attack: 1 - provide patches for the stuff i know about now (tranql/tranql- connector is missing for example from the repository) 2 - finish getting deployment working from the console (data sources, ejb-jar's, wars etc) 3 - poke on the rest of the console 4 - deploy daytrader 5 - anything else anyone comes up with I will be posting bunches of jira's and fixes over the next few days as I work through this stuff (unless someone has a better idea about how to tackle it). TTFN, -bd-
Re: building eclipse projects with M2 build
Hey Jacek, When its happened to me its been because the pom or jar only partially download or some other such bad behavior. Since this simple fix makes it work I've not looked any further. I don't see anyway the bootstrap could be causing this since the bootstrap is simply deleting the .m2/repository directory and then invoking maven. TTFN, -bd- On Aug 23, 2006, at 1:28 PM, Jacek Laskowski wrote: On 8/23/06, Jeff Genender [EMAIL PROTECTED] wrote: Joe, Delete your ~/.m2/repository/org/apache/maven/plugins directory. The error you encountered usually means you have a corrupted meta tags. This solution usually does teh trick for me. It did for me, too, but it's weird. I think it may have happened every time bootstrap.sh is used. It's just a wild guess, but it happened to me once I had built Geronimo with the new build procedure. I think we need to check it out before we rule it out as a possible cause. Is there anyone who has never built Geronimo before and has been wondering when exactly give it a shot? It's time now! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
j2ee-builder tests?
Hi All,
The tests in the j2ee-builder do not currently have valid deployment
descriptors. While that's ok for this module because of the mocked
out deployment bits I was hoping to use them in other tests. I have
most of the stuff fixed up but there are a few things that I don't
want to do without feedback.
1) there rar is empty, no jar's no xml in the deployment descriptors
its just a place holder. Thoughts on what to do with that? cook up a
simple rar? delete it? I lean towards making a simple rar.
2) The web.xml references a bogus bunch of ejb's with refs like 'fake-
ejb-ref'. Couple of things we could do with this, make them point to
valid ejb references in the ejb jar files that are part of this ear
or delete them. I would/could add some extra EJB's to the ejb jar to
make sure we covered all the reference types.
3) This is less important but I'd like to change the artifactId's so
they are unique (i.e. test-ear-j2ee-1.{3,4}) so that I can deploy
both of the ear files when its all said and done.
4) I'm not sure exactly how to do this with ear/war/ejb-jar but I'd
like to have this module produce a 'tests' jar (we do this in cayenne
with simple junit tests so we can reuse it across modules) and then
reuse these deployment units in other automated tests. I'm game to
poke at it but figure I might get a few of Jason's brain cells so I
can be a bit lazier :-)
I posted this jira;
https://issues.apache.org/jira/browse/GERONIMO-2352
to track this issue.
Thanks!
-bd-
[jira] Commented: (GERONIMO-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=comments#action_12429715 ] Bill Dudney commented on GERONIMO-2326: --- The GERONIMO-2326.djencks-2.patch patch fixes tomcat as well for all 4 derby configs (embeded, network, xa-embeded, xa-network). unable to deploy a database pool Key: GERONIMO-2326 URL: http://issues.apache.org/jira/browse/GERONIMO-2326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 1.1.2 Reporter: Bill Dudney Assigned To: David Jencks Fix For: 1.1.2, 1.2 Attachments: 2326-deploy-datasource.patch, GERONIMO-2326.djencks-2.patch, GERONIMO-2326.djencks.patch Trying to deploy a jdbc datasource leads to a blank screen and the following stack trace in the log. The issue appears to be that URLPatternSpec does not like the URL generated by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES array. java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) 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.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) -- 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-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=all ] Bill Dudney updated GERONIMO-2326: -- Attachment: GERONIMO-2326.bdudney-additional.patch sorry got a bit ahead of myself, I also had to apply this patch to the root pom to get the 1.1 version of the tranql/tranql-connector/rar. The 1.1. version is refered to explicitly by the DatabaseInfo class, perhaps David you had copied the 1.1. version into your geronimo repo? The real solution is to copy the changes that have been made in the 1.1 branch for the console to the trunk. unable to deploy a database pool Key: GERONIMO-2326 URL: http://issues.apache.org/jira/browse/GERONIMO-2326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 1.1.2 Reporter: Bill Dudney Assigned To: David Jencks Fix For: 1.1.2, 1.2 Attachments: 2326-deploy-datasource.patch, GERONIMO-2326.bdudney-additional.patch, GERONIMO-2326.djencks-2.patch, GERONIMO-2326.djencks.patch Trying to deploy a jdbc datasource leads to a blank screen and the following stack trace in the log. The issue appears to be that URLPatternSpec does not like the URL generated by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES array. java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) 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.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) -- 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
