Re: Finger in the dyke
;-) Thanks for the kind words...its appreciated more than you know. Jeff Davanum Srinivas wrote: Jeff, I know its difficult to be the boy with the finger in the dyke(http://www.thehollandring.com/hans-brinker-story.shtml)just wanted to say thank you for your efforts in Tomcat integration and all the other work you have been doing :) -- dims
Re: [VOTE]Re: M5 Cut proposal date
I think we've made significant progress in the last week towards being ready to make the branch for M5, but I think there may be reasons to wait a couple more days. There are 2 features that people want to get in (security improvements and DDL generation) that I would like to see in M5, and more stabilization is needed in any case before the release. I think that unless someone is waiting to get a new feature in that shouldn't go in M5 we should wait until monday and see where we are. If anyone is contemplating a commit that may destabilize our code please speak up so we can branch beforehand. thanks david jencks On Sep 6, 2005, at 9:33 PM, Jeff Genender wrote: Ok ...I am hijacking this thread... enough discussion...lets vote on it... [ ] Friday 9/9 is the QA Cut date [ ] I think it should be after Friday...and should be on __ For me: [X] Friday 9/9 is the QA Cut date David Blevins wrote: On Sep 6, 2005, at 6:50 PM, Jeff Genender wrote: Aaron Mulder wrote: What is the point of the frozen list? At this point, it doesn't appear to have stopped development of things that aren't on the list. The list for what we are agreeing to go into M5. If something isn't on the list and its an added bonus, then fine. We need a closure date at this point. I think we have all agreed what is minimally in the cut. Maybe we should make the branch like Friday, so any code not on the list has to go into HEAD, and just have a longer closing period to resolve the list items. There is a lot on the list, so that would mean a lot of merges to HEAD, but unless everyone is willing to hold off on non-list items, I'm not sure we're actually moving toward greater stability in the mean time. Ok..shall we branch on Friday? Anhyone have any issues with this? I am game. Friday is great. Aaron expressed the same concern I was thinking about; getting further and further from stable the long we wait to branch. Things always tend to creep in. +1 David
[jira] Commented: (GERONIMO-989) client side css-link's get resolved on the server, so they break.
[ http://issues.apache.org/jira/browse/GERONIMO-989?page=comments#action_12322998 ] David Jencks commented on GERONIMO-989: --- These changes seem to fix the problem but I would like more verification before I close. Sending modules/j2ee-builder/src/java/org/apache/geronimo/j2ee/deployment/RefContext.java Sending modules/naming-builder/src/java/org/apache/geronimo/naming/deployment/ENCConfigBuilder.java Deleting modules/naming-builder/src/test/org/apache/geronimo/naming/MessageDestinationTest.java Adding modules/naming-builder/src/test/org/apache/geronimo/naming/deployment Adding modules/naming-builder/src/test/org/apache/geronimo/naming/deployment/MessageDestinationTest.java Transmitting file data ... Committed revision 279717. client side css-link's get resolved on the server, so they break. - Key: GERONIMO-989 URL: http://issues.apache.org/jira/browse/GERONIMO-989 Project: Geronimo Type: Bug Components: naming Versions: 1.0-M5 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0-M5 css-links in an ejb ref on an app client get resolved to gbeans on the server. This normally means they will break. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMODEVTOOLS-9) Patch for #8 didn't include assembly project
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-9?page=all ] Geir Magnusson Jr reassigned GERONIMODEVTOOLS-9: Assign To: Geir Magnusson Jr Patch for #8 didn't include assembly project Key: GERONIMODEVTOOLS-9 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-9 Project: Geronimo-Devtools Type: Bug Reporter: Sachin Patel Assignee: Geir Magnusson Jr Attachments: patch.txt Forgot to run svn add before creating patch for jira #8. Thus the assembly project didn't get included. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMODEVTOOLS-9) Patch for #8 didn't include assembly project
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-9?page=all ] Geir Magnusson Jr closed GERONIMODEVTOOLS-9: Resolution: Fixed applied and committed Patch for #8 didn't include assembly project Key: GERONIMODEVTOOLS-9 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-9 Project: Geronimo-Devtools Type: Bug Reporter: Sachin Patel Assignee: Geir Magnusson Jr Attachments: patch.txt Forgot to run svn add before creating patch for jira #8. Thus the assembly project didn't get included. -- 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: Mavenizing tools update...
applied On Sep 8, 2005, at 10:26 PM, Sachin Patel wrote: Ok. submitted the patch for #9. Once you invoke the command mentioned below then cd into the assembly project and invoke maven. This will generate geronimo-server-adapter_1.0.zip in ./ target. You can then extract this over your eclipse image. (I have yet to launch eclipse with with the extracted zip, so you'll be the first to try :) Sachin Patel wrote: Sorry... you will also need to point to your eclipse install plugin locatioin (which needs to include WTP and its required projects (etc.. EMF, GEF...) maven -Dgoal=jar,jar:install multiproject:goal - Declipse.home.plugins=C:/eclipse/plugins/ Sachin Patel wrote: In order to build all the projects, from the ../eclipse-plugin/ directory invoke maven -Dgoal=jar,jar:install multiproject:goal This will compile and generate the artifacts as well as deploy them into the repo. However, it looks like my last patch didn't include the assembly project since I forgot to run svn add. Thus the binary zip distribution won't get created. So I'll open a new jira and get it commmited ASAP. Let me know if you have any more problems. Sachin. So the correct sequence of steps (temporaril Miguel A Paraz wrote: On 9/8/05, Sachin Patel [EMAIL PROTECTED] wrote: I still need to clean things up, lots of duplicate info that can be pushed up into a parent POM. Still need a top level maven.xml. (Need to figure out the whole mutiproject enablement). But with this patch everything should build and you can also creates a zip distribution. Hi, I'm trying out a fresh checkout. I would like to build. What's the correct sequence of steps? I tried maven in org.apache.geronimo.core but it couldn't find org.apache.geronimo.deployment.model-1.0.jar. I tried maven in org.apache.geronimo.deployment.model built it builds successfully and produces nothing. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Updated: (GERONIMO-880) Geronimo ships patent-protected bouncycastle IDEA implementation.
[ http://issues.apache.org/jira/browse/GERONIMO-880?page=all ] Geir Magnusson Jr updated GERONIMO-880: --- Fix Version: 1.0-M5 (was: 1.0) Version: 1.0-M5 Geronimo ships patent-protected bouncycastle IDEA implementation. - Key: GERONIMO-880 URL: http://issues.apache.org/jira/browse/GERONIMO-880 Project: Geronimo Type: Bug Components: console, OpenEJB Versions: 1.0-M5 Environment: All Reporter: Rick McGuire Fix For: 1.0-M5 Attachments: IDEAEngine.java Current Geronimo is shipping the full bouncycastle jar file, which includes an implementation of the IDEA encryption algorithm. Additionally, the openejb code explicitly includes the IDEA algorithm in its supported cryptography suite. The IDEA algorithm is a bit problematic, since the royalty agreement is for non-commercial use only...royalties are expected for commercial use. It's not clear what the definition of commercial use would actually be, but any user building a commercial website with Geronimo might be at risk for a patent claim just from the presence of the code. Additionally, since there is no way to explicitly enable or discable the IDEA suite, a user might be using the code for commercial purposes without even knowing it. The presence of this code is also a problem for any companies wishing to embed Geronimo in a commercial offering. Having this code in the Geronomo base would probably kick in the commercial uses clause and make those companies subject to royalties. The IDEA code code in bouncycastle is not easily removed because the encryption engines are not dyamically loaded. It would be a simple matter to replace the IDEA engine class with a simple one that merely threw an exception (see attached class). The openejb code probably needs to remove the IDEA algorithms from the supported list as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE]Re: M5 Cut proposal date
On Sep 9, 2005, at 2:39 AM, David Jencks wrote: I think we've made significant progress in the last week towards being ready to make the branch for M5, but I think there may be reasons to wait a couple more days. There are 2 features that people want to get in (security improvements and DDL generation) that I would like to see in M5, and more stabilization is needed in any case before the release. I think that unless someone is waiting to get a new feature in that shouldn't go in M5 we should wait until monday and see where we are. If anyone is contemplating a commit that may destabilize our code please speak up so we can branch beforehand. Along with your list in the initial thread, we need to deal with the BouncyCastle situation, since we need to stop shipping this jar. The status quo is unacceptable because of the patent encumbrance of IDEA and therefore the liability that could be accidentally triggered. Rick has done some great work on hunting this down. (http:// issues.apache.org/jira/browse/GERONIMO-880) I think the fix is easy on our side - we can just change the keystore portlet to detect BC and do something different if not there (like show a page telling user where to get it if they want it, etc...) but right now, we need OpenEJB to remove the dependency. For OpenEJB, I think there are two aspects - the inclusion of IDEA in the SSLCipherSuite list (modules/ core/src/java/org/openejb/corba/sunorb/SSLCipherSuiteDatabase.java) and it's usage of the ASN1 codec. I don't know what they (OpenEJB) want to do there - it's been suggested that the necessary code can be copied (it's under a modified X.Net-ish license) or Directory could be enhanced and used. It seems the former is simpler. Ideas? (No pun intended...) geir thanks david jencks On Sep 6, 2005, at 9:33 PM, Jeff Genender wrote: Ok ...I am hijacking this thread... enough discussion...lets vote on it... [ ] Friday 9/9 is the QA Cut date [ ] I think it should be after Friday...and should be on __ For me: [X] Friday 9/9 is the QA Cut date David Blevins wrote: On Sep 6, 2005, at 6:50 PM, Jeff Genender wrote: Aaron Mulder wrote: What is the point of the frozen list? At this point, it doesn't appear to have stopped development of things that aren't on the list. The list for what we are agreeing to go into M5. If something isn't on the list and its an added bonus, then fine. We need a closure date at this point. I think we have all agreed what is minimally in the cut. Maybe we should make the branch like Friday, so any code not on the list has to go into HEAD, and just have a longer closing period to resolve the list items. There is a lot on the list, so that would mean a lot of merges to HEAD, but unless everyone is willing to hold off on non-list items, I'm not sure we're actually moving toward greater stability in the mean time. Ok..shall we branch on Friday? Anhyone have any issues with this? I am game. Friday is great. Aaron expressed the same concern I was thinking about; getting further and further from stable the long we wait to branch. Things always tend to creep in. +1 David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Assigned: (GERONIMO-940) Dual contribution code in Geronimo has pedigree questions.
[ http://issues.apache.org/jira/browse/GERONIMO-940?page=all ] Geir Magnusson Jr reassigned GERONIMO-940: -- Assign To: Geir Magnusson Jr Dual contribution code in Geronimo has pedigree questions. -- Key: GERONIMO-940 URL: http://issues.apache.org/jira/browse/GERONIMO-940 Project: Geronimo Type: Bug Components: common, kernel Versions: 1.0-M4 Environment: All Reporter: Rick McGuire Assignee: Geir Magnusson Jr Fix For: 1.0-M5 Attachments: cleanroom.zip There are a number of Geronimo classes that have also been contributed into the JBoss code base. These dual-contribution classes raise some pedigree and licensing conflict questions and should be replaced with cleanroom versions. Attached are cleanroom versions of the problem classes. In addition to these replacement classes, the files in the packages org.apache.geronimo.system.url.file and org.apache.geronimo.system.url.resource also have a similar problem. However, these classes are not actually being used by Geronimo, and should just be removed rather than deleted. Removal of these requires a patch to GeronimoURLFactory, which is also attached. NOTE: The class GeronimoURLFactory has some JVM portability issues, and it's not clear that this URL factory is really required any more. If possible, it might be best to remove that class also. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE]Re: M5 Cut proposal date
Geir Magnusson Jr. wrote: On Sep 9, 2005, at 2:39 AM, David Jencks wrote: I think we've made significant progress in the last week towards being ready to make the branch for M5, but I think there may be reasons to wait a couple more days. There are 2 features that people want to get in (security improvements and DDL generation) that I would like to see in M5, and more stabilization is needed in any case before the release. I think that unless someone is waiting to get a new feature in that shouldn't go in M5 we should wait until monday and see where we are. If anyone is contemplating a commit that may destabilize our code please speak up so we can branch beforehand. Along with your list in the initial thread, we need to deal with the BouncyCastle situation, since we need to stop shipping this jar. The status quo is unacceptable because of the patent encumbrance of IDEA and therefore the liability that could be accidentally triggered. Rick has done some great work on hunting this down. (http:// issues.apache.org/jira/browse/GERONIMO-880) I think the fix is easy on our side - we can just change the keystore portlet to detect BC and do something different if not there (like show a page telling user where to get it if they want it, etc...) but right now, we need OpenEJB to remove the dependency. For OpenEJB, I think there are two aspects - the inclusion of IDEA in the SSLCipherSuite list (modules/ core/src/java/org/openejb/corba/sunorb/SSLCipherSuiteDatabase.java) and it's usage of the ASN1 codec. I don't know what they (OpenEJB) want to do there - it's been suggested that the necessary code can be copied (it's under a modified X.Net-ish license) or Directory could be enhanced and used. It seems the former is simpler. Ideas? (No pun intended...) I've taken a look at both solutions for the openejb ASN1 usage. The ASN1 bouncy castle code is realatively selfcontained, and can be separated out an repackaged relatively quickly. I've already managed to build a version of the BC code that contains just the classes necessary to get the asn1 subdirectory to compile, and am working on a pruned version that removes support not likely to be required for openejb/geronimo. Once that is done, the changes to openejb are pretty trivial (mostly just changing package names). Right now, I'm planning on creating a util module in Geronimo for this to live. The Directory stuff is a little trickier. The Directory ASN1 support doesn't include support for different types of objects that use ASN1 encodings (in this case X509 names). I took a crack at writing the equivalent, and found the Directory ASN1 support to be incomplete enough that you'd end up reimplementing a lot of the bc classes in the Directory. A quick-and-dirty approach just implementing X509 name parsing in the openejb Util module look doable, but was still a fairly tricky bit of code AND required some enhancements to the Directory ans1 support to implement. Right now, the bc subset version looks like the best route to take. geir thanks david jencks On Sep 6, 2005, at 9:33 PM, Jeff Genender wrote: Ok ...I am hijacking this thread... enough discussion...lets vote on it... [ ] Friday 9/9 is the QA Cut date [ ] I think it should be after Friday...and should be on __ For me: [X] Friday 9/9 is the QA Cut date David Blevins wrote: On Sep 6, 2005, at 6:50 PM, Jeff Genender wrote: Aaron Mulder wrote: What is the point of the frozen list? At this point, it doesn't appear to have stopped development of things that aren't on the list. The list for what we are agreeing to go into M5. If something isn't on the list and its an added bonus, then fine. We need a closure date at this point. I think we have all agreed what is minimally in the cut. Maybe we should make the branch like Friday, so any code not on the list has to go into HEAD, and just have a longer closing period to resolve the list items. There is a lot on the list, so that would mean a lot of merges to HEAD, but unless everyone is willing to hold off on non-list items, I'm not sure we're actually moving toward greater stability in the mean time. Ok..shall we branch on Friday? Anhyone have any issues with this? I am game. Friday is great. Aaron expressed the same concern I was thinking about; getting further and further from stable the long we wait to branch. Things always tend to creep in. +1 David
[jira] Created: (GERONIMO-990) Remove external SNAPSHOT dependencies
Remove external SNAPSHOT dependencies - Key: GERONIMO-990 URL: http://issues.apache.org/jira/browse/GERONIMO-990 Project: Geronimo Type: Bug Versions: 1.0-M5 Reporter: Jeremy Boynes Priority: Blocker Remove dependencies on external SNAPSHOTs so release is consistently rebuildable -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-991) Remove SNAPSHOT dependency on TranQL
Remove SNAPSHOT dependency on TranQL Key: GERONIMO-991 URL: http://issues.apache.org/jira/browse/GERONIMO-991 Project: Geronimo Type: Sub-task Versions: 1.0-M5 Reporter: Jeremy Boynes Assigned to: Jeremy Boynes Switch to a released version of TranQL -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-992) Remove SNAPSHOT dependency on ActiveMQ
Remove SNAPSHOT dependency on ActiveMQ -- Key: GERONIMO-992 URL: http://issues.apache.org/jira/browse/GERONIMO-992 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assigned to: Hiram Chirino -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-993) Remove SNAPSHOT dependency on Driectory
Remove SNAPSHOT dependency on Driectory --- Key: GERONIMO-993 URL: http://issues.apache.org/jira/browse/GERONIMO-993 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assigned to: Jeff Genender -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-994) Remove SNAPSHOT dependency on Axis
Remove SNAPSHOT dependency on Axis -- Key: GERONIMO-994 URL: http://issues.apache.org/jira/browse/GERONIMO-994 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assigned to: David Blevins -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-995) Remove SNAPSHOT dependency on jUUI and Scout
Remove SNAPSHOT dependency on jUUI and Scout Key: GERONIMO-995 URL: http://issues.apache.org/jira/browse/GERONIMO-995 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assigned to: Geir Magnusson Jr -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-996) Remove SNAPSHOT dependency on ServiceMix
Remove SNAPSHOT dependency on ServiceMix Key: GERONIMO-996 URL: http://issues.apache.org/jira/browse/GERONIMO-996 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assigned to: Hiram Chirino -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-993) Remove SNAPSHOT dependency on Directory
[ http://issues.apache.org/jira/browse/GERONIMO-993?page=all ] Jeremy Boynes updated GERONIMO-993: --- Summary: Remove SNAPSHOT dependency on Directory (was: Remove SNAPSHOT dependency on Driectory) Description: Environment: Remove SNAPSHOT dependency on Directory --- Key: GERONIMO-993 URL: http://issues.apache.org/jira/browse/GERONIMO-993 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assignee: Jeff Genender -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-995) Remove SNAPSHOT dependency on jUDDI and Scout
[ http://issues.apache.org/jira/browse/GERONIMO-995?page=all ] Jeremy Boynes updated GERONIMO-995: --- Summary: Remove SNAPSHOT dependency on jUDDI and Scout (was: Remove SNAPSHOT dependency on jUUI and Scout) Description: Environment: Remove SNAPSHOT dependency on jUDDI and Scout - Key: GERONIMO-995 URL: http://issues.apache.org/jira/browse/GERONIMO-995 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assignee: Geir Magnusson Jr -- 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: [jira] Created: (GERONIMO-990) Remove external SNAPSHOT dependencies
Jeremy Boynes (JIRA) wrote: Remove dependencies on external SNAPSHOTs so release is consistently rebuildable I created a bunch of JIRA tasks for this and assigned them to likely victims :-) If I picked the wrong person or you won't have time to look at this please reassign. Thanks -- Jeremy
[jira] Created: (GERONIMO-997) Remove SNAPSHOT dependency on Pluto
Remove SNAPSHOT dependency on Pluto --- Key: GERONIMO-997 URL: http://issues.apache.org/jira/browse/GERONIMO-997 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assigned to: Aaron Mulder -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-998) Remove SNAPSHOT depedency on ActiveCluster
Remove SNAPSHOT depedency on ActiveCluster -- Key: GERONIMO-998 URL: http://issues.apache.org/jira/browse/GERONIMO-998 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assigned to: Hiram Chirino -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-995) Remove SNAPSHOT dependency on jUDDI and Scout
[ http://issues.apache.org/jira/browse/GERONIMO-995?page=all ] Geir Magnusson Jr closed GERONIMO-995: -- Resolution: Invalid Unless I'm missing something basic, Geronimo has been dependent on released versions of jUDDI and Scout since M4. Remove SNAPSHOT dependency on jUDDI and Scout - Key: GERONIMO-995 URL: http://issues.apache.org/jira/browse/GERONIMO-995 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assignee: Geir Magnusson Jr -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (GERONIMO-995) Remove SNAPSHOT dependency on jUDDI and Scout
[ http://issues.apache.org/jira/browse/GERONIMO-995?page=all ] Jeremy Boynes reopened GERONIMO-995: The installer directory still contains a SNAPSHOT version of jaxr (but the normal assembly does not) - I have no idea why Remove SNAPSHOT dependency on jUDDI and Scout - Key: GERONIMO-995 URL: http://issues.apache.org/jira/browse/GERONIMO-995 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assignee: Geir Magnusson Jr -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-995) Remove SNAPSHOT dependency on jUDDI and Scout
[ http://issues.apache.org/jira/browse/GERONIMO-995?page=all ] Geir Magnusson Jr closed GERONIMO-995: -- Resolution: Fixed Jeremy was right - I had forgotten to check in the update to etc/project.properties Remove SNAPSHOT dependency on jUDDI and Scout - Key: GERONIMO-995 URL: http://issues.apache.org/jira/browse/GERONIMO-995 Project: Geronimo Type: Sub-task Reporter: Jeremy Boynes Assignee: Geir Magnusson Jr -- 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: Tomcat, logging, admin portlet, and GBeans
Aaron Mulder wrote: In order to do this right, I think we should define an interface for web server request log access. That interface should have a method that searches the logs, like the server log GBean does, so rather than the console code asking the web server for log files and then opening files and scanning them, the console should pass a bunch of search parameters to the web server, and the web server should identify and search its own logs and just return the results to the console. If the web server has multiple logs, I guess it should have a method that gets a list of log file names, so the portlet can let you select the log to query, and the search method can take the log file name as a parameter. I have an outstanding task to rearrange the management interface works for the web containers and connectors, so part of that can be exposing the log manager or whatever we call the interface mentioned above. So after those changes, the code should look something like this: J2EEServer server = ... WebManager[] managers = ... server.getWebManagers(); (select Tomcat or Jetty WebManager to work with) RequestLogManager log = ... managers[i].getRequestLog(); (do log stuff such as: String[] logFiles = log.getLogFiles(); LogLine[] hits = log.searchLogs(logFile, start, end, maxRows, ...); ) To resurrect this item I would propose the following: - We continue to assume that there will be only 1 container and hence 1 Web Manager in an image (see my earlier question on this point). - As you suggest we add a mechanism to the WebManager to get access to logs. - Create an Interface (WebAccessLogHelper) with methods similar to the class methods on the current WebAccessLogHelper class. There will be some additions for handling multiple logs and some other changes (see below). - Create implementations of the WebAccessLogHelper for each supported container type. - Add a method to the WebManager to return a reference to the appropriate WebAccessLogHelper implementation for the container. - Have the portlet interact with the WebAccessLogHelper and in particular make queries via an enhanced WebAcessLogCriteria object (enhanced to include the log selection, max# of records to return, etc...). So the WebAccessLogViewerPortlet pseudo-code would look something like this: J2EEServer server = WebManager[] managerArray = server.getWebManagers(); WebManager manager = WebManagers[0]; // select the first manager in the set for now. If we support multiple managers we can enhance this for some user selection. WebAccessLogHelper logHelper = manager.getLogHelper(); // No need to query the container type .. that's hidden behind the implementation of the log helper interface. ArrayList logs = logHelper.getLogs() // to return a list of logs for display/selection (initially select the first log in the list) File[] files = logHelper.getFiles() // to return a list of files for display only (for those who would like to see the actual files and the locations). WebAccessLogCriteria = new WebAccessLogCriteria( criteria defaults .. including the selected log). ArrayList searchResults = WebAccessLogHelp.searchLogs( criteria); Criteria would include most of what there is is today with some minor changes: - selected Log (user can select from list if more than one). - Start date/time - End data/time - Host - authUser - method - URI - message - max # of messages to return - Starting record # (for displaying subsequent pages). To get started, perhaps you could propose an interface for the RequestLogManager or whatever we call it, and look at how we could implement that for Tomcat and Jetty. Thanks, Aaron On Wed, 31 Aug 2005, Joe Bohn wrote: I was investigating what is necessary to get the log management portlet in the console working for tomcat. It currently only works to display the jetty web log. As I was digging into this it is starting to get a little deeper than I anticipated and would like some recommendations. - The log portlet references a GBean object for the JettyRequestLog. - I don't see an equivalent GBean in tomcat. Should I attempt to create one and wrap the Tomcat web log in a GBean too? -- Joe Bohn [EMAIL PROTECTED] "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot -- Joe Bohn [EMAIL PROTECTED] "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Tomcat, logging, admin portlet, and GBeans
I don't fully understand what this issue is about, but I would like to point out that the first assumption (that there is one web container per image) is currently wrong and IMO not likely to change for M5 thanks david jencks On Sep 9, 2005, at 7:49 AM, Joe Bohn wrote: Aaron Mulder wrote:In order to do this right, I think we should define an interface for web server request log access. That interface should have a method that searches the logs, like the server log GBean does, so rather than the console code asking the web server for log files and then opening files and scanning them, the console should pass a bunch of search parameters to the web server, and the web server should identify and search its own logs and just return the results to the console. If the web server has multiple logs, I guess it should have a method that gets a list of log file names, so the portlet can let you select the log to query, and the search method can take the log file name as a parameter. I have an outstanding task to rearrange the management interface works for the web containers and connectors, so part of that can be exposing the log manager or whatever we call the interface mentioned above. So after those changes, the code should look something like this: J2EEServer server = ... WebManager[] managers = ... server.getWebManagers(); (select Tomcat or Jetty WebManager to work with) RequestLogManager log = ... managers[i].getRequestLog(); (do log stuff such as: String[] logFiles = log.getLogFiles(); LogLine[] hits = log.searchLogs(logFile, start, end, maxRows, ...); ) - We continue to assume that there will be only 1 container and hence 1 Web Manager in an image (see my earlier question on this point). - As you suggest we add a mechanism to the WebManager to get access to logs. - Create an Interface (WebAccessLogHelper) with methods similar to the class methods on the current WebAccessLogHelper class. There will be some additions for handling multiple logs and some other changes (see below). - Create implementations of the WebAccessLogHelper for each supported container type. - Add a method to the WebManager to return a reference to the appropriate WebAccessLogHelper implementation for the container. - Have the portlet interact with the WebAccessLogHelper and in particular make queries via an enhanced WebAcessLogCriteria object (enhanced to include the log selection, max# of records to return, etc...). So the WebAccessLogViewerPortlet pseudo-code would look something like this: J2EEServer server = WebManager[] managerArray = server.getWebManagers(); WebManager manager = WebManagers[0]; // select the first manager in the set for now. If we support multiple managers we can enhance this for some user selection. WebAccessLogHelper logHelper = manager.getLogHelper(); // No need to query the container type .. that's hidden behind the implementation of the log helper interface. ArrayList logs = logHelper.getLogs() // to return a list of logs for display/selection (initially select the first log in the list) File[] files = logHelper.getFiles() // to return a list of files for display only (for those who would like to see the actual files and the locations). WebAccessLogCriteria = new WebAccessLogCriteria( criteria defaults .. including the selected log). ArrayList searchResults = WebAccessLogHelp.searchLogs( criteria); Criteria would include most of what there is is today with some minor changes: - selected Log (user can select from list if more than one). - Start date/time - End data/time - Host - authUser - method - URI - message - max # of messages to return - Starting record # (for displaying subsequent pages). To get started, perhaps you could propose an interface for the RequestLogManager or whatever we call it, and look at how we could implement that for Tomcat and Jetty. Thanks, Aaron On Wed, 31 Aug 2005, Joe Bohn wrote: I was investigating what is necessary to get the log management portlet in the console working for tomcat. It currently only works to display the jetty web log. As I was digging into this it is starting to get a little deeper than I anticipated and would like some recommendations. - The log portlet references a GBean object for the JettyRequestLog. - I don't see an equivalent GBean in tomcat. Should I attempt to create one and wrap the Tomcat web log in a GBean too? -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Tomcat, logging, admin portlet, and GBeans
On Fri, 9 Sep 2005, David Jencks wrote: I don't fully understand what this issue is about, but I would like to point out that the first assumption (that there is one web container per image) is currently wrong and IMO not likely to change for M5 I'm not sure I understand. I really oppose shipping a server with both Tomcat and Jetty active. I thought it was going to be a Tomcat download and a Jetty download. And if this was achieved by having both present in the server but one was disabled and effectively invisible, fine, that's effectively equivalent to only one being present. Aaron On Sep 9, 2005, at 7:49 AM, Joe Bohn wrote: Aaron Mulder wrote:In order to do this right, I think we should define an interface for web server request log access. That interface should have a method that searches the logs, like the server log GBean does, so rather than the console code asking the web server for log files and then opening files and scanning them, the console should pass a bunch of search parameters to the web server, and the web server should identify and search its own logs and just return the results to the console. If the web server has multiple logs, I guess it should have a method that gets a list of log file names, so the portlet can let you select the log to query, and the search method can take the log file name as a parameter. I have an outstanding task to rearrange the management interface works for the web containers and connectors, so part of that can be exposing the log manager or whatever we call the interface mentioned above. So after those changes, the code should look something like this: J2EEServer server = ... WebManager[] managers = ... server.getWebManagers(); (select Tomcat or Jetty WebManager to work with) RequestLogManager log = ... managers[i].getRequestLog(); (do log stuff such as: String[] logFiles = log.getLogFiles(); LogLine[] hits = log.searchLogs(logFile, start, end, maxRows, ...); ) - We continue to assume that there will be only 1 container and hence 1 Web Manager in an image (see my earlier question on this point). - As you suggest we add a mechanism to the WebManager to get access to logs. - Create an Interface (WebAccessLogHelper) with methods similar to the class methods on the current WebAccessLogHelper class. There will be some additions for handling multiple logs and some other changes (see below). - Create implementations of the WebAccessLogHelper for each supported container type. - Add a method to the WebManager to return a reference to the appropriate WebAccessLogHelper implementation for the container. - Have the portlet interact with the WebAccessLogHelper and in particular make queries via an enhanced WebAcessLogCriteria object (enhanced to include the log selection, max# of records to return, etc...). So the WebAccessLogViewerPortlet pseudo-code would look something like this: J2EEServer server = WebManager[] managerArray = server.getWebManagers(); WebManager manager = WebManagers[0]; // select the first manager in the set for now. If we support multiple managers we can enhance this for some user selection. WebAccessLogHelper logHelper = manager.getLogHelper(); // No need to query the container type .. that's hidden behind the implementation of the log helper interface. ArrayList logs = logHelper.getLogs() // to return a list of logs for display/selection (initially select the first log in the list) File[] files = logHelper.getFiles() // to return a list of files for display only (for those who would like to see the actual files and the locations). WebAccessLogCriteria = new WebAccessLogCriteria( criteria defaults .. including the selected log). ArrayList searchResults = WebAccessLogHelp.searchLogs( criteria); Criteria would include most of what there is is today with some minor changes: - selected Log (user can select from list if more than one). - Start date/time - End data/time - Host - authUser - method - URI - message - max # of messages to return - Starting record # (for displaying subsequent pages). To get started, perhaps you could propose an interface for the RequestLogManager or whatever we call it, and look at how we could implement that for Tomcat and Jetty. Thanks, Aaron On Wed, 31 Aug 2005, Joe Bohn wrote: I was investigating what is necessary to get the log management portlet in the console working for tomcat. It currently only works to display the jetty web log. As I was digging into this it is starting to get a little deeper than I anticipated and would like some recommendations. - The log portlet references a GBean object for the JettyRequestLog. - I don't see an equivalent GBean in
Re: Tomcat, logging, admin portlet, and GBeans
Of course you are correct David. Your hard work has made it possible so that we can support multiple containers concurrently. My statement below was not directly related to this design. I was only trying to keep things consistent in the console for now (which always assumes just 1 active web container at a time). Since the console is still being considered a tech preview for M5 I don't think this will present a problem for that delivery. However, since you brought it up ... did we ever gain consensus on our packaging plans and typical environment? I wasn't aware that this issue was settled (not that I want to start the discussion here :-) ). IIRC there were questions about this being a scenario that most users would understand and I don't believe that we have yet identified a practical scenario where a user would require this. There were also questions about supporting multiple containers of the same or different versions and any problems that might arise as a result (such as class loader issues). I'm referring to the discussion that you started in this thread so perhaps we should take the discussion up again on that thread. http://mail-archives.apache.org/mod_mbox/geronimo-dev/200509.mbox/[EMAIL PROTECTED] If has been decided that we will give the user the option of configuring the system with numerous web containers then we need to expose this fact in the console and possibly in other places for management capabilities (do we currently have a command line that would need to change?). From the web console perspective we will also need to evaluate how we can manage this complexity without confusing the typical user (who I suspect will probably be running just 1 web container). -Joe . David Jencks wrote: I don't fully understand what this issue is about, but I would like to point out that the first assumption (that there is one web container per image) is currently wrong and IMO not likely to change for M5 thanks david jencks On Sep 9, 2005, at 7:49 AM, Joe Bohn wrote: Aaron Mulder wrote:In order to do this right, I think we should define an interface for web server request log access. That interface should have a method that searches the logs, like the server log GBean does, so rather than the console code asking the web server for log files and then opening files and scanning them, the console should pass a bunch of search parameters to the web server, and the web server should identify and search its own logs and just return the results to the console. If the web server has multiple logs, I guess it should have a method that gets a list of log file names, so the portlet can let you select the log to query, and the search method can take the log file name as a parameter. I have an outstanding task to rearrange the management interface works for the web containers and connectors, so part of that can be exposing the log manager or whatever we call the interface mentioned above. So after those changes, the code should look something like this: J2EEServer server = ... WebManager[] managers = ... server.getWebManagers(); (select Tomcat or Jetty WebManager to work with) RequestLogManager log = ... managers[i].getRequestLog(); (do log stuff such as: String[] logFiles = log.getLogFiles(); LogLine[] hits = log.searchLogs(logFile, start, end, maxRows, ...); ) - We continue to assume that there will be only 1 container and hence 1 Web Manager in an image (see my earlier question on this point). - As you suggest we add a mechanism to the WebManager to get access to logs. - Create an Interface (WebAccessLogHelper) with methods similar to the class methods on the current WebAccessLogHelper class. There will be some additions for handling multiple logs and some other changes (see below). - Create implementations of the WebAccessLogHelper for each supported container type. - Add a method to the WebManager to return a reference to the appropriate WebAccessLogHelper implementation for the container. - Have the portlet interact with the WebAccessLogHelper and in particular make queries via an enhanced WebAcessLogCriteria object (enhanced to include the log selection, max# of records to return, etc...). So the WebAccessLogViewerPortlet pseudo-code would look something like this: J2EEServer server = WebManager[] managerArray = server.getWebManagers(); WebManager manager = WebManagers[0]; // select the first manager in the set for now. If we support multiple managers we can enhance this for some user selection. WebAccessLogHelper logHelper = manager.getLogHelper(); // No need to query the container type .. that's hidden behind the implementation of the log helper interface. ArrayList logs = logHelper.getLogs() // to return a list of logs for display/selection (initially select the first log in the list) File[] files = logHelper.getFiles() // to return a list of files
Re: Tomcat, logging, admin portlet, and GBeans
On Sep 9, 2005, at 9:47 AM, Aaron Mulder wrote: On Fri, 9 Sep 2005, David Jencks wrote: I don't fully understand what this issue is about, but I would like to point out that the first assumption (that there is one web container per image) is currently wrong and IMO not likely to change for M5 I'm not sure I understand. I really oppose shipping a server with both Tomcat and Jetty active. I thought it was going to be a Tomcat download and a Jetty download. And if this was achieved by having both present in the server but one was disabled and effectively invisible, fine, that's effectively equivalent to only one being present. Aaron On Sep 9, 2005, at 9:30 AM, Joe Bohn wrote: Of course you are correct David. Your hard work has made it possible so that we can support multiple containers concurrently. My statement below was not directly related to this design. I was only trying to keep things consistent in the console for now (which always assumes just 1 active web container at a time). Since the console is still being considered a tech preview for M5 I don't think this will present a problem for that delivery. However, since you brought it up ... did we ever gain consensus on our packaging plans and typical environment? I wasn't aware that this issue was settled (not that I want to start the discussion here :-) ). IIRC there were questions about this being a scenario that most users would understand and I don't believe that we have yet identified a practical scenario where a user would require this. There were also questions about supporting multiple containers of the same or different versions and any problems that might arise as a result (such as class loader issues). I'm referring to the discussion that you started in this thread so perhaps we should take the discussion up again on that thread. http://mail-archives.apache.org/mod_mbox/geronimo-dev/200509.mbox/ [EMAIL PROTECTED] If has been decided that we will give the user the option of configuring the system with numerous web containers then we need to expose this fact in the console and possibly in other places for management capabilities (do we currently have a command line that would need to change?). From the web console perspective we will also need to evaluate how we can manage this complexity without confusing the typical user (who I suspect will probably be running just 1 web container). -Joe . Right now, both jetty and tomcat are running in the standard server. We can make it so only one starts by default fairly easily by changing the config.list. The tomcat goal or setting the web container to tomcat changes the ports each container uses by default, but both start at the moment. However, if we ship both configurations, it is going to be very easy to get 2 web containers running at once, whether on purpose or not, by starting a configuration that is deployed to the other web container. I don't see a great deal of utility for running multiple web containers in one geronimo server, but I'm not an end user. I certainly hesitate to tell our end users that they will never want to do it. Since we have the technical ability to do it I would prefer that the management console support it in some way or at least not prevent it. thanks david jencks
Re: Tomcat, logging, admin portlet, and GBeans
I really believe that choice is a bad thing. I don't believe we should offer 2 options to a user. How are they supposed to decide? How are we supposed to guide them? I'll grant you that there may (*may*) be some possible reason for a very advanced user to want to run 2 different web containers. I really believe this should be an advanced manual process (e.g. download Tomcat build, then deploy Jetty plan). I really really really don't want to encumber every user with both Jetty and Tomcat in order to support this dual-container feature. I really really really don't want to make it easy for a user to inadvertently or on a whim run both containers, such that every web-related question or bug report will require us to get the user to figure out what's actually running and what they deployed to and so on. Anyway, all that said, I agree that the console should support runing more than one web container, but I don't feel that's a priority for M5. The same is true for EJB, JMS, etc. It will require some thought on how we want to present things and a fair bit of work to revise the JSPs. Not a huge deal, but not something I feel the urge to spent time in in the short term. Do you think it's necessary for M5? Aaron On Fri, 9 Sep 2005, David Jencks wrote: Right now, both jetty and tomcat are running in the standard server. We can make it so only one starts by default fairly easily by changing the config.list. The tomcat goal or setting the web container to tomcat changes the ports each container uses by default, but both start at the moment. However, if we ship both configurations, it is going to be very easy to get 2 web containers running at once, whether on purpose or not, by starting a configuration that is deployed to the other web container. I don't see a great deal of utility for running multiple web containers in one geronimo server, but I'm not an end user. I certainly hesitate to tell our end users that they will never want to do it. Since we have the technical ability to do it I would prefer that the management console support it in some way or at least not prevent it. thanks david jencks
Re: Tomcat, logging, admin portlet, and GBeans
Aaron Mulder wrote: I really believe that choice is a bad thing. I don't believe we should offer 2 options to a user. How are they supposed to decide? How are we supposed to guide them? I'll grant you that there may (*may*) be some possible reason for a very advanced user to want to run 2 different web containers. I really believe this should be an advanced manual process (e.g. download Tomcat build, then deploy Jetty plan). I really really really don't want to encumber every user with both Jetty and Tomcat in order to support this dual-container feature. +1 Gratuitous feature creep is evil and this particular feature violates the principle of least astonishment. Bill
Re: Console JIRA Geronimo 846
Has anybody taken a look at this JIRA and the fix (Aaron ... it says that you are assigned to it) ? http://issues.apache.org/jira/browse/GERONIMO-846 The fix has been there for over a month ... so the patch might be a little difficult to apply now. Did somebody have a problem with the fix? If so I'd like to talk about it. -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Console JIRA Geronimo 846
Yeah, I've just been putting it off because it didn't seem real high-priority. But I'm still planning to do it (it's on the list for M5), and I don't think there's going to be trouble applying it. Thanks, Aaron On Fri, 9 Sep 2005, Joe Bohn wrote: Has anybody taken a look at this JIRA and the fix (Aaron ... it says that you are assigned to it) ? http://issues.apache.org/jira/browse/GERONIMO-846 The fix has been there for over a month ... so the patch might be a little difficult to apply now. Did somebody have a problem with the fix? If so I'd like to talk about it. -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Console JIRA Geronimo-922
Aaron ... you expressed some concerns with this enhancement (Geronimo-922) and I attempted to answer them in the JIRA. I think the patch provided improves the views greatly (both in the improved appearance of the table and the addition of the simple filter). Our last interaction on this was some time ago and I haven't seen any additional activity on this? Are there more questions/concerns that we should discuss? http://issues.apache.org/jira/browse/GERONIMO-922 -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: [VOTE]Re: M5 Cut proposal date
On 9/9/2005 4:55 AM, Rick McGuire wrote: I've taken a look at both solutions for the openejb ASN1 usage. The ASN1 bouncy castle code is realatively selfcontained, and can be separated out an repackaged relatively quickly. I've already managed to build a version of the BC code that contains just the classes necessary to get the asn1 subdirectory to compile, and am working on a pruned version that removes support not likely to be required for openejb/geronimo. Once that is done, the changes to openejb are pretty trivial (mostly just changing package names). Right now, I'm planning on creating a util module in Geronimo for this to live. The Directory stuff is a little trickier. The Directory ASN1 support doesn't include support for different types of objects that use ASN1 encodings (in this case X509 names). I took a crack at writing the equivalent, and found the Directory ASN1 support to be incomplete enough that you'd end up reimplementing a lot of the bc classes in the Directory. A quick-and-dirty approach just implementing X509 name parsing in the openejb Util module look doable, but was still a fairly tricky bit of code AND required some enhancements to the Directory ans1 support to implement. Right now, the bc subset version looks like the best route to take. Let's go with the former. Toss it up on the Jira issue and I'll get to it immediately. Thanks for all your help on this. Regards, Alan
Re: Tomcat, logging, admin portlet, and GBeans
I've explained what is currently implemented. I'm willing to make it so selecting jetty or tomcat does not start the other configuration, but where both configurations are present. If anyone wants to build separate jetty and tomcat distributions that are actually missing the other container, for m5, I will not stand in their way so long as they keep the tck running at least as smoothly as it is now, but I do not have the time or interest to put into it. I have no expectations that the console will do anything in particular in M5. I do wonder how you determine which container is running. I will say that I think that the current assembly module approach to building geronimo distributions is really bad and that something based on the packaging and assembly plugins should be much more maintainable. I am aware that this opinion is shall we say controversial. Using the same module to build two unrelated versions of the geronimo distribution definitely violates the maven philosophy, and I suggest if anyone wants to build separate distributions that they do so in two separate modules. On Sep 9, 2005, at 10:11 AM, Bill Stoddard wrote: Aaron Mulder wrote: I really believe that choice is a bad thing. umm, really? why aren't we using jboss? or jonas? I don't believe we should offer 2 options to a user. How are they supposed to decide? How are we supposed to guide them? So we should just drop support for jetty or tomcat completely? Which one? I'll grant you that there may (*may*) be some possible reason for a very advanced user to want to run 2 different web containers. I really believe this should be an advanced manual process (e.g. download Tomcat build, then deploy Jetty plan). I really really really don't want to encumber every user with both Jetty and Tomcat in order to support this dual-container feature. We have been including all the jar files for both jetty and tomcat for some time. Adding the configurations to run them is a tiny step compared to this. I think if we remove one of the configurations we need to remove the jar files that are only used with it. +1 Gratuitous feature creep is evil and this particular feature violates the principle of least astonishment. From my point of view, we are finally seeing some partial benefits from being able to use some of the fundamental architectural features of geronimo. I don't really care how we present the choice of container to the user in M5 so long as it doesn't complicate the build or running the tck. I've taken the approach that seems to me to most clearly express geronimo principles and provides (in my opinion) the simplest build and test path. I don't think that the possible benefits of providing two builds that each include only one container outweigh the additional project management complexity involved. thanks david jencks
Re: Tomcat, logging, admin portlet, and GBeans
Can I ask that we move this thread back to its intended purpose (the proposal of a design for the web console to display either Tomcat or Jetty web logs ... )? It looks like we're on the verge of branching off into more detailed discussion on how to build the Geronimo distributions. I think this is all very important and I'd like to continue the discussion but I really would also like some input on the design that I proposed. David Jencks wrote: I've explained what is currently implemented. I'm willing to make it so selecting jetty or tomcat does not start the other configuration, but where both configurations are present. If anyone wants to build separate jetty and tomcat distributions that are actually missing the other container, for m5, I will not stand in their way so long as they keep the tck running at least as smoothly as it is now, but I do not have the time or interest to put into it. I have no expectations that the console will do anything in particular in M5. I do wonder how you determine which container is running. I will say that I think that the current assembly module approach to building geronimo distributions is really bad and that something based on the packaging and assembly plugins should be much more maintainable. I am aware that this opinion is shall we say controversial. Using the same module to build two unrelated versions of the geronimo distribution definitely violates the maven philosophy, and I suggest if anyone wants to build separate distributions that they do so in two separate modules. On Sep 9, 2005, at 10:11 AM, Bill Stoddard wrote: Aaron Mulder wrote: I really believe that choice is a bad thing. umm, really? why aren't we using jboss? or jonas? I don't believe we should offer 2 options to a user. How are they supposed to decide? How are we supposed to guide them? So we should just drop support for jetty or tomcat completely? Which one? I'll grant you that there may (*may*) be some possible reason for a very advanced user to want to run 2 different web containers. I really believe this should be an advanced manual process (e.g. download Tomcat build, then deploy Jetty plan). I really really really don't want to encumber every user with both Jetty and Tomcat in order to support this dual-container feature. We have been including all the jar files for both jetty and tomcat for some time. Adding the configurations to run them is a tiny step compared to this. I think if we remove one of the configurations we need to remove the jar files that are only used with it. +1 Gratuitous feature creep is evil and this particular feature violates the principle of least astonishment. From my point of view, we are finally seeing some partial benefits from being able to use some of the fundamental architectural features of geronimo. I don't really care how we present the choice of container to the user in M5 so long as it doesn't complicate the build or running the tck. I've taken the approach that seems to me to most clearly express geronimo principles and provides (in my opinion) the simplest build and test path. I don't think that the possible benefits of providing two builds that each include only one container outweigh the additional project management complexity involved. thanks david jencks -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Tomcat, logging, admin portlet, and GBeans
thanks! Not that I know much about this, but your design looks fine to me. I might suggest warning the user somehow if there is more than one WebManager so they know they are missing half the picture and can take steps to turn off the other container. I agree supporting multiple simultaneous web managers is a very low priority (if indeed 0). thanks david jencks On Sep 9, 2005, at 12:27 PM, Joe Bohn wrote: Can I ask that we move this thread back to its intended purpose (the proposal of a design for the web console to display either Tomcat or Jetty web logs ... )? It looks like we're on the verge of branching off into more detailed discussion on how to build the Geronimo distributions. I think this is all very important and I'd like to continue the discussion but I really would also like some input on the design that I proposed. David Jencks wrote: I've explained what is currently implemented. I'm willing to make it so selecting jetty or tomcat does not start the other configuration, but where both configurations are present. If anyone wants to build separate jetty and tomcat distributions that are actually missing the other container, for m5, I will not stand in their way so long as they keep the tck running at least as smoothly as it is now, but I do not have the time or interest to put into it. I have no expectations that the console will do anything in particular in M5. I do wonder how you determine which container is running. I will say that I think that the current assembly module approach to building geronimo distributions is really bad and that something based on the packaging and assembly plugins should be much more maintainable. I am aware that this opinion is shall we say controversial. Using the same module to build two unrelated versions of the geronimo distribution definitely violates the maven philosophy, and I suggest if anyone wants to build separate distributions that they do so in two separate modules. On Sep 9, 2005, at 10:11 AM, Bill Stoddard wrote: Aaron Mulder wrote: I really believe that choice is a bad thing. umm, really? why aren't we using jboss? or jonas? I don't believe we should offer 2 options to a user. How are they supposed to decide? How are we supposed to guide them? So we should just drop support for jetty or tomcat completely? Which one? I'll grant you that there may (*may*) be some possible reason for a very advanced user to want to run 2 different web containers. I really believe this should be an advanced manual process (e.g. download Tomcat build, then deploy Jetty plan). I really really really don't want to encumber every user with both Jetty and Tomcat in order to support this dual-container feature. We have been including all the jar files for both jetty and tomcat for some time. Adding the configurations to run them is a tiny step compared to this. I think if we remove one of the configurations we need to remove the jar files that are only used with it. +1 Gratuitous feature creep is evil and this particular feature violates the principle of least astonishment. From my point of view, we are finally seeing some partial benefits from being able to use some of the fundamental architectural features of geronimo. I don't really care how we present the choice of container to the user in M5 so long as it doesn't complicate the build or running the tck. I've taken the approach that seems to me to most clearly express geronimo principles and provides (in my opinion) the simplest build and test path. I don't think that the possible benefits of providing two builds that each include only one container outweigh the additional project management complexity involved. thanks david jencks -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
[jira] Reopened: (GERONIMO-986) ContextManager.registerPrincipal() should be removed
[ http://issues.apache.org/jira/browse/GERONIMO-986?page=all ] Alan Cabrera reopened GERONIMO-986: --- ContextManager.registerPrincipal() should be removed Key: GERONIMO-986 URL: http://issues.apache.org/jira/browse/GERONIMO-986 Project: Geronimo Type: Task Components: security Versions: 1.0-M5 Reporter: Alan Cabrera Assignee: Alan Cabrera Fix For: 1.0-M5 I have no idea why I thought that I needed to register RealmPrincipals. I will remove this before David Jenks lays his eyes on it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-986) ContextManager.registerPrincipal() should be removed
[ http://issues.apache.org/jira/browse/GERONIMO-986?page=all ] Alan Cabrera closed GERONIMO-986: - Resolution: Fixed Removed ContextManager.registerPrincipal() should be removed Key: GERONIMO-986 URL: http://issues.apache.org/jira/browse/GERONIMO-986 Project: Geronimo Type: Task Components: security Versions: 1.0-M5 Reporter: Alan Cabrera Assignee: Alan Cabrera Fix For: 1.0-M5 I have no idea why I thought that I needed to register RealmPrincipals. I will remove this before David Jenks lays his eyes on it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-986) ContextManager.registerPrincipal() should be removed
[ http://issues.apache.org/jira/browse/GERONIMO-986?page=all ] Alan Cabrera resolved GERONIMO-986: --- Resolution: Fixed ContextManager.registerPrincipal() should be removed Key: GERONIMO-986 URL: http://issues.apache.org/jira/browse/GERONIMO-986 Project: Geronimo Type: Task Components: security Versions: 1.0-M5 Reporter: Alan Cabrera Assignee: Alan Cabrera Fix For: 1.0-M5 I have no idea why I thought that I needed to register RealmPrincipals. I will remove this before David Jenks lays his eyes on it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-999) ejb-links including a # to stateful session beans won't get resolved
ejb-links including a # to stateful session beans won't get resolved Key: GERONIMO-999 URL: http://issues.apache.org/jira/browse/GERONIMO-999 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M5 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.0-M5 An ejb-link including a # to specify the target module won't get resolved to a stateful session bean, since the # code insists on an exact match. After the search for a stateless bean fails by throwing an exception, we give up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-999) ejb-links including a # to stateful session beans won't get resolved
[ http://issues.apache.org/jira/browse/GERONIMO-999?page=all ] David Jencks closed GERONIMO-999: - Resolution: Fixed Sending modules/j2ee-builder/src/java/org/apache/geronimo/j2ee/deployment/RefContext.java Transmitting file data . Committed revision 279877. ejb-links including a # to stateful session beans won't get resolved Key: GERONIMO-999 URL: http://issues.apache.org/jira/browse/GERONIMO-999 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M5 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0-M5 An ejb-link including a # to specify the target module won't get resolved to a stateful session bean, since the # code insists on an exact match. After the search for a stateless bean fails by throwing an exception, we give up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Build error
Any ideas on how to resolve this error: [mkdir] Created dir: C:\dev\geronimo\modules\assembly\target\geronimo-1.0-SN APSHOT\doc [mkdir] Created dir: C:\dev\geronimo\modules\assembly\target\geronimo-1.0-SN APSHOT\doc\plan [copy] Copying 23 files to C:\dev\geronimo\modules\assembly\target\geronimo- 1.0-SNAPSHOT\doc\plan [copy] Copying 4 files to C:\dev\geronimo\modules\assembly\target\geronimo-1 .0-SNAPSHOT\bin [echo] Bootstrapping service deployer [mkdir] Created dir: C:\dev\geronimo\modules\assembly\target\geronimo-1.0-SN APSHOT\config-store BUILD FAILED File.. C:\Documents and Settings\Administrator\.maven\cache\maven-multiproje ct-plugin-1.3.1\plugin.jelly Element... maven:reactor Line.. 217 Column 9 Unable to obtain goal [default] -- C:\dev\geronimo\modules\assembly\maven.xml:36 4:15: bootstrap:bootstrap org.apache.geronimo.deployment.service.ServiceConfig Builder.init(Ljava/net/URI;Lorg/apache/geronimo/kernel/repository/Repository;) V Michael Malgeri Mgr Gluecode Client Technical Services PHONE: 310-536-8355 x 14 FAX: 310-536-9062 CELLULAR: 310-704-6403
Re: Build error
If you are building head, something is really out of date, that constructor signature was changed at least a week ago. I would try updating geronimo and openejb and rebuilding. If this doesn't help please give more details and perhaps run with -X thanks david jencks On Sep 9, 2005, at 3:24 PM, Michael Malgeri wrote: Any ideas on how to resolve this error: [mkdir] Created dir: C:\dev\geronimo\modules\assembly\target\geronimo-1.0-SN APSHOT\doc [mkdir] Created dir: C:\dev\geronimo\modules\assembly\target\geronimo-1.0-SN APSHOT\doc\plan [copy] Copying 23 files to C:\dev\geronimo\modules\assembly\target\geronimo- 1.0-SNAPSHOT\doc\plan [copy] Copying 4 files to C:\dev\geronimo\modules\assembly\target\geronimo-1 .0-SNAPSHOT\bin [echo] Bootstrapping service deployer [mkdir] Created dir: C:\dev\geronimo\modules\assembly\target\geronimo-1.0-SN APSHOT\config-store BUILD FAILED File.. C:\Documents and Settings\Administrator\.maven\cache\maven-multiproje ct-plugin-1.3.1\plugin.jelly Element... maven:reactor Line.. 217 Column 9 Unable to obtain goal [default] -- C:\dev\geronimo\modules\assembly\maven.xml:36 4:15: bootstrap:bootstrap org.apache.geronimo.deployment.service.ServiceConfig Builder.init(Ljava/net/URI;Lorg/apache/geronimo/kernel/repository/ Repository;) V Michael Malgeri Mgr Gluecode Client Technical Services PHONE: 310-536-8355 x 14 FAX: 310-536-9062 CELLULAR: 310-704-6403
Re: [openejb-scm] openejb/modules/itests/src/var/config config.list
Thank you, David! This one was kicking my butt. -David On Sep 9, 2005, at 3:35 PM, [EMAIL PROTECTED] wrote: djencks 2005/09/09 18:35:01 Added: modules/itests/src/var/config config.list Log: fix itests to work with new configurations Revision ChangesPath 1.1 openejb/modules/itests/src/var/config/ config.list Index: config.list === org/apache/geronimo/System org/apache/geronimo/RMINaming org/apache/geronimo/Server org/apache/geronimo/Security org/apache/geronimo/ServerCORBA org/apache/geronimo/SystemDatabase org/apache/geronimo/SystemJMS org/apache/geronimo/RuntimeDeployer org/apache/geronimo/JettyRuntimeDeployer org/apache/geronimo/TomcatRuntimeDeployer org/apache/geronimo/applications/Welcome org/apache/geronimo/Console org/apache/geronimo/DefaultDatabase
[jira] Created: (GERONIMO-1000) GenericSecurityRealm and ServerRealmConfigurationEntry can have loginService reference null when run on client
GenericSecurityRealm and ServerRealmConfigurationEntry can have loginService reference null when run on client -- Key: GERONIMO-1000 URL: http://issues.apache.org/jira/browse/GERONIMO-1000 Project: Geronimo Type: Bug Versions: 1.0-M5 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.0-M5 GenericSecurityRealm and ServerRealmConfigurationEntry now have a reference to loginService. This will be null if they are on a client, so we should not try to extract the objectName from the reference if it is null. On a client the loginService would not be used since the client will connect to a remote login service. -- 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
