Re: [announce] Apache Geronimo welcomes Joe Bohn as our newest committer
Thank you all for your most gracious welcome. I'm both honored and humbled to be working with such a talented group of developers. I'll do my best to try to keep up with all of you! :-) Joe Sachin Patel wrote: In recognition of his contributions to the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Joe Bohn. Joe has contributed in many areas, including the console and as of recent, the work on our minimal distributions. His work shows initiative, concern to get user feedback, empathy for problems faced by other committers and willingness to work on fixing these problems. We look forward to his continued involvement as a committer. Please join us in congratulating Joe. The Apache Geronimo PMC -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
+1 Joe Matt Hogstrom wrote: The corrections applied due to license files are first in this list. Thanks to John for dogging this. The distributions and builds were not affected. Based on previous feedback the vote continues. Thanks for your feedback. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2.1_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2.1_src.zip John noted that the source zip had a META-INF. I've created a script to use in the future because with so many changes forgetting to use zip and typing jar is not acceptable. Also, note that the build itself has the LICENSE and NOTICES in two different places. The are located in modules/scripts/src/main/resources/ which put the right files in the distributions however they werenot correctly specified for source as the LICENSE and NOTICES are part of the source tree. After this release we need to address this issue so as to avoid manual problems like this. *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.1.tar.gz http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.1.zip Corrected LICENSE and NOTICES files. Use zip rather than jar to create zip. *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.1.ear Corrected LICENSE and NOTICE files in ear. John, whats the correct command to set the properties? Or, would you like to address these? No changes to the below files. *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Deploying a duplication application
I've noticed some problems (and differences between our Tomcat and Jetty assemblies) when attempting to deploy the same application more than once without a plan (hence using a generated version). What are the expected results when this is done either by accident or deliberately to install a newer version of an application? My thinking is that we should do 1 of 2 things: 1) warn the user that they are attempting to deploy another version and require some type of confirmation before proceeding. 2) deploy so long as it is a newer version and ensure that the newest version is the one that we start/run. I assume that if it is an older version we should always fail the deploy and warn the user but I guess that's just a matter of opinion as well. I haven't tried this scenario but my guess is that we don't currently do any version checking at all and would get the same results that I'm seeing with newer versions. Here is what I'm observing: Jetty: - The second deploy succeeds without error. All instances of the deployed application are marked as running when viewed either in the web console of via the list-modules command and all share the same url. It's not clear to me which instance of the application is actually servicing the requests. Both the command line and the web console deploy result in messages indicating that the application was successfully deployed. Tomcat: - The second deploy fails with a NPE on the server. I've opened http://issues.apache.org/jira/browse/GERONIMO-1700 for this problem. When doing the deploy from the command line, a number of exceptions are displayed to the user (life-cycle exception, Illegal arg exception on doStart, etc...). When doing the deployment from the web console the typical success message is returned with no mention of any errors. The net result in the system is that multiple instances of the application are deployed but only the original is started and running. Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Lets start moving to m2
I'll jump on that band wagon too. My m1 build on trunk works (or at least it does with my image from a few days ago). I'm going to give m2 a try later today, but would prefer to know that I have at least one way to build geronimo until the m2 build changes are complete. Joe anita kulshreshtha wrote: I agree. As of today M2 build requires building xmlbeans plugin, fixing xbeans pom and building spec jars. This is not the best way to introduce users to a new build system. Thanks Anita --- Jacek Laskowski [EMAIL PROTECTED] wrote: On 6/28/06, Matt Hogstrom [EMAIL PROTECTED] wrote: -1 on removing M1 until M2 is working. I second that. No need to rush to M2 until it's fully workable solution. We may not break trunk only because few of us want to move to M2 whereas others might want to look into other areas, but be unable to work on them. Jacek -- Jacek Laskowski http://www.laskowski.net.pl __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: [jira] Commented: (GERONIMO-1674) Daytrader gets NullPointerException attempting to log in a user
Thanks for your response Chris. So are you saying that even the defaults for Daytrader are insufficient? What's confusing is that it always returns a login error even though it appears that login succeeds and this is really related to the initial display(s). I get the same error if I select Trade Portfolios and then log in. I also noticed that even if I return the settings to the defaults of 50 users and 100 max quotes I still get the error. You are correct that making the max quotes 1000 resolves the problem. So, I guess the next question is what needs to change?. It seems that we should not ship the sample with default values that don't work well with the application. We also should not allow the user to set values that can cause a failure. However, I'm not clear if the correct fix should be changing the defaults (and validating settings to ensure they are not too small) or changing the display code to deal with the range of values that can be set. What is the recommendation of the Daytrader experts? Joe Christopher Blythe wrote: Joe... I've worked on Trade for quite some time and am slowly starting to dig into DayTrader. Anyway, just wanted to respond to your question since I think I know what the problem is. In order for the MarketSummary to be display, at least 200 quotes need to be populated in the database. If you look at the queries the MarketSummary uses (either the EJBQL or SQL in TradeDirect.java) you will see something like this... ejb-qlSELECT OBJECT(q) FROM Quote q WHERE q.symbol LIKE 's:1__' ORDER BY q.change DESC/ejb-ql This indicates that the MarketSummary needs quotes between 100 and 199. If we are only populating 10 quotes by default, this query will return 0 results and I imagine the MarketSummary will throw an exception (as indicated by the stack traces). To get you up and running, I would re-populate your database with at least 200 quotes. The default for Trade was actually 1000. I also suggest that the default be changed from 10 to something more realistic for performance testing ( i.e. 1000 or even higher). Hope this helps... Chris Blythe On 6/27/06, *Joe Bohn (JIRA)* dev@geronimo.apache.org mailto:dev@geronimo.apache.org wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1674?page=comments#action_12418036 ] Joe Bohn commented on GERONIMO-1674: I still get this error. I get it with tomcat as well as jetty. I think I may very well be doing something wrong. Here is my scenario after successfully deploying daytrader. 1) select configuration-configure Daytrader runtime paramenters ... and change the max users and max quotes to 10 each. Note, I'm not really running daytrader for performance stats ... I was just using it to verify geronimo functions after making some substantial changes as a way to verify that I hadn't broken things too radically. 2) from confirguration select (Re)-populate Daytrader Database. This appears to be successful. 3) Next, from under Configuration utilities I select Test DayTrader Scenario and I get this attached exception. It does seem strange that if I do this a number of time eventually things seem to start working. Here is another stack trace (unfortunately from jetty again but I do get it with tomcat as well) from a recent attempt on 1.1. ## Trade configuration update. Current config: RunTimeMode:Direct OrderProcessingMode:Synchronous AcessMode: Standard Workload Mix: Standard Web Interface: JSP CachingType:No Caching #Trade Users: 10 #Trade Quotes: 10 Long Run Enabled: true 10:47:43,984 ERROR [Log] Error: TradeDirect:login -- error logging in user java.lang.NullPointerException java.lang.NullPointerException at org.apache.geronimo.samples.daytrader.util.FinancialUtils.computeGainPercent(FinancialUtils.java:43) at org.apache.geronimo.samples.daytrader.MarketSummaryDataBean .init(MarketSummaryDataBean.java:54) at org.apache.geronimo.samples.daytrader.direct.TradeDirect.getMarketSummary(TradeDirect.java:152) at org.apache.geronimo.samples.daytrader.TradeAction.getMarketSummary (TradeAction.java:100) at jsp.marketSummary_jsp._jspService(marketSummary_jsp.java:55) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service (HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428
Re: [M2 build] : Error building application uddi-db on XP
of the build plz.
--jason
On Jul 11, 2006, at 7:15 AM, Prasad Kashyap wrote:
Nope. No such luck. I deleted the entire applications
dir. I
also
deleted the o.a.g.applications group from the local
repo.
I then
did
an 'svn update' from top level geronimo dir. I
rebuilt the
bootstrap
stage and then the assembly stage. Same problem.
Cheers
Prasad
On 7/10/06, Jason Dillon [EMAIL PROTECTED] wrote:
The uddi-db module should be buildable now since
#420661
Give it a whirl and let me know if you run into
anything
else.
--jason
On Jul 10, 2006, at 4:28 PM, Jason Dillon wrote:
It appears that the uddi-db module should *NOT*
have
any
webapp
stuff, but only the derby database files.
So, unless someone can shed some light onto why
the db
module
has
webapp files in it, I'm going to remove them.
--jason
On Jul 10, 2006, at 4:15 PM, Jason Dillon wrote:
Why are the uddi-* webapp files duplicated in
the -
server
and -db
modules?
snip
uddi-db/src
uddi-db/src/sql
uddi-db/src/sql/juddi.sql
uddi-db/src/webapp
uddi-db/src/webapp/happyjuddi.jsp
uddi-db/src/webapp/WEB-INF
uddi-db/src/webapp/WEB-INF/juddi.properties
uddi-db/src/webapp/WEB-INF/web.xml
uddi-server/src
uddi-server/src/webapp
uddi-server/src/webapp/happyjuddi.jsp
uddi-server/src/webapp/WEB-INF
uddi-server/src/webapp/WEB-INF/juddi.properties
uddi-server/src/webapp/WEB-INF/web.xml
/snip
--jason
On Jul 10, 2006, at 5:12 AM, Prasad Kashyap wrote:
Seeing this error on Windows XP only. Unable to
recreate
it on
Linux.
I am trying to build the trunk using m2. I began
with a
clean
repo and
did a fresh checkout.
I executed build.bat and it ran the bootstrap
stage.
Then I
executed
build.bat -Dstage=assembly
-Dmaven.test.skip=true.
It failed while trying to build applications/
uddi-db
with the
following error
---
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db
\target
\resources
\META-INF\geronimo-uddi-db\var\derby
[mkdir] Created dir:
C:\Apache\geronimo\trunk\applications\uddi-db
\target
\resources
\META-INF\geronimo-uddi-db\var\derby
[sql] Executing file:
C:\Apache\geronimo\trunk\applications\uddi-db
\src\sql
\juddi.sql
[sql] 87 of 87 SQL statements executed
successfully
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered
resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [jspc:compile {execution: jspc}]
[INFO] Built File: \happyjuddi.jsp
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db
\taget
\resources
\META-INF\geronimo-uddi-db\var\derby
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: Unable to delete file
C:\Apache\geronimo\trunk\applications\uddi-db
\target
\resources
\META-INF\geronimo-uddi-db\var\derby\UddiDatabase
\db.lck
[INFO]
[INFO] For more information, run Maven with
the -e
switch
[INFO]
[INFO] Total time: 1 minute 36 seconds
[INFO] Finished at: Mon Jul 10 07:47:20 EDT 2006
[INFO] Final Memory: 28M/51M
-
It is trying to execute the antrun plugin in the
applications/uddi-db/pom.xml a second time when
the
error
occurs.
Cheers
Prasad
mvn.log
comment-examples-configs.patch
--
Joe Bohn
joe.bohn at earthlink.net
He
Re: Proposal: Improve runtime integration with tooling (All non-eclipse users please read)
Looks good to me Sachin (at least for those items that I understand). The Geronimo runtime requirement to support deployment of modules that don't comply with the specification (because of the IDE structure) sounds like it will be challenging. Just a few comments/questions: - Is this a roadmap for multiple releases or what you think is needed in the next release? If it's a roadmap for multiple release it would be helpful if these were indicated (or perhaps just a simple breakdown of r1.2 and anything else as future). - Can we include an item to support a little-G assemblies via the plugin in the future? - Rather than one catch-all item to support the deployment plan editors, these should probably be listed individually. I suspect they will most likely be implemented individually. Also, are you thinking of these as wizard-like capabilities really just editors? - What are your thoughts about providing a mechanism to query available elements that are already deployed in the server for the purpose of offering the users lists of potential dependencies when building the plans. Building the plans using wizards were facilitate such features but this probably isn't feasible with just editor support. - I recall that Paul had mentioned the desire to include the ability to generate a plugin from the tooling. Should this be added to the list? Joe Sachin Patel wrote: I've started a development roadmap on the Wiki for the eclipse-plugin. http://cwiki.apache.org/confluence/display/GMOxDOC11/Geronimo+Eclipse+Plugin+-+Development+Roadmap In the last section, is a section entitled Geronimo Runtime Requirements. The problem mentioned in the proposal is already being seen by users with a large project set, and I feel is an important problem that needs to be solved so that we can improve our development experience for our users. So I ask If everyone could take a moment and take a look at the feature request in this section and provide feedback, concerns, and or possible solutions, it would be greatly appreciated. Thank you. -sachin -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Need help on classloading related problem(What is shared/lib in Apache Geronimo)
Hi Sunil, In Geronimo 1.1 you can add a jar to a shared library in Geronimo by doing the following: - Add your jars into this location: geronimo-install-root/var/shared/lib - Add the following dependency into your geronimo deployment plan: environment dependencies dependency groupIdgeronimo/groupId artifactIdsharedlib/artifactId /dependency /dependencies /environment The sharedlib support is new in Geronimo 1.1. HTH, Joe sunil patil wrote: Hi, I am trying to install Pluto 1.1 portal server into Geronimo. Till now i am able to get About and Admin portlets working. Both these portlets are part of pluto.war. Now i am facing one classloader related problem when i try to install HelloWorld Portlet in HelloWorld.war (Separate war). *Basic Problem* - I have A.war and B.war they depend on Class1 which is part of 1.jar. What i want is A.war should create object of Class1 and that object should be accessible to class in B.war so where should i put 1.jar and how should i configure both A.war and B.war so that they will be able to look at this class. *Detailed Description -* Thing is Pluto portlet has PortalDriverServlet which is controller servlet and is shipped with Pluto.war. When it gets request for HelloWorldportlet it wraps that request in object of RenderRequestImpl.java which is in pluto-container-1.1.0-dev.jar and sets is as request parameter and passes control to HelloWorldPortlet. Now HelloWOrldPortlet uses PlutoServlet.java class for handling request and this is again part of pluto-container-1.1.0-dev.jar. When PlutoServlet tries to get object of RenderRequestImpl.java from request it throws ClassCastException because both of them have different class loader. Till now i tried to 1) Create pluto in repository folder containing pluto-container-1.1.0-dev.jar and add dependencies from both pluto.war and HelloWorldPortlet.war on pluto repository. But in that case i get ClasscastException. 2) I tried copying all jars in Geronimo_Base/lib and removed dependencies but that does not work either 3) I tried copying all jars in Geronimo_Base/repository/geronimo/jars and that does not work. Can you please let me know what is equivalent of shared/lib in Geronimo. Place where i could copy jars used by more than one application Thank You Sunil
Re: Geronimo Startup Error
Michael, Before you open a JIRA can you please double check this? I just downloaded both of those files and extracted them using winzip. The empty directories were created. I've also noticed that when I copy an image I need to be careful to ensure the empty directories are included in the copy. For example, xcopy * /s won't include the empty directories so you must use the /e option. I'm not sure if that's what happened on your system but it's happened to me before. Joe Jason Dillon wrote: Looks like its an oversight... can you please file an issue in Jira: http://issues.apache.org/jira/browse/GERONIMO Zip can sometimes (annoyingly omit empty directories)... we will have to put in placeholders to prevent this lame behavior. Anyways, its an easy fix we can get in for 1.1.1 --jason On Jul 15, 2006, at 5:25 PM, Michael Malgeri wrote: I created empty directories for var\shared\classes and var\shared\lib and the server started up and I was able to log on and access the console and poke around. I didn't run any other tests like deploying apps, etc. I didn't see this in the install notes. Is there a problem with the distribution bundles or did I install incorrectly? Michael Malgeri Technical Services Manager PHONE: 310-727-4544 Tie Line: 286-4544 CELLULAR: 310-704-6403 *Michael Malgeri/Los Angeles/IBM* 07/15/2006 05:19 PM To dev@geronimo.apache.org mailto:dev@geronimo.apache.org cc Subject Geronimo Startup Error Hi, I downloaded geronimo-tomcat-j2ee-1.1.zip for Windows, ran the startup script and got the following error: [*** ] 70% 20s Loading geronimo/sharedlib/1.1/car 17:07:15,3 41 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/sharedlib/1.1/car?ServiceModule=geronimo/sharedlib/1.1/car,j2eeType=GBean,name=SharedLib java.lang.IllegalArgumentException: Classes dir does not exist: C:\AppServers\geronimo-1.1\var\shared\classes There's no ..\geronimo-1.1\var\shared\classes directory in the distribution Got the same error with Little-G Michael Malgeri Technical Services Manager PHONE: 310-727-4544 Tie Line: 286-4544 CELLULAR: 310-704-6403
Re: [jira] Updated: (GERONIMO-1182) Connector portlet delete challenge
I still have to track down (with infra@ I suppose) why I am the silent committer. For some reason my changes aren't showing up on the svn commit list even though I've verified that they are in fact making it into the svn repo. Joe Jason Dillon wrote: Where is thew SVN commit mail for this? --jason On 7/24/06, Joe Bohn (JIRA) dev@geronimo.apache.org wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1182?page=all ] Joe Bohn updated GERONIMO-1182: --- Fix Version/s: 1.2 Applied patch to trunk (had to override module names to conform to new structure for console in trunk) Sending applications\console\console-standard\src\java\org\apache\geronimo\console\webmanager\ConnectorPortlet.java Sending applications\console\console-standard\src\webapp\WEB-INF\view\webmanager\connector\editHTTP.jsp Sending applications\console\console-standard\src\webapp\WEB-INF\view\webmanager\connector\editHTTPS.jsp Sending applications\console\console-standard\src\webapp\WEB-INF\view\webmanager\connector\normal.jsp Transmitting file data Committed revision 425198. Connector portlet delete challenge -- Key: GERONIMO-1182 URL: http://issues.apache.org/jira/browse/GERONIMO-1182 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Assigned To: Joe Bohn Priority: Minor Fix For: 1.2, 1.1.1 Attachments: GERONIMO-1182-1.1.1.patch, GERONIMO-1182-1.patch, GERONIMO-1182.patch Minor improvements to Connector portlet. 1. User confirmation on clicking delete link to delete a connector. 2. Add Reset and Cancel buttons to edit pages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Is SingleFileHotDeployer still used?
Yes, it is still used. I know of at least one user that is using SingleFileHotDeploy. In an earlier thread on the subject, Dain mentioned that this would be replaced with a new Hot Deploy implementation in 1.2. AFAIK that new implementation has not yet been created. Also, the current Hot Deploy (while providing much more capability than SFHD) doesn't cover at least one scenario that I understand is being used: forcing a deployment of the application on each server restart without regard to application changes. Joe John Sisson wrote: Is 1.1\modules\deployment\src\java\org\apache\geronimo\deployment\SingleFileHotDeployer.java still used? I can see anything referencing it except for some tests. It was added in April 2006 by Dain in http://svn.apache.org/viewcvs?rev=397307view=rev What is its relationship to the org.apache.geronimo.deployment.hot.DirectoryHotDeployer used in the hot-deployer-config? There were a number of issues with a fix version of 1.1 referencing the SingleFileHotDeployer so it seems like it is/was used: http://issues.apache.org/jira/browse/GERONIMO-1946 http://issues.apache.org/jira/browse/GERONIMO-1962 http://issues.apache.org/jira/browse/GERONIMO-2036 Thanks, John
1.1 keystore portlet bugs patches
I was looking to see what else we need to get fixed in 1.1.1 and noticed that there are several issues (in both 1.1 and 1.1.1) around the keystore portlet. I know nothing about the keystore portlet and thought I'd check here (esp. with Aaron) before I started looking into the patches that Vamsi has provided. It appears that this is a real problem spot (esp. given my initial experiment ... see below), so I'm hoping that the patch from Vamsi works wonders :-) . It seems like there are a number of issues (1196, 1531, 1984, and 2218) which have all been grouped with one fix under 2218. Some of these sound like enhancements to me but since they appear to be addressing function that was previously available in 1.0 but dropped from the updated keystore portlet I assume they could be considered bug fixes. Comments? While just trying to get familiar with the keystore portlet as it currently stands (w/o the 2218 patch) I managed to get serialization errors that then reappeared each time I attempted to stop the server (even with no additional changes). I also managed to get the jetty server into a state where it could not start with just two clicks of the mouse from the portlet (one on the unlocked icon under Available for the geronimo-default keystore and then a second click on then locked icon attempting to undo what I did with the first click). The result was the following set of stack traces on server restart (kinda funny how it wants me to unlock the keystore using the console when the server itself won't even start). Joe Booting Geronimo Kernel (in Java 1.4.2_08)... Starting Geronimo Application Server v1.1.1-SNAPSHOT [*] 43% 8s Starting geronimo/jetty/1.1.1-SNA...10:27:12,640 WARN [SslListener] EXCEPTION org.apache.geronimo.management.geronimo.KeystoreIsLocked: Keystore 'geronimo-default' is locked; please use the keystore page in the admin console to unlock it at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:300) at org.apache.geronimo.security.keystore.FileKeystoreManager$$FastClassByCGLIB$$4d9d2a71.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:817) 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.geronimo.management.geronimo.KeystoreManager$$EnhancerByCGLIB$$be50f1ec.createSSLServerFactory(generated) at org.apache.geronimo.jetty.connector.GeronimoSSLListener.createFactory(GeronimoSSLListener.java:41) at org.mortbay.http.SslListener.newServerSocket(SslListener.java:283) at org.mortbay.util.ThreadedServer.open(ThreadedServer.java:477) at org.apache.geronimo.jetty.connector.JettyConnector.doStart(JettyConnector.java:233) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
Re: 1.1 keystore portlet bugs patches
(GBeanInstance.java:548) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:548) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:548) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:310) at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668) at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645) at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:245) Server shutdown completed Aaron Mulder wrote: On 7/26/06, Joe Bohn [EMAIL PROTECTED] wrote: I was looking to see what else we need to get fixed in 1.1.1 and noticed that there are several issues (in both 1.1 and 1.1.1) around the keystore portlet. I know nothing about the keystore portlet and thought I'd check here (esp. with Aaron) before I started looking into the patches that Vamsi has provided. It appears that this is a real problem spot (esp. given my initial experiment ... see below), so I'm hoping that the patch from Vamsi works wonders :-) . It seems like there are a number of issues (1196, 1531, 1984, and 2218) which have all been grouped with one fix under 2218. Some of these sound like enhancements to me but since they appear to be addressing function that was previously available in 1.0 but dropped from the updated keystore portlet I assume they could be considered bug fixes. Comments? While I don't agree with your logic, I'm happy to consider this a bug fix, because that way some improvements might actually be applied. While just trying to get familiar with the keystore portlet as it currently stands (w/o the 2218 patch) I managed to get serialization errors that then reappeared each time I attempted to stop the server (even with no additional changes). I also managed to get the jetty server into a state where it could not start with just two clicks of the mouse from the portlet (one on the unlocked icon under Available for the geronimo-default keystore and then a second click on then locked icon attempting to undo what I did with the first click). The result was the following set of stack traces on server restart (kinda funny how it wants me to unlock the keystore using the console when the server itself won't even start). It is unfortunate that you can hose the server this way. But it's correct that the HTTPS connectors shouldn't start if they lack a correctly configured keystore. I think the best solution would be for the server to start up without HTTPS enabled, but that's a much larger conversation (there was a decision made in 1.1 to bail on startup if any GBean fails to start, and I'm not sure I agree). If the patch in question changes the startup failure if the keystore is locked, can you explain how it does it? For now, it might be best to have a confirm popup or screen if you lock a keystore that's currently in use by a web connector, though that's not a very scalable solution once things like CORBA (and perhaps EJB) start using these keystores too. Thanks, Aaron Joe Booting Geronimo Kernel (in Java 1.4.2_08)... Starting Geronimo Application Server v1.1.1-SNAPSHOT [*] 43% 8s Starting geronimo/jetty/1.1.1-SNA...10:27:12,640 WARN [SslListener] EXCEPTION org.apache.geronimo.management.geronimo.KeystoreIsLocked: Keystore 'geronimo-default' is locked; please use the keystore page in the admin console to unlock it at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:300) at org.apache.geronimo.security.keystore.FileKeystoreManager$$FastClassByCGLIB$$4d9d2a71.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:817) 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.geronimo.management.geronimo.KeystoreManager$$EnhancerByCGLIB
Re: 1.1 keystore portlet bugs patches
Aaron, Once again, thanks for the comments. Some more responses inline. I also renumbered the items to avoid the duplicate #2's ... sorry for the confusion. Aaron Mulder wrote: On 7/26/06, Joe Bohn [EMAIL PROTECTED] wrote: I think I understand your goals here Vamsi. However, I'm not sure that the portlet (as it currently stands) is a net positive or negative for Geronimo, even with your changes. It's not a matter of stress tests. It looks like basic function tests (unit tests) aren't working with this portlet. I don't fully understand the function of this portlet and perhaps that is clouding my judgment. Here's a list of the problems that I'm seeing (not necessarily complete): 1) You can hose the jetty server with one simple mouse click on the available lock icon. Even if we provided a warning prior to taking any action, it is still not a safe situation. There was a comment on the dev list just before 1.1 went out that this could be fixed by setting load=false on the SSLConnector and making the keystore available after server restart ... then restarting with the SSLConnector loaded again. However, even after doing this the next restart of the server still fails with the same error even though the console shows the keystore as available. I think this is a critical problem (see earlier post for one proposal on how to fix this by requiring the password). 2) Serialization failures terminating tomcat after attempting to lock a keystore so that it is unavailable. 3) The first panel indicates that the initial state of the keystores is locked and unavailable. However, it appears this is in error as the default keystore is locked to edit but available. This might just be semantics but it sounds like the capability doesn't match the description. This is not my experience. On a default install, if I look at that portlet, I see: Editable=(locked icon) Available=(unlocked icon) 1 key available Indicating that the keystore is available to be used by clients, but requires a password in order to edit. If that's not what you see can you try again from a fresh install of Geronimo? We are seeing the same thing. What I was pointing out was that the text on the panel says Keystores start out as locked against editing and also not available for usage by other components in the server. The *not available* statement led me to think that the portlet should show: Editable=(locked icon) Available=(locked icon) not available Again, it might just be a semantic problem with the wording on the panel rather than the state of keystore, but right now the two don't seem to match. 4) Unlocking for edit state or making the keystore available after it's been locked seems to always result in serialization errors. This is the same as #2 above, and as I said, there's an easy workaround for the Serialization errors. I'm not disputing your proposed change ... just listing some basic problems I'm seeing with the front-door code. I listed this separately because it is a different scenario that fails both on jetty and tomcat. This failure happens immediately on *unlock*. The #2 failure is on the available *lock* but only when the server is terminated as opposed to when the action is issued. And, IIRC, #2 only happens on tomcat. The same available lock operation on jetty results in #1 above. 5) The keystore itself is not selectable when edit is locked. I assume this is by design. If you attempt to unlock the keystore for edit and provide no password (or a bogus password), then in addition to the exception being tossed for the bad password I would expect the keystore to remain locked. However, the edit icon will show unlocked and you can get to the edit fields of the keystore. It would be good to chage it to detect bad passwords and handle by not claiming that the keystore is unlocked. That's also important for when you make it available not just when you make it editable. Not only would this be good, but it is the expected behavior when we challenge for a password to act accordingly if the correct password is not provided, isn't it? To add to your list: we currently act like you can unlock specific keys in the keystore when you make the keystore available. However, I think most consumers expect to get the one and only private key in the keystore. It would be great to test with a keystore with two private keys and see if we can really allow you to select one or the other and have the HTTPS connectors use it accordingly. Yep, sounds like another test case that should be run. Finally, based on your questions below, you should do a bit more research on key/certificate plumbing. A certificate is different from a CA signing request and a CA signing response. It is appropriate to generate or upload a certificate but paste out a CA request and paste in a CA response. The procedure is more or less to create or install an unsigned cert, then ask a CA to sign
Re: 1.1 keystore portlet bugs patches
Aaron, I think we can do the wiki page at some point to look at the complete design of the portlet but not right now. Right now I'm more concerned with fixing some of the problems with what we have before 1.1.1 goes out the door. I'll work on the problems that I listed and see if I can also integrate the fixes from Vamsi to restore the function that was lost from 1.0. Thanks, Joe Aaron Mulder wrote: I don't have a ton of time to work on this right now -- that's the only reason I'm trying to avoid doing it myself. However, it sounds like we probably ought to start in any case with a Wiki page and a description of what we think this portlet ought to be able to do, and perhaps a list of which of those functions have problems or are missing and which patches address each issue. Could you and Vamsi work on putting that together? If we all agree on exactly what needs to be done then it should be easier to get the patches aligned and make it easier to evaluate and apply them. Thanks, Aaron On 7/26/06, Joe Bohn [EMAIL PROTECTED] wrote: Aaron, Once again, thanks for the comments. Some more responses inline. I also renumbered the items to avoid the duplicate #2's ... sorry for the confusion. Aaron Mulder wrote: On 7/26/06, Joe Bohn [EMAIL PROTECTED] wrote: I think I understand your goals here Vamsi. However, I'm not sure that the portlet (as it currently stands) is a net positive or negative for Geronimo, even with your changes. It's not a matter of stress tests. It looks like basic function tests (unit tests) aren't working with this portlet. I don't fully understand the function of this portlet and perhaps that is clouding my judgment. Here's a list of the problems that I'm seeing (not necessarily complete): 1) You can hose the jetty server with one simple mouse click on the available lock icon. Even if we provided a warning prior to taking any action, it is still not a safe situation. There was a comment on the dev list just before 1.1 went out that this could be fixed by setting load=false on the SSLConnector and making the keystore available after server restart ... then restarting with the SSLConnector loaded again. However, even after doing this the next restart of the server still fails with the same error even though the console shows the keystore as available. I think this is a critical problem (see earlier post for one proposal on how to fix this by requiring the password). 2) Serialization failures terminating tomcat after attempting to lock a keystore so that it is unavailable. 3) The first panel indicates that the initial state of the keystores is locked and unavailable. However, it appears this is in error as the default keystore is locked to edit but available. This might just be semantics but it sounds like the capability doesn't match the description. This is not my experience. On a default install, if I look at that portlet, I see: Editable=(locked icon) Available=(unlocked icon) 1 key available Indicating that the keystore is available to be used by clients, but requires a password in order to edit. If that's not what you see can you try again from a fresh install of Geronimo? We are seeing the same thing. What I was pointing out was that the text on the panel says Keystores start out as locked against editing and also not available for usage by other components in the server. The *not available* statement led me to think that the portlet should show: Editable=(locked icon) Available=(locked icon) not available Again, it might just be a semantic problem with the wording on the panel rather than the state of keystore, but right now the two don't seem to match. 4) Unlocking for edit state or making the keystore available after it's been locked seems to always result in serialization errors. This is the same as #2 above, and as I said, there's an easy workaround for the Serialization errors. I'm not disputing your proposed change ... just listing some basic problems I'm seeing with the front-door code. I listed this separately because it is a different scenario that fails both on jetty and tomcat. This failure happens immediately on *unlock*. The #2 failure is on the available *lock* but only when the server is terminated as opposed to when the action is issued. And, IIRC, #2 only happens on tomcat. The same available lock operation on jetty results in #1 above. 5) The keystore itself is not selectable when edit is locked. I assume this is by design. If you attempt to unlock the keystore for edit and provide no password (or a bogus password), then in addition to the exception being tossed for the bad password I would expect the keystore to remain locked. However, the edit icon will show unlocked and you can get to the edit fields of the keystore. It would be good to chage it to detect bad passwords and handle by not claiming that the keystore is unlocked
Re: TCK Dog
Kevan, Sorry for being so late with this response, but I was thinking that I should probably get involved some with the TCK (to help address your desire for broader participation across the project and get some much deserved personal relief). I just faxed my NDA for confidential materials. I'll let you know when I get my authorization. Thanks, Joe Kevan Miller wrote: On Jul 10, 2006, at 1:55 PM, David Blevins wrote: Kevan, you've been tck dog for six months now. Having built the system and done the job myself, I know you're not going to survive another six months. We definitely need to get someone else to take that job for a while. What do you think? I certainly agree with that... I would also hope that we can work on distributing the burden, a bit. So, it's not one dog, but several... Although I certainly had a lot of help from you, David J, and Dain, It'd be great to see a broader base of participation... I see the following pieces: 1) Keeping builds running through Continuum 2) Keeping tests running through GBuild 3) Monitoring/advertising test results. 4) Fixing problems It's #4 that can be the killer and where we should be working as a team... but the others can eat up time, also. I have #1 going for 1.1.1-SNAPSHOT and 1.2-SNAPSHOT. Hope to get #2 going later today... Now, would be a great time for getting more people involved... --kevan
potenial problem with GBean attribute processing
There is either a problem with the attribute processing on gbeans or the
keystore use of this processing, I'm not sure which.
The problem is that there are times when an attribute is being set which
result in two entries in the config.xml for the same attribute rather
than replacing the current setting. Here is the scenario.
There is an attribute on the keystore instance gbean (the default one we
provide) for the keystore lock password and key passwords. The scenario
happens with both attributes but I'm most concerned with the keystore
lock at the moment so I'll just discuss that one.
With a brand new image, the attribute for the keystore lock is set to
the default password (which effectively means it is unlocked). If we
lock the keystore the password is then replaced with a null value and
this is reflected in the config.xml. So far, so good. However, when we
subsequently unlock the keystore, rather than replacing the password
attribute with the value again it ends up creating a second entry for
the attribute just before the null value entry. Here is what it looks
like in the config.xml:
gbean
name=geronimo/j2ee-security/1.1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-security/1.1.1-SNAPSHOT/car,j2eeType=Keystore,name=geronimo-default
attribute
name=keystorePassword{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwEArVToThqcjvbXFD5C2uUmpwdAADQUVT/attribute
attribute
name=keyPasswords{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwIJu+zYXdGgTo+dMtBxYduheM0Te6O/om49Ln+vWNipopcHQAA0FFUw==/attribute
attribute name=keystorePassword null=true/
attribute name=keyPasswords null=true/
It appears that null wins out (probably because it is last) and the
net result is that the keystore remains locked. This is not a good
thing (see other posts on the keystore processing).
So my question is this: Is this a problem with the way we are setting
the attribute or is it a problem with the attribute processing itself
(particularly around the setting and removing of a null value)? The
code that sets the attribute is in FileKeystoreInstance around line 130.
Thanks,
Joe
Re: potenial problem with GBean attribute processing
I created this JIRA for the problem:
http://issues.apache.org/jira/browse/GERONIMO-2241
Joe
Aaron Mulder wrote:
It sounds like a problem with the attribute manager and related code
to me -- it's responsible for writing config.xml and it should ensure
that there are no duplicate entries. Can you create a Jira for 1.1.1
for this? We better fix it.
Thanks,
Aaron
On 7/28/06, Joe Bohn [EMAIL PROTECTED] wrote:
There is either a problem with the attribute processing on gbeans or the
keystore use of this processing, I'm not sure which.
The problem is that there are times when an attribute is being set which
result in two entries in the config.xml for the same attribute rather
than replacing the current setting. Here is the scenario.
There is an attribute on the keystore instance gbean (the default one we
provide) for the keystore lock password and key passwords. The scenario
happens with both attributes but I'm most concerned with the keystore
lock at the moment so I'll just discuss that one.
With a brand new image, the attribute for the keystore lock is set to
the default password (which effectively means it is unlocked). If we
lock the keystore the password is then replaced with a null value and
this is reflected in the config.xml. So far, so good. However, when we
subsequently unlock the keystore, rather than replacing the password
attribute with the value again it ends up creating a second entry for
the attribute just before the null value entry. Here is what it looks
like in the config.xml:
gbean
name=geronimo/j2ee-security/1.1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-security/1.1.1-SNAPSHOT/car,j2eeType=Keystore,name=geronimo-default
attribute
name=keystorePassword{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwEArVToThqcjvbXFD5C2uUmpwdAADQUVT/attribute
attribute
name=keyPasswords{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwIJu+zYXdGgTo+dMtBxYduheM0Te6O/om49Ln+vWNipopcHQAA0FFUw==/attribute
attribute name=keystorePassword null=true/
attribute name=keyPasswords null=true/
It appears that null wins out (probably because it is last) and the
net result is that the keystore remains locked. This is not a good
thing (see other posts on the keystore processing).
So my question is this: Is this a problem with the way we are setting
the attribute or is it a problem with the attribute processing itself
(particularly around the setting and removing of a null value)? The
code that sets the attribute is in FileKeystoreInstance around line 130.
Thanks,
Joe
Re: potenial problem with GBean attribute processing
I wish it were that easy, but it isn't. There are two attributes that
are each repeated in this order:
keystorePassword (with value)
keyPasswords (with value)
keystorePassword (null value)
keyPasswords (null value)
Joe
Dain Sundstrom wrote:
I don't see any duplicate entries. You have two attributes
keystorePassword and keystorePasswords.
-dain
On Jul 28, 2006, at 2:33 PM, Aaron Mulder wrote:
It sounds like a problem with the attribute manager and related code
to me -- it's responsible for writing config.xml and it should ensure
that there are no duplicate entries. Can you create a Jira for 1.1.1
for this? We better fix it.
Thanks,
Aaron
On 7/28/06, Joe Bohn [EMAIL PROTECTED] wrote:
There is either a problem with the attribute processing on gbeans or
the
keystore use of this processing, I'm not sure which.
The problem is that there are times when an attribute is being set
which
result in two entries in the config.xml for the same attribute rather
than replacing the current setting. Here is the scenario.
There is an attribute on the keystore instance gbean (the default
one we
provide) for the keystore lock password and key passwords. The
scenario
happens with both attributes but I'm most concerned with the keystore
lock at the moment so I'll just discuss that one.
With a brand new image, the attribute for the keystore lock is set to
the default password (which effectively means it is unlocked). If we
lock the keystore the password is then replaced with a null value and
this is reflected in the config.xml. So far, so good. However,
when we
subsequently unlock the keystore, rather than replacing the password
attribute with the value again it ends up creating a second entry for
the attribute just before the null value entry. Here is what it looks
like in the config.xml:
gbean
name=geronimo/j2ee-security/1.1.1-SNAPSHOT/car?
ServiceModule=geronimo/j2ee-security/1.1.1-SNAPSHOT/
car,j2eeType=Keystore,name=geronimo-default
attribute
name=keystorePassword{Simple}
rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZ
GVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB
+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB
+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwEArVToThqcjvbXFD5C2uUmpwdAADQUVT
/attribute
attribute
name=keyPasswords{Simple}
rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZ
GVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB
+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB
+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwIJu+zYXdGgTo+dMtBxYduheM0Te6O/
om49Ln+vWNipopcHQAA0FFUw==/attribute
attribute name=keystorePassword null=true/
attribute name=keyPasswords null=true/
It appears that null wins out (probably because it is last) and the
net result is that the keystore remains locked. This is not a good
thing (see other posts on the keystore processing).
So my question is this: Is this a problem with the way we are setting
the attribute or is it a problem with the attribute processing itself
(particularly around the setting and removing of a null value)? The
code that sets the attribute is in FileKeystoreInstance around line
130.
Thanks,
Joe
critical jetty keystore problems on 1.1.1
I'm still trying to figure out some critical problems with the keystore processing on jetty. The most serious problem that I've yet to resolve is a problem with the lock/unlock of the keystore availability lock. A subsequent server restart will fail because Keystore 'geronimo-default' is locked. It appears that we cannot recover from this error either. Even if I change the config.xml for SSLConnector to load=false, restart the server, unlock the keystore/key (again) I still get the same failure when I attempt to start with the SSLConnector enabled. At first I thought this was because of the duplicate attribute entries referenced in an earlier post. In fact, I'm pretty sure that I edited the config.xml to remove the null entries and was able to get the server started. However, I have recently been unable to recover from this error using the same mechanism. In fact it seems to create more problems because after removing the null entries I now get an UnrecoverableKeyException. Any advice or recommendations? I'm beginning to wonder if we should disable the keystore portlet for 1.1.1 so that the user can't shoot himself in the foot. Joe
Re: 1.1 keystore portlet bugs patches
Aaron Mulder wrote: Here's the serialization error on shutdown. There are no errors on restart but subsequent shutdowns continue to produce the same error if I navigate to the portlet at all: Looks like it's putting an instance of the KeystoreInstance GBean in the session. We should probably change the code to put some Serializable object in the session that holds the AbstractName for the KeystoreInstance and looks it up again from the kernel every time the portlet needs it. Aaron, It looked to me like were were already looking up the KeystoreInstance GBean on each view request in the portlet (renderView() in ListHandler). Therefore, it seemed like the simpliest fix was to just make the KeystoreInstance transient in the BaseKeystoreHandler.KeystoreData class so that it wouldn't be serialized. I put that change in last week. Please let me know if you see a problem with this. Thanks, Joe
Re: 1.1.1 Status
I'm fine with both items. Joe John Sisson wrote: Any objections to removing the licenses from the about page in the console. See GERONIMO-2136 (listed below) FYI, I was originally planning on upgrading Derby (*GERONIMO-2155 https://issues.apache.org/jira/browse/GERONIMO-2155)*, but the debug versions of the derby libraries aren't in the maven repos and I'm running out of time, so will leave as targeted for 1.x. Thanks, John Matt Hogstrom wrote: There has been a lot of progress on 1.1.1. We started with 61 issues and we're down to 21 left. Originally I suggested that we branch on Friday. I'd like to give a little more time and would like to revise the branch to a freeze state on Tuesday, August 1 at 0500 PT. At that time I'll spin off branches/1.1.1 and update branches/1.1 to be 1.1.2-SNAPSHOT. We'll do performance regression and TCK work during the next week and shoot for an official release within two weeks. If anyone is opposed to this plan let me know. Also, please review the JIRA's below. If you don't think you can get thte ones done with your name please unassign yourself and hopefully someone else will pick them up. Thanks. *Outstanding Issues* GERONIMO- Open John Sisson Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL GERONIMO-2218 Open Unassigned KeyStore portlet: Functionality missing from 1.0 GERONIMO-1906 Reopened Sachin Patel Cannot add a new connector using ActiveMQManagerGBean GERONIMO-1917 Open David Jencks repository doesn't deal well with case insensitive file systems GERONIMO-1996 Open John Sisson Serialization failure during deployment leaves a config.ser in the repository but doesn't write a config.info causing problems later. GERONIMO-2080 Open John Sisson Create a Geronimo Bug Guidelines Page GERONIMO-2169 Open Kevan Miller Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch) GERONIMO-2170 Open Kevan Miller Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories GERONIMO-2167 Open Kevan Miller deployer.jar not cleaning up properly during redeploy and undeploy GERONIMO-2202 Open Kevan Miller Move to new Apache Maven 1 repo (repo/m1-snapshot-repository 1.2 GERONIMO-2030 Open Unassigned Allow WebServiceBuilder determine if there are WebServices to be deployed GERONIMO-1476 Open Unassigned Changes to default log4j.rootCategory are not dynamic GERONIMO-2228 Open Unassigned GeronimoAsMavenServlet.java generates wrong default-repository element GERONIMO-2230 Open Aaron Mulder No cleanup after DeploymentWatcher exception GERONIMO-2142 Open David Jencks EJB Refs to EJB in parent module often fail GERONIMO-2227 Open David Jencks ENC Lookup Fix (include parent modules) GERONIMO-1557 Open David Jencks When you enter the url of a web service in the console You should get a page showing the service name GERONIMO-1531 Open Unassigned KeyStore portlet should support deletion of certificates and private keys GERONIMO-1716 Open Donald Woods Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console GERONIMO-2204 Open David Jencks ProxyMethodInterceptor doesn't handle finalize appropriately GERONIMO-2136 Open John Sisson Remove/Update licenses displayed in about page of console GERONIMO-1810 Open John Sisson Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message
Re: critical jetty keystore problems on 1.1.1
Just an update on this problem. There is still a problem with the locking (esp. in jetty) due to multiple attributes (containing both the password value and null) for the keystorePassword and keyPasswords. However, with the fix just integrated for GERONIMO-2252 we at least have some recovery plan (modify the config.xml to remove the null entries and the remain stored entries will correctly unlock the keys). Thanks to Vamsavardhana Reddy for finding the root cause of why the passwords were being stored incorrectly. Now we just need to figure out why we're ending up with multiple entries in config.xml for the same attributes. Joe Joe Bohn wrote: I'm still trying to figure out some critical problems with the keystore processing on jetty. The most serious problem that I've yet to resolve is a problem with the lock/unlock of the keystore availability lock. A subsequent server restart will fail because Keystore 'geronimo-default' is locked. It appears that we cannot recover from this error either. Even if I change the config.xml for SSLConnector to load=false, restart the server, unlock the keystore/key (again) I still get the same failure when I attempt to start with the SSLConnector enabled. At first I thought this was because of the duplicate attribute entries referenced in an earlier post. In fact, I'm pretty sure that I edited the config.xml to remove the null entries and was able to get the server started. However, I have recently been unable to recover from this error using the same mechanism. In fact it seems to create more problems because after removing the null entries I now get an UnrecoverableKeyException. Any advice or recommendations? I'm beginning to wonder if we should disable the keystore portlet for 1.1.1 so that the user can't shoot himself in the foot. Joe
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Congratulations David Joe Matt Hogstrom wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
Re: critical jetty keystore problems on 1.1.1
I think that Aaron raised this issue (or indicated there might be a problem here) in a previous post on an earlier thread. Aaron suggested that there be a wiki page or some other summary page that explains what we think we need to have functionally so that it can be agreed upon and them implemented in a future Geronimo release. Can you take a stab at this summary Vamsi? I think that you along with David Jencks, Aaron, and possibly a few others will need to reach a consensus. Joe Vamsavardhana Reddy wrote: Looks like there is no point in having more than one private key entry in a keystore for the purpose of SSL Server authentication as there is no control on which key will be picked. I do not know if this is useful for Client authentication. Unless all the private key entries have the same password, KeyManagerFactory.init() will throw an exception. -Vamsi On 7/31/06, *Joe Bohn* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Just an update on this problem. There is still a problem with the locking (esp. in jetty) due to multiple attributes (containing both the password value and null) for the keystorePassword and keyPasswords. However, with the fix just integrated for GERONIMO-2252 we at least have some recovery plan (modify the config.xml to remove the null entries and the remain stored entries will correctly unlock the keys). Thanks to Vamsavardhana Reddy for finding the root cause of why the passwords were being stored incorrectly. Now we just need to figure out why we're ending up with multiple entries in config.xml for the same attributes. Joe Joe Bohn wrote: I'm still trying to figure out some critical problems with the keystore processing on jetty. The most serious problem that I've yet to resolve is a problem with the lock/unlock of the keystore availability lock. A subsequent server restart will fail because Keystore 'geronimo-default' is locked. It appears that we cannot recover from this error either. Even if I change the config.xml for SSLConnector to load=false, restart the server, unlock the keystore/key (again) I still get the same failure when I attempt to start with the SSLConnector enabled. At first I thought this was because of the duplicate attribute entries referenced in an earlier post. In fact, I'm pretty sure that I edited the config.xml to remove the null entries and was able to get the server started. However, I have recently been unable to recover from this error using the same mechanism. In fact it seems to create more problems because after removing the null entries I now get an UnrecoverableKeyException. Any advice or recommendations? I'm beginning to wonder if we should disable the keystore portlet for 1.1.1 so that the user can't shoot himself in the foot. Joe
Re: Terminology and status
I agree. I'd prefer something that is directly integrated with JIRA rather than adding an additional file that must be maintained (and therefore is more likely to contain errors). Joe Matt Hogstrom wrote: Fine...I prefer a field in JIRA so I can execute a single query. I'll assume the patches are in JIRA anyway and its a great place for comments too :) Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 People have been referring to things requiring votes as 'RTCs'. Everyone *please* stop using RTC in this manner. RTC is a development model; what it and CTR are concerned with are patches. Please call them patches. Changes are patches; RTC and CTR are how they get applied. If you said something about 'an RTC' outside Geronimo, no-one would have the least idea what you were talking about. This is *not* a place where it's necessary for us to invent new nomenclature. There has been some discussion about keeping status in the wiki. The wiki is a 'pull' mechanism; if you don't actively go looking for it, you won't get it. I have updated the STATUS file in trunk from its incubation content to something more current, and have set it up to be mailed to the list every Wednesday night. I suggest filling things in there so all the various issues are listed in a single places, along with who has voted on patches, critical issues, etc. Right now information is scattered all over the place. Take a look at http://tinyurl.com/hzwes (or at http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS if you prefer the full URL) to see how another project uses the STATUS file as a central repository of such info. If the consensus is to not use the STATUS file, that's cool. But I decided that *doing* it was more productive that just proposing to possibly set it up. - -- #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 iQCVAwUBRNDmpZrNPMCpn3XdAQKWpgP+L6fVMia9/QIb/QRX6Q9PvW3GI7+TFTMe 2feNTUraxSxuKY2CT3Bk8m8s2H/iObbgt+ILidYnKXMU8FKEFW2nCzZBPpCEi1cO CaawPX7PhMltfhbaJquR4qZM1VRUxd2YfyDzvJEYIbP1c166TgV5Q4FZjnt8lFJR 96KAuOpSqTI= =W2iC -END PGP SIGNATURE-
Re: [jira] Commented: (GERONIMO-1823) Add Embedded LDAP Server Viewer Portlet
Hi Aaron, So we *do* have a way to extend the console at deploy time (either plugin deployment or application deployment)? Will this handle updates to the pageregistry and portletentityregistry? Is there also a mechanism to undo the changes when a plugin or application is undeployed? If so, then that is excellent!! I wasn't aware of anything in this area to make the console extensible and was thinking that we really needed this (esp. since Geronimo itself is extensible). Has this been integrated in other places or just with gplugins (whatever that is ... I just started to see what I could find on this based upon your response)? Is there any more information that you can point me to on this? Thanks, Joe Aaron Mulder (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1823?page=comments#action_12425725 ] Aaron Mulder commented on GERONIMO-1823: I think this would be better packaged as a plugin than integrated into the console, since the same is true of our Apache DS integration. Can you package this portlet as a standalone WAR? The gplugins project has a GBean you can add to geronimo-web.xml that can install portlets into the console. Add Embedded LDAP Server Viewer Portlet --- Key: GERONIMO-1823 URL: http://issues.apache.org/jira/browse/GERONIMO-1823 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Chris Cardona Attachments: dojo-0.3.1-bin.zip, ldapMgrPortlet-B1.1.1.jpg, ldapMgrPortlet-B1.1.1.patch, ldapMgrPortlet-Snapshot.zip, ldapMgrPortlet.patch, sample.ldif Add a new portlet for viewing the contents of the embedded directory server (Apache DS). This portlet will be under 'Misc' portlets.
plugin site(s?) need to be updated with newer versions
It appears that the plugin site (geronimoplugins.com) needs to be updated to reflect the new Geronimo version numbers. At the moment, if you search for plugins using the 1.1 branch image (Geronimo 1.1.2-SNAPSHOT) or with a 1.1.1 branch image (Geronimo 1.1.1) none of the plugins are marked as available. The metadata for the plugins only indicates that they are valid for Geronimo 1.1.1-SNAPSHOT (this no longer exists) or Geronimo 1.1. Can somebody with the proper authority update the geronimoplugins.com site? Are there other plugin sites that need to be updated? Also, would it make sense relax the version verification some to ignore anything in a version following the - on the server version? If the plugin as only specified as 1.1.1 and we didn't include the -SNAPSHOT from a pre-release image then the plugin registry wouldn't have to change when we cut the official release. It seems reasonable to me that a plugin targeted for 1.1.1 should be mostly functional with a SNAPSHOT drop of 1.1.1 prior to the official release. thoughts? Joe
Re: plugin site(s?) need to be updated with newer versions
Ah yes ... now I remember the thread. It seems that we may need to revive this discussion not only for the plugins but also for the dependency versions as well until we have a consistent solution that will work for both cases. We'll also need to address the case of build numbers/SNAPSHOTs/REVISIONS/etc... as indicated in GERONIMO_1637 Joe Paul McMahan wrote: Joe, Here's some discussion on plugin versioning you may want to check out: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200606.mbox/[EMAIL PROTECTED] Dain proposed a simple globbing approach that was well received, but AFAIK it hasn't been implemented yet. Paul On 8/4/06, Joe Bohn [EMAIL PROTECTED] wrote: It appears that the plugin site (geronimoplugins.com) needs to be updated to reflect the new Geronimo version numbers. At the moment, if you search for plugins using the 1.1 branch image (Geronimo 1.1.2-SNAPSHOT) or with a 1.1.1 branch image (Geronimo 1.1.1) none of the plugins are marked as available. The metadata for the plugins only indicates that they are valid for Geronimo 1.1.1-SNAPSHOT (this no longer exists) or Geronimo 1.1. Can somebody with the proper authority update the geronimoplugins.com site? Are there other plugin sites that need to be updated? Also, would it make sense relax the version verification some to ignore anything in a version following the - on the server version? If the plugin as only specified as 1.1.1 and we didn't include the -SNAPSHOT from a pre-release image then the plugin registry wouldn't have to change when we cut the official release. It seems reasonable to me that a plugin targeted for 1.1.1 should be mostly functional with a SNAPSHOT drop of 1.1.1 prior to the official release. thoughts? Joe
Re: Maven2... we are almost there!
I'm trying to build with m2 on windows with some suspicious results. Right now I'm getting a number of errors just trying to run bootstrap. One of my windows machines claims that it is successful while the other one fails with this error: [ERROR] BUILD ERROR [INFO] [INFO] Destination c:\geronimo\m2-assemblies\geronimo-tomcat-j2ee\target\archive-tmp\repository\org\apache\geronimo\configs\webconsole-tomcat\1.2-SNAPSHOT\webconsole-tomcat-1.2-SNAPSHOT.car already exists! [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 5 minutes 3 seconds [INFO] Finished at: Tue Aug 08 09:24:29 EDT 2006 [INFO] Final Memory: 55M/104M [INFO] bootstrap: Bootstrap failed in stage assemble I was talking with Prasad offline on this and he thinks that the failure is because of the windows long name issue causing the cleanup to fail. I'll manually clean things up and try again on that machine. However, both machines received a ton of other errors. Are all of these excepted problems? If so, then if we can't clean them up I think we should at least warn people to expect them. Here are the errors that were in the logs (I can't attach the logs because they are too large). several of these: 09:09:01,062 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=test/3/3.3/bar?j2eeType=GBean,name=gbean3 java.lang.RuntimeException: FAILING at org.apache.geronimo.kernel.config.ConfigurationManagerTest.checkFail(ConfigurationManagerTest.java:663) at org.apache.geronimo.kernel.config.ConfigurationManagerTest.access$300(ConfigurationManagerTest.java:54) at org.apache.geronimo.kernel.config.ConfigurationManagerTest$TestBean.init(ConfigurationManagerTest.java:809) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.restartConfiguration(SimpleConfigurationManager.java:628) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.restartConfiguration(SimpleConfigurationManager.java:588) at org.apache.geronimo.kernel.config.ConfigurationManagerTest.testRestartException(ConfigurationManagerTest.java:236) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) 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.executeTestSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122) at
Re: [ANNOUNCE] Welcome Kevan Miller to the Geronimo PMC
Way to go Kevan!!! Joe Matt Hogstrom wrote: Please welcome Kevan Miller as the newest member of the Geronimo PMC. Kevan recently accepted the invitation to join the PMC. As such we now have an additional set of eyes to help with reviews as well as other PMC oversight responsibilities. Kevan has shown that he is not only a valuable member of the technical community but also spends much of his time helping others as well as making sure those pesky LICENSE files make it into every jar we ship. Give it up for Kevan :-0
Re: 1.1.1 - Ready or not ? Soliciting input
Are these issues newly broken in 1.1.1 or are they issues that also exist with 1.1? From looking at the JIRAs all list 1.1 or earlier as being affected with the exception of GERONIMO-2270. I don't see a reason to hold up 1.1.1 unless we have introduced some new blocking issues in the 1.1.1 release. Joe Aaron Mulder wrote: Here are the issues that bother me most in 1.1.1. I believe they are all also issues in 1.1. DEPLOYMENT http://issues.apache.org/jira/browse/GERONIMO-2270 - Redeploy broken when module ID does not include a type (patch available) http://issues.apache.org/jira/browse/GERONIMO-2269 - Redeploy broken when module ID does not include a version and app uses JNDI (patch available) I also just found a deploy problem with web apps with a plan with no environment, but I haven't investigated much yet. SECURITY http://issues.apache.org/jira/browse/GERONIMO-2294 - For a security realm with multiple login modules, we do not handle the JAAS Control Flags correctly (e.g. we do not call the login modules using the correct logic). Code to reproduce available. Alan had claimed a predecessor to this issue; I'm not sure if he's planning on working on this one. http://issues.apache.org/jira/browse/GERONIMO-2295 - For a web app, if the security url-patterns don't exactly match the servlet-mapping url-patterns, we apply no security at all. Code to reproduce available. Alan has claimed this issue. http://issues.apache.org/jira/browse/GERONIMO-1053 - Likely not still a problem (reported against M5), but if it is, it sounds serious. There are a large number of other issues out there in the security category, but I don't think they're all as urgent (e.g. GEORNIMO-1747, GERONIMO-2274, GERONIMO-2275, and GERONIMO-2279 probably ought to be addressed in 1.1.2 but I don't think need to hold up 1.1.1). Thanks, Aaron On 8/8/06, Matt Hogstrom [EMAIL PROTECTED] wrote: 1.1.1 is in a form that we can get ready to release it. I was talking with Aaron and he mentioned that there were some security issues he was concerned about. I would like to use this thread to identify any issues that should be considered show stoppers and make the decision on how to move forward. Please use this thread to provide that information. What I think we'll need to make an appropriate assessement is: Issue Description How long have we had it? (has it existed in earlier releases and we knew it) Exposure JIRA issue number tracking the issue. Please provide your input as quickly as possible so we can assess how to proceed with 1.1.1. Thanks.
Re: 1.1.1 - Ready or not ? Soliciting input
I'm not familiar with the issue and I'm not arguing that we don't need to fix it. But this problem indicates that it was present in 1.1 and somehow it didn't make it to the top of the list for 1.1.1 earlier. Does it need to hold up the release or could it be delivered in 1.1.2? Joe Kevan Miller wrote: On Aug 8, 2006, at 10:14 AM, Matt Hogstrom wrote: 1.1.1 is in a form that we can get ready to release it. I was talking with Aaron and he mentioned that there were some security issues he was concerned about. I would like to use this thread to identify any issues that should be considered show stoppers and make the decision on how to move forward. Please use this thread to provide that information. What I think we'll need to make an appropriate assessement is: Issue Description How long have we had it? (has it existed in earlier releases and we knew it) Exposure JIRA issue number tracking the issue. Please provide your input as quickly as possible so we can assess how to proceed with 1.1.1. I don't have any background information -- other than what's in the jira database for 1.1.1. I see GERONIMO-2295 -- http:// issues.apache.org/jira/browse/GERONIMO-2295 I haven't verified the problem. However, given the description, I'd say it's definitely something that needs to be fixed. It's currently assigned to Alan. Alan, are you working on this? --kevan
Re: Maven2... we are almost there!
Ok, once I learned to ignore the errors (and work around the windows pathlength issues) I was able to get a successful build. Things went pretty smoothly ... nice work!!! There seems to be a problem with the minimal assemblies. They do not include the deployer.jar in the image which kinda makes it difficult to deploy things. However, when I deployed my application into the minimal assembly using the deployer from the j2ee assembly it seemed to work well! Joe David Jencks wrote: On Aug 8, 2006, at 8:16 AM, Joe Bohn wrote: I'm trying to build with m2 on windows with some suspicious results. Right now I'm getting a number of errors just trying to run bootstrap. One of my windows machines claims that it is successful while the other one fails with this error: [ERROR] BUILD ERROR [INFO] -- -- [INFO] Destination c:\geronimo\m2-assemblies\geronimo-tomcat-j2ee \target\archive-tmp\repository\org\apache\geronimo\configs \webconsole-tomcat\1.2-SNAPSHOT\webconsole-tomcat-1.2-SNAPSHOT.car already exists! [INFO] -- -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 5 minutes 3 seconds [INFO] Finished at: Tue Aug 08 09:24:29 EDT 2006 [INFO] Final Memory: 55M/104M [INFO] -- -- bootstrap: Bootstrap failed in stage assemble I was talking with Prasad offline on this and he thinks that the failure is because of the windows long name issue causing the cleanup to fail. I'll manually clean things up and try again on that machine. However, both machines received a ton of other errors. Are all of these excepted problems? If so, then if we can't clean them up I think we should at least warn people to expect them. Here are the errors that were in the logs (I can't attach the logs because they are too large). I believe most or all of these were always happening, we just see them now because jason figured out how to set up log4j for the tests properly -- previously all this was not getting recorded in any obvious place. thanks david jencks several of these: 09:09:01,062 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=test/3/3.3/bar? j2eeType=GBean,name=gbean3 java.lang.RuntimeException: FAILING at org.apache.geronimo.kernel.config.ConfigurationManagerTest.checkFail (ConfigurationManagerTest.java:663) at org.apache.geronimo.kernel.config.ConfigurationManagerTest.access $300(ConfigurationManagerTest.java:54) at org.apache.geronimo.kernel.config.ConfigurationManagerTest $TestBean.init(ConfigurationManagerTest.java:809) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance (GBeanInstance.java:933) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start (GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive (GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive (GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean (BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguration GBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start (KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.restartCo nfiguration(SimpleConfigurationManager.java:628) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.restartCo nfiguration(SimpleConfigurationManager.java:588) at org.apache.geronimo.kernel.config.ConfigurationManagerTest.testRestart Exception(ConfigurationManagerTest.java:236) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106
Re: Maven2... we are almost there!
Yep, I hit a console deploy problem with the j2ee jetty image ... so I think it's a real issue (although I didn't look at the details of the exception). Joe Bill Dudney wrote: Hi Joe, Could you try to deploy via the console. I'm not having any luck with that (about to post a JIRA about it) would be nice to know if anyone else is able to deploy via the console. Basically it appears that the DeploymentFactoryImpl (from geronimo- deploy-jsr88) is not being started and thus there are no deployers (at least for the console). I'm still poking around but a confirmation would be nice :-) TTFN, -bd On Aug 8, 2006, at 11:09 AM, Joe Bohn wrote: Ok, once I learned to ignore the errors (and work around the windows pathlength issues) I was able to get a successful build. Things went pretty smoothly ... nice work!!! There seems to be a problem with the minimal assemblies. They do not include the deployer.jar in the image which kinda makes it difficult to deploy things. However, when I deployed my application into the minimal assembly using the deployer from the j2ee assembly it seemed to work well! Joe David Jencks wrote: On Aug 8, 2006, at 8:16 AM, Joe Bohn wrote: I'm trying to build with m2 on windows with some suspicious results. Right now I'm getting a number of errors just trying to run bootstrap. One of my windows machines claims that it is successful while the other one fails with this error: [ERROR] BUILD ERROR [INFO] -- -- [INFO] Destination c:\geronimo\m2-assemblies\geronimo-tomcat-j2ee \target\archive-tmp\repository\org\apache\geronimo\configs \webconsole-tomcat\1.2-SNAPSHOT\webconsole-tomcat-1.2- SNAPSHOT.car already exists! [INFO] -- -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 5 minutes 3 seconds [INFO] Finished at: Tue Aug 08 09:24:29 EDT 2006 [INFO] Final Memory: 55M/104M [INFO] -- -- bootstrap: Bootstrap failed in stage assemble I was talking with Prasad offline on this and he thinks that the failure is because of the windows long name issue causing the cleanup to fail. I'll manually clean things up and try again on that machine. However, both machines received a ton of other errors. Are all of these excepted problems? If so, then if we can't clean them up I think we should at least warn people to expect them. Here are the errors that were in the logs (I can't attach the logs because they are too large). I believe most or all of these were always happening, we just see them now because jason figured out how to set up log4j for the tests properly -- previously all this was not getting recorded in any obvious place. thanks david jencks several of these: 09:09:01,062 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=test/3/3.3/bar? j2eeType=GBean,name=gbean3 java.lang.RuntimeException: FAILING at org.apache.geronimo.kernel.config.ConfigurationManagerTest.checkFail (ConfigurationManagerTest.java:663) at org.apache.geronimo.kernel.config.ConfigurationManagerTest.access $300(ConfigurationManagerTest.java:54) at org.apache.geronimo.kernel.config.ConfigurationManagerTest $TestBean.init(ConfigurationManagerTest.java:809) at sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java: 274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance (GBeanInstance.java:933) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStar t( GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start (GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive (GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive (GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean (BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurati on GBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start ( KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.restart Co nfiguration(SimpleConfigurationManager.java:628
Re: Maven2... we are almost there!
I applied a fix for https://issues.apache.org/jira/browse/GERONIMO-2304 to correct the problem with the missing deployer.jar in the minimal assemblies. Joe Joe Bohn wrote: Ok, once I learned to ignore the errors (and work around the windows pathlength issues) I was able to get a successful build. Things went pretty smoothly ... nice work!!! There seems to be a problem with the minimal assemblies. They do not include the deployer.jar in the image which kinda makes it difficult to deploy things. However, when I deployed my application into the minimal assembly using the deployer from the j2ee assembly it seemed to work well! Joe David Jencks wrote: On Aug 8, 2006, at 8:16 AM, Joe Bohn wrote: I'm trying to build with m2 on windows with some suspicious results. Right now I'm getting a number of errors just trying to run bootstrap. One of my windows machines claims that it is successful while the other one fails with this error: [ERROR] BUILD ERROR [INFO] -- -- [INFO] Destination c:\geronimo\m2-assemblies\geronimo-tomcat-j2ee \target\archive-tmp\repository\org\apache\geronimo\configs \webconsole-tomcat\1.2-SNAPSHOT\webconsole-tomcat-1.2-SNAPSHOT.car already exists! [INFO] -- -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 5 minutes 3 seconds [INFO] Finished at: Tue Aug 08 09:24:29 EDT 2006 [INFO] Final Memory: 55M/104M [INFO] -- -- bootstrap: Bootstrap failed in stage assemble I was talking with Prasad offline on this and he thinks that the failure is because of the windows long name issue causing the cleanup to fail. I'll manually clean things up and try again on that machine. However, both machines received a ton of other errors. Are all of these excepted problems? If so, then if we can't clean them up I think we should at least warn people to expect them. Here are the errors that were in the logs (I can't attach the logs because they are too large). I believe most or all of these were always happening, we just see them now because jason figured out how to set up log4j for the tests properly -- previously all this was not getting recorded in any obvious place. thanks david jencks several of these: 09:09:01,062 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=test/3/3.3/bar? j2eeType=GBean,name=gbean3 java.lang.RuntimeException: FAILING at org.apache.geronimo.kernel.config.ConfigurationManagerTest.checkFail (ConfigurationManagerTest.java:663) at org.apache.geronimo.kernel.config.ConfigurationManagerTest.access $300(ConfigurationManagerTest.java:54) at org.apache.geronimo.kernel.config.ConfigurationManagerTest $TestBean.init(ConfigurationManagerTest.java:809) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance (GBeanInstance.java:933) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start (GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive (GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive (GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean (BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguration GBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start (KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.restartCo nfiguration(SimpleConfigurationManager.java:628) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.restartCo nfiguration(SimpleConfigurationManager.java:588) at org.apache.geronimo.kernel.config.ConfigurationManagerTest.testRestart Exception(ConfigurationManagerTest.java:236) 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
Re: Daytrader config exceptions in 1.1.1 branch
Hi John, Unfortunately I am familiar with this problem. Although it doesn't look like it ... it's really another manifestation of the infamous windows pathlength problem. I don't know which path in particular is causing the problem ... but I have discovered that if you shorten your root pathname it seems to avoid the issue. Not sure what the magic number of characters is at the moment. c:\geronimo1.1.1 is too long and c:\g works. The actual limit may be something around 14 chars at the moment (I'm currently giving it a try) since I can build the 1.1 branch with c:\geronimo1.1 without the error and I don't think they're that different wrt the paths created. Joe John Sisson wrote: Does anyone else get this problem or is it just me ? John + | configurations Daytrader using derby deployed on jetty | Memory: 47M/60M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download geronimo-daytrader-derby-db-1.1.1-SNAPSHOT.jar. Attempting to download openejb-1.1.1-SNAPSHOT.car. build:start: multiproject:install-callback: [echo] Running car:install for Daytrader using derby deployed on jetty car:prepare-plan: car:package: [mkdir] Created dir: R:\dev\g-br-1.1.1\configs\daytrader-jetty\target\repository Packaging configuration R:\dev\g-br-1.1.1\configs\daytrader-jetty\target\plan\plan.xml Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. 22:04:03,140 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:03,937 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geroni mo.apache.org 22:04:04,078 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:04,171 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:04,265 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geroni mo.apache.org 22:04:04,359 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:04,453 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.g eronimo.apache.org 22:04:04,531 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.g eronimo.apache.org 22:04:04,625 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples .geronimo.apache.org 22:04:05,750 ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: Could not load servlet class org.apache.geronimo .samples.daytrader.web.prims.PingServlet2Session2EntityCollection org.apache.geronimo.common.DeploymentException: Could not load servlet class org.apache.geronimo.samples.daytrader.web.prims.PingSer vlet2Session2EntityCollection at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addServlet(JettyModuleBuilder.java:830) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addServlets(JettyModuleBuilder.java:790) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:697) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder$$FastClassByCGLIB$$b30bba8a.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:817) 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.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8ebe45b4.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:162) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
Re: Daytrader config exceptions in 1.1.1 branch
Ok, it looks like the current limit for geronimo 1.1.1 is 15 chars in the root path if you want to be able to build on windows. c:\geronimo1.1. will work but c:\geronimo\1.1.1 will not. Joe Joe Bohn wrote: Hi John, Unfortunately I am familiar with this problem. Although it doesn't look like it ... it's really another manifestation of the infamous windows pathlength problem. I don't know which path in particular is causing the problem ... but I have discovered that if you shorten your root pathname it seems to avoid the issue. Not sure what the magic number of characters is at the moment. c:\geronimo1.1.1 is too long and c:\g works. The actual limit may be something around 14 chars at the moment (I'm currently giving it a try) since I can build the 1.1 branch with c:\geronimo1.1 without the error and I don't think they're that different wrt the paths created. Joe John Sisson wrote: Does anyone else get this problem or is it just me ? John + | configurations Daytrader using derby deployed on jetty | Memory: 47M/60M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download geronimo-daytrader-derby-db-1.1.1-SNAPSHOT.jar. Attempting to download openejb-1.1.1-SNAPSHOT.car. build:start: multiproject:install-callback: [echo] Running car:install for Daytrader using derby deployed on jetty car:prepare-plan: car:package: [mkdir] Created dir: R:\dev\g-br-1.1.1\configs\daytrader-jetty\target\repository Packaging configuration R:\dev\g-br-1.1.1\configs\daytrader-jetty\target\plan\plan.xml Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. 22:04:03,140 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:03,937 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geroni mo.apache.org 22:04:04,078 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:04,171 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:04,265 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geroni mo.apache.org 22:04:04,359 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 22:04:04,453 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.g eronimo.apache.org 22:04:04,531 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.g eronimo.apache.org 22:04:04,625 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples .geronimo.apache.org 22:04:05,750 ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: Could not load servlet class org.apache.geronimo .samples.daytrader.web.prims.PingServlet2Session2EntityCollection org.apache.geronimo.common.DeploymentException: Could not load servlet class org.apache.geronimo.samples.daytrader.web.prims.PingSer vlet2Session2EntityCollection at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addServlet(JettyModuleBuilder.java:830) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addServlets(JettyModuleBuilder.java:790) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:697) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder$$FastClassByCGLIB$$b30bba8a.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:817) 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.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8ebe45b4.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:162) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder
Re: problem installing plugin for web console in g 1.1
Does anybody know how to update the Maven metadata on ibiblio? It looks like this is incorrect for all of the 1.1 artifacts. Aaron, Thanks for looking into this. Have you added (or are you going to add) the full set of geronimo artifacts for 1.1 to your plugin repo as you mentioned? Can you let me know when they are there? It seems like it makes sense to have these on the geronimo plugins repo anyway, even once ibiblio is fixed. They are geronimo artifacts that may be needed by many Geronimo plugins and it would eliminate possible failures due to connectivity problems with ibiblio. Joe Aaron Mulder wrote: This is because the Maven metadata in the Maven 2 repository on ibiblio is wrong. I'm surprised -- I would have thought this was updated when we published our 1.1 JARs. Anyway, look here: http://www.ibiblio.org/maven2/geronimo/geronimo-timer/maven-metadata.xml Notice that there's no 1.1 listed, even though http://www.ibiblio.org/maven2/geronimo/geronimo-timer/1.1/ exists. So the path we took to get here is because we need a module and there's no version in the dependency, we find the first server that has a matching module and take the highest version it has. I can probably work around this by putting a full set of Geronimo artifacts on geronimoplugins.com (so we won't fall back to ibiblio for those modules), though again, the real fix is to correct the Maven metadata on ibiblio. I have no idea how to do that. Thanks, Aaron On 8/10/06, Joe Bohn [EMAIL PROTECTED] wrote: I hit an error attempting to install the plugin for the web console on a little-G tomcat image with the official Geronimo 1.1 release. Are there known problems with this capability? I assumed that this plugin is for this very purpose (since we already include the console with the j2ee image). It looked like the download and install went as expected but failed attempting to start the gbean. I think that somehow the wrong dependencies were installed for geronimo-timer (and perhaps geronimo-derby). For both of these version 1.0 was deployed rather than 1.1. Installation Complete! Used existing: geronimo/j2ee-server//car Used existing: geronimo/j2ee-security//car Used existing: geronimo/tomcat//car Used existing: geronimo/geronimo-management//jar Used existing: geronimo/geronimo-deploy-jsr88//jar Used existing: geronimo/geronimo-service-builder//jar Used existing: geronimo/geronimo-connector-builder//jar Used existing: geronimo/geronimo-naming-builder//jar Used existing: geronimo/geronimo-security-builder//jar Used existing: geronimo/geronimo-j2ee-schema//jar Used existing: xmlbeans/xbean/2.0.0/jar Used existing: stax/stax-api/1.0.1/jar Used existing: geronimo/geronimo-util//jar Installed new: geronimo/system-database//car Installed new: geronimo/geronimo-derby//jar Installed new: org.apache.derby/derby//jar Installed new: org.apache.derby/derbynet//jar Installed new: geronimo/geronimo-timer//jar Installed new: portlet-api/portlet-api/1.0/jar Installed new: org.apache.pluto/pluto/1.0.1/jar Installed new: geronimo/geronimo-console-core//jar Installed new: geronimo/geronimo-upgrade//jar Installed new: geronimo/geronimo-test-ddbean//jar Installed new: geronimo/geronimo-deploy-config//jar Installed new: activemq/activemq-gbean-management-g1_1/3.2.4/jar Installed new: activemq/activemq-gbean-g1_1/3.2.4/jar Installed new: activemq/activemq-core/3.2.4/jar Installed new: geronimo/geronimo-converter//jar Installed new: jdom/jdom//jar Now starting geronimo/webconsole-tomcat/1.1/car... org.apache.geronimo.kernel.config.LifecycleException: start of geronimo/webconsole-tomcat/1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:529) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.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:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:338) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38
Re: Organization and versioning of specs; a new proposal
Makes sense to me too. +1
Joe
Jason Dillon wrote:
A while ago there was talks about independently versioning specs, and
Alan started a reorg branch which gives each spec module its own trunk
+branches+tags...
I have been thinking about this for a while, and with the recent desire
to split off more modules from geronimo/trunk I've been pondering it
even more. What I have come to believe is that spitting up spec
modules into their own trunk+branches+tags is probably not the best
direction for us to head in.
I believe that all of our specs can, and should, share one trunk... and
still have each module specify its own version. This is very similar
to how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently. The top-
level pom has a version too, which is independent and is only changed
when there is a major configuration change in that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check out and
building when you just want all of the specs. If each spec was in its
own trunk, you would need to svn co each one, then mvn install in each
tree, which is a pain.
We also almost never branch specs, they just keep chugging along, only
really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/ specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which we can
set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$ {pom.artifactId}
When released, the plugin will svn cp just the module's directory into
a directory under tags, so it will be easy to see what the released
versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk, and
really I think that if we did then it would just make it more difficult
for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which isn't
that major, is that the properties which live in the root pom that
control the versions need to be removed... or rather moved back to the
version element of the respective pom.
Comments?
--jason
Re: svn commit: r430833 - /geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java
Rick,
Did you intend to just add this println or were you really planning to
remove the part (as you did with trunk).
Joe
[EMAIL PROTECTED] wrote:
Author: rickmcguire
Date: Fri Aug 11 10:26:32 2006
New Revision: 430833
URL: http://svn.apache.org/viewvc?rev=430833view=rev
Log:
GERONIMO-2209 - Enable tests (geronimo-activation :: **/MailcapTest.java)
Delete invalid MailcapTest.
Modified:
geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java
Modified:
geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java
URL:
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java?rev=430833r1=430832r2=430833view=diff
==
---
geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java
(original)
+++
geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java
Fri Aug 11 10:26:32 2006
@@ -31,6 +31,7 @@
public void testTextPlainHandler() {
CommandInfo info = map.getCommand(text/plain, content-handler);
+System.out.println(Command handler classname is +
info.getCommandClass());
assertEquals(TextPlainHandler.class.getName(), info.getCommandClass());
}
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congrats Alan! Matt Hogstrom wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
Congrats Guillaume! Matt Hogstrom wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. The Apache Geronimo PMC
Re: Drop the m1 build
Does pristine mean that all those ugly runtime exceptions, gbean start errors, illegal state errors, assertion errors, and NoClassDefFound errors mentioned in the Maven2 ... we are almost there thread will be resolved? If so, and we must first remove the m1 build to get these addressed, then I'm all for removal. I realize that many of those errors may be present with the M1 build (but just not logged as DJ pointed out) but seeing them now makes the build look much worse than with M1. I'm not sure what level of confidence people have with the build when seeing these all scroll by. It sure doesn't give me any warm fuzzies. Joe Jason Dillon wrote: On Aug 17, 2006, at 8:18 PM, Bruce Snyder wrote: I caution against removing the m1 until the m2 build has been stable for a period of time. We made this mistake with ActiveMQ and ServiceMix and wound up having to restore the m1 build while gremlins were flushed from the m2 build. Hrm... its stable now :-P And I am not really sure how well the m1 build works. I tend to think Jason's proposal is better one. Give it some time to be tested and get stable. JVZ? The m2 build has been in various stages of stablish for a few weeks now. The main issue I have with keeping it around, and praying it still works kinda... is that it prevents us from continuing to clean things up (getting files into better places to reduce pom config, renaming directories to conform to artifactIds, fixing variables used for filtering). There is still a week or so that needs to be spent post-removal of m1 to get the m2 build pristine... and I don't see any reason why we should wait much longer before doing it. --jason
Re: [VOTE] Drop the M1 build artifacts in Trunk
[X] +1 Allow changes Joe Matt Hogstrom wrote: Given that we are close to completing the M2 conversion and have some disruptive changes to make to trunk this vote is to capture the communities input on the structure of the Geronimo repository. Given that this is about our build environment and development structure for purposes of this vote all votes are binding. The vote is to remove Maven 1 build artificats from trunk and allow directory reoganizations starting on Wednesday August 23. Jason to notify dev list about pending changes. JIRA http://issues.apache.org/jira/browse/GERONIMO-2331 created to track issue. [ ] +1 Allow changes [ ] 0 No opinion [ ] -1 Keep M1 artifacts in place (provide rationale)
Re: problem installing plugin for web console in g 1.1
One more time Does anybody know how/who/etc... to get the maven 2 info updated for ibiblio? Is there some way to avoid similar problems on ibiblio as we prepare to publish the 1.1.1 artifacts? Aaron, Do you think you might be able to get the geronimo 1.1 artifacts into the plugins repo soon to get around this problem? At the moment it looks like this prevents us from being able to install the console and liferay plugins on 1.1 not sure if any others are affected. Thanks, Joe Aaron Mulder wrote: I agree. I'll let you know when the site is updated. I won't be able to do it during the day, but tonight or over the weekend. Thanks, Aaron On 8/11/06, Joe Bohn [EMAIL PROTECTED] wrote: Does anybody know how to update the Maven metadata on ibiblio? It looks like this is incorrect for all of the 1.1 artifacts. Aaron, Thanks for looking into this. Have you added (or are you going to add) the full set of geronimo artifacts for 1.1 to your plugin repo as you mentioned? Can you let me know when they are there? It seems like it makes sense to have these on the geronimo plugins repo anyway, even once ibiblio is fixed. They are geronimo artifacts that may be needed by many Geronimo plugins and it would eliminate possible failures due to connectivity problems with ibiblio. Joe Aaron Mulder wrote: This is because the Maven metadata in the Maven 2 repository on ibiblio is wrong. I'm surprised -- I would have thought this was updated when we published our 1.1 JARs. Anyway, look here: http://www.ibiblio.org/maven2/geronimo/geronimo-timer/maven-metadata.xml Notice that there's no 1.1 listed, even though http://www.ibiblio.org/maven2/geronimo/geronimo-timer/1.1/ exists. So the path we took to get here is because we need a module and there's no version in the dependency, we find the first server that has a matching module and take the highest version it has. I can probably work around this by putting a full set of Geronimo artifacts on geronimoplugins.com (so we won't fall back to ibiblio for those modules), though again, the real fix is to correct the Maven metadata on ibiblio. I have no idea how to do that. Thanks, Aaron On 8/10/06, Joe Bohn [EMAIL PROTECTED] wrote: I hit an error attempting to install the plugin for the web console on a little-G tomcat image with the official Geronimo 1.1 release. Are there known problems with this capability? I assumed that this plugin is for this very purpose (since we already include the console with the j2ee image). It looked like the download and install went as expected but failed attempting to start the gbean. I think that somehow the wrong dependencies were installed for geronimo-timer (and perhaps geronimo-derby). For both of these version 1.0 was deployed rather than 1.1. Installation Complete! Used existing: geronimo/j2ee-server//car Used existing: geronimo/j2ee-security//car Used existing: geronimo/tomcat//car Used existing: geronimo/geronimo-management//jar Used existing: geronimo/geronimo-deploy-jsr88//jar Used existing: geronimo/geronimo-service-builder//jar Used existing: geronimo/geronimo-connector-builder//jar Used existing: geronimo/geronimo-naming-builder//jar Used existing: geronimo/geronimo-security-builder//jar Used existing: geronimo/geronimo-j2ee-schema//jar Used existing: xmlbeans/xbean/2.0.0/jar Used existing: stax/stax-api/1.0.1/jar Used existing: geronimo/geronimo-util//jar Installed new: geronimo/system-database//car Installed new: geronimo/geronimo-derby//jar Installed new: org.apache.derby/derby//jar Installed new: org.apache.derby/derbynet//jar Installed new: geronimo/geronimo-timer//jar Installed new: portlet-api/portlet-api/1.0/jar Installed new: org.apache.pluto/pluto/1.0.1/jar Installed new: geronimo/geronimo-console-core//jar Installed new: geronimo/geronimo-upgrade//jar Installed new: geronimo/geronimo-test-ddbean//jar Installed new: geronimo/geronimo-deploy-config//jar Installed new: activemq/activemq-gbean-management-g1_1/3.2.4/jar Installed new: activemq/activemq-gbean-g1_1/3.2.4/jar Installed new: activemq/activemq-core/3.2.4/jar Installed new: geronimo/geronimo-converter//jar Installed new: jdom/jdom//jar Now starting geronimo/webconsole-tomcat/1.1/car... org.apache.geronimo.kernel.config.LifecycleException: start of geronimo/webconsole-tomcat/1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:529) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated
Re: [VOTE] Specs organization, versioning, and releasing
[X] +1 Allow changes
Joe
Jason Dillon 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
Re: XBean site using new G-theme
Look good Jason. I noticed a peculiar thing with the links at the top right of the banner. It seems like clicking on a link like Source functions as a toggle ... such that if you click it again once there it will take you back to the home page. This is also true of Download and Mailing Lists. Also, clicking on JavaDocs takes me out of the theme completely and doesn't really show javadoc. Joe Jason Dillon wrote: I've just finished the initial re-theme-ification of the XBean site to use the AutoExport template we are using for GMOxSITE. It will eventually make it to: http://geronimo.apache.org/xbean but for now you can see what it looks like here: http://xbean.goopen.org * * * A few things... I had to drop some of the tabs, only using Home and Downloads right now. Since these are images, I can not easily pull content from the wiki to add arbitrary tabs. I will look into fixing, creating border images, so we can drop text into the boxes. I also could not figure out a nice looking way to add the XBean title to the main banner... seems that it does not fit well into the layout. Probably best to get a new graphic that incorporates the G and XBean elements. Might need to get some help from Epiq to get a updated layout that allows use to use the same theme across sub-projects the main site. * * * Take a peek and let me know what you folks think. --jason
Re: XBean site using new G-theme
Jason Dillon wrote: On Aug 21, 2006, at 1:54 PM, Joe Bohn wrote: I noticed a peculiar thing with the links at the top right of the banner. It seems like clicking on a link like Source functions as a toggle ... such that if you click it again once there it will take you back to the home page. This is also true of Download and Mailing Lists. I do not see this... what browser? They are just plain a href= links... I did not need to clear my browser cache to keep from getting the old site pages... but after that I can click the Source link all day and night and it will bring me to: http://geronimo.apache.org/xbean/source.html You're favorite ... IE ;-)I didn't think to check other browsers .. but after reading your response I tried firefox it worked as it should. Some more IE oddities I guess. Also, clicking on JavaDocs takes me out of the theme completely and doesn't really show javadoc. I did not alter the links, I just ported from the previous site. --jason
Re: 1.2 Release - Who's next and what is it?
I've started playing with a mini-G assembly (for lack of a better term) which doesn't even include a web server. I'm also looking at building plugins for tomcat, jetty, etc... The intent to use mini-G as the base and plugins to build a tailor-made Geronimo assembly to fit a user's requirements rather than a one-size-fits-all assemblies. IIUC, this was part of the original intent behind the plugins so I think this fits in pretty well with the general direction based upon discussions I've seen. At the moment what I have is pretty immature, but I was going to start to get some discussion/ideas on this with dev shortly after I had gained a better understanding of plugins in general by creating a first pass at a tomcat plugin. Joe Matt Hogstrom wrote: All, Aaron started a thread back a ways about the 1.2 release. I know that there has been discussion, interest and some action in getting it on the table. At this point I'm not exactly sure what our goals are for the next step of Geronimo and when it will be done. First step is defining what goes into the release and then who wants to guide the release to fruition. I'll start the what's in it thread and I think the whose going to do it will get resolved once we finish this piece. Given our past experience if we would like to hit another dot release this year then I think we have to be releasing in November. Thanksgiving and Christmas seem to burn up the last month and a half. So I think a release around November 15th sounds about right. This means (working backwards) we'd need to have a branch by October 15th. So, with that in mind we have a little less than 2 months for development. With that in mind here is the list of things I remember off the top of my head. I'll follow this thread and put out a summary note. I'm putting people's names next to items I remember them mentioning; I'm not assigning work :) Java 5 Ready JPA Integration (Open JPA / Cayenne) (I think Dain or Blevins ?) Clustering support (Gianny / Jeff) Pluggable JACC (Jencks) Performance (Matt) Lot's of other stuff I'm missing ?
Re: Returning to Commit-Then-Review?
+1 for CTR which I believe is accurately summarized in its most common manifestation by Kevan's #1. Joe Kevan Miller wrote: On Aug 22, 2006, at 7:02 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache Geronimo has been operating mostly under the Review-Then-Commit model for a couple of months now, and I think the issues the change was intended to highlight have been .. well, highlighted. How do people feel about the idea of switching back to Commit-Then-Review at this point? I'm certainly in favor of switching back. However, RTC has put an improved focus on communication within the community. I definitely want that to continue. Possible options would include: 1) Follow CTR. Document best practices and use community-based persuasion to keep things working well. 2) Follow CTR. Follow a strict procedure for documenting enhancements. 2) Follow RTC. Relax the reviewed/merged/tested aspect of RTC 3) Follow RTC. Institue a lazy consensus policy 4) 2 3 5) etc. IMO, 1) is the way a healthy community should be operating and I think that's the process we should be following. The best practices/guidelines should not be strict dogma -- common sense should prevail. It's communication that's important, not process. Guidelines are something along the lines of: 1) For larger changes (or potentially controversial changes), announce your intentions. Give the community an indication of what you're planning. You should allow enough time (and detail) to allow the community to understand and discuss. 2) Before you commit your changes, document your change. Describe what you are doing, why you are doing it, and provide an overview of how you did it (or a roadmap on how you plan on doing it). --kevan
building eclipse projects with M2 build
The cwiki inidicates that we can build projects for eclipse using the m2 build with the following command: mvn -o eclipse:eclipse However, when I attempt to do this I get the error below. Has anybody been successful in building the eclipse projects using M2? [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be found [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be f ound at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1281) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:381) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:135) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.version.PluginVersionNotFoundException: The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be found at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:225) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:87) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:158) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252) ... 14 more [INFO] [INFO] Total time: 8 seconds [INFO] Finished at: Wed Aug 23 13:51:13 EDT 2006 [INFO] Final Memory: 19M/37M
Re: [ANNOUNCE] Welcome David Blevins as the newest member of the Geronimo PMC
Way to go David!!! Joe Matt Hogstrom wrote: Please welcome David Blevins as the newest member of the Geronimo PMC. David recently accepted the invitation to join the PMC. David is part of the OpenEJB project that we depend on so heavily and that is joining Apache as an Incubator project. David is also a great mentor and community builder. Give it up for David :-0
Re: building eclipse projects with M2 build
Thanks Ian. I did attempt to run it both on-line as well as off-line. Either way I get the same result. Do you see something different? Joe [EMAIL PROTECTED] wrote: The -o switch tells mvn not to attempt to download any plugins or dependencies, using only whatever is in your local repository. If this is your first time running the eclipse:eclipse goal then the necessary plugin won't be present. Try running 'mvn eclipse:eclipse' (i.e., no '-o' switch). HTH, Ian It's better to be hated for who you are than loved for who you're not Ian D. Stewart Distributed Computing Engineer II DSS eCommerce Engineering JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Joe Bohn [EMAIL PROTECTED] nk.netTo Geronimo Dev 08/23/2006 01:53 dev@geronimo.apache.org PM cc Subject Please respond to building eclipse projects with M2 [EMAIL PROTECTED] build he.org The cwiki inidicates that we can build projects for eclipse using the m2 build with the following command: mvn -o eclipse:eclipse However, when I attempt to do this I get the error below. Has anybody been successful in building the eclipse projects using M2? [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be found [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be f ound at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1281) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:381) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:135) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.version.PluginVersionNotFoundException: The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be found at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:225) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:87) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:158) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252) ... 14 more [INFO] [INFO] Total time: 8 seconds [INFO
Re: building eclipse projects with M2 build
Thanks Jeff. That did the trick for me too!!! Joe Jeff Genender 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. Jeff Joe Bohn wrote: Thanks Ian. I did attempt to run it both on-line as well as off-line. Either way I get the same result. Do you see something different? Joe [EMAIL PROTECTED] wrote: The -o switch tells mvn not to attempt to download any plugins or dependencies, using only whatever is in your local repository. If this is your first time running the eclipse:eclipse goal then the necessary plugin won't be present. Try running 'mvn eclipse:eclipse' (i.e., no '-o' switch). HTH, Ian It's better to be hated for who you are than loved for who you're not Ian D. Stewart Distributed Computing Engineer II DSS eCommerce Engineering JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Joe Bohn [EMAIL PROTECTED] nk.netTo Geronimo Dev 08/23/2006 01:53 dev@geronimo.apache.org PM cc Subject Please respond to building eclipse projects with M2[EMAIL PROTECTED] build he.org The cwiki inidicates that we can build projects for eclipse using the m2 build with the following command: mvn -o eclipse:eclipse However, when I attempt to do this I get the error below. Has anybody been successful in building the eclipse projects using M2? [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be found [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be f ound at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1281) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:381) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:135) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.version.PluginVersionNotFoundException: The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be found at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:225) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:87) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:158
Re: littleG (minimal-tomcat-server) status
I'd really like to get a committer to look into these changes and hopefully commit them fairly quickly. David J ... I know that you're tied up with the configID changes. Is there somebody else that could take a quick look at these changes? I'm concerned that the current activity to convert from M1 to M2 might result in some of these changes being lost in the conversion. For example, the patch includes a change to the tomcat module which I see is being actively converted to M2. I should note that these changes are a bit risky and will possibly cause some NoClassDefFoundErrors on specific scenarios when integrated. I have done the following tests for both the jetty and tomcat assemblies but I obviously can't cover everything. 1) Verified the itests are successful. 2) Verified that deployment of a web app works 3) Verified that the main console portlets still function (all main GUIs presented without error and some detailed functions verified) 4) Verified that all of the daytrader application web primitives continued to work.At this point it might be best to integrate the changes and deal with the fall-out. Thoughts? Thanks, Joe Joe Bohn wrote: Ah ... thanks for the clarification Kevan. In that case I don't think it is needed in rmi-naming with the uber-spec removed. I couldn't find any reason to include the corba spec in the rmi-naming config. I've created a new patch with this change and added it to GERONIMO-1613. So, with the corba spec removed our image size is back down to about 15.7 meg. Thanks, Joe Kevan Miller wrote: On 3/3/06, *Joe Bohn* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I just added an updated patch to Geronimo-1613 https://issues.apache.org/jira/browse/GERONIMO-1613 After some painstaking effort, I was finally able to remove the uber-spec dependency from rmi-naming which should have resulted in an additional savings in little-G of nearly 1.2 meg. Unfortunately, I had to add in some individual spec jars that were not previously included and which decreased the savings somewhat. The real disappointment was when I picked up the latest image yesterday to create the patch and noticed Kevan's change to include the CORBA spec in rmi-naming to work around some other problem. This adds back in about 640K. The comment indicates that this is only temporary. How long will it be needed there and is somebody working to remove it? Hi Joe, If you've removed the uber-jar, then you should be able to remove the CORBA spec jar (assuming you're including the CORBA spec jar at an appropriate location...). The uber-jar currently contains bad corba spec classes. The dependency in rmi-naming put the CORBA spec jar in the classpath in front of the uber-jar. I also plan on fixing the uber-jar (getting the proper spec classes in the uber-jar). --kevan So, after all that the latest patch only takes us from 16.4 to about 16.3 meg ... but we'll drop more when CORBA comes out of rmi-naming. Would it be possible to get this patch committed to trunk before too much more work happens on the maven2 effort? I think that it would benefit the migration and integration if these updated project.xmls were used as the starting point. Joe -- Joe Bohn joe.bohn at earthlink.net http://earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: littleG (minimal-tomcat-server) status
Thank you Jeff. Please note that as you look at GERONIMO-1613, ( http://issues.apache.org/jira/browse/GERONIMO-1613 ) the only patch you should need to apply is the latest one 1613_RemoveDeps4.patch. This is all inclusive of the other patches with the exception of the first patch that Dave Jencks already integrated a few weeks back. BTW, there are also two JIRAs for some problems that I noticed were introduced as a result of the first patch (sigh) GERONIMO-1634 ( https://issues.apache.org/jira/browse/GERONIMO-1634 ) and GERONIMO-1699 ( https://issues.apache.org/jira/browse/GERONIMO-1699 ). Joe Jeff Genender wrote: Hi Joe, Thanks for working on this...I'll take a look. Jeff Joe Bohn wrote: I'd really like to get a committer to look into these changes and hopefully commit them fairly quickly. David J ... I know that you're tied up with the configID changes. Is there somebody else that could take a quick look at these changes? I'm concerned that the current activity to convert from M1 to M2 might result in some of these changes being lost in the conversion. For example, the patch includes a change to the tomcat module which I see is being actively converted to M2. I should note that these changes are a bit risky and will possibly cause some NoClassDefFoundErrors on specific scenarios when integrated. I have done the following tests for both the jetty and tomcat assemblies but I obviously can't cover everything. 1) Verified the itests are successful. 2) Verified that deployment of a web app works 3) Verified that the main console portlets still function (all main GUIs presented without error and some detailed functions verified) 4) Verified that all of the daytrader application web primitives continued to work.At this point it might be best to integrate the changes and deal with the fall-out. Thoughts? Thanks, Joe Joe Bohn wrote: Ah ... thanks for the clarification Kevan. In that case I don't think it is needed in rmi-naming with the uber-spec removed. I couldn't find any reason to include the corba spec in the rmi-naming config. I've created a new patch with this change and added it to GERONIMO-1613. So, with the corba spec removed our image size is back down to about 15.7 meg. Thanks, Joe Kevan Miller wrote: On 3/3/06, *Joe Bohn* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I just added an updated patch to Geronimo-1613 https://issues.apache.org/jira/browse/GERONIMO-1613 After some painstaking effort, I was finally able to remove the uber-spec dependency from rmi-naming which should have resulted in an additional savings in little-G of nearly 1.2 meg. Unfortunately, I had to add in some individual spec jars that were not previously included and which decreased the savings somewhat. The real disappointment was when I picked up the latest image yesterday to create the patch and noticed Kevan's change to include the CORBA spec in rmi-naming to work around some other problem. This adds back in about 640K. The comment indicates that this is only temporary. How long will it be needed there and is somebody working to remove it? Hi Joe, If you've removed the uber-jar, then you should be able to remove the CORBA spec jar (assuming you're including the CORBA spec jar at an appropriate location...). The uber-jar currently contains bad corba spec classes. The dependency in rmi-naming put the CORBA spec jar in the classpath in front of the uber-jar. I also plan on fixing the uber-jar (getting the proper spec classes in the uber-jar). --kevan So, after all that the latest patch only takes us from 16.4 to about 16.3 meg ... but we'll drop more when CORBA comes out of rmi-naming. Would it be possible to get this patch committed to trunk before too much more work happens on the maven2 effort? I think that it would benefit the migration and integration if these updated project.xmls were used as the starting point. Joe -- Joe Bohn joe.bohn at earthlink.net http://earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: M2 migration status
Prasad Kashyap wrote: Here's my next concern. For these modules that have migrated to m2, we should include them in the daily G builds as soon as possible. If we don't pull out the m1 build artifacts, project.xml and maven.xml from the migrated modules, then there's a chance that those may get changed behind our backs while we go forward converting more. There might be a regression of issues. I have the same concern and voiced it (from the other direction) in my post on little-G. We also need to ensure that when we clearly communicate what version(s) of maven are required to build Geronimo, the updated build process, and be aware of the waiting changes that may be impacted before we actually start yanking things. To accomplish that last goal we need some way to communicate changes that are waiting or in-progress which may affect or be affected by the M2 conversion. Then we can work together more closely to ensure that nothing is lost during the conversion. I will add comments to the M2 migration status list with a reference to the little-G JIRA for items where I am aware of overlap. Can others please do the same for items they are involved in? Thanks, Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: M2 migration status
One other thing. Most of my changes for little-G https://issues.apache.org/jira/browse/GERONIMO-1613 were in the configurations rather than the modules. These aren't yet included in the list of things to be migrated. I've updated the Migration Status page to include lists for the configs and assemblies. Joe Joe Bohn wrote: Prasad Kashyap wrote: Here's my next concern. For these modules that have migrated to m2, we should include them in the daily G builds as soon as possible. If we don't pull out the m1 build artifacts, project.xml and maven.xml from the migrated modules, then there's a chance that those may get changed behind our backs while we go forward converting more. There might be a regression of issues. I have the same concern and voiced it (from the other direction) in my post on little-G. We also need to ensure that when we clearly communicate what version(s) of maven are required to build Geronimo, the updated build process, and be aware of the waiting changes that may be impacted before we actually start yanking things. To accomplish that last goal we need some way to communicate changes that are waiting or in-progress which may affect or be affected by the M2 conversion. Then we can work together more closely to ensure that nothing is lost during the conversion. I will add comments to the M2 migration status list with a reference to the little-G JIRA for items where I am aware of overlap. Can others please do the same for items they are involved in? Thanks, Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: littleG (minimal-tomcat-server) status
1613_RemoveDeps4.patch Jeff Genender wrote: Hey Joe, Which patch is the most up-to-date one to use? Jeff Joe Bohn wrote: Thank you Jeff. Please note that as you look at GERONIMO-1613, ( http://issues.apache.org/jira/browse/GERONIMO-1613 ) the only patch you should need to apply is the latest one 1613_RemoveDeps4.patch. This is all inclusive of the other patches with the exception of the first patch that Dave Jencks already integrated a few weeks back. BTW, there are also two JIRAs for some problems that I noticed were introduced as a result of the first patch (sigh) GERONIMO-1634 ( https://issues.apache.org/jira/browse/GERONIMO-1634 ) and GERONIMO-1699 ( https://issues.apache.org/jira/browse/GERONIMO-1699 ). Joe Jeff Genender wrote: Hi Joe, Thanks for working on this...I'll take a look. Jeff Joe Bohn wrote: I'd really like to get a committer to look into these changes and hopefully commit them fairly quickly. David J ... I know that you're tied up with the configID changes. Is there somebody else that could take a quick look at these changes? I'm concerned that the current activity to convert from M1 to M2 might result in some of these changes being lost in the conversion. For example, the patch includes a change to the tomcat module which I see is being actively converted to M2. I should note that these changes are a bit risky and will possibly cause some NoClassDefFoundErrors on specific scenarios when integrated. I have done the following tests for both the jetty and tomcat assemblies but I obviously can't cover everything. 1) Verified the itests are successful. 2) Verified that deployment of a web app works 3) Verified that the main console portlets still function (all main GUIs presented without error and some detailed functions verified) 4) Verified that all of the daytrader application web primitives continued to work.At this point it might be best to integrate the changes and deal with the fall-out. Thoughts? Thanks, Joe Joe Bohn wrote: Ah ... thanks for the clarification Kevan. In that case I don't think it is needed in rmi-naming with the uber-spec removed. I couldn't find any reason to include the corba spec in the rmi-naming config. I've created a new patch with this change and added it to GERONIMO-1613. So, with the corba spec removed our image size is back down to about 15.7 meg. Thanks, Joe Kevan Miller wrote: On 3/3/06, *Joe Bohn* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I just added an updated patch to Geronimo-1613 https://issues.apache.org/jira/browse/GERONIMO-1613 After some painstaking effort, I was finally able to remove the uber-spec dependency from rmi-naming which should have resulted in an additional savings in little-G of nearly 1.2 meg. Unfortunately, I had to add in some individual spec jars that were not previously included and which decreased the savings somewhat. The real disappointment was when I picked up the latest image yesterday to create the patch and noticed Kevan's change to include the CORBA spec in rmi-naming to work around some other problem. This adds back in about 640K. The comment indicates that this is only temporary. How long will it be needed there and is somebody working to remove it? Hi Joe, If you've removed the uber-jar, then you should be able to remove the CORBA spec jar (assuming you're including the CORBA spec jar at an appropriate location...). The uber-jar currently contains bad corba spec classes. The dependency in rmi-naming put the CORBA spec jar in the classpath in front of the uber-jar. I also plan on fixing the uber-jar (getting the proper spec classes in the uber-jar). --kevan So, after all that the latest patch only takes us from 16.4 to about 16.3 meg ... but we'll drop more when CORBA comes out of rmi-naming. Would it be possible to get this patch committed to trunk before too much more work happens on the maven2 effort? I think that it would benefit the migration and integration if these updated project.xmls were used as the starting point. Joe -- Joe Bohn joe.bohn at earthlink.net http://earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: M2 migration status
anita kulshreshtha wrote: I am in favor of running parallel builds until all the modules can be built even by skipping the tests. Then we need to go through the dependencies and change their scopes (compile/test/runtime) and see how m2 handles it. I do not think maven.xmls are being modified , please correct me if I am wrong. People modifying project.xml chould make a note in the jira that the dependency list has been modified. Though if we do the scope thing right, we should end up with the same list... Well that is my impression... I did have to modify just one maven.xml in client-builder but only to invoke the dependency plugin. Most of the other changes are in project.xml as you expect (which, btw, is the case for the tomcat module). The changes that I needed to make were to remove, add, and relocate dependencies so these changes would need to be integrated prior to changing the scopes for M2 or they would be lost. Thanks, Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Error during server startup
I created a JIRA for this problem a week ago or so. https://issues.apache.org/jira/browse/GERONIMO-1676 I haven't had chance yet to look into a fix ... but it only seems to happen with the tomcat assemblies and seemed to be introduced about the time we upgraded to the new tomcat image. Joe anita kulshreshtha wrote: This applies to rev 385723. I am getting the following error during server startup. Booting Geronimo Kernel (in Java 1.4.2_09)... log4j:ERROR setFile(null,true) call failed. java.io.FileNotFoundException: \var\log\geronimo.log (The system cannot find the path specified) at java.io.FileOutputStream.openAppend(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:177) at java.io.FileOutputStream.init(FileOutputStream.java:102) at org.apache.log4j.FileAppender.setFile(FileAppender.java:272) at org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java :156) at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:151) at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:2 47) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.j ava:123) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.j ava:87) at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigura tor.java:645) at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigura tor.java:603) at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyC onfigurator.java:500) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurato r.java:406) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurato r.java:432). Thnaks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Error during server startup
The logs are created in Jetty for me for using the same build that gives me the error in the tomcat images (both j2ee-tomcat-server and minimal-tomcat-server). Here's one other peculiar thing. I don't see this error on windows if I start the server using startup.bat or geronimo.bat run and the log file is created. It's only when I start the server using java bin\server.jar that I see this problem. Joe anita kulshreshtha wrote: This is a problem with jetty-server as well. Jetty-server does not produce stack trace but the log files (geronimo.log, jetty-*.log) are not created. Thnaks Anita --- Jeff Genender [EMAIL PROTECTED] wrote: I am not able to reproduce this on a Mac or Linux...I need to get my hands on a Windowz box to see what is up. Can you gage what GBean is getting started that is failing? Joe Bohn wrote: I created a JIRA for this problem a week ago or so. https://issues.apache.org/jira/browse/GERONIMO-1676 I haven't had chance yet to look into a fix ... but it only seems to happen with the tomcat assemblies and seemed to be introduced about the time we upgraded to the new tomcat image. Joe anita kulshreshtha wrote: This applies to rev 385723. I am getting the following error during server startup. Booting Geronimo Kernel (in Java 1.4.2_09)... log4j:ERROR setFile(null,true) call failed. java.io.FileNotFoundException: \var\log\geronimo.log (The system cannot find the path specified) at java.io.FileOutputStream.openAppend(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:177) at java.io.FileOutputStream.init(FileOutputStream.java:102) at org.apache.log4j.FileAppender.setFile(FileAppender.java:272) at org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java :156) at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:151) at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:2 47) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.j ava:123) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.j ava:87) at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigura tor.java:645) at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigura tor.java:603) at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyC onfigurator.java:500) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurato r.java:406) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurato r.java:432). Thnaks Anita __ 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 -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Error during server startup
Actually, I suspect you're hitting a different problem there. There is a problem with the Derby log viewer and a missing class. There is a defect that I opened about a month ago on that one and I do have a patch for it - https://issues.apache.org/jira/browse/GERONIMO-1634 It's waiting for a committer to take an interest and integrate it. Any takers? Joe anita kulshreshtha wrote: I spoke too soon.. This trace is produced by clicking on 'Server Logs' from console. Thnaks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: After a fresh restart of windows jetty-server is working fine. Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: This is a problem with jetty-server as well. Jetty-server does not produce stack trace but the log files (geronimo.log, jetty-*.log) are not created. Thnaks Anita --- Jeff Genender [EMAIL PROTECTED] wrote: I am not able to reproduce this on a Mac or Linux...I need to get my hands on a Windowz box to see what is up. Can you gage what GBean is getting started that is failing? Joe Bohn wrote: I created a JIRA for this problem a week ago or so. https://issues.apache.org/jira/browse/GERONIMO-1676 I haven't had chance yet to look into a fix ... but it only seems to happen with the tomcat assemblies and seemed to be introduced about the time we upgraded to the new tomcat image. Joe anita kulshreshtha wrote: This applies to rev 385723. I am getting the following error during server startup. Booting Geronimo Kernel (in Java 1.4.2_09)... log4j:ERROR setFile(null,true) call failed. java.io.FileNotFoundException: \var\log\geronimo.log (The system cannot find the path specified) at java.io.FileOutputStream.openAppend(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:177) at java.io.FileOutputStream.init(FileOutputStream.java:102) at org.apache.log4j.FileAppender.setFile(FileAppender.java:272) at org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java :156) at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:151) at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:2 47) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.j ava:123) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.j ava:87) at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigura tor.java:645) at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigura tor.java:603) at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyC onfigurator.java:500) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurato r.java:406) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurato r.java:432). Thnaks Anita __ 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Error during server startup
Hmmm I'm not sure about that exception. The error that I fixed is
a java.lang.NoClassDefFoundError exception on Tomcat and materialized
itself somewhat differently on Jetty. I wonder if the change you made
results in the tomcat logs either not being created or created in a
different location that is causing the NPE.
Did you try (without your change) to start the server via the scripts
(either startup.bat or geronimo.bar run) and verify that the logs are
also created via that scenario (as they are for me)? If, after that,
you access the server logs from the web console I would expect you to
get the NoClassDefFoundError which the JIRA I referenced earlier fixes.
Joe
anita kulshreshtha wrote:
With this change the tomcat-server starts properly
and geronimo.log is created. However on clicking
'Server Logs' I get this trace. Does your patch for
GERONIMO-1634 cover this also? IIRC
server-log4j.properties file is copied from
configs/tomcat ?
Thnaks
Anita
--- anita kulshreshtha [EMAIL PROTECTED] wrote:
Joe,
yeah, the server logs in Jetty look ok.
The server-log4j.properties files are different
for
2 servers -
JETTY -
log4j.appender.FILE.file=${org.apache.geronimo.server.dir}/var/log/geronimo.log
TOMCAT -
log4j.appender.FILE.file=${org.apache.geronimo.base.dir}/var/log/geronimo.log
I will use .server.dir and report back.
Thanks
Anita
--- Joe Bohn [EMAIL PROTECTED] wrote:
Actually, I suspect you're hitting a different
problem there. There is
a problem with the Derby log viewer and a missing
class.
There is a defect that I opened about a month ago
on
that one and I do
have a patch for it -
https://issues.apache.org/jira/browse/GERONIMO-1634
It's waiting for a committer to take an interest
and
integrate it. Any
takers?
Joe
anita kulshreshtha wrote:
I spoke too soon.. This trace is produced by
clicking on 'Server Logs' from console.
Thnaks
Anita
--- anita kulshreshtha [EMAIL PROTECTED]
wrote:
After a fresh restart of windows
jetty-server
is
working fine.
Thanks
Anita
--- anita kulshreshtha [EMAIL PROTECTED]
wrote:
This is a problem with jetty-server as well.
Jetty-server does not produce stack trace but
the
log
files (geronimo.log, jetty-*.log) are not
created.
Thnaks
Anita
--- Jeff Genender [EMAIL PROTECTED] wrote:
I am not able to reproduce this on a Mac or
Linux...I need to get my
hands on a Windowz box to see what is up. Can
you
gage what GBean is
getting started that is failing?
Joe Bohn wrote:
I created a JIRA for this problem a week ago
or
so.
https://issues.apache.org/jira/browse/GERONIMO-1676
I haven't had chance yet to look into a fix
...
but it only seems to
happen with the tomcat assemblies and seemed
to
be
introduced about the
time we upgraded to the new tomcat image.
Joe
anita kulshreshtha wrote:
This applies to rev 385723. I am getting
the
following error during server startup.
Booting Geronimo Kernel (in Java
1.4.2_09)...
log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException:
\var\log\geronimo.log
(The system cannot find the
path specified)
at
java.io.FileOutputStream.openAppend(Native
Method)
at
java.io.FileOutputStream.init(FileOutputStream.java:177)
at
java.io.FileOutputStream.init(FileOutputStream.java:102)
at
org.apache.log4j.FileAppender.setFile(FileAppender.java:272)
at
org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java
:156)
at
org.apache.log4j.FileAppender.activateOptions(FileAppender.java:151)
at
org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:2
47)
at
org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.j
ava:123)
at
org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.j
ava:87)
at
org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigura
tor.java:645)
at
=== message truncated ===
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
Joe Bohn
joe.bohn at earthlink.net
He is no fool who gives what he cannot keep, to gain what he cannot
lose. -- Jim Elliot
Re: svn commit: r383123 - /geronimo/trunk/configs/openejb/project.xml
(ServiceConfigBuilder.java:204)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:167)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.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:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$f5ac0140.buildConfiguration(generated)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:279)
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:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:389)
at
org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:294)
... 61 more
Caused by:
org.apache.geronimo.kernel.repository.MissingDependencyException: uri
activecluster/activecluster/1.2-20051115174934/jar not found in repository
... 84 more
[EMAIL PROTECTED] wrote:
Author: jlaskowski
Date: Sat Mar 4 06:47:45 2006
New Revision: 383123
URL: http://svn.apache.org/viewcvs?rev=383123view=rev
Log:
GERONIMO-1688 Fresh build fails because of unsatisfied dependency on
activecluster in configs/openejb
Modified:
geronimo/trunk/configs/openejb/project.xml
Modified: geronimo/trunk/configs/openejb/project.xml
URL:
http://svn.apache.org/viewcvs/geronimo/trunk/configs/openejb/project.xml?rev=383123r1=383122r2=383123view=diff
==
--- geronimo/trunk/configs/openejb/project.xml (original)
+++ geronimo/trunk/configs/openejb/project.xml Sat Mar 4 06:47:45 2006
@@ -324,6 +324,12 @@
artifactIdcommons-discovery/artifactId
version${commons_discovery_version}/version
/dependency
+
+dependency
+groupIdactivecluster/groupId
+artifactIdactivecluster/artifactId
+version${wadi_activecluster_version}/version
+/dependency
/dependencies
/project
--
Joe Bohn
joe.bohn at earthlink.net
He is no fool who gives what he cannot keep, to gain what he cannot
lose. -- Jim Elliot
little-G fixes
Jeff or Aaron, After the first patch for little-G was integrated about a month ago, I soon discovered two items in the console that were broken because they relied upon dependencies specified in other configurations that were removed. I have patches for these items that are waiting to be integrated. Could one of you take a look at them? https://issues.apache.org/jira/browse/GERONIMO-1634 https://issues.apache.org/jira/browse/GERONIMO-1699 Thanks, Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Console Patches
Aaron, Regarding 1130, I just attached a new version of the patch for the current trunk so it is ready to go be considered. Please use the newly added patch (1130_WebServerStatsJetty.patch). 1408 would be fine to include in the second group of JIRAs (those w/o patches) but it really isn't directly related to this JIRA. This only deals with the web server statistics ... not the Network Listeners portlet that is presented on the same page. Thanks for looking into these. Joe Aaron Mulder wrote: I'm looking at console issues and patches in JIRA. The following ones look like good candidates. Does anyone have any comments or thoughts on which ones may be or not be ready or any dependencies between them? Thanks, Aaron Patches: 1037: confirmation when deleting things 1130: make more generic web statistics for Jetty (NOTE: waiting on updated patch from Joe), see also 1408 1182: web connector portlet confirmation, cancel button, etc. 1196: keystore portlet improvements (empty alias blows up) 1199: keystore portlet improvements (display fingerprints) 1396: more consistent look and feel for tables 1413: set JSPs to UTF-8 1414: set icon for about page 1426: console breakage on Windows with spaces in install path 1484: display logged-in username 1498: not serializable exception due to JDBC driver download 1503: keystore portlet improvements (passwords) 1524: allow selection of multiple JDBC driver JARs 1529: show Geronimo version number in console 1531: keystore portlet enhancements (delete cert/key) 1572: better error if cookies are disabled 1634: NoClassDefFoundError in log viewer (NOTE: Jeff looking at this) 1699: missing JDOM classes (NOTE: Jeff looking at this) 1700: stack trace printed if deploy app that's already deployed 1701: improvements to EJB portlet No patch yet, but should be looked at: 1273: More context info when adding JMS protocol 1376: display URL for deployed web apps 1388: Make sure Go button is visible 1390: Link not always visible 1391: keystore error, looks like keystore issues described above 1592: Add new security realm type 1692: Next server restart after console edits dumps stack trace 1704: Need to be able to select a JAR for a security realm 1705: AJAX progress bar for JDBC driver download 1711: Add restart option for web connector 1721: Ability to delete a security realm 1741: Ability to redeploy an application 1746: Change to log config file not respected on restart -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: New Feature: Configuration Import/Export
This is a good summary of the possibilities Matt. I've got some questions/comments. 2. User downloads a bootstrap agent (much like Cygwin) and then chooses either the pacakges they want (specific OSS projects) or the features they want (JMS, Servlet 2.4, EJB 1.1, Spring, etc.) The downloaded agent would resolve the required dependencies and suck down the appropriate parts and configure the runtime. 3. Similar paradigm to above but rather than running a single server instance they would specify a target location to export a server image that would be bootable. The instance they operate from is an AppServer factory and not an AppServer instance. But they aren't interacting with an AppServer in #2 either ... right? Isn't the bootstrap in #2 really just an AppServer Factory as well? The interfaces would include a GUI (nice user interface, dynamic resolution of dependencies, etc.) as well as a command line utility that could build the instances required for a specific set of applications. Can you clarify the command line utility? Do you envision a command line that accepts all of the configuration choices as parameters or are you thinking of a response/properties/XML/whatever file that would be created to specify the particulars of a configuration and then the factory uses this information to generate an executable instance? I assume that's what you mean but I may be missing some other aspect of the proposal. 4. A variation on the above would also install the application artifacts and create disposable runtimes. Users could then take these images and distribute them in a cluster and they would be fully functional containers but are designed to be disposed of after use. The paradigm of defining and iterating a server instance doesn't exist in this mode. The disposable instances would be able to federate into a managable cluster from an operations perspective but would be limited to starting and stopping the servers and pulling runtime statistics. I think that we may need to provide some capability for iteration and updates ... but I agree that we should limit this. For example, I can see why it might be desirable to change ports, users, passwords, queues, drivers, etc... in a configuration without requiring the creation of a new image. The problem is that there isn't necessarily a clear cut distinction between normal maintenance and what would require a new configuration. Perhaps you're correct that we should prevent any updates and always require a new image but I'm not sure how that will be perceived by the user. Replacing the image typically requires an interruption of service while an update such as installing a new service or application doesn't impact other applications on the server. I guess I'm thinking that we might need to give the user the choice. Basically let the resultant server image be no different than other images which can be incrementally enhanced if the user chooses to do so. However, the creation of the complete runtime image gives them the choice to maintain the template or the individual instances. Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Problems building on windows
I've been encountering a number of problems building on Windows which seem to be steadily getting worse and I was wondering if anybody else is experiencing this (and hopefully has some work-arounds). - Out of Memory Errors. These seem to be related to two different things: 1) Long file names. If I remember correctly Windows has issues if the file names exceed 256 bytes. I've been working with multiple levels of geronimo concurrently and so have had to name the root something other than simply geronimo. It seems like if I start to get longer than 12 characters or so I begin to hit these problems. I think we may be getting into trouble here with the depth of our packages and embedded classes. 2) Extra garbage hanging around in %temp% from previous builds. The geronimo build leaves a lot of trash in %temp% and when that seems to cause problems with out of memory errors and subsequent builds. - File IO errors when running the CRLF plugin. These may be related to the %temp% storage but I seem to get them at times even when I've just cleaned out my %temp%. Running back to back I get different results. Thanks for the help, Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Problems building on windows
John, First, thanks for the detailed response! I'll have to try out some of the utilities that you mention, reproduce the problems, and get back with the details. But I'd like to say how much I appreciate all of the advice you've provided. More responses in-line. John Sisson wrote: Joe Bohn wrote: I've been encountering a number of problems building on Windows which seem to be steadily getting worse and I was wondering if anybody else is experiencing this (and hopefully has some work-arounds). - Out of Memory Errors. These seem to be related to two different things: 1) Long file names. If I remember correctly Windows has issues if the file names exceed 256 bytes. I've been working with multiple levels of geronimo concurrently and so have had to name the root something other than simply geronimo. It seems like if I start to get longer than 12 characters or so I begin to hit these problems. I think we may be getting into trouble here with the depth of our packages and embedded classes. Yes, it is concerning.. http://mail-archives.apache.org/mod_mbox/geronimo-dev/200601.mbox/[EMAIL PROTECTED] I also have had to shorten my directory path I am building in. The long file name issue should go way when we move to JDK 1.5_06 but a number of other programs on Windows that deal with files also have the issue (e.g. Windows File Explorer, WinZip, Visual SourceSafe) so this issue could bite us with users complaining that other tools they are using can't work with Geronimo's long directory paths. Do we have a JIRA for this issue? I'm not aware of a JIRA for this. I'll search again and if I can't find one I'll create one. Another tool to add to the list is xcopy. 2) Extra garbage hanging around in %temp% from previous builds. The geronimo build leaves a lot of trash in %temp% and when that seems to cause problems with out of memory errors and subsequent builds. See http://issues.apache.org/jira/browse/GERONIMO-777 Hmmm ... I had seen this JIRA and all the discussion but somehow I always only focused on the config-store part of it and I haven't noticed that problem recently. Are you seeing these problems on trunk, 1.0 or 1.1 branches or all? I'm seeing them on 1.0 and trunk for sure. I haven't been keeping careful tabs on 1.1 but I'd be surprised if it was any different there. What JDK are you using? Sun JDK 1.4.2_08 (build 1.4.2_08-b03) For a long time I have been using the following (from memory I think there was something in maven or one of the libraries it uses that had a leak - not sure if this still exists) SET MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=128m What command are you using to build? (this could possibly affect what code gets invoked and how much memory is used). Do you have MAVEN_OPTS environment variables set? No, I don't have MAVEN_OPTS set but I'll certainly give that a try. I build with many different commands and from many different location depending upon what I'm doing. This problem seems more pronounced when I do a full clean build with itests maven m:clean new from geronimo root. I will try to reproduce with the same JDK level and commands once you provide the info. - File IO errors when running the CRLF plugin. These may be related to the %temp% storage but I seem to get them at times even when I've just cleaned out my %temp%. Running back to back I get different results. One thing to try is disabling XP's file indexing (which I have done). It looks like this has caused problems for Java elsewhere (see the workaround in this bug).. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5006328 I also found that http://www.sysinternals.com/Utilities/ProcessExplorer.html utility is good for tracking down processes that have file handles open. Use the Find--Find Handle menu option and specify the file name. I had some similar problems for a while and ended up tracking it down my incorrectly configured Diskeeper disk defragmenter that had paused defragmentation and held file handles open. Have you tried with real-time virus checking disabled to check it isn't a virus checker causing issues? What files are you getting the IO errors on? Can you include the error output? Thanks for the pointers to utilities. I'll give them a try (including disabling the real-time virus checker but it seems to happen with too great a frequency to be this). The FileIO errors are always on files deep within the config-store when it fails during the CRLF plugin ... perhaps related to the long file names again. It makes me wonder if we need to have some kind of retry logic for file operations if we are possibly competing with file indexers etc so we can run on a Windows box without problems. I noticed some of the Ant tasks have retry logic for some file operations: http://svn.apache.org/viewcvs.cgi/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Mkdir.java?view=markup http
Re: Problems building on windows
:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] Finished at : Wednesday, March 29, 2006 9:59:36 AM EST 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] 09:59:36,042 INFO [App] -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Problems building on windows
Thanks for the information Kevan. Kevan Miller wrote: [snip] I'd concentrate on the Temp files to begin with... They're more likely at the heart of the problem -- they give an explanation for why this is only happening on Windoze... Each open file descriptor is going to be consuming memory. As I recall, the delete-on-exit function will also consume memory. How many temp files are being created during the course of a build? It appears that there are about 47 of the test* files, 35 of the geronimo-deploymentUtil* files, and 31 package*.tmpdir directories containing a varying number of files each. All together, there are 249 files and 469 directories created in temp as a result of this build attempt. Around LDAP Demo for Jetty, my build on Mac OSX is only using ~ 60megs. By the end of the build, however, I'm using 90 out of 108 megs. So, we don't have a lot of headroom. Quite possible that there's a memory leak floating around... --kevan (who is happy to not have this problem, yet... ;-) [snip] -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Problems building on windows
I ran another clean build but this time with the MAVEN_OPTS settings John mentioned below. I'm not sure yet if it's indicative of a general solution (since it didn't always fail) but it didn't fail with the out of memory error this time. However, this time it did fail with the fileIO exception (actually, it's a java.io.FileNotFoundException). assemble:package-assembly: [echo] Preparing CRLF line endings in text based files for zip distribution [zip] Building zip: C:\geronimo\assemblies\j2ee-tomcat-server\target\geronimo-tomcat-j2ee-1.2-SNAPSHOT.zip [echo] Preparing LF line endings in text based files for tar.gz distribution BUILD FAILED File.. C:\geronimo\maven.xml Element... maven:reactor Line.. 227 Column -1 Unable to obtain goal [multiproject:install-callback] -- C:\Documents and Settings\Administrator\.maven\cache\geronimo-assembly-plugin-1.2.0-8\plugin.jelly:352: -1: ant:fixcrlf java.io.FileNotFoundException: C:\geronimo\assemblies\j2ee-tomcat-server\target\geronimo-1.2-SNAPSHOT\config-store\30\geronimo-console-standar d-1.2-SNAPSHOT.war\WEB-INF\work\org\apache\jsp\WEB_002dINF\view\certmanager\generateCSRNormal_jsp.java (Access is denied) Total time : 36 minutes 34 seconds 15:58:36,934 INFO [App] Total time : 36 minutes 34 seconds The referenced file (generateCSRNormal_jsp.java) does not exist in this work location (just as the exception indicated). It's the only jsp that doesn't have both the java and class files in that work location. However, it makes me wonder if we need to be processing these work files anyway in the plugin. Do we really need to touch the line endings on these files (if in fact that is what we're doing at this point in time)? As a side note: After the build %temp% included about the same number of test* files as my earlier post (47), only 9 geronimo-deploymentUtil* files and 11 package*.tmpdir directories. John Sisson wrote: Joe Bohn wrote: I've been encountering a number of problems building on Windows which seem to be steadily getting worse and I was wondering if anybody else is experiencing this (and hopefully has some work-arounds). - Out of Memory Errors. These seem to be related to two different things: 1) Long file names. If I remember correctly Windows has issues if the file names exceed 256 bytes. I've been working with multiple levels of geronimo concurrently and so have had to name the root something other than simply geronimo. It seems like if I start to get longer than 12 characters or so I begin to hit these problems. I think we may be getting into trouble here with the depth of our packages and embedded classes. Yes, it is concerning.. http://mail-archives.apache.org/mod_mbox/geronimo-dev/200601.mbox/[EMAIL PROTECTED] I also have had to shorten my directory path I am building in. The long file name issue should go way when we move to JDK 1.5_06 but a number of other programs on Windows that deal with files also have the issue (e.g. Windows File Explorer, WinZip, Visual SourceSafe) so this issue could bite us with users complaining that other tools they are using can't work with Geronimo's long directory paths. Do we have a JIRA for this issue? 2) Extra garbage hanging around in %temp% from previous builds. The geronimo build leaves a lot of trash in %temp% and when that seems to cause problems with out of memory errors and subsequent builds. See http://issues.apache.org/jira/browse/GERONIMO-777 Are you seeing these problems on trunk, 1.0 or 1.1 branches or all? What JDK are you using? For a long time I have been using the following (from memory I think there was something in maven or one of the libraries it uses that had a leak - not sure if this still exists) SET MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=128m What command are you using to build? (this could possibly affect what code gets invoked and how much memory is used). Do you have MAVEN_OPTS environment variables set? I will try to reproduce with the same JDK level and commands once you provide the info. - File IO errors when running the CRLF plugin. These may be related to the %temp% storage but I seem to get them at times even when I've just cleaned out my %temp%. Running back to back I get different results. One thing to try is disabling XP's file indexing (which I have done). It looks like this has caused problems for Java elsewhere (see the workaround in this bug).. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5006328 I also found that http://www.sysinternals.com/Utilities/ProcessExplorer.html utility is good for tracking down processes that have file handles open. Use the Find--Find Handle menu option and specify the file name. I had some similar problems for a while and ended up tracking it down my incorrectly configured Diskeeper disk defragmenter that had paused defragmentation and held file handles open. Have you tried with real-time virus
Re: Restructuring the console src dirs
+1 Joe Prasad Kashyap wrote: Last week Aaron, Joe, Paul and I discussed on IRC the intent to restructure the src dirs of the console under the application directory. (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330) Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660) will seek to achieve this. Just wanted to send this out to the larger community before we commit the patch. Currently, the console is made up of 4 dirs under applications - geronimo - applications + console-core + console-ear + console-standard + console-framework The new structure will be as follows - geronimo - applications - console --- new dir added here. existing console sub-dirs moved under this. + console-core + console-ear + console-standard + console-framework This will keep all the console dirs in one place. As the console grows to add more components/directories, it won't clutter up the applications dir. Comments welcome. Cheers Prasad -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Servlet GBeans for Tomcat
Anita, Can you provide some more details on this? Is there a JIRA containing a patch with the changes? Some more comments/questions in-line below: anita kulshreshtha wrote: Hi All, An implementation of servlet GBeans for Tomcat is now available. I have discussed this with Jeff and would like your comments about including it in the upcoming release. To give some background, the current Tomcat integration is at module level. This implementation will provide finer grained integration, i.e. at the servlet level. This will provide access to Tomcat servlets. This is a requirement as per JSR77.3.17. There is already a Servlet object extending J2EEManagedObject org.apache.geronimo.management.Servlet. Are you talking about a different interface or the Tomcat implementation of that interface? This implementation also provides access to tomcat performance statistics via JSR77. Some of these statistics are needed for the admin console. This is also required by JSR77.6.32 Another feature is a webapp which can be used to access tomcat internals, i.e. all the Mbeans! It can be added to the applications directory for now. We can consider merging it with either the debug or admin console at a later time. How does webapp differ from the JMXExplorer that is still waiting to be integrated in GERONIMO-1163? From a user's perspective it will make both web containers have a similar look and feel. But your change only includes the tomcat implementation for now ... correct? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Cannot build 1.1 on Windows - long file paths
] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(CompilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(CompilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(CompilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(CompilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(CompilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addPacks(CompilerConfig.java:632) [java] ... 3 more [java] [java] (tip : use -? to get the commmand line parameters) [java] [ERROR] Java Result: 1 BUILD FAILED File.. C:\geronimo1.1\maven.xml Element... maven:reactor Line.. 63 Column -1 Unable to obtain goal [multiproject:install-callback] -- C:\Documents and Settings\sissonj\.geronimo-1.1.x-maven\cache\geronimo-izpa ck-plugin-1.1-SNAPSHOT\plugin.jelly:78:-1: ant:copy Warning: Could not find file C:\geronimo1.1\assemblies\j2ee-installer\target\g eronimo-installer-1.1-SNAPSHOT.jar to copy. Total time : 21 minutes 1 seconds Finished at : Tuesday, 4 April 2006 17:31:34 -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Dependencies on jars in 1.1 and beyond
I have a situation where I need to make several web modules dependent upon a large number of jars. I'd like to add the jars to the Geronimo repo and add the dependencies into the plans for the web modules. However, most of the jars don't follow the maven naming convention because the names don't include a version (and I'd rather not rename all the jars). I know that there are changes being included in 1.1 to make the version in a reference optional. However, I doubt that it is possible to reference a jar in the repo that doesn't contain any version. Just thought I should ask in case it really is possible. I could see where this might be something users would like when they have picked up jars from various places which may or may not contain a version in the jar name. If it *is* possible to have a non-versioned jar in the repo ... how do we differentiate in geronimo 1.1 between a dependency on a non-versioned jar versus a dependency on the latest version of a jar (in case both are present). Thanks for the help, Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Dependencies on jars in 1.1 and beyond
Yes, I agree that the assumption would be a non-versioned jar would be considered version 0.0. But I haven't thought of a way yet to support both versioned and unversioned jars when calling out the dependency without a schema change. For example, suppose the repo contains both mattsjar.jar and mattsjar-1.0.jar. If I want the latest version of a jar in Geronimo 1.1 I just omit the version number from the dependency. No version number = the latest version number. So, that means that we can't use the lack of a version number to mean we have a dependency on the unversioned jar. Short of a change in the schema, I'm not sure how to support both versioned and unversioned jars with an optional version element. I hate to open this issue up again now but I think we need to consider this if we want to support unversioned jars (which I think would make the life a bit easier for our users). Joe Matt Hogstrom wrote: I think an implicit Version of 0.0 might be reasonable for jars that do not follow Maven conventions. Personally I think forcing everyone to rename their jars is a bit intrusive as not everyone would want / need to do this. How about this: mattsjar.jar would be implicitly mattsjar-0.0.jar without the usewr having to change a thing. Thoughts? Matt Joe Bohn wrote: I have a situation where I need to make several web modules dependent upon a large number of jars. I'd like to add the jars to the Geronimo repo and add the dependencies into the plans for the web modules. However, most of the jars don't follow the maven naming convention because the names don't include a version (and I'd rather not rename all the jars). I know that there are changes being included in 1.1 to make the version in a reference optional. However, I doubt that it is possible to reference a jar in the repo that doesn't contain any version. Just thought I should ask in case it really is possible. I could see where this might be something users would like when they have picked up jars from various places which may or may not contain a version in the jar name. If it *is* possible to have a non-versioned jar in the repo ... how do we differentiate in geronimo 1.1 between a dependency on a non-versioned jar versus a dependency on the latest version of a jar (in case both are present). Thanks for the help, Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Dependencies on jars in 1.1 and beyond
I can't claim that the scenario will be very common. However, for completeness, it seems like we need to address the possibility if we support unversioned jars. Actually, to be clear, I think we need to speak in terms of a maven version versus a non-maven version. My real concern is that we shouldn't force users to conform to the maven version convention if they already have jars that they are using which either don't include a version at all or don't conform to the maven syntax. In addition to the 2 issues you mentioned I was trying to get at a 3rd issue: 1) where do we put the jars physically? - I'm not sure I follow the need to add the jars to the root of the repo. My assumption was that we would continue to follow the groupID/jar organization. Since the groupID doesn't actually get included in the physical file name, I don't think there is a problem from a user perspective if we stick to the group/jars structure (if maven can handle jars under a group that aren't versioned not sure if this is case or not). Since my main concern was to avoid the need to rename the jars I don't think the group is a big deal. 2) How do we treat these jars in the server? - Within the server I think it's fair to treat these jars as if they were maven version 0.0.0-0. In this case the non-maven version jar would be used in the case that the dependency omits the version and there is no maven version of the jar available. In fact, I think this is good because it gives users a way to gradually move from the non-maven version jars to the maven convention gradually as they upgrade each jar. Without changing any dependencies they will automatically pick up the newer version. Of course, that assumes that the jar didn't already follow a non-maven version scheme (such as _1_1_0) in which case they may have to change the artifact portion of their dependencies as they convert to maven versions. 3) How do we specify dependencies on non-versioned jars? - Even though I like the approach presented in the previous question is still makes it does take away some control from the user. With maven versions a user a choose to either ignore the version or use a specific version. However, with this approach there is no way to use a specific non-versioned jar if there is a newer versioned one available. One way to solve this odd case would be to have a keyword value for the version field such as null which would mean that the dependency can only be fulfilled by a the non-maven versioned jar. If no such jar exists we could then look use the latest maven version available. However, if it's useful to use a lower maven versioned jar then I think it would also be useful to use a lower non-maven versioned jar. I hope that last point is clear even if we decide that it isn't a scenario we choose to support. Joe Dain Sundstrom wrote: Do we need to support this scenario? It seems far fetched to have both a mattsjar.jar and a mattsjar-1.0.jar available. As for unversioned jars, I think we need to decide how we want to handle these in the repository. I see two issues that we need to address: where do we put the jars physically in the server, and how to we treat these jars in the server? For the first, I was thinking we could just let users dump unversioned jars in the root of the repository dir. The the server would treat them as belonging to the unspecified (default) group and have a version of 0.0.0-0. I don't think having extra jars in the root of the repo will hurt the maven code, but we do have some weird side effects of the making the jar version 0.0.0-0. What if the user puts the mattsjar-1.0.jar in the root directory? It will have name mattsjar-1.0 and version 0.0.0-0. We could decide to attempt to parse the version out of the jar, but that will not work reliably as people put jars in with poorly formed names like mattsjar1.0.jar or mattsjar-jdk-1.4.jar. How do you think we should handle this? -dain On Apr 5, 2006, at 6:06 AM, Joe Bohn wrote: Yes, I agree that the assumption would be a non-versioned jar would be considered version 0.0. But I haven't thought of a way yet to support both versioned and unversioned jars when calling out the dependency without a schema change. For example, suppose the repo contains both mattsjar.jar and mattsjar-1.0.jar. If I want the latest version of a jar in Geronimo 1.1 I just omit the version number from the dependency. No version number = the latest version number. So, that means that we can't use the lack of a version number to mean we have a dependency on the unversioned jar. Short of a change in the schema, I'm not sure how to support both versioned and unversioned jars with an optional version element. I hate to open this issue up again now but I think we need to consider this if we want to support unversioned jars (which I think would make the life a bit easier
Re: Shared Libs
I think the shared libraries may solve this issue for a lot of people. Do you have some more thoughts on how this capability may be made available to users? Looking at what was checked in already it seems that the user would have to create an array of the libDirs in code via some home-grown mechanism and then invoke your class to update the classpath. Do you already have plans for an easier way to expose this to the users (perhaps via some server configuration or some new elements on the deployment plans to add new shared libraries)? Joe Dain Sundstrom wrote: One new feature I'm working on for 1.1 is support for tomcat style shared libs. This creates a shared class loader visible to all j2ee applications which contains shared/lib/*.jar and shared/classes/ to the class loader. Will this address your issues? -dain On Apr 4, 2006, at 7:35 PM, Joe Bohn wrote: I have a situation where I need to make several web modules dependent upon a large number of jars. I'd like to add the jars to the Geronimo repo and add the dependencies into the plans for the web modules. However, most of the jars don't follow the maven naming convention because the names don't include a version (and I'd rather not rename all the jars). I know that there are changes being included in 1.1 to make the version in a reference optional. However, I doubt that it is possible to reference a jar in the repo that doesn't contain any version. Just thought I should ask in case it really is possible. I could see where this might be something users would like when they have picked up jars from various places which may or may not contain a version in the jar name. If it *is* possible to have a non-versioned jar in the repo ... how do we differentiate in geronimo 1.1 between a dependency on a non- versioned jar versus a dependency on the latest version of a jar (in case both are present). Thanks for the help, Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
ConfigurationInstaller - InvalidConfigurationException in Geronimo 1.1
I'm getting the following error attempting to start a server with the latest 1.1 image. Seems to be related to some changes introduced last night for a ConfigurationInstaller gbean. Booting Geronimo Kernel (in Java 1.4.2_08)... [ ] 0% 1s Startup failed org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more Server shutdown begun Server shutdown completed -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: ConfigurationInstaller - InvalidConfigurationException in Geronimo 1.1
:-) Hey ... for 2:30 in the morning I'm impressed that it compiles! I think the problem is that the Maven2Repository class implements the WriteableListableRepository interface but not WriteableRepository interface the ConfigurationInstaller gbean needs. Joe Aaron Mulder wrote: Well come on, man, it builds, what more do you want? Aaron On 4/14/06, Joe Bohn [EMAIL PROTECTED] wrote: I'm getting the following error attempting to start a server with the latest 1.1 image. Seems to be related to some changes introduced last night for a ConfigurationInstaller gbean. Booting Geronimo Kernel (in Java 1.4.2_08)... [ ] 0% 1s Startup failed org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more Server shutdown begun Server shutdown completed -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: ConfigurationInstaller - InvalidConfigurationException in Geronimo 1.1
Scratch that suggestion ... I sent it too soon. WriteableListableRepository extends WriteableRepository so that isn't the problem. Joe Joe Bohn wrote: :-) Hey ... for 2:30 in the morning I'm impressed that it compiles! I think the problem is that the Maven2Repository class implements the WriteableListableRepository interface but not WriteableRepository interface the ConfigurationInstaller gbean needs. Joe Aaron Mulder wrote: Well come on, man, it builds, what more do you want? Aaron On 4/14/06, Joe Bohn [EMAIL PROTECTED] wrote: I'm getting the following error attempting to start a server with the latest 1.1 image. Seems to be related to some changes introduced last night for a ConfigurationInstaller gbean. Booting Geronimo Kernel (in Java 1.4.2_08)... [ ] 0% 1s Startup failed org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference named Repository in gbean geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceMod ule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ConfigurationInstaller at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:282) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:335) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:155) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:252) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:367) Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?j2eeType=GBean,name=Repository#org.apache.geronimo.kernel.repo sitory.WriteableRepository] at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:586) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:562) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:557) at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:280) ... 6 more Server shutdown begun Server shutdown completed -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
support for shared libraries/classes in Geronimo 1.1
Dain added some initial support for shared libraries in 1.1 and (with the help of David Jencks) I have a configuration and gbean to make the feature available to applications to use. I'll create a patch for this today for Geronimo 1.1. However, I have a question about how public we want this function to be. There has been some concern that we shouldn't encourage the use of shared libraries. The thought is that it is better to use the repository and explicit dependencies. If we include the gbean in the configuration for an assembly then the any specified shared library(ies) or class directory(ies) must exist or an exception is thrown. At the moment I'm using var/shared/lib and var/shared/classes as the defaults. If we just add the gbean to the assemblies without the default libraries then the user will have to update the configuration to use the feature and specify the attributes for the libs or classes. That isn't very user friendly and doesn't provide a default location. On the other hand, adding in defaults requires that we also add in the empty directories which is a bit of an advertisement to use them. At the moment, I'm leaning toward adding the default directories. Any recommendations before I create the patch? Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: support for shared libraries/classes in Geronimo 1.1
Sorry, I should have described the function a little better. There is one shared library gbean that will enhance the classpath with the jars from any number of shared libraries or shared class directories. The gbean is a child of rmi-naming. An application that wants to use the shared library would call out a dependency on the sharedlib config. Joe Aaron Mulder wrote: I'm not really following your description of how this will work, but this is my thought: - We pick a shared library directory (var/shared/lib is fine with me) and make that the standard. I don't think shared classes are even necessary, though I don't object to having a directory for that too. - If the directory is not present during startup, we create it - By default, application deployments do not see shared libraries - If you put an enable-shared-libs / in the environment in your plan, then the shared libraries are added to the application class loader I'm imaging there's one shared library GBean in the whole server and you set the directory on that in the j2ee-server plan and we don't encourage people to change it (though they could in config.xml I suppose). Is that what you have or are you thinking of one GBean per application deployment? Thanks, Aaron On 4/14/06, Joe Bohn [EMAIL PROTECTED] wrote: Dain added some initial support for shared libraries in 1.1 and (with the help of David Jencks) I have a configuration and gbean to make the feature available to applications to use. I'll create a patch for this today for Geronimo 1.1. However, I have a question about how public we want this function to be. There has been some concern that we shouldn't encourage the use of shared libraries. The thought is that it is better to use the repository and explicit dependencies. If we include the gbean in the configuration for an assembly then the any specified shared library(ies) or class directory(ies) must exist or an exception is thrown. At the moment I'm using var/shared/lib and var/shared/classes as the defaults. If we just add the gbean to the assemblies without the default libraries then the user will have to update the configuration to use the feature and specify the attributes for the libs or classes. That isn't very user friendly and doesn't provide a default location. On the other hand, adding in defaults requires that we also add in the empty directories which is a bit of an advertisement to use them. At the moment, I'm leaning toward adding the default directories. Any recommendations before I create the patch? Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: support for shared libraries/classes in Geronimo 1.1
Some additional information in the description below Joe Bohn wrote: Sorry, I should have described the function a little better. There is one shared library gbean that will enhance the classpath with the jars from any number of shared libraries or shared class directories. It updates the classloader by appending the sharedlibs to the multiparentclassloader (the new sharedlib class and the interaction with the multiparentclassloader is what Dain had already created). The gbean is a child of rmi-naming. An application that wants to use the shared library would call out a dependency on the sharedlib config. Joe Aaron Mulder wrote: I'm not really following your description of how this will work, but this is my thought: - We pick a shared library directory (var/shared/lib is fine with me) and make that the standard. I don't think shared classes are even necessary, though I don't object to having a directory for that too. - If the directory is not present during startup, we create it - By default, application deployments do not see shared libraries - If you put an enable-shared-libs / in the environment in your plan, then the shared libraries are added to the application class loader I'm imaging there's one shared library GBean in the whole server and you set the directory on that in the j2ee-server plan and we don't encourage people to change it (though they could in config.xml I suppose). Is that what you have or are you thinking of one GBean per application deployment? Thanks, Aaron On 4/14/06, Joe Bohn [EMAIL PROTECTED] wrote: Dain added some initial support for shared libraries in 1.1 and (with the help of David Jencks) I have a configuration and gbean to make the feature available to applications to use. I'll create a patch for this today for Geronimo 1.1. However, I have a question about how public we want this function to be. There has been some concern that we shouldn't encourage the use of shared libraries. The thought is that it is better to use the repository and explicit dependencies. If we include the gbean in the configuration for an assembly then the any specified shared library(ies) or class directory(ies) must exist or an exception is thrown. At the moment I'm using var/shared/lib and var/shared/classes as the defaults. If we just add the gbean to the assemblies without the default libraries then the user will have to update the configuration to use the feature and specify the attributes for the libs or classes. That isn't very user friendly and doesn't provide a default location. On the other hand, adding in defaults requires that we also add in the empty directories which is a bit of an advertisement to use them. At the moment, I'm leaning toward adding the default directories. Any recommendations before I create the patch? Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Error trying to build 1.1 from scratch.
I was assuming that this error was because we were still waiting on fixes for the long path issue (particularly one from David Jencks). However, it looks like that was integrated on Sunday. Looking more closely at this error the path length of the jar we're trying to remove is 275 characters. The removal of the SHAPSHOT suffixes should help ... but daytrader also has some long names that contribute to the problem (daytrader-derby-jetty-streamer-client). I know it's just a band-aid .. but there any chance we could shorten this (and similar) names? I think we've got to get building working completely on 1.1 before we release. Joe Joe Bohn wrote: Rick, You must be building on windows :-) .The failure looks like the same error that I get on windows because of the long path name problem. If you don't need to run the installer you can choose to skip that and build the other assemblies manually (they appear to work fine. NOTE: for the j2ee-tomcat-server you need to remove any previous target or the build will fail attempting to remove it ... long path name problem again). As to the long time-outs when you try to build online ... I'm not sure. It always takes longer and attempts to download and fail many items ... but it never take me 4 hours. Joe Rick McGuire wrote: I'm trying to create a fresh build of 1.1, and I'm having some problems getting everything to build cleanly. If I build without the -o option, it's taking 4-5 hours to build, most of that time spent attempting to download jars from the maven repositories (and it appears, with lots of timeouts). Is there any way to speed this up? If I build with -o, then the build fails with the error below. I don't know if this is because -o disabled the repository download or some other problem. At 4-5 hours per build attempt, it will take me a long time to figure this out :-( Is anybody else seeing this error, or is it just an artifact of using the -o option? Any suggestions on how to speed these builds up so they complete in less than geologic time? Rick [java] - Fatal error : [java] C:\Geronimo\builds\1.1\assemblies\j2ee-installer/target/geronimo-1 .1-SNAPSHOT/geronimo-izpack.xml:96: C:\Geronimo\builds\1.1\assemblies\j2ee-insta ller\target\geronimo-1.1-SNAPSHOT\repository\geronimo\daytrader-derby-jetty-stre amer-client\1.1-SNAPSHOT\daytrader-derby-jetty-streamer-client-1.1-SNAPSHOT.car\ activemq\activemq-ra\3.2.4-SNAPSHOT\rar\activecluster-1.1-SNAPSHOT.jar [java] com.izforge.izpack.compiler.CompilerException: C:\Geronimo\builds\1.1 \assemblies\j2ee-installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml:96: C:\Geronimo\builds\1.1\assemblies\j2ee-installer\target\geronimo-1.1-SNAPSHOT\re pository\geronimo\daytrader-derby-jetty-streamer-client\1.1-SNAPSHOT\daytrader-d erby-jetty-streamer-client-1.1-SNAPSHOT.car\activemq\activemq-ra\3.2.4-SNAPSHOT\ rar\activecluster-1.1-SNAPSHOT.jar [java] at com.izforge.izpack.compiler.CompilerConfig.parseError(Compile rConfig.java:1531) [java] at com.izforge.izpack.compiler.CompilerConfig.addPacks(CompilerC onfig.java:636) [java] at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(Co mpilerConfig.java:317) [java] at com.izforge.izpack.compiler.CompilerConfig.main(CompilerConfi g.java:1847) [java] at com.izforge.izpack.compiler.Compiler.main(Compiler.java:620) [java] Caused by: java.io.FileNotFoundException: C:\Geronimo\builds\1.1\asse mblies\j2ee-installer\target\geronimo-1.1-SNAPSHOT\repository\geronimo\daytrader -derby-jetty-streamer-client\1.1-SNAPSHOT\daytrader-derby-jetty-streamer-client- 1.1-SNAPSHOT.car\activemq\activemq-ra\3.2.4-SNAPSHOT\rar\activecluster-1.1-SNAPS HOT.jar [java] at com.izforge.izpack.compiler.PackInfo.addFile(PackInfo.java:19 3) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(Com pilerConfig.java:959) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(Com pilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(Com pilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(Com pilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(Com pilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(Com pilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(Com pilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(Com pilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(Com pilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addRecursively(Com pilerConfig.java:969) [java] at com.izforge.izpack.compiler.CompilerConfig.addPacks(CompilerC
Re: Update on Long Paths
We own John Sisson thanks for the patch ... not me. I tested the patch
prior to the commit but it was John that created the patch just before
leaving on vacation. So, thank you John! I for one, am very grateful
to be able to build on windows ago!
Joe
Dain Sundstrom wrote:
Ever since I applied Prasad's patch for jaring the WEB-INF/classes of
our wars the server has been well under the windows path length limit.
Unfortunately, you couldn't build the server on windows since we
actually assemble the server in a deeply nested path.
I just applied a patch from Joe Bohn that shortened the names of nested
modules in ears. This has brought the longest path in our build to:
229 assemblies/j2ee-installer/target/geronimo-1.1-SNAPSHOT/repository/
geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/jsp-examples-tomcat-1.1-
SNAPSHOT.car/WEB-INF/classes/org/apache/jsp/jsp2/jspattribute/
shuffle_jsp$shuffle_jspHelper.class
So as long as you checkout path is less then 27 characters you should
be able to build on windows.
-dain
On Apr 14, 2006, at 6:03 PM, John Sisson wrote:
It would be good if we could use precompiled jsps so the server is
always responsive - that first time hit often happens when you are
running a demo :-)
John
Prasad Kashyap wrote:
I could not use the ant task to precompile jsps. Using the following,
simply nothing happens.
ant:taskdef classname=org.apache.jasper.JspC name=ant:jasper2
classpathref=jspc.classpath/
ant:jasper2 validateXml=false uriroot=${webroot}
webXmlFragment=${webroot}/generated_web.xml addWebXmlMappings=true
outputDir=${outDir} /
So by passing a few more args to our existing ant:java execution, I
was able to generate the xml file too. Using the option
addWebXmlMappings, I tried to merge the web.xmls but JspC cried that
it was a unrecognized option.
!-- arg value=-addWebXmlMappings/
arg value=true/ --
Looking at the JspC code,
http://svn.apache.org/repos/asf/tomcat/jasper/branches/tc5.0.x/
jasper2/src/share/org/apache/jasper/JspC.java
it seems like you can't pass addWebXmlMappings in a java command line
argument. It is not recognized or set by the setArgs(). Seems like a
jasper bug ?
So I added another goal to our deployment plugin called mergeWebXML.
This goal merges the generated web.xml fragment with the existing one
from source.
When I spoke to the Tomcat guys, they feel that precompiling JSPs
doesn't buy us anything anymore, except for that first time hit. The
request mapper is supposedly fixed in 5.5.x versions and thus we
shouldn't see any other performance hit.
Anyways, I have uploaded the patch to
http://issues.apache.org/jira/browse/GERONIMO-1844
Cheers
Prasad
On 4/14/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
OK. I'll take care of the JSP pages. I am done with jar'ing the
generated class files. I shall look into generating a web.xml and
merging it.
Cheers
Prasad
On 4/13/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
Prasad got the patch working on all web applications. The next big
offenders left are the auto generated WebServices wrapper class and
the precompiled JSP pages. David Jencks has a patch for the
WebServices class, but we are waiting to get the TCK running so we
can judge the impact. I disabled precompiled JSP pages, as they
didn't work anyway. We generate the classes and compile them, but we
never added them to the class path and we are not merging generated-
web.xml into our web.xml. I'm hoping Prasad has time to tackle this
one.
With these patches in, except for the WS class, the longest paths
including server name is 224 and 217 characters:
geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-jetty-
streamer-client/1.1-SNAPSHOT/daytrader-derby-jetty-streamer-
client-1.1-SNAPSHOT.car/activemq/activemq-ra/3.2.4-SNAPSHOT/rar/
activemq-optional-3.2.4-SNAPSHOT.jar
geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1-
SNAPSHOT/webconsole-jetty-1.1-SNAPSHOT.car/geronimo-console-
framework-1.1-SNAPSHOT.war/WEB-INF/config/services/
PortletDefinitionRegistryService.properties
These will become 179 and 189 characters when we drop -SNAPSHOT from
all of the version numbers. I'm also hoping we can change the name
daytrader-derby-jetty-streamer-client to something shorter.
This is a lot better and will allow for at least 50 characters of
head room, which I hope is plenty for windows users.
As for next steps, I'd like to get the hot deploy service working
better. With the addition of the in-place deployment feature from
Gianny and the timestamp I added to the configuration, we should be
able to write a much better service. Once we have the better hot
deploy service, we will be able to implement the flat deployment
model that Hernan and others have suggested.
-dain
--
Joe Bohn
joe.bohn at earthlink.net
He is no fool who gives what he cannot keep, to gain what he cannot
lose. -- Jim Elliot
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Congratulations Rick!!! Great work and certainly well deserved. Joe Geir Magnusson Jr wrote: In recognition of his contributions and participation in the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Rick McGuire. Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer. Please join us in congratulating Rick. The Apache Geronimo PMC -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Release 1.1 - Question about Java 1.5 Warning message
+1 on #3. We should not the JDK 1.5 concerns in the readme. I also like Dave Colasurdo's suggestion that we issue a warning message if we can detect that we are running on JDK 1.5 and CORBA EJBs are being used. Not sure how feasible (or visible) it will be to add those warnings but it would be nice to have. Joe Matt Hogstrom wrote: All, I wanted to clarify what our plan is for the JVM Check that is done to verify that a user is running on Java 1.4. If someone chooses to accept the responsibility and use Java 1.5 it would be rather annoying to have this message come out every time. I think we have three options: 1. Leave it as is (warning comes out all the time) 2. Allow someone to set a property or other mechanism to tell the server to not to issue the warning message. 3. Take the message out because 1.1 will tolerate 1.5 and we're not shipping DayTrader installed so the javax.xml.namespace.QName problem won't be visible. Personally I prefer 3 if there are no other issues. Thoughts? Matt -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: hot deployment directory
SFHD is similar to hot deployer but has these differences: - It is not an integrated part of the server itself. It is a gbean itself that must be deployed into the server to use it. - It only takes action when the SFHD gbean is started (which is typically during server startup). Hot Deploy monitors files for changes at any time. - It monitors just one directory for one deployable element - It controls the life-cycle of the element it deploys. I'm not sure if hot deploy does this as well. For example, a war deployed via this mechanism is not added to the server config.xml for auto-start. You might want to consider my patches to SFHD as well included in geronmio-1946 http://issues.apache.org/jira/browse/GERONIMO-1946 . These haven't been blessed by Dain yet so they may change some. Joe Rakesh Ranjan wrote: Can anybody please tell me the purpose of SingleFileHotDeploy service. Is it same as the purpose of hot deployment directory? Rakesh Ranjan On 5/4/06, *Dain Sundstrom* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I suggest you start by reading the SingleFileHotDeploy service I wrote last week. It uses the most recent apis. -dain On May 3, 2006, at 10:30 PM, Rakesh Ranjan wrote: I have seen the same problems with Geronimo-1.1-SNAPSHOT also. So i will create JIRA ID for these two issues and start working. Rakesh Ranjan On 5/4/06, Aaron Mulder [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Please do any work in the 1.1 branch. Right now 1.2 is in a very uncertain state. Though, I suspect the issues will be different in 1.1, so you may want to start by testing the same things there. IIRC, the hot deployer does not yet check the timestamp of the deployments in it its directory during startup and compare those to the timestamps of the current modules to determine whether an existing file there is the same as ever or a new version was copied in while the server was down. That should be doable in 1.1. Thanks, Aaron On 5/4/06, Rakesh Ranjan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Thanks Aaron for the quick response. Here are two issues with Geronimo-1.2-SNAPSHOT which need to be fixed : 1. When Geronimo starts, it try to deploy the modules in the hot deployment directory even if that module is already deployed. Since the application is already deployed, it throws an error : the application already exists in the server. 2. Geronimo is not able to deploy the database plans kept in the hot deployment directory. Rakesh Ranjan On 5/4/06, Aaron Mulder [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: You're welcome to look at that. Can you list the issues you're going to attempt to fix? There seems to be a lot of variation in what people think the problems actually are. Thanks, Aaron On 5/4/06, Rakesh Ranjan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi all, I have not seen much activity in hot deployment directory enhancement. I have seen there are some bugs in the current implementation of hot deployment directory. I am interested to work on this enhancement. So i want to know the current status of this enhancement? Is some other member working on this issue? Rakesh -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Startup messages with URLs
During Geronimo startup we print out all of the URLs for the web applications that are started. For example: Web Applications: http://127.0.0.1:8080/ http://127.0.0.1:8080/admin http://127.0.0.1:8080/none I'm working with the customer that is creating multiple connectors. They are questioning why the URLs only display for one of the connectors (and it appears to be random which connector is used). Is there a reason that we don't show the context path listed under each possible connector? StartupMonitorUtil currently queries each web module GBean for a URLFor attribute which is implemented in either TomcatWebAppContext or JettyWebAppContext depending upon the container. In that code we currently prefer to return the first connector that supports the HTTP protocol. If none are present we then prefer the HTTPS and finally AJP. However, we only return one URL for this query. Would it be helpful if I add a new collection attribute (URLsFor?) and query this attribute during startup so that we can print all possible URLs for the application or do you think this would be confusing? Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Startup messages with URLs
Yes, the customer has multiple HTTP connectors. By random I mean that the customers gets different results than I get. When I run the scenario I always see the first connector that was deployed listed for the applications. When the customer runs the scenario they see the port for the last connector that was deployed in the URL. However, I believe that once a connector for a particular protocol is selected it is consistent for all applications listed at startup. In other words, if there are two HTTP connectors defined (say 8080 and 8090) then all applications are listed under just one of the connectors and not a mixture between the two (or at least that has been my experience and the code seems to back this up). I think it would be good if we could make this predictable in some way. Using the numeric value is certainly one. Using the deployment order of the connectors is another that I think is just as valid. Joe Aaron Mulder wrote: I don't think it's all that useful to print 3+ URLs for each web app. Plus, we don't have the space in the startup output. Are you saying the customer has multiple HTTP connectors and it's random which one of those is selected? Is there any suggested logic for picking one? We could, for example, always pick the lowest port -- it would beat random if only by a little. Thanks, Aaron On 5/9/06, Joe Bohn [EMAIL PROTECTED] wrote: During Geronimo startup we print out all of the URLs for the web applications that are started. For example: Web Applications: http://127.0.0.1:8080/ http://127.0.0.1:8080/admin http://127.0.0.1:8080/none I'm working with the customer that is creating multiple connectors. They are questioning why the URLs only display for one of the connectors (and it appears to be random which connector is used). Is there a reason that we don't show the context path listed under each possible connector? StartupMonitorUtil currently queries each web module GBean for a URLFor attribute which is implemented in either TomcatWebAppContext or JettyWebAppContext depending upon the container. In that code we currently prefer to return the first connector that supports the HTTP protocol. If none are present we then prefer the HTTPS and finally AJP. However, we only return one URL for this query. Would it be helpful if I add a new collection attribute (URLsFor?) and query this attribute during startup so that we can print all possible URLs for the application or do you think this would be confusing? Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: configuration dependencies
Anita,
Sorry for the long delay ... had queued this up to look at later and
later finally arrived. :-)
On the first change we should probably remove unnecessary dependencies
such as jetty in rmi-naming and system-database. I'm sure there are
plenty more.
I'll defer to Aaron on the way versions for dependencies are specified
in the console geronimo-plugin.xml. It seems like the best approach is
to omit the version if possible as with many of the other dependencies
listed. My guess is that there must have been multiple versions
available in the system for activemq and some other modules where they
are hard coded. This may be resolved by now and we might be able to
omit the activemq version entirely.
Can you describe the second patch some more? What is the goal? I
recall that you were trying to build the assemblies without building the
configurations (by just downloading the plugins). This would provide a
faster build (really assembly creation) if you had no need to build
any of the contents of any of the configurations. However, I'm not
certain that is a common case.
Joe
anita kulshreshtha wrote:
David J and Joe,
I am attaching two patches:
The first one configs.patch removes jetty from rmi-naming and
system-database configurations. The
console-tomcat/..geronimo-plugin.xml is using
dependencyactivemq/activemq-gbean-management/3.2.4-SNAPSHOT/jar/dependency
dependencyactivemq/activemq-gbean/3.2.4-SNAPSHOT/jar/dependency
and the versions are hardcoded instead of using ${...}. Is this
desired? If not there is a patch to fix this. This file does not have
its eol style set, hence there are so many lines in the patch.
The second patch shortens the build time and makes the server
assembly independent of the earlier build stages. Is this useful?
How is geronimo-console...ear being generated?
Thanks
Anita
--- anita kulshreshtha [EMAIL PROTECTED] wrote:
Joe,
Thanks! Sending it to the list..
--- Joe Bohn [EMAIL PROTECTED] wrote:
Anita,
Ahh ... now I see what you were trying to accomplish. I think this
is a
good question for the dev list.
I personally don't think that it is important to ensure that your
build
includes/excludes match what is in geronimo with M1 exactly. In
fact, I
think what we have in M1 is really just a jumble of things that
people
at one time thought were needed, copied from other configurations,
or
whatever to get things to build. Sure, there are very specific,
well
placed dependencies that were added as well. But I don't think
that
the
omissions were necessarily deliberate just as not all of the
additions
were deliberate (such as is likely the case with the jetty deployer
in
remote-deploy-tomcat).
Also, based upon my recent experience with the
geronimo.dependencies,
even those are often the result of copied code. I didn't resolve
all
of these geronimo.dependencies by a long shot. I was specifically
focused on making changes and validating dependencies to remove
unnecessary items from inclusion in the little-G assembly. So I'm
fairly sure there are still plenty of bogus geronimo.dependencies
there too.
Yes, with the M2 transitive dependencies we may very well be able
to
build and bad things could happen because of a missing
geronimo.dependency when you attempt to run the server. However, I
consider this no different than today where you must manually add
both.
It's still very possible to add one and not the other with the
result
being a server that cannot start (in fact I just did it this
morning
on
my test machine). However, I think this typically speaks more to
a
problem in the building of the configuration rather than the
building
of
the assembly. External dependencies by configuration must be added
to
the verified/added to the assemblies when the configurations are
added
to the assemblies.
Joe
anita kulshreshtha wrote:
Joe,
Thanks. I was trying to understand the process of assembly. so
I
did
the following :
1. checkout ONLY top level dir, /etc and /assemblies.
2. cd j2ee-tomcat-server
3. maven
I think I should be able to do this without building
(modules,
configs, apps) anything else. It worked fine until I got to
g/javamail/../car. A jar was missing.
Now why would someone in the right mind do that... It is for
M2. As
you said downloading everything is automatic in m2, Trying to
prevent
one dependency is a nightmare. It will be quite a challenge to
find
equivalent of g.reference, g.import and g.dependency using only
'provided' and 'exclude' and arrive at the same list as m1.
You have answered my question that the
javamail-transport..jar
is
needed for j2ee-tomcat-server. So if it gets added by M2 it will
not be
a bad thing!
I built the server using above 3 step today, the error
message
is gone. But this jar is not in GERONIMO_HOME/repository/.. When
I
start this server bad things
Re: New Feature Wednesday
I agree with everyone else that it is really great to have these unstable builds being produced and posted on a regular basis! It will help encourage users to pick up the latest more quickly and provide us with quicker feedback. How is it expected that users will find these unstable builds? Is there some way to get to the unstable builds from the geronimo web site? I think more people would find it and use it if there was a link from the downloads page to http://cvs.apache.org/dist/geronimo/unstable/ . One more question: How long will these builds hang around? I see that there are still builds from 1.0 out there. Just a nit - but it would be nice if we could put the most recent build at the top of the list. Joe David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Latest +Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
replacing tomcat classes
Jeff, I am working with a user that is moving some applications from tomcat to geronimo. Due to some problems they have had to modify tomcat source. I was chatting with jasonb on the tomcat irc channel and he recommended that we only build the classes rather than rebuilding all of tomcat. He discouraged rebuilding all of tomcat because there are many permutations that can result in different build images and we should run with as much of the official tomcat build as possible to avoid problems. He also indicated that Tomcat's directory structure provides a place to put these patch classes in CATALINA_HOME/server/classes . Is there a similar place that we can put classes when tomcat is running under geronimo to have them picked up? Adding the tomcat classes to our new sharedlib doesn't seem to be the right place because it would require a dependency from the tomcat config on sharelib. The net result would be that all tomcat apps would potentially pick up user classes added in sharedlib even if the user only intended these classes for some subset of the apps. Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: replacing tomcat classes
Thanks for the quick response Jeff. I like the idea of a system patch location in the classpath where we can pick up patches for anything we might include in a geronimo assembly. I too was confused by the tomcat recommendation but it does seem that they have a strategy for addressing necessary changes with minimal interference in tomcat. I have also noticed some things that make me wonder if my local tomcat build of 5.5.15 really does match the official 5.5.15 build. For example, the only source for 5.5.15 that I could find was a zip file rather than a svn branch or tag. I am not able to build from the unpacked zip without making a change to move the contents of jasper/jasper2 into the jasper directory itself. And the version that is displayed when I hit tomcat with my rebuilt image is 5.5 rather than 5.5.15 as with the official image. Until we figure out the correct approach for Geronimo I'm thinking of using a compromise solution. The changes I need in tomcat result in 4 of the 13 tomcat jars getting rebuilt. Rather than replacing all of the tomcat jars with my local build I have verified that replacing just the 4 changed jars appears to work fine. I'm hoping this hybrid solution keeps most of the official tomcat image and our local changes. I haven't noticed any problems. Assuming the source is mostly identical (apart from our changes) does anybody know of a reason that I should definitely not take this approach? Joe Jeff Genender wrote: Ultimately, we probably would need to somehow build a patch directory or lib directory where we can ensure the URLClassLoader picks that up before all other classes. I think this is probably a good idea to have as well, so that we could release service paks or patches. I would be interested in others' thoughts on this, but I think this would be a nice feature to have. Right now I think your only choices are to either hard set a classpath to be sure the patches get picked up first or build a hacked Tomcat version, or rebuild Tomcat. Dain or David Jencks may be able to verify if the classpath solution would work or not as I have not dug into the new G classloaders to know if this would even be possible. The best solution right now may be to just build TC. I am a little confused as to why the TC guys say not to build the Tomcat from source (after its hacked). It seems like just an ant build script, so I don't understand why this is being discouraged. This way you can replace the Tomcat jars in the repo and you are good to go. Jeff Joe Bohn wrote: Jeff, I am working with a user that is moving some applications from tomcat to geronimo. Due to some problems they have had to modify tomcat source. I was chatting with jasonb on the tomcat irc channel and he recommended that we only build the classes rather than rebuilding all of tomcat. He discouraged rebuilding all of tomcat because there are many permutations that can result in different build images and we should run with as much of the official tomcat build as possible to avoid problems. He also indicated that Tomcat's directory structure provides a place to put these patch classes in CATALINA_HOME/server/classes . Is there a similar place that we can put classes when tomcat is running under geronimo to have them picked up? Adding the tomcat classes to our new sharedlib doesn't seem to be the right place because it would require a dependency from the tomcat config on sharelib. The net result would be that all tomcat apps would potentially pick up user classes added in sharedlib even if the user only intended these classes for some subset of the apps. Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: replacing tomcat classes
Bumping up the version should work for the jar approach. However, I was still trying to figure out a way to honor the tomcat recommendation of replacing just the modified classes. Is there some way to make the version independent classloaders pick up individual classes rather than entire jars? Joe David Jencks wrote: On May 11, 2006, at 8:29 AM, Joe Bohn wrote: Thanks for the quick response Jeff. I like the idea of a system patch location in the classpath where we can pick up patches for anything we might include in a geronimo assembly. I think this system patch idea will only work in environments with only one classloader, i.e. not geronimo. The problem is that the patched classes need to get into the correct classloader, before the normal versions. We'd need a patch directory for each module. I also think any solution that relies on the order of stuff in a classpath is inherently unstable and unreliable. Basically I think this is a terrible idea and we should avoid it at all costs. I think instead we should use our new version independence and replace jars with patched jars with slightly higher version numbers. IIUC this is what you propose doing below. This should not require removing the standard tomcat jars: the hight version number should be enough to get the correct version picked up. thanks david jencks I too was confused by the tomcat recommendation but it does seem that they have a strategy for addressing necessary changes with minimal interference in tomcat. I have also noticed some things that make me wonder if my local tomcat build of 5.5.15 really does match the official 5.5.15 build. For example, the only source for 5.5.15 that I could find was a zip file rather than a svn branch or tag. I am not able to build from the unpacked zip without making a change to move the contents of jasper/jasper2 into the jasper directory itself. And the version that is displayed when I hit tomcat with my rebuilt image is 5.5 rather than 5.5.15 as with the official image. Until we figure out the correct approach for Geronimo I'm thinking of using a compromise solution. The changes I need in tomcat result in 4 of the 13 tomcat jars getting rebuilt. Rather than replacing all of the tomcat jars with my local build I have verified that replacing just the 4 changed jars appears to work fine. I'm hoping this hybrid solution keeps most of the official tomcat image and our local changes. I haven't noticed any problems. Assuming the source is mostly identical (apart from our changes) does anybody know of a reason that I should definitely not take this approach? Joe Jeff Genender wrote: Ultimately, we probably would need to somehow build a patch directory or lib directory where we can ensure the URLClassLoader picks that up before all other classes. I think this is probably a good idea to have as well, so that we could release service paks or patches. I would be interested in others' thoughts on this, but I think this would be a nice feature to have. Right now I think your only choices are to either hard set a classpath to be sure the patches get picked up first or build a hacked Tomcat version, or rebuild Tomcat. Dain or David Jencks may be able to verify if the classpath solution would work or not as I have not dug into the new G classloaders to know if this would even be possible. The best solution right now may be to just build TC. I am a little confused as to why the TC guys say not to build the Tomcat from source (after its hacked). It seems like just an ant build script, so I don't understand why this is being discouraged. This way you can replace the Tomcat jars in the repo and you are good to go. Jeff Joe Bohn wrote: Jeff, I am working with a user that is moving some applications from tomcat to geronimo. Due to some problems they have had to modify tomcat source. I was chatting with jasonb on the tomcat irc channel and he recommended that we only build the classes rather than rebuilding all of tomcat. He discouraged rebuilding all of tomcat because there are many permutations that can result in different build images and we should run with as much of the official tomcat build as possible to avoid problems. He also indicated that Tomcat's directory structure provides a place to put these patch classes in CATALINA_HOME/server/classes . Is there a similar place that we can put classes when tomcat is running under geronimo to have them picked up? Adding the tomcat classes to our new sharedlib doesn't seem to be the right place because it would require a dependency from the tomcat config on sharelib. The net result would be that all tomcat apps would potentially pick up user classes added in sharedlib even if the user only intended these classes for some subset of the apps. Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what
Re: rename the configuration element in config.xml file ?
I created a JIRA for this issue so that we had a place to put Dain's patch until SVN is back up. http://issues.apache.org/jira/browse/GERONIMO-2012 Joe Dain Sundstrom wrote: On May 10, 2006, at 11:25 PM, John Sisson wrote: I noticed we still have a configuration element in the config.xml file. I am thinking of doing the following for 1.1: * most importantly, change the configuration element name to module to have consistent terminology considering the recent configId changes. I have a commit (since svn went down) for this one. My code supports the both 1.0 (configuration) and 1.1 (module) formats. * update cmd line help for --override option in Daemon to use module terminology. * update the wording in the var\config\README.txt to use the module terminology. * change the --long startup output to use the word Module instead of Configuration - also give us a bit more room on each line. +1 -dain -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
