Re: Geronimo Community
David Jencks wrote: in my understanding of "the apache way", one of the important principles is that all decisions happen on the mailing list. To me, for Geronimo, that means that if you are working on a feature more complex than a simple bug fix, you describe it in general terms in an email to the dev list or in a jira entry. While I try to follow this I know I often fail and would appreciate reminders when I do. Well, a soft commit-then-review also works, especially when people are really good at what they are doing. (like you are) I think that most of the time, there's no issue, and assuming good faith all around, when there is an issue, it's gets resolved easily. After all, that's why we have version control. I think of it as optimistic locking of sorts. I think the only risk is the time of the volunteer - if you are going to invest a lot of time into something, you might want to make sure that everyone will like it if you care about the time investment. When I don't see this happening, for Geronimo code or for code in projects that are supposed to be on the way into incubation as Geronimo sub projects, I get worried and wonder how long the project will survive. Comments? :x geir thanks david jencks
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
Jason Dillon wrote: I think that a documentation system should be a combination of - reasonably easy to use - versionable - able to be used offline - extractable into an open and transformable format for reuse Wikis that I've used fail on #2, #3 and #4. Confluence (as well as other mature wikis) provide #2, and #4 isn't that really to achieve. Most wikis provide some way to version content. I mean across pages - like how we do tags and branches, so a doco set can be associated with a version of G. It happens that Confluence uses Hibernate and versioned entities for this not a SCM like SVN or Perforce. Confluence wiki-markup could itself be considered that open and transformable format. So could anything, I suppose :) I was thinking more along the lines of some XML dialect like DocBook - even if it could export, that would be cool. I was thinking about docs the other day - OpenOffice can output DocBook (which I'm sure everyone on the planet knew except me...), so there now is an offline, WYSIWYG editor that produces a standard format that allows transform for various presentation formats. If you don't like that, then you could always write a transformer into that language which you do like. The question that leaps to mind is what keeps me assured that the confluence wiki format is stable and not changing? #3 is the only one that isn't so easy to resolve out of the box. It is possible however, but is lacking in many ways. For example, you could setup a Confluence standalone on whatever your mobile workstation was, then import/export spaces. Its definitely not ideal, but it is possible. Perhaps someone will write a bidirectional SVN sync, so that you could update Confluence wiki-markup in SVN, which would then get picked up in Confluence. While this could be done, there are some issues with potential merging conflicts, as the definitive copy of the data is in Confluence (from Confluence's perspective), so if a user offline make several changes, in addition to online users, there would potentially be a window of error. I keep hoping I have some free time to take this on. This is the canonical detached dataset problem, isn't it? It seems that marging isn't so hard because it is human-readable textual content, so a merge process is pretty straightforward in case of collision. I realize the clear majority is for Confluence, but these factors should be considered. There are several... or many (not sure) of us who are aware of these issues. I've been actively looking at resolving some of them and/or finding alternatives which will appease most of the interested parties. For example, I've got a crude Confluence listener which will persist wiki-markup (w/editor id and comments) to SVN. That gets us closer to a #2 that more people can agree on. Atlassian are cool/reasonable peeps so it might be possible to expose the basic versioning/content mechanism as a plugin to allow us to completly replace that with a SVN impl... but don't hold your breath. Using SVN as a backing store would go part of the way, as I can then setup the Free Local JIRA that those cool peeps at Atlassian would give away for single-machine personal use, aim it at my data tree, and let me edit away (or a real local WYSIWYG editor...). Then I can just svn co and deal the any merge issues... geir --jason
JMS Portlet Testing needed on HEAD and 1.0 Branch
All, I just put in the start of the revised JMS portlet. Currently it lets you deploy a new JMS resource (or just show the plan) with connection factories and/or destinations. It does not yet let you view or edit existing resources. Anyway, please take it for a spin and let me know what you think. It's the top portlet in the "JMS Resources" entry in the console (not "JMS Server", and not the lower 2 portlets which are still the old ones). Note that you'll need a fresh SVN build as of just now. Thanks, Aaron
Re: gbuild: need up with eclipse tools setup?
- sachin On Jan 23, 2006, at 9:55 PM, David Blevins wrote: Great. You might want to check out the xmlbeans generation code. There might be something in there for you. The mixed generated and not generate on a per method level aspect of this certainly presents an interesting spin on the problem. Well XML is generating just binaries directly into target since the move to XMLBeans2 right, not any source? Yes, the method level aspect makes it trickier. Any generated code I want to modify and source ctrl, needs to be at a different location, but at the same time during the build, the generator still needs to run on the modfied-gen'd code in case their is any updates to other methods. What tool is generating this code? EMF (Eclipse Modeling Framework) http://www.eclipse.org/emf/ -David On Jan 23, 2006, at 5:36 PM, Sachin Patel wrote: Thanks David, you're exactly right. This would hit other developers as well. I think I should be able to separate things out. - sachin On Jan 23, 2006, at 7:58 PM, David Blevins wrote: On Jan 17, 2006, at 5:52 AM, Sachin Patel wrote: I was tired of seeing all the BUILD FAILED errors so I disabled it temorarily due to the one svn issue that keeps on appearing stating a resource already exists when it updates. I know what exactly scenario triggers the error, and I'll probably need your help debugging it. The problem is the following, perhaps you can make some sense out of it... I have a project that consists of autogenerated EMF code. Most of the generated code is not source controled and is created only during the build. In EMF, any generated class can be modified by the developer to contain custom implementations of a method. A methods custom implementation can be preserved by adding a @generated NOT comment on that method. The next time the generator is run, that method implementation is not overridden. So for all the classes where I do have custom implementations I check only those into source control. Anytime these source files are committed, GBuild fails during the update stating the given class already exists. So what happens on the gbuild end is the following... (1) An initial fresh checkout of the code (2) The plugin builds successfully, so there exist in the work directory a file "N" that was generated during the build. (3) Now I end up making a custom changes to "N" locally and commit. (4) GBuild does an update, but since the generated code never was removed, "N" exists but the delta from the commit is "N" as well so it complains that "N" is already there. Only if the existing generated "N" from the previous build was removed, would the update for the committed "N" work. Does that make sense? I follow, though I'm not sure why you'd set it up that way. Anyone who attempts to work with you on the eclipse tooling will run into the same issue when they checkout. Why don't you separate the generated source from the once- generated source? In the main geronimo build we code generate tons and tons of xmlbeans classes and whatnot right into the target/ directory so they are never generated on top of anything that is scm controlled. Mixing build-time generated code in with your regular source doesn't seem like the best approach. Not sure what kind of constraints you are working with but at the very least you can keep them separate and do some footwork to compile the class files into the same dir. -David
Re: gbuild: need up with eclipse tools setup?
Great. You might want to check out the xmlbeans generation code. There might be something in there for you. The mixed generated and not generate on a per method level aspect of this certainly presents an interesting spin on the problem. What tool is generating this code? -David On Jan 23, 2006, at 5:36 PM, Sachin Patel wrote: Thanks David, you're exactly right. This would hit other developers as well. I think I should be able to separate things out. - sachin On Jan 23, 2006, at 7:58 PM, David Blevins wrote: On Jan 17, 2006, at 5:52 AM, Sachin Patel wrote: I was tired of seeing all the BUILD FAILED errors so I disabled it temorarily due to the one svn issue that keeps on appearing stating a resource already exists when it updates. I know what exactly scenario triggers the error, and I'll probably need your help debugging it. The problem is the following, perhaps you can make some sense out of it... I have a project that consists of autogenerated EMF code. Most of the generated code is not source controled and is created only during the build. In EMF, any generated class can be modified by the developer to contain custom implementations of a method. A methods custom implementation can be preserved by adding a @generated NOT comment on that method. The next time the generator is run, that method implementation is not overridden. So for all the classes where I do have custom implementations I check only those into source control. Anytime these source files are committed, GBuild fails during the update stating the given class already exists. So what happens on the gbuild end is the following... (1) An initial fresh checkout of the code (2) The plugin builds successfully, so there exist in the work directory a file "N" that was generated during the build. (3) Now I end up making a custom changes to "N" locally and commit. (4) GBuild does an update, but since the generated code never was removed, "N" exists but the delta from the commit is "N" as well so it complains that "N" is already there. Only if the existing generated "N" from the previous build was removed, would the update for the committed "N" work. Does that make sense? I follow, though I'm not sure why you'd set it up that way. Anyone who attempts to work with you on the eclipse tooling will run into the same issue when they checkout. Why don't you separate the generated source from the once- generated source? In the main geronimo build we code generate tons and tons of xmlbeans classes and whatnot right into the target/ directory so they are never generated on top of anything that is scm controlled. Mixing build-time generated code in with your regular source doesn't seem like the best approach. Not sure what kind of constraints you are working with but at the very least you can keep them separate and do some footwork to compile the class files into the same dir. -David
[jira] Commented: (GERONIMO-1427) Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction
[ http://issues.apache.org/jira/browse/GERONIMO-1427?page=comments#action_12363773 ] David Jencks commented on GERONIMO-1427: I made an even smaller server Adding minimal-tomcat-server Sendingminimal-tomcat-server/project.xml Sendingminimal-tomcat-server/src/var/config/config.xml Transmitting file data .. Committed revision 371771. We have serious dependency problems as illustrated by this trace of stuff getting pulled in much of which we do not need: Copying geronimo/geronimo-activation/1.1-SNAPSHOT/jar Copying org.apache.geronimo.specs/geronimo-j2ee_1.4_spec/1.0/jar Copying geronimo/geronimo-management/1.1-SNAPSHOT/jar Copying geronimo/geronimo-j2ee/1.1-SNAPSHOT/jar Copying geronimo/geronimo-core/1.1-SNAPSHOT/jar Copying geronimo/geronimo-naming/1.1-SNAPSHOT/jar Copying geronimo/geronimo-transaction/1.1-SNAPSHOT/jar Copying geronimo/geronimo-security/1.1-SNAPSHOT/jar Copying geronimo/geronimo-webservices/1.1-SNAPSHOT/jar Copying concurrent/concurrent/1.3.4/jar Copying tranql/tranql/1.2.1/jar Copying howl/howl-logger/0.1.11/jar Copying antlr/antlr/2.7.2/jar Copying activeio/activeio/2.0-r118/jar Configuration geronimo/j2ee-system/1.1-SNAPSHOT/car already present in configuration store Installed configuration geronimo/j2ee-server/1.1-SNAPSHOT/car Copying geronimo/geronimo-connector/1.1-SNAPSHOT/jar Copying geronimo/geronimo-timer/1.1-SNAPSHOT/jar Copying geronimo/geronimo-client/1.1-SNAPSHOT/jar Copying xstream/xstream/1.0.2/jar Copying xpp3/xpp3/1.1.3.3/jar Copying asm/asm/1.4.3/jar Copying activemq/activemq-gbean-management/3.2.1/jar Copying scout/jaxr-api/0.5/jar Copying scout/scout/0.5/jar Copying juddi/juddi/0.9rc4/jar Copying jdom/jdom/1.0/jar Copying geronimo/geronimo-derby/1.1-SNAPSHOT/jar Copying org.apache.derby/derby/10.1.1.0/jar Copying org.apache.derby/derbynet/10.1.1.0/jar Configuration geronimo/rmi-naming/1.1-SNAPSHOT/car already present in configuration store Installed configuration geronimo/j2ee-security/1.1-SNAPSHOT/car Copying geronimo/geronimo-jmxremoting/1.1-SNAPSHOT/jar Configuration geronimo/rmi-naming/1.1-SNAPSHOT/car already present in configuration store Installed configuration geronimo/tomcat/1.1-SNAPSHOT/car Copying geronimo/geronimo-tomcat/1.1-SNAPSHOT/jar Copying activecluster/activecluster/1.2-20051115174934/jar Copying springframework/spring/1.2.5/jar Copying tomcat/catalina/5.5.12/jar Copying tomcat/tomcat-ajp/5.5.12/jar Copying tomcat/catalina-cluster/5.5.12/jar Copying tomcat/catalina-optional/5.5.12/jar Copying tomcat/tomcat-coyote/5.5.12/jar Copying tomcat/tomcat-http/5.5.12/jar Copying tomcat/jasper-compiler/5.5.12/jar Copying tomcat/jasper-compiler-jdt/5.5.12/jar Copying tomcat/jasper-runtime/5.5.12/jar Copying tomcat/tomcat-util/5.5.12/jar Copying tomcat/naming-resources/5.5.12/jar Copying tomcat/servlets-default/5.5.12/jar Copying tomcat/servlets-invoker/5.5.12/jar Copying commons-beanutils/commons-beanutils/1.6.1/jar Copying commons-collections/commons-collections/3.1/jar Copying commons-digester/commons-digester/1.6/jar Copying commons-el/commons-el/1.0/jar Copying commons-modeler/commons-modeler/1.1/jar Copying regexp/regexp/1.3/jar Copying wadi/wadi-core/2.0M1/jar Copying wadi/wadi-tomcat55/2.0M1/jar Configuration geronimo/rmi-naming/1.1-SNAPSHOT/car already present in configuration store Installed configuration geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car Copying geronimo/geronimo-service-builder/1.1-SNAPSHOT/jar Copying xmlbeans/xbean/2.0.0/jar Copying stax/stax-api/1.0/jar Installed configuration geronimo/j2ee-deployer/1.1-SNAPSHOT/car Copying geronimo/geronimo-j2ee-schema/1.1-SNAPSHOT/jar Copying geronimo/geronimo-j2ee-builder/1.1-SNAPSHOT/jar Copying geronimo/geronimo-client-builder/1.1-SNAPSHOT/jar Copying geronimo/geronimo-naming-builder/1.1-SNAPSHOT/jar Copying geronimo/geronimo-security-builder/1.1-SNAPSHOT/jar Copying geronimo/geronimo-web-builder/1.1-SNAPSHOT/jar Copying geronimo/geronimo-connector-builder/1.1-SNAPSHOT/jar Configuration geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car already present in configuration store Configuration geronimo/j2ee-server/1.1-SNAPSHOT/car already present in configuration store Installed configuration geronimo/unavailable-ejb-deployer/1.1-SNAPSHOT/car Configuration geronimo/j2ee-deployer/1.1-SNAPSHOT/car already present in configuration store Installed configuration geronimo/unavailable-webservices-deployer/1.1-SNAPSHOT/car Configuration geronimo/j2ee-deployer/1.1-SNAPSHOT/car already present in configuration store Installed configuration geronimo/unavailable-client-deployer/1.1-SNAPSHOT/car Configuration geronimo/j2ee-deployer/1.1-SNAPSHOT/car already present in configuration store Installed configuration geronimo/tomcat-deployer/1.1-SNAPSHOT/car Copying geronimo/geronimo-tomcat-builder/1.1-SNAPSHOT/jar Configuration geronimo/j2ee-deployer/1.1-SNAPSHOT/car already present in configuration store Configuration geronimo/tom
Re: gbuild: need up with eclipse tools setup?
Thanks David, you're exactly right. This would hit other developers as well. I think I should be able to separate things out. - sachin On Jan 23, 2006, at 7:58 PM, David Blevins wrote: On Jan 17, 2006, at 5:52 AM, Sachin Patel wrote: I was tired of seeing all the BUILD FAILED errors so I disabled it temorarily due to the one svn issue that keeps on appearing stating a resource already exists when it updates. I know what exactly scenario triggers the error, and I'll probably need your help debugging it. The problem is the following, perhaps you can make some sense out of it... I have a project that consists of autogenerated EMF code. Most of the generated code is not source controled and is created only during the build. In EMF, any generated class can be modified by the developer to contain custom implementations of a method. A methods custom implementation can be preserved by adding a @generated NOT comment on that method. The next time the generator is run, that method implementation is not overridden. So for all the classes where I do have custom implementations I check only those into source control. Anytime these source files are committed, GBuild fails during the update stating the given class already exists. So what happens on the gbuild end is the following... (1) An initial fresh checkout of the code (2) The plugin builds successfully, so there exist in the work directory a file "N" that was generated during the build. (3) Now I end up making a custom changes to "N" locally and commit. (4) GBuild does an update, but since the generated code never was removed, "N" exists but the delta from the commit is "N" as well so it complains that "N" is already there. Only if the existing generated "N" from the previous build was removed, would the update for the committed "N" work. Does that make sense? I follow, though I'm not sure why you'd set it up that way. Anyone who attempts to work with you on the eclipse tooling will run into the same issue when they checkout. Why don't you separate the generated source from the once-generated source? In the main geronimo build we code generate tons and tons of xmlbeans classes and whatnot right into the target/ directory so they are never generated on top of anything that is scm controlled. Mixing build-time generated code in with your regular source doesn't seem like the best approach. Not sure what kind of constraints you are working with but at the very least you can keep them separate and do some footwork to compile the class files into the same dir. -David
[jira] Commented: (GERONIMO-1427) Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction
[ http://issues.apache.org/jira/browse/GERONIMO-1427?page=comments#action_12363770 ] David Jencks commented on GERONIMO-1427: Bruce made an lw_assemblies branch for this and checked in some changes for it. I worked some more and now all 3 servers start (new one is tomcat + amq + derby) rev. 371766 > Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat > and transaction > --- > > Key: GERONIMO-1427 > URL: http://issues.apache.org/jira/browse/GERONIMO-1427 > Project: Geronimo > Type: New Feature > Components: general > Versions: 1.1 > Reporter: Bruce Snyder > Attachments: separate-openejb-2.diff > -- 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: gbuild: need up with eclipse tools setup?
On Jan 17, 2006, at 5:52 AM, Sachin Patel wrote: I was tired of seeing all the BUILD FAILED errors so I disabled it temorarily due to the one svn issue that keeps on appearing stating a resource already exists when it updates. I know what exactly scenario triggers the error, and I'll probably need your help debugging it. The problem is the following, perhaps you can make some sense out of it... I have a project that consists of autogenerated EMF code. Most of the generated code is not source controled and is created only during the build. In EMF, any generated class can be modified by the developer to contain custom implementations of a method. A methods custom implementation can be preserved by adding a @generated NOT comment on that method. The next time the generator is run, that method implementation is not overridden. So for all the classes where I do have custom implementations I check only those into source control. Anytime these source files are committed, GBuild fails during the update stating the given class already exists. So what happens on the gbuild end is the following... (1) An initial fresh checkout of the code (2) The plugin builds successfully, so there exist in the work directory a file "N" that was generated during the build. (3) Now I end up making a custom changes to "N" locally and commit. (4) GBuild does an update, but since the generated code never was removed, "N" exists but the delta from the commit is "N" as well so it complains that "N" is already there. Only if the existing generated "N" from the previous build was removed, would the update for the committed "N" work. Does that make sense? I follow, though I'm not sure why you'd set it up that way. Anyone who attempts to work with you on the eclipse tooling will run into the same issue when they checkout. Why don't you separate the generated source from the once-generated source? In the main geronimo build we code generate tons and tons of xmlbeans classes and whatnot right into the target/ directory so they are never generated on top of anything that is scm controlled. Mixing build-time generated code in with your regular source doesn't seem like the best approach. Not sure what kind of constraints you are working with but at the very least you can keep them separate and do some footwork to compile the class files into the same dir. -David
[jira] Commented: (GERONIMODEVTOOLS-50) resource reference specified in geronimo-web.xml is not shown up in the naming tab of the geronimo web deployment plan editor
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-50?page=comments#action_12363765 ] Sachin Patel commented on GERONIMODEVTOOLS-50: -- I could not reproduce this, the existing ref was shown in the editor. > resource reference specified in geronimo-web.xml is not shown up in the > naming tab of the geronimo web deployment plan editor > - > > Key: GERONIMODEVTOOLS-50 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-50 > Project: Geronimo-Devtools > Type: Bug > Components: eclipse-plugin > Environment: Eclipse 3.1.1, Geronimo 1.0, winxp, JDK 1.4.2 > Reporter: Lin Sun > Priority: Minor > > Imported a simple war file that contains a geronimo-web.xml. The > geronimo-web.xml also contains a resource reference elements. > 1) I can open the geronimo-web.xml file via the geronimo web deployment plan > editor, but I don't see the resource reference I specified in the > geronimo-web.xml file under the naming tab. > 2) I tried to add a resource reference at the naming tab, and save the file. > Reopen the geronimo-web.xml, the previous defined resource reference is > replaced with the newly added one. -- 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-1287) IzPack Installer does not set line endings to CRLF on windows and LF on non-Windows platforms
[ http://issues.apache.org/jira/browse/GERONIMO-1287?page=all ] erik daughtrey updated GERONIMO-1287: - Geronimo Info: [Patch Available] This patch is applicable to trunk and branches/1.0. We should ensure that this is available for 1.0.1. > IzPack Installer does not set line endings to CRLF on windows and LF on > non-Windows platforms > - > > Key: GERONIMO-1287 > URL: http://issues.apache.org/jira/browse/GERONIMO-1287 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0-M5, 1.0-M4, 1.0 > Reporter: John Sisson > Fix For: 1.1 > Attachments: installer-fix-crlf.patch > > Currently we build one IzPack installer that is used on Windows and > non-Windows platforms. IzPack does not provide any fixcrlf type > functionality when copying files from its packs to the install location. > IzPack needs to be enhanced to be able to do this "easily". -- 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-1287) IzPack Installer does not set line endings to CRLF on windows and LF on non-Windows platforms
[ http://issues.apache.org/jira/browse/GERONIMO-1287?page=all ] erik daughtrey updated GERONIMO-1287: - Attachment: installer-fix-crlf.patch This patch adds a main (FixTextLines) which runs during IzPack processing after the files are laid down to ensure that text file line terminators are correct. > IzPack Installer does not set line endings to CRLF on windows and LF on > non-Windows platforms > - > > Key: GERONIMO-1287 > URL: http://issues.apache.org/jira/browse/GERONIMO-1287 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0-M5, 1.0-M4, 1.0 > Reporter: John Sisson > Fix For: 1.1 > Attachments: installer-fix-crlf.patch > > Currently we build one IzPack installer that is used on Windows and > non-Windows platforms. IzPack does not provide any fixcrlf type > functionality when copying files from its packs to the install location. > IzPack needs to be enhanced to be able to do this "easily". -- 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: context.xml gbeans
This is what I'm trying to figure out, if there are thoughts on a faster way. A restart is a step in the redirection, but would love not even have to do that. When I found the following... http://tomcat.apache.org/tomcat-4.0-doc/catalina/docs/api/org/apache/ catalina/loader/WebappLoader.html I thought this may do the trick. Is there not a way we could hook an implementation of this in, in a generic way so that we could have auto-reload support across a J2EE application? - sachin On Jan 23, 2006, at 6:35 PM, David Jencks wrote: On Jan 23, 2006, at 2:49 PM, Sachin Patel wrote: Thanks for your input David. So is there support today to plugin additional config-stores and repositories? I didn't think there was. I think Toby Cabot has geronimo running with multiple config stores and repositories. The packaging and assembly plugins use local- maven-repo based repository and config store implmementations. One thing I completely don't understand :-) is how you are going to get a classloader in geronimo to reload a class. At the moment this requires stopping and (re)starting the configuration involved. Although this certainly doesn't involve redeploying the app, it is still somewhat non-trivial. Do you have a faster way? thanks david jencks - sachin On Jan 23, 2006, at 5:35 PM, David Jencks wrote: On Jan 23, 2006, at 2:13 PM, Sachin Patel wrote: I think I have found my hook at least for (Tomcat) to load all resources from Eclipse. I will need to implement a classloader that extends org.apache.catalina.loader.WebappLoader to handle the WTP project structure. From a pure tomcat perspective a Loader entry for each web app can be provided in the context.xml file. Many of the attributes in server.xml are provided as gbeans in the tomcat plan, but their doesn't seem to be anything for elements in the context.xml. Is provding a gbean for the loader element the correct hook into geronimo to provide this support? If so, could someone advise me on how best to continue from a geronimo perspective? This would be really cool we could get this working even if it were just for web projects using the tomcat distro. I'm afraid I haven't followed what you are proposing very closely, but I would expect the most portable way to do something like this would be to implement an eclipse-aware config-store and repository.I thought we were preventing tomcat from building any classloaders by supplying our own. thanks david jencks - sachin
Re: context.xml gbeans
On Jan 23, 2006, at 2:49 PM, Sachin Patel wrote: Thanks for your input David. So is there support today to plugin additional config-stores and repositories? I didn't think there was. I think Toby Cabot has geronimo running with multiple config stores and repositories. The packaging and assembly plugins use local-maven- repo based repository and config store implmementations. One thing I completely don't understand :-) is how you are going to get a classloader in geronimo to reload a class. At the moment this requires stopping and (re)starting the configuration involved. Although this certainly doesn't involve redeploying the app, it is still somewhat non-trivial. Do you have a faster way? thanks david jencks - sachin On Jan 23, 2006, at 5:35 PM, David Jencks wrote: On Jan 23, 2006, at 2:13 PM, Sachin Patel wrote: I think I have found my hook at least for (Tomcat) to load all resources from Eclipse. I will need to implement a classloader that extends org.apache.catalina.loader.WebappLoader to handle the WTP project structure. From a pure tomcat perspective a Loader entry for each web app can be provided in the context.xml file. Many of the attributes in server.xml are provided as gbeans in the tomcat plan, but their doesn't seem to be anything for elements in the context.xml. Is provding a gbean for the loader element the correct hook into geronimo to provide this support? If so, could someone advise me on how best to continue from a geronimo perspective? This would be really cool we could get this working even if it were just for web projects using the tomcat distro. I'm afraid I haven't followed what you are proposing very closely, but I would expect the most portable way to do something like this would be to implement an eclipse-aware config-store and repository.I thought we were preventing tomcat from building any classloaders by supplying our own. thanks david jencks - sachin
The web XSDs...need to clean them up
Hi, I was going through the generic, tomcat and jetty web xsds and I saw a number of issues I wanted to chat about and see if I can personally be cleared up, or if I am seeing some anomolies. I notice a couple of differences that weren't making a lot of sense to me. First the geronimo-jetty-1.0 appears to still have the container-configType in the XSD. Am I correct in assuming that this should only be in the generic? Second, I noticed both the geronimo-jetty-1.0 and geronimo-tomcat-1.0 schemas have the inverseClassLoading attribute in them, but the generic does not. Is there a reason the generic does not? Jeff
Re: context.xml gbeans
Thanks for your input David. So is there support today to plugin additional config-stores and repositories? I didn't think there was. - sachin On Jan 23, 2006, at 5:35 PM, David Jencks wrote: On Jan 23, 2006, at 2:13 PM, Sachin Patel wrote: I think I have found my hook at least for (Tomcat) to load all resources from Eclipse. I will need to implement a classloader that extends org.apache.catalina.loader.WebappLoader to handle the WTP project structure. From a pure tomcat perspective a Loader entry for each web app can be provided in the context.xml file. Many of the attributes in server.xml are provided as gbeans in the tomcat plan, but their doesn't seem to be anything for elements in the context.xml. Is provding a gbean for the loader element the correct hook into geronimo to provide this support? If so, could someone advise me on how best to continue from a geronimo perspective? This would be really cool we could get this working even if it were just for web projects using the tomcat distro. I'm afraid I haven't followed what you are proposing very closely, but I would expect the most portable way to do something like this would be to implement an eclipse-aware config-store and repository.I thought we were preventing tomcat from building any classloaders by supplying our own. thanks david jencks - sachin
Re: context.xml gbeans
On Jan 23, 2006, at 2:13 PM, Sachin Patel wrote: I think I have found my hook at least for (Tomcat) to load all resources from Eclipse. I will need to implement a classloader that extends org.apache.catalina.loader.WebappLoader to handle the WTP project structure. From a pure tomcat perspective a Loader entry for each web app can be provided in the context.xml file. Many of the attributes in server.xml are provided as gbeans in the tomcat plan, but their doesn't seem to be anything for elements in the context.xml. Is provding a gbean for the loader element the correct hook into geronimo to provide this support? If so, could someone advise me on how best to continue from a geronimo perspective? This would be really cool we could get this working even if it were just for web projects using the tomcat distro. I'm afraid I haven't followed what you are proposing very closely, but I would expect the most portable way to do something like this would be to implement an eclipse-aware config-store and repository.I thought we were preventing tomcat from building any classloaders by supplying our own. thanks david jencks - sachin
Re: [openejb-dev] Re: Cut date for 1.1?
On Jan 22, 2006, at 5:58 PM, David Jencks wrote: On Jan 20, 2006, at 1:33 PM, Dain Sundstrom wrote: I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Does this mean there will be one interceptor stack for each ejb type, shared among all the e.g. stateless sesssion ejbs? By default, yes. The idea is you can deploy extra invocation processors that have different QoSes configured and then you assign an ejb to the processor you want. What is the advantage of this design? I think the important important advantage for OpenEJB is that this change aligns the 2 code with the 1 code. The other big advantage is that it the job of a deployer is simpler because the most complex configurations (like caches) are placed on the invocation processors which will be defined using he generic gbean xml tags. I can think of some disadvantages compared to our present design but no advantages. Probably just a lack of imagination, but I'd really appreciate discussion of architectural changes before the code arrives. The architectural change is to split the current EJB container into a service for each EJB and a shared service for invocation processing. If you want to have a discussion on this, we should move to the openejb dev mailing list. I thought about this several years ago in reference to another app server and thought of 2 designs. I'm curious if you picked one or found a third, and your reasons. I'll describe the designs in terms of gbeans for simplicity. 1. The gbeans themselves form the interceptor stack. This means the ejb gbean needs to have an ejb context object that it sends down the stack with each call containing the info particular to that ejb, such as the transaction policy settings. Since you don't really have any idea what interceptors are present, AFAICT you either need to code generate a context object to suit the particular interceptors present, or use a map. A map is a bit slow and loses type safety, whereas code generation seems awfully complicated. I suppose it might be possible to use an Object[] and figure out the indices for each interceptor when the ejb starts. 2. The gbeans are interceptor factories, and when the ejb starts it uses the factories to construct its own personalized interceptor stack. Here, each interceptor instance can hold the context information for itself, and initializing it from a map does not have a performance penalty. On the other hand, you get more interceptor object instances. Dain's on the road again, but I have seen some of the code and try and recall what I can. From the choices, I'd say it's closer to 1 than 2. I distinctly remember a very impressive looking map implementation that was type safe in it's understanding of methods. IIRC it was an object array, not a true map, that gave you method -> object indexing ability. Something of that nature. The motivation is something I can speak a little more about as it's basically a lot of design concepts we found useful in the past. I think he just got sick of hearing me talk about it and decided to give it a try :) The idea being to split the ejb specific stuff from the stuff that is not entirely ejb specific, but likely more specific to beans of that type. So things like pool settings, or caching settings could just be configured generally and not over and over again on a per-ejb basis. You can do more at a macroscopic level and are forced to do less at a microscopic level. The bean type information goes to the container (which could be implemented as a stack of interceptors) and the bean specific information goes into the ejb context object. For people who know OpenEJB 1, that would be DeploymentInfo (bad name) and Container. Surprisingly, it cleans up your code quite a bit to separate concerns at that level and allows you some great config options. Say for example, you could tweak the pool size for all the stateless session beans running in a given container via a management console. No need to grab each bean individually and set it's pool size. It also allows you to easily leverage new container implementations. For example, when we ran the ejb test suite at ApacheCon 2003 that was basically the "nova" containers wrapped with an adapter and used in an unmodified OpenEJB 0.9.2 distribution. Adhering to the idea that simple things should be simple and complex things possible, if you did want to be very specific and microscopic in the management of a particular ejb, you just dedicate a new container definition to that ejb (i.e. a container with one ejb). An easy way to do that would be via another gbean declaration which you could probably put right in the openejb-jar.xml f
context.xml gbeans
I think I have found my hook at least for (Tomcat) to load all resources from Eclipse. I will need to implement a classloader that extends org.apache.catalina.loader.WebappLoader to handle the WTP project structure. From a pure tomcat perspective a Loader entry for each web app can be provided in the context.xml file. Many of the attributes in server.xml are provided as gbeans in the tomcat plan, but their doesn't seem to be anything for elements in the context.xml. Is provding a gbean for the loader element the correct hook into geronimo to provide this support? If so, could someone advise me on how best to continue from a geronimo perspective? This would be really cool we could get this working even if it were just for web projects using the tomcat distro. - sachin
[jira] Closed: (GERONIMODEVTOOLS-49) Add resource reference GUI created unnecessary target-name elements
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-49?page=all ] Lin Sun closed GERONIMODEVTOOLS-49: --- This is fixed > Add resource reference GUI created unnecessary target-name elements > --- > > Key: GERONIMODEVTOOLS-49 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-49 > Project: Geronimo-Devtools > Type: Bug > Components: eclipse-plugin > Environment: WinXP, JDK 1.4.2, Geronimo 1.0, Eclipse 3.1.1 > Reporter: Lin Sun > Assignee: Sachin Patel > Priority: Minor > > If you specify a resource reference via the naming page in geronimo-web.xml, > the naming:target-name elements will be created unnecessarily, and it will > cause deploy error when the module is deployed. For example: > > test > test > > > The workaround is to remove the "" > at the source tab and save the change. -- 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
commit == tck work
Just a friendly reminder ... if you've checked in code since last certified release, you've signed yourself up for TCK work. [this has been a public service announcement]
[jira] Updated: (GERONIMO-1534) Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db
[ http://issues.apache.org/jira/browse/GERONIMO-1534?page=all ] Lin Sun updated GERONIMO-1534: -- Attachment: G1534-daytrader.patch > Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db > - > > Key: GERONIMO-1534 > URL: http://issues.apache.org/jira/browse/GERONIMO-1534 > Project: Geronimo > Type: Bug > Components: sample apps > Versions: 1.0 > Environment: WinXP, > Reporter: Lin Sun > Priority: Minor > Attachments: G1534-daytrader.patch > > In daytrader plan it contains the following ejb-ql-compiler-factory elements: > > If you uncomment the following line and configure daytrader with DB2, you > will see a classloader problem when deploying daytrader. > This should be changed to ejbqlcompiler instead of ejbcompiler: > > org.tranql.ejbqlcompiler.DB2EJBQLCompilerFactory > > org.tranql.sql.db2.DB2DBSyntaxFactory > Same problem with Oracle. -- 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-1535) Error in security realm portlet
Error in security realm portlet --- Key: GERONIMO-1535 URL: http://issues.apache.org/jira/browse/GERONIMO-1535 Project: Geronimo Type: Bug Components: console Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1, 1.0.1 7:09:31,937 ERROR [SecurityRealmPortlet] Unable to render portlet ava.lang.NullPointerException at org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortle .loadDriverJARList(SecurityRealmPortlet.java:610) at org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortle .renderConfigure(SecurityRealmPortlet.java:529) at org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortle .doView(SecurityRealmPortlet.java:236) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMODEVTOOLS-51) Cannot remove published applications
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-51?page=all ] Lin Sun closed GERONIMODEVTOOLS-51: --- This issue is fixed. > Cannot remove published applications > > > Key: GERONIMODEVTOOLS-51 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-51 > Project: Geronimo-Devtools > Type: Bug > Environment: WINXP, JDK 1.4.2 eclipse 3.1.1 > Reporter: Lin Sun > Assignee: Sachin Patel > Priority: Blocker > > This problem started to appear in one of the very recent builds. > 1) Start with a clean workspace: eclipse -clean and define the geronimo > server. > 2) Imported the Hello.war > 3) did the normal Run on server > 4) saw the hello page in the eclipse browser > 5) any attempts to Run on server, Remove, ... failed. The .log and > server.log was showing that the hello app was already on the server and it > was not being redeployed. Did a deploy list-modules, and saw hello program > with a + sign on the left indicating it is still running. -- 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-1534) Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db
Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db - Key: GERONIMO-1534 URL: http://issues.apache.org/jira/browse/GERONIMO-1534 Project: Geronimo Type: Bug Components: sample apps Versions: 1.0 Environment: WinXP, Reporter: Lin Sun Priority: Minor In daytrader plan it contains the following ejb-ql-compiler-factory elements: If you uncomment the following line and configure daytrader with DB2, you will see a classloader problem when deploying daytrader. This should be changed to ejbqlcompiler instead of ejbcompiler: org.tranql.ejbqlcompiler.DB2EJBQLCompilerFactory org.tranql.sql.db2.DB2DBSyntaxFactory Same problem with Oracle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1533) geronimo server started with errors
[ http://issues.apache.org/jira/browse/GERONIMO-1533?page=all ]
Aaron Mulder closed GERONIMO-1533:
--
Resolution: Invalid
Assign To: Aaron Mulder
Daytrader is known to not work under JDK 1.5. There was a thread about this on
the mailing list recently ("JDK 1.6.0 to JDK 1.5.0 downgrade"). You should run
under 1.4.2 if you can, or if you must use 1.5 then undeploy daytrader and make
sure to avoid anything that requires CORBA or javax.xml.namespace.QName.
> geronimo server started with errors
> ---
>
> Key: GERONIMO-1533
> URL: http://issues.apache.org/jira/browse/GERONIMO-1533
> Project: Geronimo
> Type: Bug
> Versions: 1.0
> Environment: Windows XP SP2, Sun JDK 1.5.0 update 6
> Reporter: akakunin
> Assignee: Aaron Mulder
> Priority: Minor
>
> I just downloaded geronimo-tomcat-1.0.zip and unzipped it.
> after starting geronimo server I've got to error (in console with long stack
> trace).
> In geronimo console I found two issues:
> 140: 19:09:25,520 ERROR [GBeanInstance] Problem in doFail of
> geronimo.server:J2EEApplication=geronimo/daytrader-derby-tomcat/1.0/car,J2EEServer=geronimo,j2eeType=WebModule,name=daytrader-web-1.0.war
> 190: 19:09:25,530 ERROR [GBeanInstanceState] Error while starting; GBean is
> now in the FAILED state:
> objectName="geronimo.server:J2EEApplication=geronimo/daytrader-derby-tomcat/1.0/car,J2EEServer=geronimo,j2eeType=WebModule,name=daytrader-web-1.0.war"
> I really have no ideas about that daytrader-web is.
> Seems server works well, but these unexpected exceptions make it not to
> comfortable to see how server started
--
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-1533) geronimo server started with errors
geronimo server started with errors --- Key: GERONIMO-1533 URL: http://issues.apache.org/jira/browse/GERONIMO-1533 Project: Geronimo Type: Bug Versions: 1.0 Environment: Windows XP SP2, Sun JDK 1.5.0 update 6 Reporter: akakunin Priority: Minor I just downloaded geronimo-tomcat-1.0.zip and unzipped it. after starting geronimo server I've got to error (in console with long stack trace). In geronimo console I found two issues: 140: 19:09:25,520 ERROR [GBeanInstance] Problem in doFail of geronimo.server:J2EEApplication=geronimo/daytrader-derby-tomcat/1.0/car,J2EEServer=geronimo,j2eeType=WebModule,name=daytrader-web-1.0.war 190: 19:09:25,530 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName="geronimo.server:J2EEApplication=geronimo/daytrader-derby-tomcat/1.0/car,J2EEServer=geronimo,j2eeType=WebModule,name=daytrader-web-1.0.war" I really have no ideas about that daytrader-web is. Seems server works well, but these unexpected exceptions make it not to comfortable to see how server started -- 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
Testing SMTP authentication
Looking for suggestions for testing the javamail SMTP authentication support. The server I've been using so far (James) only supports LOGIN authentication. I'm going to need a server that supports CRAM_MD5 and MD5_DIGEST, as well as STARTTLS. I've been searching around, and postfix supposedly supports all of these, but getting it set up and configured properly appears to be a lot of work. Anybody have any suggestions for other options (or even have a suitable server already setup that I can use for testing). Rick
[jira] Resolved: (GERONIMODEVTOOLS-27) Need timer task to setServerState
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-27?page=all ] Sachin Patel resolved GERONIMODEVTOOLS-27: -- Resolution: Fixed > Need timer task to setServerState > - > > Key: GERONIMODEVTOOLS-27 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-27 > Project: Geronimo-Devtools > Type: Improvement > Components: eclipse-plugin > Reporter: Sachin Patel > Assignee: Sachin Patel > > If user stops or starts server outside of tools, server state in the Servers > view will be out of sync. Need timer task to periodicly run to check and > update server state. -- 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: Docco system (Confluent, MoinMoin, ...)
Count me in. I can devote time and effort towards this workitem too. Cheers PrasadOn 1/23/06, Paul McMahan <[EMAIL PROTECTED]> wrote: I'm neither a commiter nor a Confluence/Wiki expert but I'm available to help. I have written some crazy perl scripts in my time (could help with content xfer) and have a decent amount of experience with web & sysadmin type stuff (could help with setup & maintenance). Best wishes, Paul On 1/21/06, Jason Dillon <[EMAIL PROTECTED] > wrote: Agreed, the xfr from Moin to Confluence is minor.The bigger problem is convincing ASF Infra to let us run Confluence and allow us to setup the right env for that (rdbms + smtp server)--jason
Re: Docco system (Confluent, MoinMoin, ...)
I'm neither a commiter nor a Confluence/Wiki expert but I'm available to help. I have written some crazy perl scripts in my time (could help with content xfer) and have a decent amount of experience with web & sysadmin type stuff (could help with setup & maintenance). Best wishes, Paul On 1/21/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Agreed, the xfr from Moin to Confluence is minor.The bigger problem is convincing ASF Infra to let us run Confluence and allow us to setup the right env for that (rdbms + smtp server)--jason
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
[ X ] Confluence Cheers PrasadOn 1/23/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > I think that a documentation system should be a combination of>> - reasonably easy to use> - versionable> - able to be used offline> - extractable into an open and transformable format for reuse >> Wikis that I've used fail on #2, #3 and #4.Confluence (as well as other mature wikis) provide #2, and #4 isn'tthat really to achieve. Most wikis provide some way to versioncontent. It happens that Confluence uses Hibernate and versioned entities for this not a SCM like SVN or Perforce. Confluence wiki-markup could itself be considered that open and transformableformat. If you don't like that, then you could always write atransformer into that language which you do like. #3 is the only one that isn't so easy to resolve out of the box. Itis possible however, but is lacking in many ways. For example, youcould setup a Confluence standalone on whatever your mobileworkstation was, then import/export spaces. Its definitely not ideal, but it is possible.Perhaps someone will write a bidirectional SVN sync, so that youcould update Confluence wiki-markup in SVN, which would then getpicked up in Confluence. While this could be done, there are some issues with potential merging conflicts, as the definitive copy ofthe data is in Confluence (from Confluence's perspective), so if auser offline make several changes, in addition to online users, therewould potentially be a window of error. > I realize the clear majority is for Confluence, but these factors> should be considered.There are several... or many (not sure) of us who are aware of theseissues. I've been actively looking at resolving some of them and/or finding alternatives which will appease most of the interested parties.For example, I've got a crude Confluence listener which will persistwiki-markup (w/editor id and comments) to SVN. That gets us closer to a #2 that more people can agree on. Atlassian are cool/reasonablepeeps so it might be possible to expose the basic versioning/contentmechanism as a plugin to allow us to completly replace that with aSVN impl... but don't hold your breath. --jason
[jira] Created: (GERONIMO-1532) NullPointerException when a badly named jar is put into repository directory
NullPointerException when a badly named jar is put into repository directory Key: GERONIMO-1532 URL: http://issues.apache.org/jira/browse/GERONIMO-1532 Project: Geronimo Type: Bug Versions: 1.0 Reporter: Heikki Linnakangas Priority: Minor Attachments: listURIs.diff I copied a JDBC driver jar to geronimo/repository-directory, thinking that geronimo would pick it up from there. What I didn't know, is that jars in the repository need to be named in a particular way. I then tried to add a Database pool using the wizard. I filled the name and type in step 1, and clicked next. Instead of step 2, I got a blank screen, and this stack trace in the log: 14:30:33,322 ERROR [DatabasePoolPortlet] Unable to render portlet java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.loadDriverJARList(DatabasePoolPortlet.java:750) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderBasicParams(DatabasePoolPortlet.java:721) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:625) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) ... The culprit seems to be the FileSystemRepository.listURIs-method, that doesn't handle invalid filenames properly, but returns nulls in the array it returns instead. -- 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-1532) NullPointerException when a badly named jar is put into repository directory
[ http://issues.apache.org/jira/browse/GERONIMO-1532?page=all ] Heikki Linnakangas updated GERONIMO-1532: - Attachment: listURIs.diff Here's a patch that fixes the issue. > NullPointerException when a badly named jar is put into repository directory > > > Key: GERONIMO-1532 > URL: http://issues.apache.org/jira/browse/GERONIMO-1532 > Project: Geronimo > Type: Bug > Versions: 1.0 > Reporter: Heikki Linnakangas > Priority: Minor > Attachments: listURIs.diff > > I copied a JDBC driver jar to geronimo/repository-directory, thinking that > geronimo would pick it up from there. What I didn't know, is that jars in the > repository need to be named in a particular way. > I then tried to add a Database pool using the wizard. I filled the name and > type in step 1, and clicked next. Instead of step 2, I got a blank screen, > and this stack trace in the log: > 14:30:33,322 ERROR [DatabasePoolPortlet] Unable to render portlet > java.lang.NullPointerException > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.loadDriverJARList(DatabasePoolPortlet.java:750) > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderBasicParams(DatabasePoolPortlet.java:721) > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:625) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) > ... > The culprit seems to be the FileSystemRepository.listURIs-method, that > doesn't handle invalid filenames properly, but returns nulls in the array it > returns instead. -- 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: DefaultWorkManager and Pool Size
To increase the pool size you should be able to add an entry for DefaultWorkManager to config.xml (if it's not there already) and just bump up the number of threads. You do have to do that while the server is not running, though. Eventually, we're planning to add thread pool managment to the console. Thanks, Aaron On 1/23/06, Krishnakumar B <[EMAIL PROTECTED]> wrote: > Hi, > > The DefaultWorkManager has a pool size of 10. If i submit more than 10 > long running units of work i dont know that the Threads > 10 are > waiting. Can some message be printed in log so that i can know that > the pool is fully consumed and Work instances are waiting for > execution. > > The PooledExecutor getPoolSize() gives the size of pool currently consumed > If so can this check can be added to WorkExecutorPoolImpl to check the > pool size during execution? > > If i need to increase the pool size is it enough to redeploy > DefaultWorkManager GBean? > > Regards > Krishnakumar B >
[jira] Updated: (GERONIMO-1529) Console should display Geronimo Version
[ http://issues.apache.org/jira/browse/GERONIMO-1529?page=all ]
Matthias Schmidt updated GERONIMO-1529:
---
Description:
One should be able to figure out geronimo's Version by:
a) looking in the Console, perhaps under "Server Info"
b) looking in the Logfiles.
for a) one can do the following:
---
applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java
2006-01-23 14:57:59.0 +0100
+++
applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java.CHANGE
2006-01-23 15:02:27.0 +0100
@@ -34,6 +34,7 @@
import org.apache.geronimo.console.BasePortlet;
import org.apache.geronimo.console.util.PortletManager;
import org.apache.geronimo.management.geronimo.JVM;
+import org.apache.geronimo.console.GeronimoVersion;
/**
* Calculates various information about the server to display in the server
@@ -71,6 +72,8 @@
Date bootDate = jvm.getKernelBootTime();
svrProps.put("Kernel Boot Time", bootDate);
+svrProps.put("Geronimo Version", new
GeronimoVersion().GERONIMO_VERSION);
+
renderRequest.setAttribute("svrProps", svrProps);
jvmProps.put("Java Version", jvm.getJavaVersion());
---
applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp
2006-01-11 17:34:52.0 +0100
+++
applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp.CHANGE
2006-01-23 15:06:42.0 +0100
@@ -5,6 +5,7 @@
+
@@ -19,6 +20,10 @@
Kernel Up Time
Not Yet
Available
+
+Geronimo Version
+${svrProps['Geronimo
Version']}
+
> Key: GERONIMO-1529
> URL: http://issues.apache.org/jira/browse/GERONIMO-1529
> Project: Geronimo
> Type: Improvement
> Components: console, Logging
> Versions: 1.0, 1.0-M5, 1.0-M4, 1.0-M3, 1.0-M2, 1.0-M1, 1.0.1, 1.1, 1.x
> Reporter: Matthias Schmidt
> Priority: Minor
>
> One should be able to figure out geronimo's Version by:
> a) looking in the Console, perhaps under "Server Info"
> b) looking in the Logfiles.
> for a) one can do the following:
> ---
> applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java
>2006-01-23 14:57:59.0 +0100
> +++
> applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java.CHANGE
> 2006-01-23 15:02:27.0 +0100
> @@ -34,6 +34,7 @@
> import org.apache.geronimo.console.BasePortlet;
> import org.apache.geronimo.console.util.PortletManager;
> import org.apache.geronimo.management.geronimo.JVM;
> +import org.apache.geronimo.console.GeronimoVersion;
> /**
> * Calculates various information about the server to display in the server
> @@ -71,6 +72,8 @@
> Date bootDate = jvm.getKernelBootTime();
> svrProps.put("Kernel Boot Time", bootDate);
> +svrProps.put("Geronimo Version", new
> GeronimoVersion().GERONIMO_VERSION);
> +
> renderRequest.setAttribute("svrProps", svrProps);
> jvmProps.put("Java Version", jvm.getJavaVersion());
> ---
> applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp
> 2006-01-11 17:34:52.0 +0100
> +++
> applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp.CHANGE
> 2006-01-23 15:06:42.0 +0100
> @@ -5,6 +5,7 @@
> src='/console-standard/dwr/engine.js'>
>
> +
>
>
> @@ -19,6 +20,10 @@
> Kernel Up Time
> Not
> Yet Available
>
> +
> +Geronimo Version
> +${svrProps['Geronimo
> Version']}
> +
>
>
>
DefaultWorkManager and Pool Size
Hi, The DefaultWorkManager has a pool size of 10. If i submit more than 10 long running units of work i dont know that the Threads > 10 are waiting. Can some message be printed in log so that i can know that the pool is fully consumed and Work instances are waiting for execution. The PooledExecutor getPoolSize() gives the size of pool currently consumed If so can this check can be added to WorkExecutorPoolImpl to check the pool size during execution? If i need to increase the pool size is it enough to redeploy DefaultWorkManager GBean? Regards Krishnakumar B
Re: Replication using totem protocol
Still, it doesn't seem like there is much interest in using totem. For session replication you can use primary-backup, if anything. On Sun, 22 Jan 2006, Geir Magnusson Jr wrote: > Catching up : > > [EMAIL PROTECTED] wrote: > >> No. You license the code to the Apache Software Foundation giving > >> the foundation the rights to relicense under any license (so the > >> foundation can upgrade the license as they did with ASL2). We do ask > >> that you change the copyrights on the version of the code you give to > >> the ASF to something like "Copyright 2004 The Apache Software > >> Foundation or its licensors, as applicable." > > > > That _is_ transferring the copyright. > > No, it isn't. You are still the copyright holder of the contributed > material. The (c) statement that Dain suggested represents the > collective copyright of the whole package, which is your original code > (for which you hold the copyright), and additions from other people (who > individually hold copyright or share copyright depending on the > contribution.) > > That's why it's "or it's licensors", which you would certainly be. > > > > > As I told Jeff on the phone, I would definitely considering this if it > > turns that evs4j will really be used, but I would rather not grant someone > > an unlimited license at the present time. Jeff said we are going to have a > > discussion, so we'll know more soon enough. > > The Apache License is fairly close to an unlimited license, so if it's > available under the AL, you are already there. > > The only thing different is that you are giving the ASF the ability to > distribute the collective work under other terms other than the current > version of the Apache License. > > I hope that makes you feel a little more comfortable about things. > > geir > >
[jira] Created: (GERONIMO-1531) KeyStore portlet should support deletion of certificates and private keys
KeyStore portlet should support deletion of certificates and private keys - Key: GERONIMO-1531 URL: http://issues.apache.org/jira/browse/GERONIMO-1531 Project: Geronimo Type: Improvement Components: console Versions: 1.0 Reporter: Vamsavardhana Reddy Priority: Minor Fix For: 1.0.1, 1.1 KeyStore portlet currently supports generation of keypairs, adding trusted certificates to keystore and importing certificate issued by CA. It does not address "deletion" of any of these from the keystore. -- 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: Geronimo Community
Thanks for suggesting this. There's another reason to do it - in areas where Geronimo documentation might be a little "thin", this could serve as an overview of how a particular feature works.
[jira] Updated: (GERONIMO-1530) javax.mail.Service does not properly implement the protocol between javamail infrastructure and transport handlers.
[ http://issues.apache.org/jira/browse/GERONIMO-1530?page=all ] Rick McGuire updated GERONIMO-1530: --- Attachment: Service.patch > javax.mail.Service does not properly implement the protocol between javamail > infrastructure and transport handlers. > --- > > Key: GERONIMO-1530 > URL: http://issues.apache.org/jira/browse/GERONIMO-1530 > Project: Geronimo > Type: Bug > Components: mail > Versions: 1.0 > Reporter: Rick McGuire > Attachments: Service.patch > > The javamail spec defines a Service.connect() method that performs a number > of setup functions (including authentication) before doing a mail transport > operation by calling a transport's protocolConnect() method. . Currently, > the Geronimo javamail implementation has very incomplete implementation of > the connect method, and the SMTP transport implementation directly overrides > connect rather than perform the connection operation in protocolConnect(). > Implementation of SMTP authentication is dependent on a more complete > implementation. -- 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-1529) Console should display Geronimo Version
Console should display Geronimo Version --- Key: GERONIMO-1529 URL: http://issues.apache.org/jira/browse/GERONIMO-1529 Project: Geronimo Type: Improvement Components: console, Logging Versions: 1.0-M1, 1.0-M2, 1.0-M3, 1.0-M4, 1.0-M5, 1.0, 1.1, 1.x, 1.0.1 Reporter: Matthias Schmidt Priority: Minor One should be able to figure out geronimo's Version by: a) looking in the Console, perhaps under "Server Info" b) looking in the Logfiles. -- 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-1530) javax.mail.Service does not properly implement the protocol between javamail infrastructure and transport handlers.
javax.mail.Service does not properly implement the protocol between javamail infrastructure and transport handlers. Key: GERONIMO-1530 URL: http://issues.apache.org/jira/browse/GERONIMO-1530 Project: Geronimo Type: Bug Components: mail Versions: 1.0 Reporter: Rick McGuire The javamail spec defines a Service.connect() method that performs a number of setup functions (including authentication) before doing a mail transport operation by calling a transport's protocolConnect() method. . Currently, the Geronimo javamail implementation has very incomplete implementation of the connect method, and the SMTP transport implementation directly overrides connect rather than perform the connection operation in protocolConnect(). Implementation of SMTP authentication is dependent on a more complete implementation. -- 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-1528) javax.mail.BodyPart does not implement setParent() method
[ http://issues.apache.org/jira/browse/GERONIMO-1528?page=all ] Rick McGuire updated GERONIMO-1528: --- Attachment: BodyPart.patch > javax.mail.BodyPart does not implement setParent() method > - > > Key: GERONIMO-1528 > URL: http://issues.apache.org/jira/browse/GERONIMO-1528 > Project: Geronimo > Type: Bug > Components: mail > Versions: 1.0 > Reporter: Rick McGuire > Priority: Minor > Attachments: BodyPart.patch > > The class javax.mail.BodyPart does not implement the setParent() method > (which the Sun version does do). Since this is an abstract class, concrete > implementations are expected to implement this, which creates a difference > between running with the Sun version vs. the Geronimo version. -- 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-1528) javax.mail.BodyPart does not implement setParent() method
javax.mail.BodyPart does not implement setParent() method - Key: GERONIMO-1528 URL: http://issues.apache.org/jira/browse/GERONIMO-1528 Project: Geronimo Type: Bug Components: mail Versions: 1.0 Reporter: Rick McGuire Priority: Minor The class javax.mail.BodyPart does not implement the setParent() method (which the Sun version does do). Since this is an abstract class, concrete implementations are expected to implement this, which creates a difference between running with the Sun version vs. the Geronimo version. -- 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-1527) InternetAddress does not properly implement address parsing.
[ http://issues.apache.org/jira/browse/GERONIMO-1527?page=all ] Rick McGuire updated GERONIMO-1527: --- Attachment: InternetAddress.patch Patch to add internet address parsing to javamail, including unit tests for the package. > InternetAddress does not properly implement address parsing. > > > Key: GERONIMO-1527 > URL: http://issues.apache.org/jira/browse/GERONIMO-1527 > Project: Geronimo > Type: Improvement > Components: mail > Versions: 1.0 > Environment: All. > Reporter: Rick McGuire > Attachments: InternetAddress.patch > > The InternetAddress class of the javamail spec package does not properly > implement RFC822 address parsing. This is impacting the ability to implement > full SMTP support, as well as adding POP3 and IMAP support. -- 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-1527) InternetAddress does not properly implement address parsing.
InternetAddress does not properly implement address parsing. - Key: GERONIMO-1527 URL: http://issues.apache.org/jira/browse/GERONIMO-1527 Project: Geronimo Type: Improvement Components: mail Versions: 1.0 Environment: All. Reporter: Rick McGuire The InternetAddress class of the javamail spec package does not properly implement RFC822 address parsing. This is impacting the ability to implement full SMTP support, as well as adding POP3 and IMAP support. -- 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: Geronimo Community
Speaking of which, ... I seem to recall a long time ago you mentioning the idea of supplying a portlet app for each component and plugging it into the admin console. I think J2 in geronimo will now support deploying portlet apps more or less dynamically, although I'm not yet happy with exactly how this is happening. However, I'm not sure how to extend the portal itself based on adding a portlet app, nor do I have any idea what else in the portal needs changing when a component "registers". Are we at a point where talking about this makes sense? It would be nice if applications could provide a set of portlets to admin the app itself too. Then ops folks would get a nice looking unified interface for admin of the system, as well as the applications running inside of it. --jason
Re: CORBA incubation proposal
On Jan 22, 2006, at 2:02 AM, Alan D. Cabrera wrote: Anders Hessellund Jensen (Trifork) wrote, On 1/21/2006 5:09 AM: Alan D. Cabrera wrote: Its name isn't CORBA Server. It is being characterized as a CORBA server, which IIUC is perfectly legal. I understand it differently. In the "Proper usage of OMG trademarks and logos" section, it specifically states: Do not use OMG Marks as all or part of a product name or in or on any product, packaging, labels, advertisements, press releases, marketing materials, web pages, trade show materials, or any other materials. Thus, IIUC, we are not allowed to characterize our product as CORBA anything, unless we get permission. Perhaps we should submit a request for use on the CORBA trademark. Since we are a non-profit organisation we may get a permission to use the CORBA trademark for free. What did Trifork do for its server? Our CORBA implementation was never that in itself; we have made a Java EE stack and that is what we have marketed it as. The fact that it includes a CORBA ORB implementation is just a consequence of spec requirements. We never marketed it as CORBA. Kresten smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
I think that a documentation system should be a combination of - reasonably easy to use - versionable - able to be used offline - extractable into an open and transformable format for reuse Wikis that I've used fail on #2, #3 and #4. Confluence (as well as other mature wikis) provide #2, and #4 isn't that really to achieve. Most wikis provide some way to version content. It happens that Confluence uses Hibernate and versioned entities for this not a SCM like SVN or Perforce. Confluence wiki- markup could itself be considered that open and transformable format. If you don't like that, then you could always write a transformer into that language which you do like. #3 is the only one that isn't so easy to resolve out of the box. It is possible however, but is lacking in many ways. For example, you could setup a Confluence standalone on whatever your mobile workstation was, then import/export spaces. Its definitely not ideal, but it is possible. Perhaps someone will write a bidirectional SVN sync, so that you could update Confluence wiki-markup in SVN, which would then get picked up in Confluence. While this could be done, there are some issues with potential merging conflicts, as the definitive copy of the data is in Confluence (from Confluence's perspective), so if a user offline make several changes, in addition to online users, there would potentially be a window of error. I realize the clear majority is for Confluence, but these factors should be considered. There are several... or many (not sure) of us who are aware of these issues. I've been actively looking at resolving some of them and/or finding alternatives which will appease most of the interested parties. For example, I've got a crude Confluence listener which will persist wiki-markup (w/editor id and comments) to SVN. That gets us closer to a #2 that more people can agree on. Atlassian are cool/reasonable peeps so it might be possible to expose the basic versioning/content mechanism as a plugin to allow us to completly replace that with a SVN impl... but don't hold your breath. --jason
