Re: Common Visual Design for Geronimo's User Interfaces
When I first saw these I was surprised at what a dramatic difference this is over what we sent to Epiq. As I've already told the Epiq team great work!! I also agree that we should spread the style to as many G user interfaces as possible. It would be great if we could come up with some simple format that everything supports - such as all having the banner at the top and perhaps even some shaded primary tasks area on the left. The tasks could be navigation choices for the web console, commands for the debug console, primary links for the web page, etc... If we could share the exact image across the build that would really help when making changes. Joe David Klavon wrote: Now that there is an official logo image for Geronimo, we thought that it would be useful to extend the color scheme, font style, icon use, etc. across the various user interfaces in the project, and create a common 'visual appearance' for the Geronimo project for v1.0. The Epiq Team, the recent winners of the logo contest, have drafted some ideas of what an integrated suite would look like to get the discussion going in the community. While there are many details to be worked out on each of the respective interfaces, we would like to get the community feedback on the general approach and style. If found favorable, we could begin to create the icon libraries and other style sheets for implementation. http://www.epiqtech.com/corp/products/technology/opensource/ServerConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/ServerConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/GeronimoWelcomeScreen.htm http://www.epiqtech.com/corp/products/technology/opensource/DebugConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/DebugConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/DaytraderLogo.htm I think the Epiq Team has really showcased their award winning skills in giving Geronimo a professional look and integrated-suite feel that would add great value to the v1.0 delivery. Let us know what everyone thinks... Dave -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: TCK Access
Thanks Geir, I either missed it or didn't get it. I'll get the monster and send it in. Thanks :) Geir Magnusson Jr. wrote: I already responded to you. Maybe you didn't get the mail? You need to sign the NDA found here : http://people.apache.org/~geirm/ApacheNDA.pdf and fax to +1 203 665 6400 We'll go from there. geir On Nov 1, 2005, at 10:01 PM, Matt Hogstrom wrote: Anyone, I'd like to get access to the TCK. What is the process to get access as a committer? Do I need to sign an additional NDA or something and where is the monster anyway? Thanks.
Re: Common Visual Design for Geronimo's User Interfaces
Absolutely stunning. Glenn, you've outdone yourself. Is it possible to get a patch for this and integrate so we can get some functional feedback as well. I think the entire Geronimo team owes you a debt of gratitude for heling to get us out of the Grey console into the Great! console :) - Matt Joe Bohn wrote: When I first saw these I was surprised at what a dramatic difference this is over what we sent to Epiq. As I've already told the Epiq team great work!! I also agree that we should spread the style to as many G user interfaces as possible. It would be great if we could come up with some simple format that everything supports - such as all having the banner at the top and perhaps even some shaded primary tasks area on the left. The tasks could be navigation choices for the web console, commands for the debug console, primary links for the web page, etc... If we could share the exact image across the build that would really help when making changes. Joe David Klavon wrote: Now that there is an official logo image for Geronimo, we thought that it would be useful to extend the color scheme, font style, icon use, etc. across the various user interfaces in the project, and create a common 'visual appearance' for the Geronimo project for v1.0. The Epiq Team, the recent winners of the logo contest, have drafted some ideas of what an integrated suite would look like to get the discussion going in the community. While there are many details to be worked out on each of the respective interfaces, we would like to get the community feedback on the general approach and style. If found favorable, we could begin to create the icon libraries and other style sheets for implementation. http://www.epiqtech.com/corp/products/technology/opensource/ServerConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/ServerConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/GeronimoWelcomeScreen.htm http://www.epiqtech.com/corp/products/technology/opensource/DebugConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/DebugConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/DaytraderLogo.htm I think the Epiq Team has really showcased their award winning skills in giving Geronimo a professional look and integrated-suite feel that would add great value to the v1.0 delivery. Let us know what everyone thinks... Dave
[jira] Updated: (GERONIMO-1088) Add Tomcat jsp-examples to geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-1088?page=all ] Dave Colasurdo updated GERONIMO-1088: - Geronimo Info: [Patch Available] Add Tomcat jsp-examples to geronimo --- Key: GERONIMO-1088 URL: http://issues.apache.org/jira/browse/GERONIMO-1088 Project: Geronimo Type: Improvement Components: sample apps Versions: 1.0 Reporter: Dave Colasurdo Attachments: jsp-examples.war, tomcat-jsp-examples-source.zip, tomcat_jsp_example.patch Introduce the tomcat jsp-examples into geronimo.. This is a follow-on to GERONIMO-1087.. -- 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: Common Visual Design for Geronimo's User Interfaces
David Klavon wrote: Now that there is an official logo image for Geronimo, we thought that it would be useful to extend the color scheme, font style, icon use, etc. across the various user interfaces in the project, and create a common 'visual appearance' for the Geronimo project for v1.0. Very nice! How about a Powered by Apache Geronimo logo for folks to display on their AG powered websites or in their Apache Geronimo derivitive distros? Bill
Single download, setup and build.
This may be slightly related to Hernan's wiki thread but since we were talking about G for the impatient and a newbie manual, thought I'd ask this. Dave Klavon was talking about a single download and setup of all prereqsand G source, and build it too. I liked that idea andthinkthat would be really nice. I even put togethera package with basic scripts for that. However, now I am beginning to wonder if it is legal/permissiblefor us to ship JDK,svn, maven and CVS in this single package ? Comments ? Cheers Prasad
Re: Single download, setup and build.
-1 from me. I could possibly understand the JDK, but definatley not svn, maven, and CVS. Prasad Kashyap wrote: This may be slightly related to Hernan's wiki thread but since we were talking about G for the impatient and a newbie manual, thought I'd ask this. Dave Klavon was talking about a single download and setup of all prereqs and G source, and build it too. I liked that idea and think that would be really nice. I even put together a package with basic scripts for that. However, now I am beginning to wonder if it is legal/permissible for us to /ship/ JDK, svn, maven and CVS in this single package ? Comments ? Cheers Prasad -- Sachin
Axis Issue 2278
FYI, I've raised an issue and supplied a patch for an Axis problem which is causing memory leaks in Geronimo -- http://issues.apache.org/jira/browse/AXIS-2278. I don't know of a formal process for tracking dependencies on other projects. So, I've advertised it here... Fix was for axis trunk. Should we request an update to Axis 1.3? Possible that there's another Axis problem, but need to dig a bit more.. --kevan
Re: Single download, setup and build.
We could not ship the SDK (which is required to build the code) but we could in theory ship the others. You'd still need to worry about integrating them into the OS though, so I'd suggest we just keep pointing the users to instructions for CVS, SVN and Maven. It's a pain to set up, but most developers will either already have it or will know how to install it (with or without the instructions) Once you have everything setup, G is one of the easiest environments to work with. On 11/2/05, Sachin Patel [EMAIL PROTECTED] wrote: -1 from me. I could possibly understand the JDK, but definatley not svn, maven, and CVS. Prasad Kashyap wrote: This may be slightly related to Hernan's wiki thread but since we were talking about G for the impatient and a newbie manual, thought I'd ask this. Dave Klavon was talking about a single download and setup of all prereqs and G source, and build it too. I liked that idea and think that would be really nice. I even put together a package with basic scripts for that. However, now I am beginning to wonder if it is legal/permissible for us to /ship/ JDK, svn, maven and CVS in this single package ? Comments ? Cheers Prasad -- Sachin
Re: Common Visual Design for Geronimo's User Interfaces
Coool. I like it. Also, I like the welcome page inside the consoleto be the welcome page (or something similar) you'd get at http://localhost:8080/. IMHO, the Server Infodoes't look like agood first page inside the console. Maybe it's just me. Cheers, Prasad On 11/2/05, Bill Stoddard [EMAIL PROTECTED] wrote: David Klavon wrote: Now that there is an official logo image for Geronimo, we thought that it would be useful to extend the color scheme, font style, icon use, etc. across the various user interfaces in the project, and create a common 'visual appearance' for the Geronimo project for v1.0.Very nice!How about a Powered by Apache Geronimo logo for folks to display on their AG powered websites or in their Apache Geronimo derivitive distros?Bill
Re: Single download, setup and build.
I don't disagree with that. G is pretty easy to build. It's just a chore downloading upto 4 different prereqs from 4 different locations. But I see your point reg. SDK. Thanx Prasad On 11/2/05, Barry van Someren [EMAIL PROTECTED] wrote: We could not ship the SDK (which is required to build the code) but wecould in theory ship the others. You'd still need to worry about integrating them into the OS though,so I'd suggest we just keep pointing the users to instructions forCVS, SVN and Maven.It's a pain to set up, but most developers will either already have it or will know how to install it (with or without the instructions)Once you have everything setup, G is one of the easiest environmentsto work with.On 11/2/05, Sachin Patel [EMAIL PROTECTED] wrote: -1 from me.I could possibly understand the JDK, but definatley not svn, maven, and CVS. Prasad Kashyap wrote: This may be slightly related to Hernan's wiki thread but since we were talking about G for the impatient and a newbie manual, thought I'd ask this. Dave Klavon was talking about a single download and setup of all prereqs and G source, and build it too. I liked that idea and think that would be really nice. I even put together a package with basic scripts for that. However, now I am beginning to wonder if it is legal/permissible for us to /ship/JDK, svn, maven and CVS in this single package ? Comments ? Cheers Prasad -- Sachin
Re: Single download, setup and build.
Well, but seeing how these tools are only required if you actually want to work with the Geronimo people, the requirements aren't really that strong. Perhaps we could make daily code drops available for those who want the somewhat current source but can't (or won't) use CVS/SVN. Still CVS and SVN are easy to install On 11/2/05, Prasad Kashyap [EMAIL PROTECTED] wrote: I don't disagree with that. G is pretty easy to build. It's just a chore downloading upto 4 different prereqs from 4 different locations. But I see your point reg. SDK. Thanx Prasad On 11/2/05, Barry van Someren [EMAIL PROTECTED] wrote: We could not ship the SDK (which is required to build the code) but we could in theory ship the others. You'd still need to worry about integrating them into the OS though, so I'd suggest we just keep pointing the users to instructions for CVS, SVN and Maven. It's a pain to set up, but most developers will either already have it or will know how to install it (with or without the instructions) Once you have everything setup, G is one of the easiest environments to work with. On 11/2/05, Sachin Patel [EMAIL PROTECTED] wrote: -1 from me. I could possibly understand the JDK, but definatley not svn, maven, and CVS. Prasad Kashyap wrote: This may be slightly related to Hernan's wiki thread but since we were talking about G for the impatient and a newbie manual, thought I'd ask this. Dave Klavon was talking about a single download and setup of all prereqs and G source, and build it too. I liked that idea and think that would be really nice. I even put together a package with basic scripts for that. However, now I am beginning to wonder if it is legal/permissible for us to /ship/ JDK, svn, maven and CVS in this single package ? Comments ? Cheers Prasad -- Sachin
Re: Single download, setup and build.
There was a discussion earlier on the alias on what Geronimo could or couldn't do with the JDK and other Sun libraries. You can actually do more than most people think, but anyway for a developer using Java already making them download another JDK is overkill. regards calvin Barry van Someren wrote: We could not ship the SDK (which is required to build the code) but we could in theory ship the others. You'd still need to worry about integrating them into the OS though, so I'd suggest we just keep pointing the users to instructions for CVS, SVN and Maven. It's a pain to set up, but most developers will either already have it or will know how to install it (with or without the instructions) Once you have everything setup, G is one of the easiest environments to work with. On 11/2/05, Sachin Patel [EMAIL PROTECTED] wrote: -1 from me. I could possibly understand the JDK, but definatley not svn, maven, and CVS. Prasad Kashyap wrote: This may be slightly related to Hernan's wiki thread but since we were talking about G for the impatient and a newbie manual, thought I'd ask this. Dave Klavon was talking about a single download and setup of all prereqs and G source, and build it too. I liked that idea and think that would be really nice. I even put together a package with basic scripts for that. However, now I am beginning to wonder if it is legal/permissible for us to /ship/ JDK, svn, maven and CVS in this single package ? Comments ? Cheers Prasad -- Sachin
[jira] Created: (GERONIMO-1125) AbstractSinglePoolConnectionInterceptor$IdleReleaser keeps MultiParentClassLoaders alive
AbstractSinglePoolConnectionInterceptor$IdleReleaser keeps MultiParentClassLoaders alive - Key: GERONIMO-1125 URL: http://issues.apache.org/jira/browse/GERONIMO-1125 Project: Geronimo Type: Bug Components: connector Versions: 1.0-M5 Environment: JDK 1.4/WinXP Reporter: Kevan Miller Assigned to: Kevan Miller Fix For: 1.0 After a deploy/undeploy of DayTrader, the following chain of references (there are others which I'm investigating) is keeping a MultiClassLoader instance from being marked as available for GC. java.util.TaskQueue.queue -- java.util.TimerTask[128] java.util.TimerTask[5] -- org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor$IdleReleaser IdleReleaser.this$0 -- org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor SinglePoolConnectionInterceptor.next -- org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor XAResourceInsertionInterceptor.next -- org.apache.geronimo.connector.outbound.MCFConnectionInterceptor MCFConnectionInterceptor.stack -- org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor ConnectionTrackingInterceptor.next -- org.apache.geronimo.connector.outbound.TCCLInterceptor TCCLInterceptor.classLoader -- org.apache.geronimo.kernel.config.MultiParentClassLoader The default interval for the IdleReleaser TimerTask is 30 minutes. Plenty of time for us to run out of PermGen space. Currently the task is never cancelled. I'm working on cancelling the task. However, that's not sufficient. TimerTask.cancel() simply updates state. It doesn't remove the Task from the TimerQueue. So, the task lives until it expires (looks like this feature is fixed in 1.5). Easiest fix is to break the chain of references at the IdleReleaser task when the task is cancelled. This should be good enough. Alternative is to implement our own Timer -- which wouldn't be too hard... Or have multiple Timers and cancel the whole timer... I'm working on breaking the chain of references at IdleReleaser. Note that this means the IdleReleaser classloader will be kept alive until the TimerTask expires. However, the IdleReleaser classloader is a long-lived Geronimo class loader. So, this shouldn't be a problem, but it's not ideal, either... -- 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: Common Visual Design for Geronimo's User Interfaces
On 11/2/05, Bill Stoddard [EMAIL PROTECTED] wrote: Very nice! How about a Powered by Apache Geronimo logo for folks to display on their AG powered websites or in their Apache Geronimo derivitive distros? There is a powered by image on the lower right-hand corner of this page: http://www.epiqtech.com/corp/products/technology/opensource/GeronimoWelcomeScreen.htm But I'm sure that the Epiq team would be willing to design some more. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
[jira] Closed: (GERONIMO-1123) generate geronimo-service.xml files from marked dependencies in project.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1123?page=all ] David Jencks closed GERONIMO-1123: -- Resolution: Fixed Sendingetc/maven.xml Sendingmodules/axis/project.xml Deleting modules/axis/src/etc/META-INF/geronimo-service.xml Sendingmodules/jetty/project.xml Deleting modules/jetty/src/etc Sendingmodules/tomcat/project.xml Deleting modules/tomcat/src/etc Adding plugins/geronimo-dependency-plugin Adding plugins/geronimo-dependency-plugin/LICENSE.txt Adding plugins/geronimo-dependency-plugin/NOTICE.txt Adding plugins/geronimo-dependency-plugin/maven.xml Adding plugins/geronimo-dependency-plugin/plugin.jelly Adding plugins/geronimo-dependency-plugin/plugin.properties Adding plugins/geronimo-dependency-plugin/project.properties Adding plugins/geronimo-dependency-plugin/project.xml Adding plugins/geronimo-dependency-plugin/src Adding plugins/geronimo-dependency-plugin/src/java Adding plugins/geronimo-dependency-plugin/src/java/org Adding plugins/geronimo-dependency-plugin/src/java/org/apache Adding plugins/geronimo-dependency-plugin/src/java/org/apache/geronimo Adding plugins/geronimo-dependency-plugin/src/java/org/apache/geronimo/plugin Adding plugins/geronimo-dependency-plugin/src/java/org/apache/geronimo/plugin/dependency Adding plugins/geronimo-dependency-plugin/src/java/org/apache/geronimo/plugin/dependency/GenerateServiceXml.java Transmitting file data Committed revision 330285. openejb: Checking in etc/maven.xml; new revision: 1.6; previous revision: 1.5 Checking in modules/core/project.xml; new revision: 1.60; previous revision: 1.59 Removing modules/core/src/etc/META-INF/geronimo-service.xml; new revision: delete; previous revision: 1.13 This may obstruct M2 conversion of openejb since there is not yet an m2 version of this dependency plugin. generate geronimo-service.xml files from marked dependencies in project.xml --- Key: GERONIMO-1123 URL: http://issues.apache.org/jira/browse/GERONIMO-1123 Project: Geronimo Type: Improvement Components: buildsystem Versions: 1.0 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0 Write a maven plugin to generate the geronimo-service.xml dependency lists from marked dependencies in project.xml. I'm going to use properties geronimo.dependencytrue/geronimo.dependency /properties unless someone has a better idea. -- 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: Old branches (was: Old tags in Geornimo)
This is exactly why I brought it up last time. There is obviously something wrong when the people that are supposed to know better are making mistakes? It is just confusing to have the branch there it is not a branch just a temp place we worked wile packaging the release. I suggest next time we are creating a milestone, preview or tag only (unsupported) release, we don't create the temp branch in branches. +1 to remove the confusing, non-supported, temporary branch we created for 1.0-M5 packaging. -dain On Nov 1, 2005, at 10:09 PM, David Blevins wrote: The last nail in the coffin for me was when, in a sleep deprived state, I got a little disoriented and built the M5 installer from the branch directory rather than the tag directory. Accidents happen. A simple svn copy cheaply creates a new branch, keeps it clear its different than the tag, and gives someone a place to work with it. The possibility of that is small, so we'll just let the person create it when they wish to do something weird. :) -David On Nov 1, 2005, at 3:20 AM, Geir Magnusson Jr. wrote: I don't understand the harm of leaving the branches - it costs nothing since it's already created, it keeps the history clear, and it gives someone an opportunity in the future to work with it. I know the probability of that is small, but people do weird things... geir On Oct 31, 2005, at 9:06 PM, David Blevins wrote: Can we kill this old branch? http://svn.apache.org/repos/asf/geronimo/branches/1.0-M5 We have a tag for it here. http://svn.apache.org/repos/asf/geronimo/tags/1_0_M5 And can we also agree that we don't leave branches hanging around after every release unless that is planned to be an actual branch point? -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Old branches (was: Old tags in Geornimo)
On 11/2/05, Dain Sundstrom [EMAIL PROTECTED] wrote: I suggest next time we are creating a milestone, preview or tag only (unsupported) release, we don't create the temp branch in branches. I respectfully disagree with this idea and my reasons are simple - tags are meant to mark a point in time and *should not change* (i.e., commits to a tag should not happen). If a tag needs to change (i.e., something needs to be committed to it) then that tag figuratively becomes a branch (and should therefore be moved to the branches dir). Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: Wiki reorganization proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Sisson wrote: The suggested layout sounds fine to me. This is long overdue and is an opportunity to remove/move/fix documentation that no longer matches what has been implemented. My main concern with the use of the Wiki for documentation is that the Wiki content isn't versioned to match Geronimo releases. I think that's pretty significant. Documentation needs to be versioned allong with the code. Just as you can say 'this is the state of the code as of tag-or-date X' you need to be able to locate the corresponding documentation (regardless of how well it has kept up with the code). Wikis historically have been a collaboration tool, not a documentation tool. Working together on docco in a wiki is great and can speed things up enormously -- but it needs to get integrated into the SVN repository periodically for versioning and history retention. An alternative is to develop the main documentation under svn control (the Derby project does this), but that would mean updates would have to be submitted as patches. Derby's doco can be easily generated as a PDF with bookmarks etc, which is great for offline or printing. The patch model is used a lot, and it has the advantage of handling the docco the same way the code is. However, it doesn't lend itself to quick fixes of typos or contributions by non-developers. Wikis are great for that sort of thing, but have the problems you've already pointed out. Perhaps some mix would be good, such as a weekly checkin to svn of any changes to the wiki. Of course, then there's the issue of format compatibility. Do the wikis in use provide for XML exports? If so, a little glue should be able to automatically manage the conversion and checkin. The major problems I see with that is that the who-changed-what accountability is lost (unless a change to the wiki can be included in the export as an XML entity that can be used to identify the changer in svn), and that changes made between checkpoints don't get recorded. There are lots of docco models in use out there. There's the patch model which is used by Derby and the httpd project; there's the user-comments-get-periodically-rolled-in model that PHP uses; there's the wiki-only method, and probably lots of others. I think the documentation should be considered as much a product of the Geronimo project as the code, and should be treated with the same care and attention to versioning, history, and accountability. My US$0.02. - -- #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 Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ2hAKJrNPMCpn3XdAQJTkgQAzqd9n9viIJKEmIR31rsbkv5+6YyN+9Nd 4cxDpJDoz037ZIZ/wo8XrKughZlltgcedECEDvOd/XQ4jTdSFS0OhVK2FRwpTIsH Novl7V1Z/3p7Gb9MT6NlEhbKSn/RrCw0296fKNbLo1kz/+Db2r6B3WYJ8TpoeJri BXv+kYkfJT4= =VPrR -END PGP SIGNATURE-
[jira] Created: (GERONIMO-1126) Packaging plugin should add marked dependencies from project.xml
Packaging plugin should add marked dependencies from project.xml Key: GERONIMO-1126 URL: http://issues.apache.org/jira/browse/GERONIMO-1126 Project: Geronimo Type: Improvement Components: buildsystem Versions: 1.0 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.0 Similar to Geronimo-1123. The packaging plugin should add dependencies from project.xml. This will tie the geronimo dependency model into the maven dependency model. -- 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-1127) Assembly plugin should analyse config dependencies to fill geronimo repo
Assembly plugin should analyse config dependencies to fill geronimo repo Key: GERONIMO-1127 URL: http://issues.apache.org/jira/browse/GERONIMO-1127 Project: Geronimo Type: Improvement Components: buildsystem Versions: 1.0 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.0 Currently the assembly plugin fills the geronimo repo using marked dependencies from project.xml. This duplicates information from the configurations the assembly plugin is installing. The assembly plugin should extract the list of dependencies from each config it is installing and install all those dependencies in the geronimo repo. At the moment this still requires all possible dependencies to be listed in project.xml to make sure they are on the current system, but if we use a maven version with transitive dependency support simply listing the configs to include as dependencies should be sufficient. -- 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: Axis Issue 2278
Problem has been fixed in Axis' SVN. -- dims On 11/2/05, Kevan Miller [EMAIL PROTECTED] wrote: FYI, I've raised an issue and supplied a patch for an Axis problem which is causing memory leaks in Geronimo -- http://issues.apache.org/jira/browse/AXIS-2278. I don't know of a formal process for tracking dependencies on other projects. So, I've advertised it here... Fix was for axis trunk. Should we request an update to Axis 1.3? Possible that there's another Axis problem, but need to dig a bit more.. --kevan -- Davanum Srinivas : http://wso2.com/blogs/
Re: Single download, setup and build.
One thing I'd like to see working is the scm:bootstrap goal. Assuming you have a JDK and maven installed, maven will checkout your source and build the project. For example, this works for activeIO: maven scm:bootstrap -Dmaven.scm.url=scm:svn:https://svn.codehaus.org/ activeio/trunk/activeio -Dmaven.scm.checkout.dir=activeio Of course activeIO doesn't complete the build for some reason, but you get the idea :) -dain On Nov 2, 2005, at 7:21 AM, Prasad Kashyap wrote: This may be slightly related to Hernan's wiki thread but since we were talking about G for the impatient and a newbie manual, thought I'd ask this. Dave Klavon was talking about a single download and setup of all prereqs and G source, and build it too. I liked that idea and think that would be really nice. I even put together a package with basic scripts for that. However, now I am beginning to wonder if it is legal/permissible for us to ship JDK, svn, maven and CVS in this single package ? Comments ? Cheers Prasad
Re: Old branches (was: Old tags in Geornimo)
On Nov 2, 2005, at 9:18 AM, Bruce Snyder wrote: On 11/2/05, Dain Sundstrom [EMAIL PROTECTED] wrote: I suggest next time we are creating a milestone, preview or tag only (unsupported) release, we don't create the temp branch in branches. I respectfully disagree with this idea and my reasons are simple - tags are meant to mark a point in time and *should not change* (i.e., commits to a tag should not happen). If a tag needs to change (i.e., something needs to be committed to it) then that tag figuratively becomes a branch (and should therefore be moved to the branches dir). You know, I think the big problem here is we are trying to apply CVS terminology and dogma developed due to the limitations of CVS. In CVS, the dogma is you never create a branch from a tag, always branch then tag. In subversion there is no difference between a tag and a branch and we can easily change between them. The difference lives in how we treat them. I get the feeling that this debate is in a quagmire because we do not have a common set of definitions for the terms we are using, so let's formally define them. I think we have the following categories for code lines in our repository: supported code line (mutable) snapshot code line (immutable) experimental code line ?? others ?? The nice thing with subversion is we can switch a code line between the three groups with zero impact to history and development. We can simply move a code line to a new category, or create a copy of a code line in a new category. Another big problem we have is creating a snapshot line is can not atomic operation. Subversion is more then willing to make an atomic copy, but we can not create a snapshot code line without modifying the build and sometimes the code, and then there is certification testing which sometimes requires modification to the code line. I think how we handle the hand off from a supported code line to a snapshot code line is at the heart of this debate. -dain
[jira] Created: (GERONIMO-1128) Derby Log Viewer performance problem
Derby Log Viewer performance problem Key: GERONIMO-1128 URL: http://issues.apache.org/jira/browse/GERONIMO-1128 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: Win32 w/ latest 1.4.2 JDK Reporter: Donald Woods When the Derby Log Viewer is rendered on the Servers Log page, the DerbyLogHelper.java copying ALL lines from derby.log and sending it back as a request attribute. As the Derby logfile grows, this will consume more server cycles and eventually impact other user apps and response time. Also, the BufferedReader/FileReader is never closed, so this will leak a file handle everytime the page is rendered. This portlet needs to be replaced with the logmanager/LogViewerPortet implementation, so users can choose how many lines to display -- 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
globalJNDINAME global-jndi-name
It looks like there used to be an attribute (globalJNDIName) once that was set on the GBeans for objects like connectors. This would be specified in the plan for the connector using the global-jndi-name element. This name was supposed to be globally unique in G so that the item (connector or whatever) could be referenced from client applications. We have several places in the web console that are broken now because the code assumes this is set on the gbeans to display for a connector and/or to specify it when a new connector is created. I really don't know much about connectors. Was the globalJNDName replaced by something else that we should reference? Or, should the console simply stop retrieving, setting, and displaying this attribute (and jndiName which is often set from the globalJNDIName)? Patches have been contributed that just ignore the field but I'm not sure if that is the right fix. Joe -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Question reg: build script
On Nov 1, 2005, at 2:47 PM, David Blevins wrote: On Nov 1, 2005, at 2:09 PM, Prasad Kashyap wrote: I have a question regarding one of our build scripts, particularly the publish_build.sh http://svn.apache.org/repos/asf/geronimo/scripts/publish_build.sh Why is there a build() at all ? The publish_build_archives() seems relevant and appropriate. The original version of the script didn't have the build part in it and assumed you knew the build was good. It's a kind of hackish part of the script that 1) builds online and makes sure you have everything on your machine you need to build and 2) builds all the projects related to Geronimo. Both of which can take a long time. It can easily be yanked for a box that runs a build very often. So last night I hacked up the publish_build.sh script creates the unstable builds to fix some of the things you've mentioned on IRC . First, i yanked the build function as you note above is a little crufty. Second, I modified the maven call in the publish_build_archives section to do an m:build-all. Also, we now pass -Dgeronimo_version=1.0-12345 (for example) as a parameter which is now possible via a couple changes in the maven setup Dims and I made recently. Much nicer than the perl technique that was previously there. Give it a run and tell me if it works for you. -David
Re: Common Visual Design for Geronimo's User Interfaces
Bruce Snyder wrote: On 11/2/05, Bill Stoddard [EMAIL PROTECTED] wrote: Very nice! How about a Powered by Apache Geronimo logo for folks to display on their AG powered websites or in their Apache Geronimo derivitive distros? There is a powered by image on the lower right-hand corner of this page: http://www.epiqtech.com/corp/products/technology/opensource/GeronimoWelcomeScreen.htm But I'm sure that the Epiq team would be willing to design some more. Bruce, This was exactly what I was looking for. Thanks for pointing it out. Bill
Re: Old branches (was: Old tags in Geornimo)
On Nov 2, 2005, at 10:51 AM, Dain Sundstrom wrote: On Nov 2, 2005, at 9:18 AM, Bruce Snyder wrote: On 11/2/05, Dain Sundstrom [EMAIL PROTECTED] wrote: I suggest next time we are creating a milestone, preview or tag only (unsupported) release, we don't create the temp branch in branches. I respectfully disagree with this idea and my reasons are simple - tags are meant to mark a point in time and *should not change* (i.e., commits to a tag should not happen). If a tag needs to change (i.e., something needs to be committed to it) then that tag figuratively becomes a branch (and should therefore be moved to the branches dir). You know, I think the big problem here is we are trying to apply CVS terminology and dogma developed due to the limitations of CVS. In CVS, the dogma is you never create a branch from a tag, always branch then tag. Guys, you are totally agreeing. To paraphrase Dain, It should be fine to create a branch from a tag, forget CVS dogma. To paraphrase Bruce, If we need to updated a tag, move it to the branches dir at that point, so it's not a tag anymore. And my thoughts are the same as well, If we need to update a tag for some unknow reason in the future, let's move it (or copy it with a new name) to the branches directory at that point. Did I capture everything correctly? -David
Re: Old branches (was: Old tags in Geornimo)
On 11/2/05, Dain Sundstrom [EMAIL PROTECTED] wrote: On Nov 2, 2005, at 9:18 AM, Bruce Snyder wrote: On 11/2/05, Dain Sundstrom [EMAIL PROTECTED] wrote: I suggest next time we are creating a milestone, preview or tag only (unsupported) release, we don't create the temp branch in branches. I respectfully disagree with this idea and my reasons are simple - tags are meant to mark a point in time and *should not change* (i.e., commits to a tag should not happen). If a tag needs to change (i.e., something needs to be committed to it) then that tag figuratively becomes a branch (and should therefore be moved to the branches dir). You know, I think the big problem here is we are trying to apply CVS terminology and dogma developed due to the limitations of CVS. In CVS, the dogma is you never create a branch from a tag, always branch then tag. In subversion there is no difference between a tag and a branch and we can easily change between them. The difference lives in how we treat them. Yes, it is a figurative and semantic difference (unless one implements some sophisticated commit hooks to disable committing to a tag). However, the concepts of tags vs. branches does not change from CVS to SVN - tags are meant to be static whereas branches are meant to be lines of development. In fact, here's a message from the svn-user@ mailing list supporting this notion: http://svn.haxx.se/users/archive-2003-09/0021.shtml I get the feeling that this debate is in a quagmire because we do not have a common set of definitions for the terms we are using, so let's formally define them. Actually, I agree completely with this statement. Agreement on terms and their definitions is more meaningful than any other concept really. I think we have the following categories for code lines in our repository: supported code line (mutable) snapshot code line (immutable) experimental code line ?? others ?? The nice thing with subversion is we can switch a code line between the three groups with zero impact to history and development. We can simply move a code line to a new category, or create a copy of a code line in a new category. Exactly ;-). Another big problem we have is creating a snapshot line is can not atomic operation. Subversion is more then willing to make an atomic copy, but we can not create a snapshot code line without modifying the build and sometimes the code, and then there is certification testing which sometimes requires modification to the code line. I think how we handle the hand off from a supported code line to a snapshot code line is at the heart of this debate. Yes, and this is a very common dilemma. The recommended procedure is the following set of steps: 1) Create a tag from HEAD named tag_foo1 2) Create a branch from tag_foo named tag_foo1_branch 3) Do work 4) Create a tag from tag_foo1_branch named tag_foo2 5) Remove tag_foo1_branch accordingly The reasons for making the two tags is many, but the most important one is to easily create a diff between the start and the end of the development. This covers any need to merge changes back into HEAD from the work done on the branch. In addition, copies are cheap in Subversion so creating many, many tags has little impact on the server. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: Common Visual Design for Geronimo's User Interfaces
Isn't this it? http://www.epiqtech.com/corp/products/technology/opensource/ GeronimoWelcomeScreen.htm -dain On Nov 2, 2005, at 11:21 AM, Jeff Genender wrote: Yes a powered-by would be most excellent ;-) Also...How about a new special welcome screen for the web containers? I know...I know...I shouldn't ask...but the squeaky wheel gets the oil ;-) Jeff Bill Stoddard wrote: David Klavon wrote: Now that there is an official logo image for Geronimo, we thought that it would be useful to extend the color scheme, font style, icon use, etc. across the various user interfaces in the project, and create a common 'visual appearance' for the Geronimo project for v1.0. Very nice! How about a Powered by Apache Geronimo logo for folks to display on their AG powered websites or in their Apache Geronimo derivitive distros? Bill
Re: globalJNDINAME global-jndi-name
On Nov 2, 2005, at 10:59 AM, Joe Bohn wrote: It looks like there used to be an attribute (globalJNDIName) once that was set on the GBeans for objects like connectors. This would be specified in the plan for the connector using the global-jndi-name element. This name was supposed to be globally unique in G so that the item (connector or whatever) could be referenced from client applications. We have several places in the web console that are broken now because the code assumes this is set on the gbeans to display for a connector and/or to specify it when a new connector is created. I really don't know much about connectors. Was the globalJNDName replaced by something else that we should reference? no, it was removed as a bad idea/implementation Or, should the console simply stop retrieving, setting, and displaying this attribute (and jndiName which is often set from the globalJNDIName)? We should not display or access a global jndi name at this time. jndi names an application might use must be specified in the app dd and may be mapped to a gbean automatically or with help from a geronimo plan. I don't see how the console could display any useful info about a connector jndi name except in context of a particular application using it. Patches have been contributed that just ignore the field but I'm not sure if that is the right fix. Deleting all references to it would be a good idea. thanks david jencks Joe -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Axis Issue 2278
Hi Dims, Thanks. BTW, I see there is a difference in the implementation of TypeDesc between 1.3 and the trunk. 1.3 is using a classMaps WeakHashMap whereas the trunk has a classMap Hashtable. I didn't try to track down the cvs history to see if it was a possible oversight or intentional. I have my doubts that the WeakHashMap would be weak because of a likely reference/chain of references from value to the key. However, I haven't confirmed. --kevan On 11/2/05, Davanum Srinivas [EMAIL PROTECTED] wrote: Problem has been fixed in Axis' SVN.-- dimsOn 11/2/05, Kevan Miller [EMAIL PROTECTED] wrote: FYI, I've raised an issue and supplied a patch for an Axis problem which is causing memory leaks in Geronimo -- http://issues.apache.org/jira/browse/AXIS-2278.I don't know of a formal process for tracking dependencies on other projects. So, I've advertised it here... Fix was for axis trunk. Should we request an update to Axis 1.3? Possible that there's another Axis problem, but need to dig a bit more..--kevan --Davanum Srinivas : http://wso2.com/blogs/
Re: Common Visual Design for Geronimo's User Interfaces
Why yes it is! Thanks for pointing it out...I haven't been as attentive as I should be...I just found out I am a dad-to-be for a third time ;-) So my head has been slightly elsewhere :) Jeff Dain Sundstrom wrote: Isn't this it? http://www.epiqtech.com/corp/products/technology/opensource/GeronimoWelcomeScreen.htm -dain On Nov 2, 2005, at 11:21 AM, Jeff Genender wrote: Yes a powered-by would be most excellent ;-) Also...How about a new special welcome screen for the web containers? I know...I know...I shouldn't ask...but the squeaky wheel gets the oil ;-) Jeff Bill Stoddard wrote: David Klavon wrote: Now that there is an official logo image for Geronimo, we thought that it would be useful to extend the color scheme, font style, icon use, etc. across the various user interfaces in the project, and create a common 'visual appearance' for the Geronimo project for v1.0. Very nice! How about a Powered by Apache Geronimo logo for folks to display on their AG powered websites or in their Apache Geronimo derivitive distros? Bill
Re: Axis Issue 2278
Could you please check here? http://svn.apache.org/viewcvs.cgi/webservices/axis/trunk/java/src/org/apache/axis/description/TypeDesc.java thanks, dims On 11/2/05, Kevan Miller [EMAIL PROTECTED] wrote: Hi Dims, Thanks. BTW, I see there is a difference in the implementation of TypeDesc between 1.3 and the trunk. 1.3 is using a classMaps WeakHashMap whereas the trunk has a classMap Hashtable. I didn't try to track down the cvs history to see if it was a possible oversight or intentional. I have my doubts that the WeakHashMap would be weak because of a likely reference/chain of references from value to the key. However, I haven't confirmed. --kevan On 11/2/05, Davanum Srinivas [EMAIL PROTECTED] wrote: Problem has been fixed in Axis' SVN. -- dims On 11/2/05, Kevan Miller [EMAIL PROTECTED] wrote: FYI, I've raised an issue and supplied a patch for an Axis problem which is causing memory leaks in Geronimo -- http://issues.apache.org/jira/browse/AXIS-2278. I don't know of a formal process for tracking dependencies on other projects. So, I've advertised it here... Fix was for axis trunk. Should we request an update to Axis 1.3? Possible that there's another Axis problem, but need to dig a bit more.. --kevan -- Davanum Srinivas : http://wso2.com/blogs/ -- Davanum Srinivas : http://wso2.com/blogs/
[jira] Created: (GERONIMO-1129) Set TTCL around GBean lifecycle methods
Set TTCL around GBean lifecycle methods --- Key: GERONIMO-1129 URL: http://issues.apache.org/jira/browse/GERONIMO-1129 Project: Geronimo Type: Improvement Components: kernel Reporter: Dain Sundstrom Assigned to: Dain Sundstrom There is a lot of code out there that assumes the TCCL is properly set in the constructor, start and stop methods, so instead of requiring everyone to write a wrapper class, lets just set it. The reason we removed most of the TCCL setting code from Geronimo was because it was a major performance impact. I just think we went a little to far. The life cycle methods are rarely called and don't happen in code paths where performance is critical. I think we should change the GBeanInstance code to set the TCCL around doStart and doStop. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1129) Set TTCL around GBean lifecycle methods
[ http://issues.apache.org/jira/browse/GERONIMO-1129?page=comments#action_12356647 ] Davanum Srinivas commented on GERONIMO-1129: +1 from me :) Set TTCL around GBean lifecycle methods --- Key: GERONIMO-1129 URL: http://issues.apache.org/jira/browse/GERONIMO-1129 Project: Geronimo Type: Improvement Components: kernel Reporter: Dain Sundstrom Assignee: Dain Sundstrom There is a lot of code out there that assumes the TCCL is properly set in the constructor, start and stop methods, so instead of requiring everyone to write a wrapper class, lets just set it. The reason we removed most of the TCCL setting code from Geronimo was because it was a major performance impact. I just think we went a little to far. The life cycle methods are rarely called and don't happen in code paths where performance is critical. I think we should change the GBeanInstance code to set the TCCL around doStart and doStop. -- 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: Common Visual Design for Geronimo's User Interfaces
On 11/2/05, Jeff Genender [EMAIL PROTECTED] wrote: Why yes it is! Thanks for pointing it out...I haven't been as attentive as I should be...I just found out I am a dad-to-be for a third time ;-) So my head has been slightly elsewhere :) I BIG congrats to Jeff and his wife! Today is their 10th wedding anniversary and she gave him the gift of a third child on the way. Wh!!! Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: Question reg: build script
Cool. My ant equivalent of the same is nearing completion too. Let me test them both. Thanx Dave. Cheers Prasad On 11/2/05, David Blevins [EMAIL PROTECTED] wrote: On Nov 1, 2005, at 2:47 PM, David Blevins wrote: On Nov 1, 2005, at 2:09 PM, Prasad Kashyap wrote: I have a question regarding one of our build scripts, particularly the publish_build.sh http://svn.apache.org/repos/asf/geronimo/scripts/publish_build.sh Why is there a build() at all ?The publish_build_archives() seems relevant and appropriate. The original version of the script didn't have the build part in it and assumed you knew the build was good.It's a kind of hackish part of the script that 1) builds online and makes sure you have everything on your machine you need to build and 2) builds all the projects related to Geronimo.Both of which can take a long time. It can easily be yanked for a box that runs a build very often.So last night I hacked up the publish_build.sh script creates the unstable builds to fix some of the things you've mentioned on IRC .First, i yanked the build function as you note above is a littlecrufty.Second, I modified the maven call in thepublish_build_archives section to do an m:build-all. Also, we now pass -Dgeronimo_version=1.0-12345 (for example) as aparameter which is now possible via a couple changes in the mavensetup Dims and I made recently.Much nicer than the perl techniquethat was previously there. Give it a run and tell me if it works for you.-David
Re: globalJNDINAME global-jndi-name
On Nov 2, 2005, at 11:38 AM, David Jencks wrote: On Nov 2, 2005, at 10:59 AM, Joe Bohn wrote: It looks like there used to be an attribute (globalJNDIName) once that was set on the GBeans for objects like connectors. This would be specified in the plan for the connector using the global- jndi-name element. This name was supposed to be globally unique in G so that the item (connector or whatever) could be referenced from client applications. We have several places in the web console that are broken now because the code assumes this is set on the gbeans to display for a connector and/or to specify it when a new connector is created. I really don't know much about connectors. Was the globalJNDName replaced by something else that we should reference? no, it was removed as a bad idea/implementation Um we need a replacement for this. There are a lot of appliation out there that assume there is a global JNDI avaiable and that they can look up JDBC connections from global JNDI. -dain
Re: Old branches (was: Old tags in Geornimo)
On Nov 2, 2005, at 11:19 AM, Bruce Snyder wrote: On 11/2/05, David Blevins [EMAIL PROTECTED] wrote: Guys, you are totally agreeing. To paraphrase Dain, It should be fine to create a branch from a tag, forget CVS dogma. To paraphrase Bruce, If we need to updated a tag, move it to the branches dir at that point, so it's not a tag anymore. I think we're in agreement as well. And my thoughts are the same as well, If we need to update a tag for some unknow reason in the future, let's move it (or copy it with a new name) to the branches directory at that point. One minor clarification. IMO, tags should remain intact forever. Therefore a tag should be copied to the branches dir, not moved. But I digress... ;-). Awesome. That's my preference as well, just didn't want to be inflexible and wasn't sure if you meant therefore be moved as in svn move. Can you +1 my proposal for clarity? Thanks, David
Re: Question reg: build script
On Nov 2, 2005, at 11:52 AM, Prasad Kashyap wrote: Cool. My ant equivalent of the same is nearing completion too. Let me test them both. Awesome! -David Thanx Dave. Cheers Prasad On 11/2/05, David Blevins [EMAIL PROTECTED] wrote: On Nov 1, 2005, at 2:47 PM, David Blevins wrote: On Nov 1, 2005, at 2:09 PM, Prasad Kashyap wrote: I have a question regarding one of our build scripts, particularly the publish_build.sh http://svn.apache.org/repos/asf/geronimo/scripts/publish_build.sh Why is there a build() at all ? The publish_build_archives() seems relevant and appropriate. The original version of the script didn't have the build part in it and assumed you knew the build was good. It's a kind of hackish part of the script that 1) builds online and makes sure you have everything on your machine you need to build and 2) builds all the projects related to Geronimo. Both of which can take a long time. It can easily be yanked for a box that runs a build very often. So last night I hacked up the publish_build.sh script creates the unstable builds to fix some of the things you've mentioned on IRC . First, i yanked the build function as you note above is a little crufty. Second, I modified the maven call in the publish_build_archives section to do an m:build-all. Also, we now pass -Dgeronimo_version=1.0-12345 (for example) as a parameter which is now possible via a couple changes in the maven setup Dims and I made recently. Much nicer than the perl technique that was previously there. Give it a run and tell me if it works for you. -David
Re: Common Visual Design for Geronimo's User Interfaces
On Nov 2, 2005, at 11:39 AM, Jeff Genender wrote: Why yes it is! Thanks for pointing it out...I haven't been as attentive as I should be...I just found out I am a dad-to-be for a third time ;-) So my head has been slightly elsewhere :) Wow! Congratulation. Alan and Geir can help you with your one arm baby holding, one arm typing skills :) -dain
[jira] Updated: (GERONIMO-861) Investigate warning from Pluto portal
[ http://issues.apache.org/jira/browse/GERONIMO-861?page=all ] Joe Bohn updated GERONIMO-861: -- Attachment: plutoWarning.patch Thanks for looking into this Bill. I looked at the reference you attached in pluto and it sounded to me like it was safer to specify no for the supportsBuffering. It stated that tomcat only supports the spec and the spec doesn't support buffering ... hence neither does tomcat.So, thanks to your pointer, I am attaching this patch. Investigate warning from Pluto portal - Key: GERONIMO-861 URL: http://issues.apache.org/jira/browse/GERONIMO-861 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Jeremy Boynes Fix For: 1.0 Attachments: plutoWarning.patch Investigate the following message: 14:31:22,763 WARN [Servlet] org.apache.pluto.portalImpl.Servlet#init(): Couldn't read property pluto.allowSetBufferSize from config file ConfigService.properties -- 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-861) Investigate warning from Pluto portal
[ http://issues.apache.org/jira/browse/GERONIMO-861?page=all ] Joe Bohn updated GERONIMO-861: -- Geronimo Info: [Patch Available] Investigate warning from Pluto portal - Key: GERONIMO-861 URL: http://issues.apache.org/jira/browse/GERONIMO-861 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Jeremy Boynes Fix For: 1.0 Attachments: plutoWarning.patch Investigate the following message: 14:31:22,763 WARN [Servlet] org.apache.pluto.portalImpl.Servlet#init(): Couldn't read property pluto.allowSetBufferSize from config file ConfigService.properties -- 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: Common Visual Design for Geronimo's User Interfaces
Very nice. Congrats...your quiver overfloweth :-0 Jeff Genender wrote: Why yes it is! Thanks for pointing it out...I haven't been as attentive as I should be...I just found out I am a dad-to-be for a third time ;-) So my head has been slightly elsewhere :) Jeff Dain Sundstrom wrote: Isn't this it? http://www.epiqtech.com/corp/products/technology/opensource/GeronimoWelcomeScreen.htm -dain On Nov 2, 2005, at 11:21 AM, Jeff Genender wrote: Yes a powered-by would be most excellent ;-) Also...How about a new special welcome screen for the web containers? I know...I know...I shouldn't ask...but the squeaky wheel gets the oil ;-) Jeff Bill Stoddard wrote: David Klavon wrote: Now that there is an official logo image for Geronimo, we thought that it would be useful to extend the color scheme, font style, icon use, etc. across the various user interfaces in the project, and create a common 'visual appearance' for the Geronimo project for v1.0. Very nice! How about a Powered by Apache Geronimo logo for folks to display on their AG powered websites or in their Apache Geronimo derivitive distros? Bill
Re: Common Visual Design for Geronimo's User Interfaces
This is fantastic! And of much superior quality than Matt's Grey to Great comment ;) Excellent work! I'd like to throw a penny in to the new website wishing-well as well. This is so cool. -David On Nov 2, 2005, at 5:08 AM, Matt Hogstrom wrote: Absolutely stunning. Glenn, you've outdone yourself. Is it possible to get a patch for this and integrate so we can get some functional feedback as well. I think the entire Geronimo team owes you a debt of gratitude for heling to get us out of the Grey console into the Great! console :) - Matt Joe Bohn wrote: When I first saw these I was surprised at what a dramatic difference this is over what we sent to Epiq. As I've already told the Epiq team great work!! I also agree that we should spread the style to as many G user interfaces as possible. It would be great if we could come up with some simple format that everything supports - such as all having the banner at the top and perhaps even some shaded primary tasks area on the left. The tasks could be navigation choices for the web console, commands for the debug console, primary links for the web page, etc... If we could share the exact image across the build that would really help when making changes. Joe David Klavon wrote: Now that there is an official logo image for Geronimo, we thought that it would be useful to extend the color scheme, font style, icon use, etc. across the various user interfaces in the project, and create a common 'visual appearance' for the Geronimo project for v1.0. The Epiq Team, the recent winners of the logo contest, have drafted some ideas of what an integrated suite would look like to get the discussion going in the community. While there are many details to be worked out on each of the respective interfaces, we would like to get the community feedback on the general approach and style. If found favorable, we could begin to create the icon libraries and other style sheets for implementation. http://www.epiqtech.com/corp/products/technology/opensource/ ServerConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/ ServerConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/ GeronimoWelcomeScreen.htm http://www.epiqtech.com/corp/products/technology/opensource/ DebugConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/ DebugConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/ DaytraderLogo.htm I think the Epiq Team has really showcased their award winning skills in giving Geronimo a professional look and integrated- suite feel that would add great value to the v1.0 delivery. Let us know what everyone thinks... Dave
[jira] Updated: (GERONIMO-877) Update TranQL connector jar filename in console properties
[ http://issues.apache.org/jira/browse/GERONIMO-877?page=all ] Joe Bohn updated GERONIMO-877: -- Geronimo Info: [Patch Available] Update TranQL connector jar filename in console properties -- Key: GERONIMO-877 URL: http://issues.apache.org/jira/browse/GERONIMO-877 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Stefan Schmidt Fix For: 1.0 I could not deploy a new DataSource via the console because the wrong TranQL connector name is used: org.apache.geronimo.common.DeploymentException: java.io.FileNotFoundException: :\web\GeronimoTrunk\repository\tranql\rars\tranql-connector-1.0-SNAPSHOT.rar (T e system cannot find the file specified) This name needs to be changed to tranql-1.1-SNAPSHOT.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: globalJNDINAME global-jndi-name
On Nov 2, 2005, at 11:54 AM, Dain Sundstrom wrote: On Nov 2, 2005, at 11:38 AM, David Jencks wrote: On Nov 2, 2005, at 10:59 AM, Joe Bohn wrote: It looks like there used to be an attribute (globalJNDIName) once that was set on the GBeans for objects like connectors. This would be specified in the plan for the connector using the global-jndi-name element. This name was supposed to be globally unique in G so that the item (connector or whatever) could be referenced from client applications. We have several places in the web console that are broken now because the code assumes this is set on the gbeans to display for a connector and/or to specify it when a new connector is created. I really don't know much about connectors. Was the globalJNDName replaced by something else that we should reference? no, it was removed as a bad idea/implementation Um we need a replacement for this. There are a lot of appliation out there that assume there is a global JNDI avaiable and that they can look up JDBC connections from global JNDI. Is there an app server independent jndi location they can look up their non-portable resource at? What is it? The location we were using (geronimo:any/place/you/want) was certainly not available on any other app server. If they have to change the location for each app server anyway, why not have them look it up in the portable java:comp/env location and use a name geronimo can resolve without a plan entry? thanks david jencks
[jira] Updated: (GERONIMO-1041) Portlets updates required to match new ActiveMQ and TranQL versions in trunk
[ http://issues.apache.org/jira/browse/GERONIMO-1041?page=all ] Joe Bohn updated GERONIMO-1041: --- Geronimo Info: [Patch Available] Portlets updates required to match new ActiveMQ and TranQL versions in trunk Key: GERONIMO-1041 URL: http://issues.apache.org/jira/browse/GERONIMO-1041 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: trunk Reporter: Donald Woods Attachments: Geronimo-1041.patch The trunk versions of the following Portlet files need to be updated with post-M5 version changes to ActiveMQ and TranQL - applications\console-standard\src\java\org\apache\geronimo\console\jmsmanager\activemqCF\ActiveMQConnectorHelper.java applications\console-standard\src\java\org\apache\geronimo\console\databasemanager\DatabaseManagerHelper.java They are currently using pre-M5 versions - activemq-ra-3.1-SNAPSHOT.rar instead of activemq-ra-3.2-SNAPSHOT.rar tranql-connector-1.0-SNAPSHOT.rar instead of tranql-connector-1.1-SNAPSHOT.rar -- 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: Old branches (was: Old tags in Geornimo)
On 11/2/05, David Blevins [EMAIL PROTECTED] wrote: One minor clarification. IMO, tags should remain intact forever. Therefore a tag should be copied to the branches dir, not moved. But I digress... ;-). Awesome. That's my preference as well, just didn't want to be inflexible and wasn't sure if you meant therefore be moved as in svn move. Can you +1 my proposal for clarity? I did that for the original message that started this discussion thread two days ago. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: Common Visual Design for Geronimo's User Interfaces
Jeff Genender wrote: Why yes it is! Thanks for pointing it out...I haven't been as attentive as I should be...I just found out I am a dad-to-be for a third time ;-) So my head has been slightly elsewhere :) Jeff Jeff, Congrats! Bill
Re: globalJNDINAME global-jndi-name
On Nov 2, 2005, at 12:08 PM, David Jencks wrote: On Nov 2, 2005, at 11:54 AM, Dain Sundstrom wrote: Um we need a replacement for this. There are a lot of appliation out there that assume there is a global JNDI avaiable and that they can look up JDBC connections from global JNDI. Is there an app server independent jndi location they can look up their non-portable resource at? What is it? The location we were using (geronimo:any/place/you/want) was certainly not available on any other app server. If they have to change the location for each app server anyway, why not have them look it up in the portable java:comp/env location and use a name geronimo can resolve without a plan entry? It should be jndi.lookup(foo/bar/Connection). -dain
[jira] Closed: (GERONIMO-1129) Set TTCL around GBean lifecycle methods
[ http://issues.apache.org/jira/browse/GERONIMO-1129?page=all ] Dain Sundstrom closed GERONIMO-1129: Resolution: Fixed Done. Set TTCL around GBean lifecycle methods --- Key: GERONIMO-1129 URL: http://issues.apache.org/jira/browse/GERONIMO-1129 Project: Geronimo Type: Improvement Components: kernel Reporter: Dain Sundstrom Assignee: Dain Sundstrom There is a lot of code out there that assumes the TCCL is properly set in the constructor, start and stop methods, so instead of requiring everyone to write a wrapper class, lets just set it. The reason we removed most of the TCCL setting code from Geronimo was because it was a major performance impact. I just think we went a little to far. The life cycle methods are rarely called and don't happen in code paths where performance is critical. I think we should change the GBeanInstance code to set the TCCL around doStart and doStop. -- 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: TCCL in doStart
Done. Let me know if you have any problems. -dain On Oct 30, 2005, at 6:17 AM, Davanum Srinivas wrote: +1 from me to clean up the rest. thanks, dims On 10/29/05, Dain Sundstrom [EMAIL PROTECTED] wrote: On Oct 29, 2005, at 11:57 AM, David Jencks wrote: On Oct 29, 2005, at 11:51 AM, Dain Sundstrom wrote: Setting the TCCL around lifecycle methods is one of the changes I made in XBean. It turns out that there is a lot of code out there that assumes the TCCL is properly set, so instead of requiring everyone to write a wrapper class, I just set it. The reason we removed most of the TCCL setting code from Geronimo was because it was a major performance impact. I just think we went a little to far :) The life cycle methods are rarely called and don't happen in code paths where performance is critical. I think we should change the GBeanInstance code to set the TCCL around doStart and doStop. What do you think? Fine with me. Do you agree that setting the TCCL while deserializing attribute values is unnecessary? I think the ObjectInputStreamEx handles all of our cases with an explicit class loader, but we may want to leave the code there in case a readObject or readReplace implementation tries to get the TCCL. So I think it is unnecessary, but I see no harm is just leaving that one there. -dain -- Davanum Srinivas : http://wso2.com/blogs/
Re: Wiki reorganization proposal
On Nov 1, 2005, at 8:27 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Sisson wrote: My main concern with the use of the Wiki for documentation is that the Wiki content isn't versioned to match Geronimo releases. [snip] An alternative is to develop the main documentation under svn control (the Derby project does this), but that would mean updates would have to be submitted as patches. Derby's doco can be easily generated as a PDF with bookmarks etc, which is great for offline or printing. Perhaps some mix would be good, such as a weekly checkin to svn of any changes to the wiki. Of course, then there's the issue of format compatibility. Do the wikis in use provide for XML exports? If so, a little glue should be able to automatically manage the conversion and checkin. The major problems I see with that is that the who-changed-what accountability is lost (unless a change to the wiki can be included in the export as an XML entity that can be used to identify the changer in svn), and that changes made between checkpoints don't get recorded. I've cranked my brain on this one for awhile as OpenEJB now uses confluence for documentation rather than generating html from xml stored in cvs as we did before. XML importing and exporting is possible in confluence, as well as html and pdf exports (no import for those, though). As a couple releases ago, they also have the ability to have listeners or something that you can set up to be executed when pages are changed, added, removed, etc. So, the most aggressive approach I can think of is that we could setup a listener that exports the entire page and checks it into svn. Some less aggressive version of that is possible too. As far as versioning, the best i can think of would be to have a Confluence Space per svn branch. So a GERONIMO-X space for each release branch under geronimo/branches/. Using Tomcat as an example as we don't have branches yet, that'd be something like TOMCAT-4, TOMCAT-50 and TOMCAT-55. You could even start a new space by exporting from the previous major version's space, creating a new space, then importing to the new space. If you export aggressively, you can start a new Space from what's in svn. Anyway, I haven't solved the problem completely but thats a high level dump of what's in my brain in regards to import/export, source control, and versioning. -David
Re: Common Visual Design for Geronimo's User Interfaces
On Nov 2, 2005, at 11:48 AM, Bruce Snyder wrote: On 11/2/05, Jeff Genender [EMAIL PROTECTED] wrote: Why yes it is! Thanks for pointing it out...I haven't been as attentive as I should be...I just found out I am a dad-to-be for a third time ;-) So my head has been slightly elsewhere :) I BIG congrats to Jeff and his wife! Today is their 10th wedding anniversary and she gave him the gift of a third child on the way. Wh!!! I'm sure he had something to do with it ;) Congradulations, Jeff y felicitaciones a tu esposa !!! You know David is an awfully popular name these days (ahem). -David
Re: Old tags in Geornimo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan D. Cabrera wrote: This is a good point. What if we moved the tag to a directory called archived? [Yes, I saw this in the original (*an* original?) proposal. :-)] I feel that keeping the mnemonic is the first importance -- but followed closely by keeping it findable. Most (if not all) of the Apache SVN trees follow the TTB pattern, and it's recommended in the SVN docco, so if someone has any expectations of the layout that's what they'll be. Unless they browse down from the top of the tree, or see a link in a file/document somewhere, they're not going to find /archived/tags/M3. I'm still +1 for keeping the tags in place, and +0 on renaming them to address the 'is this supported' issue. MHO. - -- #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 Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ2kleZrNPMCpn3XdAQIMnwP/Vx49YHDFLq7nWqoeYz07LX0ulU6LBy/C ISWCzY1OSnwCMMsKnpmrvSuJ4DeSDol4bZZxD8kSfnyYYlmty0Z7ZN6khfUChzxs ZgZljZ6AXZSvRvGJVHUMoWCPeIip+cxIoep6guRMBf7qxHmmEs4RtQr5GGiKD9KA MJWKrmxc1yI= =7WM7 -END PGP SIGNATURE-
[consolidation] next steps?
Everyone seems very positive about consolidating the community. How should we proceed? I was thinking that it would be nice to send an invitation to the projects to join the Geronimo community as a subproject. The invitation letter would simply state our interest in having the project join Geronimo and if they accept, to prepare a proposal for the incubator. When the proposals are ready, we would vote to accept the project and forward it to incubator. The projects mentioned in the Consolidating the community thread and the email addresses for their dev lists. ActiveCluster - [EMAIL PROTECTED] ActiveIO - [EMAIL PROTECTED] ActiveMQ - [EMAIL PROTECTED] ActivetSpaces - [EMAIL PROTECTED] OpenEJB - dev@openejb.org ServiceMix - dev@servicemix.codehaus.org TranQL - [EMAIL PROTECTED] WADI - [EMAIL PROTECTED] XBean - [EMAIL PROTECTED] -dain
[jira] Reopened: (GERONIMO-1123) generate geronimo-service.xml files from marked dependencies in project.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1123?page=all ] David Jencks reopened GERONIMO-1123: The way the new plugin is called in the previous fix introduces a circular dependency. generate geronimo-service.xml files from marked dependencies in project.xml --- Key: GERONIMO-1123 URL: http://issues.apache.org/jira/browse/GERONIMO-1123 Project: Geronimo Type: Improvement Components: buildsystem Versions: 1.0 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0 Write a maven plugin to generate the geronimo-service.xml dependency lists from marked dependencies in project.xml. I'm going to use properties geronimo.dependencytrue/geronimo.dependency /properties unless someone has a better idea. -- 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: [consolidation] next steps?
+1 Dain, thanks for helping this along. This is a good forward step. Dain Sundstrom wrote: Everyone seems very positive about consolidating the community. How should we proceed? I was thinking that it would be nice to send an invitation to the projects to join the Geronimo community as a subproject. The invitation letter would simply state our interest in having the project join Geronimo and if they accept, to prepare a proposal for the incubator. When the proposals are ready, we would vote to accept the project and forward it to incubator. The projects mentioned in the Consolidating the community thread and the email addresses for their dev lists. ActiveCluster - [EMAIL PROTECTED] ActiveIO - [EMAIL PROTECTED] ActiveMQ - [EMAIL PROTECTED] ActivetSpaces - [EMAIL PROTECTED] OpenEJB - dev@openejb.org ServiceMix - dev@servicemix.codehaus.org TranQL - [EMAIL PROTECTED] WADI - [EMAIL PROTECTED] XBean - [EMAIL PROTECTED] -dain
Re: [consolidation] next steps?
On 11/2/05, Dain Sundstrom [EMAIL PROTECTED] wrote: Everyone seems very positive about consolidating the community. How should we proceed? I was thinking that it would be nice to send an invitation to the projects to join the Geronimo community as a subproject. The invitation letter would simply state our interest in having the project join Geronimo and if they accept, to prepare a proposal for the incubator. When the proposals are ready, we would vote to accept the project and forward it to incubator. The projects mentioned in the Consolidating the community thread and the email addresses for their dev lists. ActiveCluster - [EMAIL PROTECTED] ActiveIO - [EMAIL PROTECTED] ActiveMQ - [EMAIL PROTECTED] ActivetSpaces - [EMAIL PROTECTED] OpenEJB - dev@openejb.org ServiceMix - dev@servicemix.codehaus.org TranQL - [EMAIL PROTECTED] WADI - [EMAIL PROTECTED] XBean - [EMAIL PROTECTED] What about MX4J? Have we spoken with Simone at all about this? Since Geronimo is a TLP, it can sponsor each of the projects. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: [consolidation] next steps?
Dain Sundstrom wrote: Everyone seems very positive about consolidating the community. How should we proceed? I was thinking that it would be nice to send an invitation to the projects to join the Geronimo community as a subproject. The invitation letter would simply state our interest in having the project join Geronimo and if they accept, to prepare a proposal for the incubator. When the proposals are ready, we would vote to accept the project and forward it to incubator. The projects mentioned in the Consolidating the community thread and the email addresses for their dev lists. ActiveCluster - [EMAIL PROTECTED] ActiveIO - [EMAIL PROTECTED] ActiveMQ - [EMAIL PROTECTED] ActivetSpaces - [EMAIL PROTECTED] OpenEJB - dev@openejb.org ServiceMix - dev@servicemix.codehaus.org TranQL - [EMAIL PROTECTED] WADI - [EMAIL PROTECTED] XBean - [EMAIL PROTECTED] -dain Dain, This is great. +1 for the effort. I'd recommend bouncing this off the ASF board just in case there are issues we're overlooking (I don't see any). The ASF doesn't generally solicit projects but I can't imagine anyone having a problem with this proposal. Bill
Re: [consolidation] next steps?
Nice...looks like a great plan. Dain Sundstrom wrote: Everyone seems very positive about consolidating the community. How should we proceed? I was thinking that it would be nice to send an invitation to the projects to join the Geronimo community as a subproject. The invitation letter would simply state our interest in having the project join Geronimo and if they accept, to prepare a proposal for the incubator. When the proposals are ready, we would vote to accept the project and forward it to incubator. The projects mentioned in the Consolidating the community thread and the email addresses for their dev lists. ActiveCluster - [EMAIL PROTECTED] ActiveIO - [EMAIL PROTECTED] ActiveMQ - [EMAIL PROTECTED] ActivetSpaces - [EMAIL PROTECTED] OpenEJB - dev@openejb.org ServiceMix - dev@servicemix.codehaus.org TranQL - [EMAIL PROTECTED] WADI - [EMAIL PROTECTED] XBean - [EMAIL PROTECTED] -dain
Re: [consolidation] next steps?
On Nov 2, 2005, at 1:38 PM, Dain Sundstrom wrote: Everyone seems very positive about consolidating the community. How should we proceed? I was thinking that it would be nice to send an invitation to the projects to join the Geronimo community as a subproject. The invitation letter would simply state our interest in having the project join Geronimo and if they accept, to prepare a proposal for the incubator. When the proposals are ready, we would vote to accept the project and forward it to incubator. The projects mentioned in the Consolidating the community thread and the email addresses for their dev lists. ActiveCluster - [EMAIL PROTECTED] ActiveIO - [EMAIL PROTECTED] ActiveMQ - [EMAIL PROTECTED] ActivetSpaces - [EMAIL PROTECTED] OpenEJB - dev@openejb.org ServiceMix - dev@servicemix.codehaus.org TranQL - [EMAIL PROTECTED] WADI - [EMAIL PROTECTED] XBean - [EMAIL PROTECTED] I think it would be a really nice gesture to send an invite to Jetty even if they are unlikely to move. I think it's really great to let them know the doors are always open. -David
Re: Common Visual Design for Geronimo's User Interfaces
I think the images look awesome as well! I was just around with integrating them into the tools to see what it looks like. Here's some screenshots. http://people.apache.org/~sppatel/screen1.jpeg http://people.apache.org/~sppatel/screen2.jpeg http://people.apache.org/~sppatel/screen3.jpeg David Blevins wrote: This is fantastic! And of much superior quality than Matt's Grey to Great comment ;) Excellent work! I'd like to throw a penny in to the new website wishing-well as well. This is so cool. -David On Nov 2, 2005, at 5:08 AM, Matt Hogstrom wrote: Absolutely stunning. Glenn, you've outdone yourself. Is it possible to get a patch for this and integrate so we can get some functional feedback as well. I think the entire Geronimo team owes you a debt of gratitude for heling to get us out of the Grey console into the Great! console :) - Matt Joe Bohn wrote: When I first saw these I was surprised at what a dramatic difference this is over what we sent to Epiq. As I've already told the Epiq team great work!! I also agree that we should spread the style to as many G user interfaces as possible. It would be great if we could come up with some simple format that everything supports - such as all having the banner at the top and perhaps even some shaded primary tasks area on the left. The tasks could be navigation choices for the web console, commands for the debug console, primary links for the web page, etc... If we could share the exact image across the build that would really help when making changes. Joe David Klavon wrote: Now that there is an official logo image for Geronimo, we thought that it would be useful to extend the color scheme, font style, icon use, etc. across the various user interfaces in the project, and create a common 'visual appearance' for the Geronimo project for v1.0. The Epiq Team, the recent winners of the logo contest, have drafted some ideas of what an integrated suite would look like to get the discussion going in the community. While there are many details to be worked out on each of the respective interfaces, we would like to get the community feedback on the general approach and style. If found favorable, we could begin to create the icon libraries and other style sheets for implementation. http://www.epiqtech.com/corp/products/technology/opensource/ServerConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/ServerConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/GeronimoWelcomeScreen.htm http://www.epiqtech.com/corp/products/technology/opensource/DebugConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/DebugConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/DaytraderLogo.htm I think the Epiq Team has really showcased their award winning skills in giving Geronimo a professional look and integrated-suite feel that would add great value to the v1.0 delivery. Let us know what everyone thinks... Dave -- Sachin
Re: Common Visual Design for Geronimo's User Interfaces
Very cool :D -dain On Nov 2, 2005, at 4:30 PM, Sachin Patel wrote: I think the images look awesome as well! I was just around with integrating them into the tools to see what it looks like. Here's some screenshots. http://people.apache.org/~sppatel/screen1.jpeg http://people.apache.org/~sppatel/screen2.jpeg http://people.apache.org/~sppatel/screen3.jpeg David Blevins wrote: This is fantastic! And of much superior quality than Matt's Grey to Great comment ;) Excellent work! I'd like to throw a penny in to the new website wishing-well as well. This is so cool. -David On Nov 2, 2005, at 5:08 AM, Matt Hogstrom wrote: Absolutely stunning. Glenn, you've outdone yourself. Is it possible to get a patch for this and integrate so we can get some functional feedback as well. I think the entire Geronimo team owes you a debt of gratitude for heling to get us out of the Grey console into the Great! console :) - Matt Joe Bohn wrote: When I first saw these I was surprised at what a dramatic difference this is over what we sent to Epiq. As I've already told the Epiq team great work!! I also agree that we should spread the style to as many G user interfaces as possible. It would be great if we could come up with some simple format that everything supports - such as all having the banner at the top and perhaps even some shaded primary tasks area on the left. The tasks could be navigation choices for the web console, commands for the debug console, primary links for the web page, etc... If we could share the exact image across the build that would really help when making changes. Joe David Klavon wrote: Now that there is an official logo image for Geronimo, we thought that it would be useful to extend the color scheme, font style, icon use, etc. across the various user interfaces in the project, and create a common 'visual appearance' for the Geronimo project for v1.0. The Epiq Team, the recent winners of the logo contest, have drafted some ideas of what an integrated suite would look like to get the discussion going in the community. While there are many details to be worked out on each of the respective interfaces, we would like to get the community feedback on the general approach and style. If found favorable, we could begin to create the icon libraries and other style sheets for implementation. http://www.epiqtech.com/corp/products/technology/opensource/ ServerConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/ ServerConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/ GeronimoWelcomeScreen.htm http://www.epiqtech.com/corp/products/technology/opensource/ DebugConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/ DebugConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/ DaytraderLogo.htm I think the Epiq Team has really showcased their award winning skills in giving Geronimo a professional look and integrated- suite feel that would add great value to the v1.0 delivery. Let us know what everyone thinks... Dave -- Sachin
Re: Common Visual Design for Geronimo's User Interfaces
Sachin, Great job Sachin Patel wrote: I think the images look awesome as well! I was just around with integrating them into the tools to see what it looks like. Here's some screenshots. http://people.apache.org/~sppatel/screen1.jpeg http://people.apache.org/~sppatel/screen2.jpeg http://people.apache.org/~sppatel/screen3.jpeg David Blevins wrote: This is fantastic! And of much superior quality than Matt's Grey to Great comment ;) Excellent work! I'd like to throw a penny in to the new website wishing-well as well. This is so cool. -David On Nov 2, 2005, at 5:08 AM, Matt Hogstrom wrote: Absolutely stunning. Glenn, you've outdone yourself. Is it possible to get a patch for this and integrate so we can get some functional feedback as well. I think the entire Geronimo team owes you a debt of gratitude for heling to get us out of the Grey console into the Great! console :) - Matt Joe Bohn wrote: When I first saw these I was surprised at what a dramatic difference this is over what we sent to Epiq. As I've already told the Epiq team great work!! I also agree that we should spread the style to as many G user interfaces as possible. It would be great if we could come up with some simple format that everything supports - such as all having the banner at the top and perhaps even some shaded primary tasks area on the left. The tasks could be navigation choices for the web console, commands for the debug console, primary links for the web page, etc... If we could share the exact image across the build that would really help when making changes. Joe David Klavon wrote: Now that there is an official logo image for Geronimo, we thought that it would be useful to extend the color scheme, font style, icon use, etc. across the various user interfaces in the project, and create a common 'visual appearance' for the Geronimo project for v1.0. The Epiq Team, the recent winners of the logo contest, have drafted some ideas of what an integrated suite would look like to get the discussion going in the community. While there are many details to be worked out on each of the respective interfaces, we would like to get the community feedback on the general approach and style. If found favorable, we could begin to create the icon libraries and other style sheets for implementation. http://www.epiqtech.com/corp/products/technology/opensource/ServerConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/ServerConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/GeronimoWelcomeScreen.htm http://www.epiqtech.com/corp/products/technology/opensource/DebugConsoleMain.htm http://www.epiqtech.com/corp/products/technology/opensource/DebugConsoleLogon.htm http://www.epiqtech.com/corp/products/technology/opensource/DaytraderLogo.htm I think the Epiq Team has really showcased their award winning skills in giving Geronimo a professional look and integrated-suite feel that would add great value to the v1.0 delivery. Let us know what everyone thinks... Dave
Re: Giving back: gbuild.org
On Oct 26, 2005, at 2:20 AM, Lyndon Samson wrote: Just a thought, RSS is a little friendlier than emails for reporting! I created a jira item for this neat idea in the continuum jira: http://jira.codehaus.org/browse/CONTINUUM-418 Feel free to updated it with a better description or even roll up your sleeves and dig in :) -David
Build Geronimo fail. Mainly error as follow. Thanks.
build:start:
default:java:prepare-filesystem:
[mkdir] Created dir:
D:\Tools\OpenSource\geronimo\modules\jetty\target\classes
java:compile: [depend] Deleted 0 out of
date files in 0 seconds [echo] Compiling to
D:\Tools\OpenSource\geronimo\modules\jetty/target/classes
[javac] Compiling 33 source files to
D:\Tools\OpenSource\geronimo\modules\jetty\target\classesD:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:3:
package javax.management.j2ee.statistics does not existimport
javax.management.j2ee.statistics.RangeStatistic;
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:4:
package javax.management.j2ee.statistics does not existimport
javax.management.j2ee.statistics.TimeStatistic;
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:5:
package javax.management.j2ee.statistics does not existimport
javax.management.j2ee.statistics.CountStatistic;
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:18:
cannot access javax.management.j2ee.statistics.Statsfile
javax\management\j2ee\statistics\Stats.class not foundpublic class
JettyWebContainerStatsImpl extends StatsImpl implements WebContainerStats
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:51:
cannot resolve symbolsymbol : class RangeStatisticlocation: class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public RangeStatistic getOpenConnectionCount()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:55:
cannot resolve symbolsymbol : class RangeStatisticlocation: class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public RangeStatistic getConnectionRequestCount()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:59:
cannot resolve symbolsymbol : class TimeStatisticlocation: class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public TimeStatistic getConnectionDuration()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:63:
cannot resolve symbolsymbol : class CountStatisticlocation: class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public CountStatistic getTotalErrorCount()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:67:
cannot resolve symbolsymbol : class CountStatisticlocation: class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public CountStatistic getTotalRequestCount()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:71:
cannot resolve symbolsymbol : class RangeStatisticlocation: class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public RangeStatistic getActiveRequestCount()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:75:
cannot resolve symbolsymbol : class TimeStatisticlocation: class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public TimeStatistic getRequestDuration()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:43:
cannot resolve symbolsymbol : method addStat
(java.lang.String,org.apache.geronimo.management.stats.RangeStatisticImpl)location:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
addStat("OpenConnectionCount",
openConnectionCount);
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:44:
cannot resolve symbolsymbol : method addStat
(java.lang.String,org.apache.geronimo.management.stats.RangeStatisticImpl)location:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
addStat("ConnectionRequestCount",
connectionRequestCount);
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:45:
cannot resolve symbolsymbol : method addStat
(java.lang.String,org.apache.geronimo.management.stats.TimeStatisticImpl)location:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
addStat("ConnectionDuration",
connectionDuration);
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:46:
cannot resolve symbolsymbol : method addStat
(java.lang.String,org.apache.geronimo.management.stats.CountStatisticImpl)location:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
addStat("TotalErrorCount",
totalErrorCount);
Re: Build Geronimo fail. Mainly error as follow. Thanks.
remove JettyWebContainerStatsImpl.java then can build the
projects.
- Original Message -
From:
jiadong.he
To: dev@geronimo.apache.org
Sent: Wednesday, November 02, 2005 9:03
PM
Subject: Build Geronimo fail. Mainly error as
follow. Thanks.
build:start:
default:java:prepare-filesystem:
[mkdir] Created dir:
D:\Tools\OpenSource\geronimo\modules\jetty\target\classes
java:compile: [depend] Deleted 0 out
of date files in 0 seconds [echo] Compiling to
D:\Tools\OpenSource\geronimo\modules\jetty/target/classes
[javac] Compiling 33 source files to
D:\Tools\OpenSource\geronimo\modules\jetty\target\classesD:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:3:
package javax.management.j2ee.statistics does not existimport
javax.management.j2ee.statistics.RangeStatistic;
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:4:
package javax.management.j2ee.statistics does not existimport
javax.management.j2ee.statistics.TimeStatistic;
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:5:
package javax.management.j2ee.statistics does not existimport
javax.management.j2ee.statistics.CountStatistic;
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:18:
cannot access javax.management.j2ee.statistics.Statsfile
javax\management\j2ee\statistics\Stats.class not foundpublic class
JettyWebContainerStatsImpl extends StatsImpl implements WebContainerStats
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:51:
cannot resolve symbolsymbol : class RangeStatisticlocation:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public RangeStatistic getOpenConnectionCount()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:55:
cannot resolve symbolsymbol : class RangeStatisticlocation:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public RangeStatistic getConnectionRequestCount()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:59:
cannot resolve symbolsymbol : class TimeStatisticlocation: class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public TimeStatistic getConnectionDuration()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:63:
cannot resolve symbolsymbol : class CountStatisticlocation:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public CountStatistic getTotalErrorCount()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:67:
cannot resolve symbolsymbol : class CountStatisticlocation:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public CountStatistic getTotalRequestCount()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:71:
cannot resolve symbolsymbol : class RangeStatisticlocation:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public RangeStatistic getActiveRequestCount()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:75:
cannot resolve symbolsymbol : class TimeStatisticlocation: class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
public TimeStatistic getRequestDuration()
{
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:43:
cannot resolve symbolsymbol : method addStat
(java.lang.String,org.apache.geronimo.management.stats.RangeStatisticImpl)location:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
addStat("OpenConnectionCount",
openConnectionCount);
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:44:
cannot resolve symbolsymbol : method addStat
(java.lang.String,org.apache.geronimo.management.stats.RangeStatisticImpl)location:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
addStat("ConnectionRequestCount",
connectionRequestCount);
^D:\Tools\OpenSource\geronimo\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebContainerStatsImpl.java:45:
cannot resolve symbolsymbol : method addStat
(java.lang.String,org.apache.geronimo.management.stats.TimeStatisticImpl)location:
class
org.apache.geronimo.jetty.JettyWebContainerStatsImpl
addStat("ConnectionDuration",
