Re: $project.xml files for ServiceMix and ActiveMQ
On 2/1/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ServiceMix and ActiveMQ folks: Sorry for the interruption in karma this afternoon. It was inadvertent but not inappropriate. Noel tells me that he's been maintaining your podling's karma according to the official list of committers in your $project.xml file -- so when I corrected the Geronimo list today, which the podling committers were mistakenly on, the karma went away. I've put the karma back temporarily, but your $project.xml file *really* needs to be updated with the official list of committers for your podling. I'm going to revert my temporary change tomorrow, and set the podling karmas according to the contents of the .xml files. Noel tells me this has come up before. Sorry again about the interruption. I guess it has turned out to be a jarring revelation that maybe those files aren't just window-dressing. :-/ Thank you very much for making us aware of this issue, Ken. I know that it was a learning experience for me. At any rate, I've fixed up the list of committers in each $project.xml file and gotten the final $project.html published to the respective Incubator sites. I hope that these files are up to snuff regarding the Incubator requirements. Please let me know if you find any faults. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: itests patch
On Jan 31, 2006, at 8:53 PM, Dain Sundstrom wrote: The test application doesn't start for me because Geronimo no longer has a DefaultDatasource :( Anyone know how to easily get one of these into the server (and don't tell me to use the console since this is an automated test)? I'd suggest following the example of juddi, daytrader, etc etc and building a database and installing a datasource with the itest app. david jencks -dain On Jan 31, 2006, at 1:59 PM, Prasad Kashyap wrote: David, The itests infrastructure now works fine but the tests themselves fail with 2 errors. The setup, test execution and teardown all work fine now. While I tackle the failing tests next, for now may I submit these patches for you to commit to the openejb project ? Cheers Prasad itest.patches.txt
Re: XML plan files not included in distributions
On Jan 31, 2006, at 9:44 PM, John Sisson wrote: Is there a reason why we no longer ship the XML plan files in the distributions? In the M5 release (when we were using modules/ assembly) we included them in the geronimo\doc\plan directory. I haven't been able to find a JIRA for this, but seem to remember someone discussing it recently. It was a combination of an oversight and the idea that being able to add gbeans using config.xml could replace the need to modify and redeploy the plans we supply. I think that we should distribute them with the servers. david jencks John
Re: differences between installer installation and tomcat/jetty installations
On Jan 31, 2006, at 9:08 PM, John Sisson wrote: 1) In the 1.0 branch I noticed that an installer installation has geronimo/repository/geronimo/cars directory (containing approx 42 MB of car files) but the tomcat jetty assemblies don't have the car directory. Is this intended? When are car files in the repository used? I think this is an artifact of the way the installer is working right now, namely including a repo inside it and copying everything into the server under construction, whether or not it is used. I want it to install only the stuff you select. 2) I also noticed that in the installer installation using the default options, the following files (that are installed for the jetty/tomcat assemblies) are not installed: geronimo/repository/jars/geronimo-javamail-transport-1.0.1- SNAPSHOT.jar geronimo/repository/jars/geronimo-mail-1.0.1-SNAPSHOT.jar What happens if the user initially does not select SMTP transport (the default) in the installer and then after installation changes their mind? How are we expecting the user to get it installed? Due to my theory about (1), I think that these are simply left out of the installers internal repo and so the mail config may not work. As noted in (1) in my opinion these should get copied into the server under construction only if you select the mail configuration for installation. thanks david jencks Thanks, John
Re: differences between installer installation and tomcat/jetty installations
On Wednesday 01 February 2006 03:09, David Jencks wrote: On Jan 31, 2006, at 9:08 PM, John Sisson wrote: 1) In the 1.0 branch I noticed that an installer installation has geronimo/repository/geronimo/cars directory (containing approx 42 MB of car files) but the tomcat jetty assemblies don't have the car directory. Is this intended? Yes When are car files in the repository used? During final processing, the ConfigInstaller runs which installs the cars associated with the selected packs into the config-store. The ConfigInstaller reads var/config/configure.xml to determine which cars need to be installed. Configure.xml is created by the assembly plugin, but contains variables to be replaced at install time to inform ConfigInstaller of which cars need to be installed. I think this is an artifact of the way the installer is working right now, namely including a repo inside it and copying everything into the server under construction, whether or not it is used. I want it to install only the stuff you select. 2) I also noticed that in the installer installation using the default options, the following files (that are installed for the jetty/tomcat assemblies) are not installed: I fixed this with the patch on GERONIMO-1518. Originally, I had missed the dependency in project.xml and the files were not copied to target. geronimo/repository/jars/geronimo-javamail-transport-1.0.1- SNAPSHOT.jar geronimo/repository/jars/geronimo-mail-1.0.1-SNAPSHOT.jar What happens if the user initially does not select SMTP transport (the default) in the installer and then after installation changes their mind? How are we expecting the user to get it installed? Interesting question. There are some interesting options here. 1. If one uses the installer in default mode, the situation mentioned will occur. For instance, if javamail is not selected, then it will not be installed and the easiest remedy is a reinstall. 2. If, however, one uses the -Dadvancedmode=true mode of the the installer, then it's possible to install the configuration, but have it inactive at runtime. It'll be in the config, but not running in the server. Of course, with item #1, it's possible to install everything and disable unwanted items in config.xml manually and achieve the same goal. 3. There's actually a third option that's not exposed well (yet?). One might install everything with the advanced installer then delete everything in config-store, modify configure.xml, run ConfigInstaller to get a new configuration and modify config.xml accordingly. Of course, this would be for very advanced folks. Due to my theory about (1), I think that these are simply left out of the installers internal repo and so the mail config may not work. As noted in (1) in my opinion these should get copied into the server under construction only if you select the mail configuration for installation. 1518 accomplishes this. thanks david jencks Thanks, John -- Regards, Erik
[jira] Created: (GERONIMO-1567) Plan XML files aren't included in Geronimo distributions (was included in M5 release)
Plan XML files aren't included in Geronimo distributions (was included in M5 release) - Key: GERONIMO-1567 URL: http://issues.apache.org/jira/browse/GERONIMO-1567 Project: Geronimo Type: Bug Components: buildsystem, usability Versions: 1.0 Reporter: John Sisson Fix For: 1.0.1, 1.1 It was a combination of an oversight and the idea that being able to add gbeans using config.xml could replace the need to modify and redeploy the plans we supply. -- 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
Request for excellent references
Hi all Sorry when i am buging you for a trivial question like mine, but I think if we succeed serviceMix will also profit. I am looking for excellent references of ServiceMix installations. We proposed to one of our customer, to use ServiceMix as SOA-Layer but he would also be shure that his investment is not going to support a technology which will soon disappear. I know that this is not going to happen because of large community which ServiceMix already has. But it would help a lot to make our customer feel more comfortable if we could show him that there is other company using ServiceMix (even on mission critical installations). If you could provide some reference in the following business-fields: - banking - insurance - newspaper - commerce it would help a lot. BTW: On my opinion it would be great if it would be manageable to post some information on the ServiceMix web-site. thanks and regards Massimo -- OTEGO AG Tel: +41 (0)1 240 00 55 Massimo Sonego, Fax: +41 (0)1 240 00 56 CEO / Eidg. dipl. Wirtschaftsinf. Mobile: +41 (0)79 262 21 00 Hohlstrasse 216 Skype : massimo_sonego CH-8004 ZürichMailto: [EMAIL PROTECTED] Web: http://www.otego.com Otego AG is a founding member of Orixo, the XML business alliance - http://www.orixo.com
Re: [jira] Created: (GERONIMO-1567) Plan XML files aren't included in Geronimo distributions (was included in M5 release)
I seem to remember some discussion as to whether the plan files should be placed in the car files. Would this be instead of having a geronimo\doc\plan directory (in the M5 release) or in addition to it? John John Sisson (JIRA) wrote: Plan XML files aren't included in Geronimo distributions (was included in M5 release) - Key: GERONIMO-1567 URL: http://issues.apache.org/jira/browse/GERONIMO-1567 Project: Geronimo Type: Bug Components: buildsystem, usability Versions: 1.0 Reporter: John Sisson Fix For: 1.0.1, 1.1 It was a combination of an oversight and the idea that being able to add gbeans using config.xml could replace the need to modify and redeploy the plans we supply.
Unit tests off? [was: svn commit: r357837]
On 12/19/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: gregw Date: Mon Dec 19 15:50:23 2005 New Revision: 357837 URL: http://svn.apache.org/viewcvs?rev=357837view=rev Log: merged r355806 from 1.0 branch to make new the default target Modified: geronimo/trunk/BUILDING.txt geronimo/trunk/maven.xml geronimo/trunk/project.properties == --- geronimo/trunk/project.properties (original) +++ geronimo/trunk/project.properties Mon Dec 19 15:50:23 2005 @@ -22,8 +22,8 @@ #module.excludes=axis #maven.test.failure.ignore=true -#maven.test.skip=true -#maven.itest.skip=true +maven.test.skip=true +maven.itest.skip=true maven.remote.group=apcvs #multiproject properties Looks like the unit tests have been off since Dec 19th. -dain
Re: Request for excellent references
Hi, Massimo! As long as you don't plan to write plenty of your own JBI-components there are no visible investments you make into the ServiceMix (besides the time spent for learning curve). It does not restrict you to particular technology/protocol or vendor solution, it also does not change your code at all. As to me I consider ServiceMix as a glue that binds services in a much more flexible way. ServiceMix is able to take almost anything you want and then expose it as a service. MS Sorry when i am buging you for a trivial question like mine, but I think MS if we succeed serviceMix will also profit. MS I am looking for excellent references of ServiceMix installations. MS We proposed to one of our customer, to use ServiceMix as SOA-Layer but MS he would also be shure that his investment is not going to support a MS technology which will soon disappear. I know that this is not going to MS happen because of large community which ServiceMix already has. But it MS would help a lot to make our customer feel more comfortable if we could MS show him that there is other company using ServiceMix (even on mission MS critical installations). MS If you could provide some reference in the following business-fields: MS - banking MS - insurance MS - newspaper MS - commerce MS it would help a lot. MS BTW: MS On my opinion it would be great if it would be manageable to post some MS information on the ServiceMix web-site. MS thanks and regards MS Massimo Èëüÿ Êóëåøîâ, êîìïàíèÿ NAUMEN, +7 (343) 378-31-76*2585 +7 (343) 376-30-53
Re: EJB Server Portlet / OpenEJB Stats
I can help you with the portlet side of this; the trick is going to be getting the statistics out of OpenEJB. Once we figure that out, we can create an API around it and call that from the portlet. The best way to go would be to create JSR-77 objects for the EJBs, and then give them JSR-77 statistics objects. There was recently talk of creating JSR-77 wrappers for Tomcat servlets I think, so if you can look into what was done there, maybe it will translate well to wrapping EJBs in OpenEJB... Thanks, Aaron On 2/1/06, Chris Cardona [EMAIL PROTECTED] wrote: Hi All, I'm interested on creating an EJB Server Portlet to show some statistics (e.g. bean count of the different bean types) about the EJB Server/Container and if possible allow a user to make some basic configuration changes. I'm not sure if this is currently supported by Geronimo. Any help, tips, or info where to start looking will be very helpful. Thanks, Chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: help needed regarding to org.activemq.network.jms package
Fan Li, you can explicitly set the local ConnectionFactory on the JmsTopicConnector/JmsQueueConnector - and use the JndiTemplate for initializing the foreign JMS provider. The JmsMessageConvertor doc is misleading in it's description - for inbound messages it will expect foreign JMS - ActiveMQ and outbound ActiveMQ - JMS. The JMS specification states that a JMS message provider should be able to convert a foreign JMS Message if one is used - so this interface is only there if special marshaling is required. cheers, Rob On 1 Feb 2006, at 12:55, Rob Davies wrote: Hi Fan Li, it's great to get some feedback on this! I'm sure we can fix your issues pretty quickly. Would you mind raising a jira issue on this ? That way I won't forget about cheers, Rob First of all, my apologies for spamming your e-mail account, but I am looking for help from any ActiveMQ developer who can help me answer a couple of questions. I am currently working on a Project that would help our company to switch our existing messaging applications to used ActiveMQ instead of our own messaging system that is based on Rendezvous. My project has to do with creating a bridge that enables the communication of applications written using our messaging system to those applications written using ActiveMQ. After looking at ActiveMQ source code, I discovered a package, org.activemq.network.jms in the activemq-core/src/main/java directory, and it seems to provide the bridge functionalities I am looking for. However, when I was trying to test out the code in this package I run into a problem. The init() method in JmsTopicConnector class calls the methods initializeForeignTopicConnection() and initializeLocalTopicConnection() to set the appropriate ConnectionFactory and Connection by look them up from the JndiTemplate object of the class. The JndiTemplate object does object lookup using a Context object that is created by the implementation of InitialContextFactroy associated with java.naming.factory.initial. This is a problem because different JMS implementations have different InitialContextFactory classes, therefore it is not possible for one implementation of InitialContextFactory to create Context object that is capable of looking up objects implemented by two different JMS providers. Unless the association between java.naming.factory.initial and the InitialContextFactory can be changed between the invocation of initializeForeignTopicConnection() and initializeLocalTopicConnection(), which would require code change in the JmsTopicConnector class. Does anyone know a way to work around this problem? Also, I need a bit of clarification on the description for the JmsMesageConvertor interface. The Java doc for the convert method of this interface says that the method is used to Convert a foreign JMS Message to a native ActiveMQ Message, but should it also be used to perform the reverse conversion, which is to convert from a native ActiveMQ Message to a foreign JMS Message or is there a different interface that takes care of it? Thank you Fan Li
Re: XML plan files not included in distributions
Yes, I would really like to see the original plans in the doc for reference. I think it will be helpful and good reference for those people who need to override Gbeans in the config.xml. Jeff Bruce Snyder wrote: On 1/31/06, John Sisson [EMAIL PROTECTED] wrote: Is there a reason why we no longer ship the XML plan files in the distributions? In the M5 release (when we were using modules/assembly) we included them in the geronimo\doc\plan directory. I haven't been able to find a JIRA for this, but seem to remember someone discussing it recently. I just discovered this the other day and as far as I can tell, it was just not considered before shipping 1.0. Call it an oversight. But there's no time like the present for fixing it. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: servicemix usage
On 1 Feb 2006, at 13:20, Ilya Kuleshov wrote: Hi, I'd like to clarify my understanding about the ServiceMix usage. ESB is frequently referred as a central part of the universe that is responsible for all communications happening in the distributed system. Unfortunately, it does not seem to be a good idea to call all my services through an ESB. Let's say I have a distributed system with a few standalone components, each of them maintains a bunch of SOAP services. Why should I plug them to the ESB? Instead, I'd like to discover those services through UDDI and consume them directly from my application. ServiceMix is definitely useful in the following cases: 1) When I need to plug the legacy application and expose it as a service. 2) When some of my native services have to be replaced with third-party services without causing an impact to my existing applications. Then I plug those new services to ESB and set up transformation rules so that my new service look like the old one. 3) When I'd like to consume some service who speaks protocol A through the protocol B. Then ESB does impedance matching. 4) When I need automatic routing for the service calls and document transformations. This list can be easily extended but still do you think that ESB should be a central part of the distributed system? Like many things in IT it all depends on what your requirements are. Some folks use an ESB when they just need reliable messaging, auditing, smart routing, mediation, orchestration, transformation or legacy integration. I think increasingly folks are going to use an ESB increasingly to be able to monitor service activity, Service Level Agreements and performance of services (kinda like BAM) in which case there's an added bonus for having the ESB be inside the flow of the application. But I don't think an ESB has to be inside the flow of every distributed system; use the right tool for the job and use an ESB when it makes sense. James --- http://radio.weblogs.com/0112098/
Re: Roadmap, tasks and things to do?
Before all these great ideas get lost in the mailing list, I would like to add them to wiki. There is a RoadMap page, I would like to rename it to Features or something similar. Add a Roadmap and things to do page. I will list all the ideas along with the name of the originator(s) and hope that they will take time to break up the ideas into manageable work and create Jira issues. Please let me know if there any objections? Thanks Anita --- Bruce Snyder [EMAIL PROTECTED] wrote: This is great input from the entire community and I hope the ideas keep coming! I think it would be best if these were all entered as JIRA issues so that they can all be categorized and tracked. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Roadmap, tasks and things to do?
Thanks Anita for taking the initiative...+1 anita kulshreshtha wrote: Before all these great ideas get lost in the mailing list, I would like to add them to wiki. There is a RoadMap page, I would like to rename it to Features or something similar. Add a Roadmap and things to do page. I will list all the ideas along with the name of the originator(s) and hope that they will take time to break up the ideas into manageable work and create Jira issues. Please let me know if there any objections? Thanks Anita --- Bruce Snyder [EMAIL PROTECTED] wrote: This is great input from the entire community and I hope the ideas keep coming! I think it would be best if these were all entered as JIRA issues so that they can all be categorized and tracked. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: differences between installer installation and tomcat/jetty installations
Erik Daughtrey wrote: On Wednesday 01 February 2006 03:09, David Jencks wrote: On Jan 31, 2006, at 9:08 PM, John Sisson wrote: 1) In the 1.0 branch I noticed that an installer installation has geronimo/repository/geronimo/cars directory (containing approx 42 MB of car files) but the tomcat jetty assemblies don't have the car directory. Is this intended? Yes When are car files in the repository used? During final processing, the ConfigInstaller runs which installs the cars associated with the selected packs into the config-store. The ConfigInstaller reads var/config/configure.xml to determine which cars need to be installed. Configure.xml is created by the assembly plugin, but contains variables to be replaced at install time to inform ConfigInstaller of which cars need to be installed. Assuming these aren't needed after installation, can/should these files be deleted by the installer therefore saving 42M? I know diskpace is cheap, though it is one of the measurements that gets used when comparisons are done against other application servers. Does this directory need to be retained when advancedMode is true? I think this is an artifact of the way the installer is working right now, namely including a repo inside it and copying everything into the server under construction, whether or not it is used. I want it to install only the stuff you select. 2) I also noticed that in the installer installation using the default options, the following files (that are installed for the jetty/tomcat assemblies) are not installed: I fixed this with the patch on GERONIMO-1518. Originally, I had missed the dependency in project.xml and the files were not copied to target. geronimo/repository/jars/geronimo-javamail-transport-1.0.1- SNAPSHOT.jar geronimo/repository/jars/geronimo-mail-1.0.1-SNAPSHOT.jar What happens if the user initially does not select SMTP transport (the default) in the installer and then after installation changes their mind? How are we expecting the user to get it installed? Interesting question. There are some interesting options here. 1. If one uses the installer in default mode, the situation mentioned will occur. For instance, if javamail is not selected, then it will not be installed and the easiest remedy is a reinstall. 2. If, however, one uses the -Dadvancedmode=true mode of the the installer, then it's possible to install the configuration, but have it inactive at runtime. It'll be in the config, but not running in the server. Of course, with item #1, it's possible to install everything and disable unwanted items in config.xml manually and achieve the same goal. 3. There's actually a third option that's not exposed well (yet?). One might install everything with the advanced installer then delete everything in config-store, modify configure.xml, run ConfigInstaller to get a new configuration and modify config.xml accordingly. Of course, this would be for very advanced folks. In the future, it may be worth considering late-feature addition. The user can rerun the installer, it detects what is already installed and allows the user to select and install additional components. Of course, I realize that izpack probably doesn't lend itself to this and am not suggesting this for any current release. Just wanted to throw out the idea for the future. For now, option 1 seems fine. Due to my theory about (1), I think that these are simply left out of the installers internal repo and so the mail config may not work. As noted in (1) in my opinion these should get copied into the server under construction only if you select the mail configuration for installation. 1518 accomplishes this. thanks david jencks Thanks, John
Re: EJB Server Portlet / OpenEJB Stats
--- Aaron Mulder [EMAIL PROTECTED] wrote: I can help you with the portlet side of this; the trick is going to be getting the statistics out of OpenEJB. Once we figure that out, we can create an API around it and call that from the portlet. The best way to go would be to create JSR-77 objects for the EJBs, and then give them JSR-77 statistics objects. There was recently talk of creating JSR-77 wrappers for Tomcat servlets I think, so if you can look into what was done there, maybe it will translate well to wrapping EJBs in OpenEJB... EJB (jsr-77) object should already be there. Could an EJB expert please confirm (deny) that? G-1293 has patches attached for the Stats part. You can use that as a starting point. Thnaks Anita Thanks, Aaron On 2/1/06, Chris Cardona [EMAIL PROTECTED] wrote: Hi All, I'm interested on creating an EJB Server Portlet to show some statistics (e.g. bean count of the different bean types) about the EJB Server/Container and if possible allow a user to make some basic configuration changes. I'm not sure if this is currently supported by Geronimo. Any help, tips, or info where to start looking will be very helpful. Thanks, Chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (GERONIMO-1568) Installer - Have ConfigInstaller optionally delete CARs after configuration is complete.
Installer - Have ConfigInstaller optionally delete CARs after configuration is complete. Key: GERONIMO-1568 URL: http://issues.apache.org/jira/browse/GERONIMO-1568 Project: Geronimo Type: Improvement Components: installer Versions: 1.1, 1.0.1 Reporter: erik daughtrey -- 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: differences between installer installation and tomcat/jetty installations
On Wednesday 01 February 2006 08:53, Dave Colasurdo wrote: Erik Daughtrey wrote: On Wednesday 01 February 2006 03:09, David Jencks wrote: On Jan 31, 2006, at 9:08 PM, John Sisson wrote: 1) In the 1.0 branch I noticed that an installer installation has geronimo/repository/geronimo/cars directory (containing approx 42 MB of car files) but the tomcat jetty assemblies don't have the car directory. Is this intended? Yes When are car files in the repository used? During final processing, the ConfigInstaller runs which installs the cars associated with the selected packs into the config-store. The ConfigInstaller reads var/config/configure.xml to determine which cars need to be installed. Configure.xml is created by the assembly plugin, but contains variables to be replaced at install time to inform ConfigInstaller of which cars need to be installed. Assuming these aren't needed after installation, can/should these files be deleted by the installer therefore saving 42M? I know diskpace is cheap, though it is one of the measurements that gets used when comparisons are done against other application servers. Already thinking about this. I was thinking that the ConfigInstaller could have an option to delete the cars when it's done. For the default install, this would be true always. JIRA 1568. I think DJ is probably glad we've gotten to the point where we can consider these cleanup options :) Does this directory need to be retained when advancedMode is true? For the advancedmode install, deletion of the cars could be an option. All this could be done with a new panel which queries for a disposition of the CAR files post install. Of course, the panel needs to explain that only CAR files for options actually installed will be available for use. Until we have a good way to use these CAR files after and install, it probably doesn't make sense to add this. I think this is an artifact of the way the installer is working right now, namely including a repo inside it and copying everything into the server under construction, whether or not it is used. I want it to install only the stuff you select. 2) I also noticed that in the installer installation using the default options, the following files (that are installed for the jetty/tomcat assemblies) are not installed: I fixed this with the patch on GERONIMO-1518. Originally, I had missed the dependency in project.xml and the files were not copied to target. geronimo/repository/jars/geronimo-javamail-transport-1.0.1- SNAPSHOT.jar geronimo/repository/jars/geronimo-mail-1.0.1-SNAPSHOT.jar What happens if the user initially does not select SMTP transport (the default) in the installer and then after installation changes their mind? How are we expecting the user to get it installed? Interesting question. There are some interesting options here. 1. If one uses the installer in default mode, the situation mentioned will occur. For instance, if javamail is not selected, then it will not be installed and the easiest remedy is a reinstall. 2. If, however, one uses the -Dadvancedmode=true mode of the the installer, then it's possible to install the configuration, but have it inactive at runtime. It'll be in the config, but not running in the server. Of course, with item #1, it's possible to install everything and disable unwanted items in config.xml manually and achieve the same goal. 3. There's actually a third option that's not exposed well (yet?). One might install everything with the advanced installer then delete everything in config-store, modify configure.xml, run ConfigInstaller to get a new configuration and modify config.xml accordingly. Of course, this would be for very advanced folks. In the future, it may be worth considering late-feature addition. The user can rerun the installer, it detects what is already installed and allows the user to select and install additional components. Of course, I realize that izpack probably doesn't lend itself to this and am not suggesting this for any current release. Just wanted to throw out the idea for the future. For now, option 1 seems fine. Yes, as the installer matures, these types of features should be considered. I'd also like to see us build an online installer. Coupling an online capability with the ability to add new features would make this even more powerful. Additionally, an online installer could allow for a very small download footprint for the installer. Then the installer would download only what is selected for install. Due to my theory about (1), I think that these are simply left out of the installers internal repo and so the mail config may not work. As noted in (1) in my opinion these should get copied into the server under construction only if you select the mail configuration for installation. 1518 accomplishes this. thanks david jencks
Re: XML plan files not included in distributions
Though personally, I think I'd rather store them in the config store and have an easy routine to get them out of there (using a JSR-77 call like the one that gets the J2EE deployment descriptor)... Some day, I guess. Thanks, Aaron On 2/1/06, Jeff Genender [EMAIL PROTECTED] wrote: Yes, I would really like to see the original plans in the doc for reference. I think it will be helpful and good reference for those people who need to override Gbeans in the config.xml. Jeff Bruce Snyder wrote: On 1/31/06, John Sisson [EMAIL PROTECTED] wrote: Is there a reason why we no longer ship the XML plan files in the distributions? In the M5 release (when we were using modules/assembly) we included them in the geronimo\doc\plan directory. I haven't been able to find a JIRA for this, but seem to remember someone discussing it recently. I just discovered this the other day and as far as I can tell, it was just not considered before shipping 1.0. Call it an oversight. But there's no time like the present for fixing it. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Confluence or Moin Moin...let's put a stake in the heart of this monster.
Guys, I want to update the Release manager doc on the Wiki but it occurred to me today that we have still not resolved the issue of Confluence or MoinMoin. We've been discussing this issue for about 3 months I think but have only succeeded in having created two environments and not pulling together a cohesive story for our users in terms of documentation. Hernan has been doing a great job of documenting on Confluence over at Atlassian and I saw Anita post today that she has graciously volunteered to update the Roadmap (I assume on the current G Wiki). Given that I'm ready to do some updating as well I wanted see what issues are in the way for us moving to a common infrastructure. From the e-mail vote started by Ken here were the votes: + 1 Votes for Confluence Erin Mulder Joe Bohn Dain Sundstrom Alan Cabrera David Jencks Bruce Snyder Jason Dillon Hernan Cunico David Blevins Matt Hogstrom Gianny Damour John Sisson Jacek Laskowski Kevan Miller Prasad Kashyap James Strachan Sachin Patel Paul McMahan +1 Votes for something else Geir +0 Votes: Jan Bartel 7 People volunteered for Infrastructure assignments Andrus Adamchik Hernan Cunico Rajith Atlapatto Jason Dillon Kevan Miller Paul McMahan Prasad Kashyap I apologize in advance for spelling mistakes above. At this point it looks like the clear winner is Confluence. So the question is what do we do from here? What makes sense to me is people do their current work at Atlassian to ease the transition (with appropriate updates on the Geronimo site to point there) and have the volunteers above start introducing themselves to the Infrastructure group and building some Karma to get Confluence setup (remembering that this is more than a Geronimo thing in terms of support; details to get worked out by infrastructure). Ken, do we need to do anything formal or can people start working with Infra now? It would seem to make sense to have one person coordinate the effort from the Geronimo side to start with. I nominate Hernan since he's been doing the Lion's share of our documentation. For now I'll move my Release Mgmt work over to Atlassian. Cheers. Matt
Integrating Geronimo and Celtix
Hi there, I am a member of the Celtix [1] development team and am currently looking at integrating Celtix into different J2EE containers. The idea is that Celtix would provide a web service stack for applications deployed in Geronimo. I've started looking at the Geronimo code-base and the WebServiceContainer piece in particular. I'm just really in the process of familiarising myself with the code and have two initial questions (I'm sure more will follow!) 1. Are there any design docs for the WebService container and how interacts with the deployer and the other containers? Anything to help get more familiar with this part of Geronimo would be good. I had a look at Geronimo web site but nothing relevant leapt out at me. 2. What is the plan for JEE 5 support in Geronimo? More specifically, Celtix depends on a bunch of specs (JAX WS 2.0, JAXB 2.0 etc.) that will form part of JEE 5 and are highly dependant on JSE 5 (principally for annotations). Presumably this will be Geronimo 2.0. That said, from reading some of the dev list on the subject it seems that JEE 5 work may be a little way off. In that case it should be possible to work within the current runtime but just requiring that JSE 5 be used. Any tips on getting started at this would be welcomed thanks Conrad [1] http://celtix.objectweb.org/
Re: XML plan files not included in distributions
Aaron, yes...that is a great idea. But then I think we get into opening up the can of worms about the plan files in the config.store matching what is actually running in Geronimo. It would be great to have something that can rebuild a plan from the running configuration, so you can see an accurate snapshot. I would love to jump on this, but my plate is really full right now... Any takers? Otherwise I may be able to get to it in a couple of weeks. In the mean time, would anyone mind if we did bundle the plan files somewhere in G for reference? Jeff Aaron Mulder wrote: Though personally, I think I'd rather store them in the config store and have an easy routine to get them out of there (using a JSR-77 call like the one that gets the J2EE deployment descriptor)... Some day, I guess. Thanks, Aaron On 2/1/06, Jeff Genender [EMAIL PROTECTED] wrote: Yes, I would really like to see the original plans in the doc for reference. I think it will be helpful and good reference for those people who need to override Gbeans in the config.xml. Jeff Bruce Snyder wrote: On 1/31/06, John Sisson [EMAIL PROTECTED] wrote: Is there a reason why we no longer ship the XML plan files in the distributions? In the M5 release (when we were using modules/assembly) we included them in the geronimo\doc\plan directory. I haven't been able to find a JIRA for this, but seem to remember someone discussing it recently. I just discovered this the other day and as far as I can tell, it was just not considered before shipping 1.0. Call it an oversight. But there's no time like the present for fixing it. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: XML plan files not included in distributions
Well, I wasn't going to go that far. Generally speaking, we can't easily reconstruct a plan from a set of GBeans (particularly for plans that use abbreviated XML syntax like for CSS/TSS or login modules). I'd prefer to start with retrieve original deployment plan and get that in there, and then if we want to we can think about stuff like you're describing. (After all, any plan we provided in docs/ wouldn't match the current state of the configuration either...) Thanks, Aaron On 2/1/06, Jeff Genender [EMAIL PROTECTED] wrote: Aaron, yes...that is a great idea. But then I think we get into opening up the can of worms about the plan files in the config.store matching what is actually running in Geronimo. It would be great to have something that can rebuild a plan from the running configuration, so you can see an accurate snapshot. I would love to jump on this, but my plate is really full right now... Any takers? Otherwise I may be able to get to it in a couple of weeks. In the mean time, would anyone mind if we did bundle the plan files somewhere in G for reference? Jeff Aaron Mulder wrote: Though personally, I think I'd rather store them in the config store and have an easy routine to get them out of there (using a JSR-77 call like the one that gets the J2EE deployment descriptor)... Some day, I guess. Thanks, Aaron On 2/1/06, Jeff Genender [EMAIL PROTECTED] wrote: Yes, I would really like to see the original plans in the doc for reference. I think it will be helpful and good reference for those people who need to override Gbeans in the config.xml. Jeff Bruce Snyder wrote: On 1/31/06, John Sisson [EMAIL PROTECTED] wrote: Is there a reason why we no longer ship the XML plan files in the distributions? In the M5 release (when we were using modules/assembly) we included them in the geronimo\doc\plan directory. I haven't been able to find a JIRA for this, but seem to remember someone discussing it recently. I just discovered this the other day and as far as I can tell, it was just not considered before shipping 1.0. Call it an oversight. But there's no time like the present for fixing it. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: [vote] XBean donation
I asked a while ago and I think my question was never answered - why bring XBean into Geronimo? geir Dain Sundstrom wrote: The XBean project has voted to donate all of the code located at https://svn.codehaus.org/xbean (view with fisheye http://cvs.codehaus.org/viewrep/xbean) to Apache Geronimo. The completed IP clearance check list can be found here https://svn.codehaus.org/xbean/xbean-ip-clearance.html [+1/-1/0] Accept the XBean code donation -dain
Re: XML plan files not included in distributions
I know its not easy, but its something I think is important to have at some point. It would be nice to know the current state of Geronimo and have it spit out the configuration or be able to view it. There are many areas where this would be very useful. So maybe one day? ;-) My .02, I would be careful to include the current plans in the config.store or through the console without some sort of disclaimer that says they are the original plans and are not the current state. What do you think? Jeff Aaron Mulder wrote: Well, I wasn't going to go that far. Generally speaking, we can't easily reconstruct a plan from a set of GBeans (particularly for plans that use abbreviated XML syntax like for CSS/TSS or login modules). I'd prefer to start with retrieve original deployment plan and get that in there, and then if we want to we can think about stuff like you're describing. (After all, any plan we provided in docs/ wouldn't match the current state of the configuration either...) Thanks, Aaron On 2/1/06, Jeff Genender [EMAIL PROTECTED] wrote: Aaron, yes...that is a great idea. But then I think we get into opening up the can of worms about the plan files in the config.store matching what is actually running in Geronimo. It would be great to have something that can rebuild a plan from the running configuration, so you can see an accurate snapshot. I would love to jump on this, but my plate is really full right now... Any takers? Otherwise I may be able to get to it in a couple of weeks. In the mean time, would anyone mind if we did bundle the plan files somewhere in G for reference? Jeff Aaron Mulder wrote: Though personally, I think I'd rather store them in the config store and have an easy routine to get them out of there (using a JSR-77 call like the one that gets the J2EE deployment descriptor)... Some day, I guess. Thanks, Aaron On 2/1/06, Jeff Genender [EMAIL PROTECTED] wrote: Yes, I would really like to see the original plans in the doc for reference. I think it will be helpful and good reference for those people who need to override Gbeans in the config.xml. Jeff Bruce Snyder wrote: On 1/31/06, John Sisson [EMAIL PROTECTED] wrote: Is there a reason why we no longer ship the XML plan files in the distributions? In the M5 release (when we were using modules/assembly) we included them in the geronimo\doc\plan directory. I haven't been able to find a JIRA for this, but seem to remember someone discussing it recently. I just discovered this the other day and as far as I can tell, it was just not considered before shipping 1.0. Call it an oversight. But there's no time like the present for fixing it. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: [result] [vote] XBean donation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: Vote passed with: +1 Jeff Genender, Alan Cabrera, Sachin Patel, Dain Sundstrom, David Blevins, Andy Piper, Aaron Mulder, Davanum Srinivas, Jacek Laskowski, Bruce Snyder, Jason Dillion, Gianny Damour, John Sission, David Jencks, James Strachan No -1s I'll file the paperwork with the incubator and import later today. Less than 50 of the committers have voted, but 72 hours have passed since the vote was called. Does anyone wish to extend the vote longer? - -- #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 iQCVAwUBQ+DcnJrNPMCpn3XdAQI/fQP/dRDczuJf2dKzTTrdnIsY/M9zNaAI7MG0 CRkS4iO8b7aqOzaeNwDt4ZoKGm19jnprHMyC4srqecC6rXi/Kk3VONrWOj7mUY8I aOqQGwMrgkC8EIK12fKGbBlg7yTojkN3xfgETA4SCDU58W94eh+zQziybqmepJ93 DQiAMXGlJgI= =Lg5M -END PGP SIGNATURE-
Re: XML plan files not included in distributions
Sure, I'm fine with a disclaimer. :) I think the JSR-77 method to get the plan may be a little generic, but then we can have a dump config tool that will spit out XML to the command line or to a file or whatever and that one would give you a little warning when you invoke it. It might also be possible to flag when the configurations were modified so we could tell if the plan was accurate (modified = deployed then accurate, modified deployed then not accurate). Thanks, Aaron On 2/1/06, Jeff Genender [EMAIL PROTECTED] wrote: I know its not easy, but its something I think is important to have at some point. It would be nice to know the current state of Geronimo and have it spit out the configuration or be able to view it. There are many areas where this would be very useful. So maybe one day? ;-) My .02, I would be careful to include the current plans in the config.store or through the console without some sort of disclaimer that says they are the original plans and are not the current state. What do you think? Jeff Aaron Mulder wrote: Well, I wasn't going to go that far. Generally speaking, we can't easily reconstruct a plan from a set of GBeans (particularly for plans that use abbreviated XML syntax like for CSS/TSS or login modules). I'd prefer to start with retrieve original deployment plan and get that in there, and then if we want to we can think about stuff like you're describing. (After all, any plan we provided in docs/ wouldn't match the current state of the configuration either...) Thanks, Aaron On 2/1/06, Jeff Genender [EMAIL PROTECTED] wrote: Aaron, yes...that is a great idea. But then I think we get into opening up the can of worms about the plan files in the config.store matching what is actually running in Geronimo. It would be great to have something that can rebuild a plan from the running configuration, so you can see an accurate snapshot. I would love to jump on this, but my plate is really full right now... Any takers? Otherwise I may be able to get to it in a couple of weeks. In the mean time, would anyone mind if we did bundle the plan files somewhere in G for reference? Jeff Aaron Mulder wrote: Though personally, I think I'd rather store them in the config store and have an easy routine to get them out of there (using a JSR-77 call like the one that gets the J2EE deployment descriptor)... Some day, I guess. Thanks, Aaron On 2/1/06, Jeff Genender [EMAIL PROTECTED] wrote: Yes, I would really like to see the original plans in the doc for reference. I think it will be helpful and good reference for those people who need to override Gbeans in the config.xml. Jeff Bruce Snyder wrote: On 1/31/06, John Sisson [EMAIL PROTECTED] wrote: Is there a reason why we no longer ship the XML plan files in the distributions? In the M5 release (when we were using modules/assembly) we included them in the geronimo\doc\plan directory. I haven't been able to find a JIRA for this, but seem to remember someone discussing it recently. I just discovered this the other day and as far as I can tell, it was just not considered before shipping 1.0. Call it an oversight. But there's no time like the present for fixing it. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: XML plan files not included in distributions
On 2/1/06, Aaron Mulder [EMAIL PROTECTED] wrote: Well, I wasn't going to go that far. Generally speaking, we can't easily reconstruct a plan from a set of GBeans (particularly for plans that use abbreviated XML syntax like for CSS/TSS or login modules). I'd prefer to start with retrieve original deployment plan and get that in there, and then if we want to we can think about stuff like you're describing. (After all, any plan we provided in docs/ wouldn't match the current state of the configuration either...) IMO, it's a problem that constucting a plan from the running configurations is so difficult. I'm not sure exactly if this is an issue with the builders or with the GBean architecture or both. But I wonder if use of the XBean kernel would facilitate this functionality? I have spoken with Dain about this very functionality but I can't recall where our conversation ended. As for including the default plans in the binary, I say put them in the docs dir. I don't think I want to require that the deployer be used to extract a plan and I certainly don't want to advise users to monkey around in the config-store. Why make access to the plans any more difficult than opening them from the docs directory in a text editor? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: XML plan files not included in distributions
On 2/1/06, Bruce Snyder [EMAIL PROTECTED] wrote: IMO, it's a problem that constucting a plan from the running configurations is so difficult. I'm not sure exactly if this is an issue with the builders or with the GBean architecture or both. But I wonder if use of the XBean kernel would facilitate this functionality? I have spoken with Dain about this very functionality but I can't recall where our conversation ended. Well, take a web or EJB plan. It may include next to nothing. However, if there are a lot of servlets or session beans or whatever, there could be loads of GBeans generated. So if you look at this set of 57 GBeans, it's hard to reduce that to the minimalist possible deployment plan. For server plans, many GBeans have complex configuration settings that should be easier to reverse out with XBean than with the current kernel. But even then, a set of 10 security-related beans could be represented as an ugly plan with 10 GBean entries or a nice plan with 1 GBean including a nested XML configuration block. Which do you produce? How do you tell when the complexity of the raw GBeans exceeds what can be represented by the pretty-looking nested XML block? Do we insist that every XML configurer also includes a deconfigurer that accepts an arbitrary set of GBeans (or just a Kernel) and backs out what the XML plan should be? I don't like that, but I also don't like always returning the big ugly format instead of the nice XML format. As for including the default plans in the binary, I say put them in the docs dir. I don't think I want to require that the deployer be used to extract a plan and I certainly don't want to advise users to monkey around in the config-store. Why make access to the plans any more difficult than opening them from the docs directory in a text editor? Because it's easier to automate. If we save the plans in the config store during deployment, it's 100% guaranteed that they'll be there, even if we forget to run some particular step while preparing a release. Also, once they're in there, we can potentially add an extract plan operation to the Maven deployment plugin, which means we can have our assembly script automatically pull them out into the docs dir if you feel strongly. Aaron
Re: [result] [vote] XBean donation
I was sick and traveling the past few days, so I missed the whole vote. I'm not necessarily against it, but worried about pointless growth - my only question is why bring this in? It's good code and all, but normally we try to draw some line between the existing project's goals and what the addition does. Maybe I missed the discussion before the vote... geir Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: Vote passed with: +1 Jeff Genender, Alan Cabrera, Sachin Patel, Dain Sundstrom, David Blevins, Andy Piper, Aaron Mulder, Davanum Srinivas, Jacek Laskowski, Bruce Snyder, Jason Dillion, Gianny Damour, John Sission, David Jencks, James Strachan No -1s I'll file the paperwork with the incubator and import later today. Less than 50 of the committers have voted, but 72 hours have passed since the vote was called. Does anyone wish to extend the vote longer? - -- #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 iQCVAwUBQ+DcnJrNPMCpn3XdAQI/fQP/dRDczuJf2dKzTTrdnIsY/M9zNaAI7MG0 CRkS4iO8b7aqOzaeNwDt4ZoKGm19jnprHMyC4srqecC6rXi/Kk3VONrWOj7mUY8I aOqQGwMrgkC8EIK12fKGbBlg7yTojkN3xfgETA4SCDU58W94eh+zQziybqmepJ93 DQiAMXGlJgI= =Lg5M -END PGP SIGNATURE-
RE: Integrating Geronimo and Celtix
Great idea conrad. Since Celtix is an ESB, integrating it into a JEE container would provide support for all of the ESB capabilities for all of J2EE based endpoints and not just webservices capabilities. This can even provide support for multi transport and multi binding capabilities to J2EE endpoints including JMS, CORBA etc. One question, does your integration is going to leverage some of the capabilities of JSR 181 for JEE based endpoints along with JAX-WS 2.0 etc. My feeling would be to get started with the integration based on current runtime making JSE 1.5 as requirement for enabling Celtix. cheers, Adi Sakala -Original Message- From: O'Dea, Conrad Sent: Wednesday, February 01, 2006 10:32 AM To: dev@geronimo.apache.org Subject: Integrating Geronimo and Celtix Hi there, I am a member of the Celtix [1] development team and am currently looking at integrating Celtix into different J2EE containers. The idea is that Celtix would provide a web service stack for applications deployed in Geronimo. I've started looking at the Geronimo code-base and the WebServiceContainer piece in particular. I'm just really in the process of familiarising myself with the code and have two initial questions (I'm sure more will follow!) 1. Are there any design docs for the WebService container and how interacts with the deployer and the other containers? Anything to help get more familiar with this part of Geronimo would be good. I had a look at Geronimo web site but nothing relevant leapt out at me. 2. What is the plan for JEE 5 support in Geronimo? More specifically, Celtix depends on a bunch of specs (JAX WS 2.0, JAXB 2.0 etc.) that will form part of JEE 5 and are highly dependant on JSE 5 (principally for annotations). Presumably this will be Geronimo 2.0. That said, from reading some of the dev list on the subject it seems that JEE 5 work may be a little way off. In that case it should be possible to work within the current runtime but just requiring that JSE 5 be used. Any tips on getting started at this would be welcomed thanks Conrad [1] http://celtix.objectweb.org/
Re: Integrating Geronimo and Celtix
On 1 Feb 2006, at 16:33, Sakala, Adinarayana wrote: Great idea conrad. Since Celtix is an ESB, integrating it into a JEE container would provide support for all of the ESB capabilities for all of J2EE based endpoints and not just webservices capabilities. This can even provide support for multi transport and multi binding capabilities to J2EE endpoints including JMS, CORBA etc. Agreed. Apache ServiceMix is already integrated into Geronimo to provide these same ESB capabilities using the underlying Geronimo services like HTTP, JMS, JCA etc. One question, does your integration is going to leverage some of the capabilities of JSR 181 for JEE based endpoints along with JAX- WS 2.0 etc. I'd recommend doing so - its what we did on ServiceMix too. I'd also recommend an SCA component as well; On ServiceMix we have a variety of different JBI binding components for different SOAP stacks and integration technologies such as a JSR 181 binding component, an SCA/ Tuscany binding component, a SOAP stack with WS-A support, pure JMS, pure HTTP etc. My feeling would be to get started with the integration based on current runtime making JSE 1.5 as requirement for enabling Celtix. That's your call on the Celtix team as to what dependencies you want to use; though be aware that AFAIK we can only currently integrate Java 1.4 components into the certified build of Geronimo; I'm not sure if we can do a distribution of Geronimo which is not J2EE certified; so any 1.5 dependent components might have to be left out; but then you could host your celtix components on the celtix website. As as aside we've been working with retrotransformer lately - with help from folks on the JAXB2 team and retrotransformer team - we've managed to get retrotransformer to create 1.4 compliant bytecode that uses JAXB2 RI. So there's a chance you could still work around the 1.5 issue http://radio.weblogs.com/0112098/2005/12/29.html#a546 FWIW there's a maven2 retrotranslator plugin James --- http://radio.weblogs.com/0112098/
EJB Server Portlet / OpenEJB Stats
Thanks Aaron, I'll start looking into JSR-77 and the Tomcat servlet wrappers (G-1293). I'll let you know how it goes and if I have questions. BTW, I created this reply in another thread because my original email ended up in different thread. My mistake :) chris --- Aaron Mulder [EMAIL PROTECTED] wrote: I can help you with the portlet side of this; the trick is going to be getting the statistics out of OpenEJB. Once we figure that out, we can create an API around it and call that from the portlet. The best way to go would be to create JSR-77 objects for the EJBs, and then give them JSR-77 statistics objects. There was recently talk of creating JSR-77 wrappers for Tomcat servlets I think, so if you can look into what was done there, maybe it will translate well to wrapping EJBs in OpenEJB... EJB (jsr-77) object should already be there. Could an EJB expert please confirm (deny) that? G-1293 has patches attached for the Stats part. You can use that as a starting point. Thnaks Anita Thanks, Aaron On 2/1/06, Chris Cardona [EMAIL PROTECTED] wrote: Hi All, I'm interested on creating an EJB Server Portlet to show some statistics (e.g. bean count of the different bean types) about the EJB Server/Container and if possible allow a user to make some basic configuration changes. I'm not sure if this is currently supported by Geronimo. Any help, tips, or info where to start looking will be very helpful. Thanks, Chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: Integrating Geronimo and Celtix
James Any idea on the timeline for integrating Java 1.5 components, we might run into this on the CORBA side also so it would be good to know. Carl. -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 01, 2006 11:55 AM To: dev@geronimo.apache.org Subject: Re: Integrating Geronimo and Celtix On 1 Feb 2006, at 16:33, Sakala, Adinarayana wrote: Great idea conrad. Since Celtix is an ESB, integrating it into a JEE container would provide support for all of the ESB capabilities for all of J2EE based endpoints and not just webservices capabilities. This can even provide support for multi transport and multi binding capabilities to J2EE endpoints including JMS, CORBA etc. Agreed. Apache ServiceMix is already integrated into Geronimo to provide these same ESB capabilities using the underlying Geronimo services like HTTP, JMS, JCA etc. One question, does your integration is going to leverage some of the capabilities of JSR 181 for JEE based endpoints along with JAX- WS 2.0 etc. I'd recommend doing so - its what we did on ServiceMix too. I'd also recommend an SCA component as well; On ServiceMix we have a variety of different JBI binding components for different SOAP stacks and integration technologies such as a JSR 181 binding component, an SCA/ Tuscany binding component, a SOAP stack with WS-A support, pure JMS, pure HTTP etc. My feeling would be to get started with the integration based on current runtime making JSE 1.5 as requirement for enabling Celtix. That's your call on the Celtix team as to what dependencies you want to use; though be aware that AFAIK we can only currently integrate Java 1.4 components into the certified build of Geronimo; I'm not sure if we can do a distribution of Geronimo which is not J2EE certified; so any 1.5 dependent components might have to be left out; but then you could host your celtix components on the celtix website. As as aside we've been working with retrotransformer lately - with help from folks on the JAXB2 team and retrotransformer team - we've managed to get retrotransformer to create 1.4 compliant bytecode that uses JAXB2 RI. So there's a chance you could still work around the 1.5 issue http://radio.weblogs.com/0112098/2005/12/29.html#a546 FWIW there's a maven2 retrotranslator plugin James --- http://radio.weblogs.com/0112098/
Re: XML plan files not included in distributions
Remember that all the plans are currently called plan.xml I think the only plausible solution for now is to have the packaging plugin copy the plan into META-INF/plan.xml in the car file. This won't catch embedded j2ee plans, but they will probably get copied in while unpacking the j2ee artifact. As for exposing the plans in a jsr-77 friendly way, what gbean would expose the plan for a non-j2ee service configuration that has only gbeans in it? thanks david jencks On Feb 1, 2006, at 8:22 AM, Aaron Mulder wrote: On 2/1/06, Bruce Snyder [EMAIL PROTECTED] wrote: IMO, it's a problem that constucting a plan from the running configurations is so difficult. I'm not sure exactly if this is an issue with the builders or with the GBean architecture or both. But I wonder if use of the XBean kernel would facilitate this functionality? I have spoken with Dain about this very functionality but I can't recall where our conversation ended. Well, take a web or EJB plan. It may include next to nothing. However, if there are a lot of servlets or session beans or whatever, there could be loads of GBeans generated. So if you look at this set of 57 GBeans, it's hard to reduce that to the minimalist possible deployment plan. For server plans, many GBeans have complex configuration settings that should be easier to reverse out with XBean than with the current kernel. But even then, a set of 10 security-related beans could be represented as an ugly plan with 10 GBean entries or a nice plan with 1 GBean including a nested XML configuration block. Which do you produce? How do you tell when the complexity of the raw GBeans exceeds what can be represented by the pretty-looking nested XML block? Do we insist that every XML configurer also includes a deconfigurer that accepts an arbitrary set of GBeans (or just a Kernel) and backs out what the XML plan should be? I don't like that, but I also don't like always returning the big ugly format instead of the nice XML format. As for including the default plans in the binary, I say put them in the docs dir. I don't think I want to require that the deployer be used to extract a plan and I certainly don't want to advise users to monkey around in the config-store. Why make access to the plans any more difficult than opening them from the docs directory in a text editor? Because it's easier to automate. If we save the plans in the config store during deployment, it's 100% guaranteed that they'll be there, even if we forget to run some particular step while preparing a release. Also, once they're in there, we can potentially add an extract plan operation to the Maven deployment plugin, which means we can have our assembly script automatically pull them out into the docs dir if you feel strongly. Aaron
Re: Integrating Geronimo and Celtix
Hi James, Adi, On 1 Feb 2006, at 16:55, James Strachan wrote: On 1 Feb 2006, at 16:33, Sakala, Adinarayana wrote: Great idea conrad. Since Celtix is an ESB, integrating it into a JEE container would provide support for all of the ESB capabilities for all of J2EE based endpoints and not just webservices capabilities. This can even provide support for multi transport and multi binding capabilities to J2EE endpoints including JMS, CORBA etc. Celtix is very pluggable so using it to expose a J2EE service endpoint would allow it use any binding or transport that is available. Agreed. Apache ServiceMix is already integrated into Geronimo to provide these same ESB capabilities using the underlying Geronimo services like HTTP, JMS, JCA etc. One question, does your integration is going to leverage some of the capabilities of JSR 181 for JEE based endpoints along with JAX- WS 2.0 etc. Absolutely. The goal will be that once a Geronimo instance is configured to use Celtix it will be more or less transparent to the J2EE developer. I'd recommend doing so - its what we did on ServiceMix too. I'd also recommend an SCA component as well; On ServiceMix we have a variety of different JBI binding components for different SOAP stacks and integration technologies such as a JSR 181 binding component, an SCA/Tuscany binding component, a SOAP stack with WS-A support, pure JMS, pure HTTP etc. Yes, we are also looking providing support for both SCA and JBI. My feeling would be to get started with the integration based on current runtime making JSE 1.5 as requirement for enabling Celtix. That's your call on the Celtix team as to what dependencies you want to use; though be aware that AFAIK we can only currently integrate Java 1.4 components into the certified build of Geronimo; I'm not sure if we can do a distribution of Geronimo which is not J2EE certified; so any 1.5 dependent components might have to be left out; but then you could host your celtix components on the celtix website. Good info, thanks. As as aside we've been working with retrotransformer lately - with help from folks on the JAXB2 team and retrotransformer team - we've managed to get retrotransformer to create 1.4 compliant bytecode that uses JAXB2 RI. So there's a chance you could still work around the 1.5 issue http://radio.weblogs.com/0112098/2005/12/29.html#a546 FWIW there's a maven2 retrotranslator plugin I had a brief look at retrotransformer. I'd be interested in seeing it a production environment. Thanks for the info. Conrad
Re: [vote] XBean donation
Because it's a great technology that would make my life easier. I encourage you to read the website for more details on the nifty things that it does. Regards, Alan Geir Magnusson Jr wrote, On 2/1/2006 7:53 AM: I asked a while ago and I think my question was never answered - why bring XBean into Geronimo? geir Dain Sundstrom wrote: The XBean project has voted to donate all of the code located at https://svn.codehaus.org/xbean (view with fisheye http://cvs.codehaus.org/viewrep/xbean) to Apache Geronimo. The completed IP clearance check list can be found here https://svn.codehaus.org/xbean/xbean-ip-clearance.html [+1/-1/0] Accept the XBean code donation -dain
RE: help needed regarding to org.activemq.network.jms package
Hi Rob: I have opened an issue at http://jira.activemq.org/jira/browse/AMQ and the Key for the issue is AMQ-520. Based on the current code for the JmsConnector and its subclasses, I think what is needed is probably two JndiTemplate objects, one for creating Foreign ConnectionFactory and one for creating Local ConnectionFactory. Fan -Original Message- From: Rob Davies [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 01, 2006 5:35 AM Cc: Li, Fan; activemq-dev@geronimo.apache.org Subject: Re: help needed regarding to org.activemq.network.jms package Fan Li, you can explicitly set the local ConnectionFactory on the JmsTopicConnector/JmsQueueConnector - and use the JndiTemplate for initializing the foreign JMS provider. The JmsMessageConvertor doc is misleading in it's description - for inbound messages it will expect foreign JMS - ActiveMQ and outbound ActiveMQ - JMS. The JMS specification states that a JMS message provider should be able to convert a foreign JMS Message if one is used - so this interface is only there if special marshaling is required. cheers, Rob On 1 Feb 2006, at 12:55, Rob Davies wrote: Hi Fan Li, it's great to get some feedback on this! I'm sure we can fix your issues pretty quickly. Would you mind raising a jira issue on this ? That way I won't forget about cheers, Rob First of all, my apologies for spamming your e-mail account, but I am looking for help from any ActiveMQ developer who can help me answer a couple of questions. I am currently working on a Project that would help our company to switch our existing messaging applications to used ActiveMQ instead of our own messaging system that is based on Rendezvous. My project has to do with creating a bridge that enables the communication of applications written using our messaging system to those applications written using ActiveMQ. After looking at ActiveMQ source code, I discovered a package, org.activemq.network.jms in the activemq-core/src/main/java directory, and it seems to provide the bridge functionalities I am looking for. However, when I was trying to test out the code in this package I run into a problem. The init() method in JmsTopicConnector class calls the methods initializeForeignTopicConnection() and initializeLocalTopicConnection() to set the appropriate ConnectionFactory and Connection by look them up from the JndiTemplate object of the class. The JndiTemplate object does object lookup using a Context object that is created by the implementation of InitialContextFactroy associated with java.naming.factory.initial. This is a problem because different JMS implementations have different InitialContextFactory classes, therefore it is not possible for one implementation of InitialContextFactory to create Context object that is capable of looking up objects implemented by two different JMS providers. Unless the association between java.naming.factory.initial and the InitialContextFactory can be changed between the invocation of initializeForeignTopicConnection() and initializeLocalTopicConnection(), which would require code change in the JmsTopicConnector class. Does anyone know a way to work around this problem? Also, I need a bit of clarification on the description for the JmsMesageConvertor interface. The Java doc for the convert method of this interface says that the method is used to Convert a foreign JMS Message to a native ActiveMQ Message, but should it also be used to perform the reverse conversion, which is to convert from a native ActiveMQ Message to a foreign JMS Message or is there a different interface that takes care of it? Thank you Fan Li
Re: [result] [vote] XBean donation
Geir Magnusson Jr wrote, On 2/1/2006 8:24 AM: I was sick and traveling the past few days, so I missed the whole vote. I'm not necessarily against it, but worried about pointless growth - my only question is why bring this in? It's good code and all, but normally we try to draw some line between the existing project's goals and what the addition does. Maybe I missed the discussion before the vote... IIRC, Dain brought this up last year. Integrating XBean into Geronimo will bring in many great features that I am eager to start using in Geronimo; it does not fall in the classification of pointless growth. I am happy to see the technology that will make my life easier brought in. Regards, Alan
Re: itests patch
Why not connect to the datasource provided by the system-database ? I thought that replaced default-database. Cheers Prasad On 2/1/06, David Jencks [EMAIL PROTECTED] wrote: On Jan 31, 2006, at 8:53 PM, Dain Sundstrom wrote: The test application doesn't start for me because Geronimo no longer has a DefaultDatasource :( Anyone know how to easily get one of these into the server (and don't tell me to use the console since this is an automated test)? I'd suggest following the example of juddi, daytrader, etc etc and building a database and installing a datasource with the itest app. david jencks -dain On Jan 31, 2006, at 1:59 PM, Prasad Kashyap wrote: David, The itests infrastructure now works fine but the tests themselves fail with 2 errors. The setup, test execution and teardown all work fine now. While I tackle the failing tests next, for now may I submit these patches for you to commit to the openejb project ? Cheers Prasad itest.patches.txt
Re: Integrating Geronimo and Celtix
On 1 Feb 2006, at 17:42, Conrad O'Dea wrote: As as aside we've been working with retrotransformer lately - with help from folks on the JAXB2 team and retrotransformer team - we've managed to get retrotransformer to create 1.4 compliant bytecode that uses JAXB2 RI. So there's a chance you could still work around the 1.5 issue http://radio.weblogs.com/0112098/2005/12/29.html#a546 FWIW there's a maven2 retrotranslator plugin I had a brief look at retrotransformer. I'd be interested in seeing it a production environment. Its mostly a build-time tool. The only thing which is used in production is backport-util-concurrent for any java.util.concurrent code you use and a small retrotranslator-runtime library which backports the annotation lookup code (currently using ASM) together with a few extra helper methods required for the bytecode transformation (such as some reflection/generics helper methods). James --- http://radio.weblogs.com/0112098/
Re: [result] [vote] XBean donation
Rodent of Unusual Size wrote, On 2/1/2006 8:06 AM: Dain Sundstrom wrote: Vote passed with: +1 Jeff Genender, Alan Cabrera, Sachin Patel, Dain Sundstrom, David Blevins, Andy Piper, Aaron Mulder, Davanum Srinivas, Jacek Laskowski, Bruce Snyder, Jason Dillion, Gianny Damour, John Sission, David Jencks, James Strachan No -1s I'll file the paperwork with the incubator and import later today. Less than 50 of the committers have voted, but 72 hours have passed since the vote was called. Does anyone wish to extend the vote longer? I think that it is always understood that some contributors will be inactive. If some form of quorum was required then we would have to institute a policy of assigning certain members an emeritus status. These policies have not been put in place at Geronimo at the time of this vote. We always have the capability of removing the code, actually any code for that matter, at a later time. I think that the vote should be concluded. Regards, Alan
Re: [vote] XBean donation
On 1 Feb 2006, at 15:53, Geir Magnusson Jr wrote: I asked a while ago and I think my question was never answered - why bring XBean into Geronimo? ActiveMQ, Jetty, OpenEJB, ServiceMix are all using it as an optional lightweight kernel for efficient and concise configuration and deployment in Spring-ish ways. It is a very useful core piece of technology and quite a lot of us are pretty excited to work with it in Geronimo James --- http://radio.weblogs.com/0112098/
Re: Confluence or Moin Moin...let's put a stake in the heart of this monster.
Hi Matt, there is a new section on confluence called *Apache Geronimo Development Process* http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+Development+Process There you will find some initial structure to get all the Geronimo Project related processes organized. If you find trouble updating on confluence, pls let me know and I'll give you a hand. Cheers! Hernan Matt Hogstrom wrote: Guys, I want to update the Release manager doc on the Wiki but it occurred to me today that we have still not resolved the issue of Confluence or MoinMoin. We've been discussing this issue for about 3 months I think but have only succeeded in having created two environments and not pulling together a cohesive story for our users in terms of documentation. Hernan has been doing a great job of documenting on Confluence over at Atlassian and I saw Anita post today that she has graciously volunteered to update the Roadmap (I assume on the current G Wiki). Given that I'm ready to do some updating as well I wanted see what issues are in the way for us moving to a common infrastructure. From the e-mail vote started by Ken here were the votes: + 1 Votes for Confluence Erin Mulder Joe Bohn Dain Sundstrom Alan Cabrera David Jencks Bruce Snyder Jason Dillon Hernan Cunico David Blevins Matt Hogstrom Gianny Damour John Sisson Jacek Laskowski Kevan Miller Prasad Kashyap James Strachan Sachin Patel Paul McMahan +1 Votes for something else Geir +0 Votes: Jan Bartel 7 People volunteered for Infrastructure assignments Andrus Adamchik Hernan Cunico Rajith Atlapatto Jason Dillon Kevan Miller Paul McMahan Prasad Kashyap I apologize in advance for spelling mistakes above. At this point it looks like the clear winner is Confluence. So the question is what do we do from here? What makes sense to me is people do their current work at Atlassian to ease the transition (with appropriate updates on the Geronimo site to point there) and have the volunteers above start introducing themselves to the Infrastructure group and building some Karma to get Confluence setup (remembering that this is more than a Geronimo thing in terms of support; details to get worked out by infrastructure). Ken, do we need to do anything formal or can people start working with Infra now? It would seem to make sense to have one person coordinate the effort from the Geronimo side to start with. I nominate Hernan since he's been doing the Lion's share of our documentation. For now I'll move my Release Mgmt work over to Atlassian. Cheers. Matt
[jira] Closed: (GERONIMO-1554) Installer - Move advanced features to non-default installer path (simplify default installation)
[ http://issues.apache.org/jira/browse/GERONIMO-1554?page=all ] David Jencks closed GERONIMO-1554: -- Fix Version: 1.0.1 1.1 Resolution: Fixed Assign To: David Jencks Applied to branch 1.0. Making a jetty server works for me, but a tomcat server won't start. This might be a peculiarity of my dev environment but could use checking. Sending1.0/assemblies/j2ee-installer/src/izpack/geronimo-izpack.xml Sending1.0/assemblies/j2ee-installer/src/izpack/izpack-user-input.xml Sending 1.0/modules/installer-support/src/java/com/izforge/izpack/panels/GeronimoConfigProcessor.java Sending 1.0/modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelections.java Transmitting file data Committed revision 374171. Installer - Move advanced features to non-default installer path (simplify default installation) Key: GERONIMO-1554 URL: http://issues.apache.org/jira/browse/GERONIMO-1554 Project: Geronimo Type: Improvement Components: installer Versions: 1.0.1, 1.1 Reporter: erik daughtrey Assignee: David Jencks Fix For: 1.0.1, 1.1 Attachments: installer-separate-advanced-features.patch.gz Installer is too complex for new users. Simplify default path and disable advanced features or move them to a non-default path. -- 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-1524) DB pool portlet should let you select multiple driver JARs
[ http://issues.apache.org/jira/browse/GERONIMO-1524?page=all ] Paul McMahan updated GERONIMO-1524: --- Attachment: GERONIMO-1524.patch Attaching a patch that will allow multiple jars to be selected for the database driver. NOTE: this patch was generated for the 1.0.1 release. This will allow the user to create db pools for databases that require more than driver jar, like DB2 which requires a license jar. DB pool portlet should let you select multiple driver JARs -- Key: GERONIMO-1524 URL: http://issues.apache.org/jira/browse/GERONIMO-1524 Project: Geronimo Type: Improvement Components: console Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.x, 1.1 Attachments: GERONIMO-1524.patch Currently the database pool portlet can handle a driver requiring multiple JARs, but the UI doesn't actually let you select more than one. Some drivers known to need more include DB/2 and MS SQL Server. Perhaps the screen should have a checkbox to reveal another 2 driver selection pick lists (the security realm portlet advanced config screen has an example of revealing extra fields if you check a particular checkbox). -- 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-1524) DB pool portlet should let you select multiple driver JARs
[ http://issues.apache.org/jira/browse/GERONIMO-1524?page=all ] Paul McMahan updated GERONIMO-1524: --- Geronimo Info: [Patch Available] DB pool portlet should let you select multiple driver JARs -- Key: GERONIMO-1524 URL: http://issues.apache.org/jira/browse/GERONIMO-1524 Project: Geronimo Type: Improvement Components: console Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.x, 1.1 Attachments: GERONIMO-1524.patch Currently the database pool portlet can handle a driver requiring multiple JARs, but the UI doesn't actually let you select more than one. Some drivers known to need more include DB/2 and MS SQL Server. Perhaps the screen should have a checkbox to reveal another 2 driver selection pick lists (the security realm portlet advanced config screen has an example of revealing extra fields if you check a particular checkbox). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1524) DB pool portlet should let you select multiple driver JARs
[ http://issues.apache.org/jira/browse/GERONIMO-1524?page=all ] Paul McMahan reassigned GERONIMO-1524: -- Assign To: Paul McMahan DB pool portlet should let you select multiple driver JARs -- Key: GERONIMO-1524 URL: http://issues.apache.org/jira/browse/GERONIMO-1524 Project: Geronimo Type: Improvement Components: console Versions: 1.0 Reporter: Aaron Mulder Assignee: Paul McMahan Fix For: 1.x, 1.1 Attachments: GERONIMO-1524.patch Currently the database pool portlet can handle a driver requiring multiple JARs, but the UI doesn't actually let you select more than one. Some drivers known to need more include DB/2 and MS SQL Server. Perhaps the screen should have a checkbox to reveal another 2 driver selection pick lists (the security realm portlet advanced config screen has an example of revealing extra fields if you check a particular checkbox). -- 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: Roadmap, tasks and things to do?
Hi Anita, +1 to this great initiative. There is a new structure in confluence with the idea of organizing all the development processes together. This initial structure holds a place for the roadmap. It would be great if you can capture here the ideas discussed in the Roadmap, tasks and things to do? thread. Here is the link to the new structure. http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+Development+Process As usual, I would really appreciate any comments on the proposed structure; content donation will be appreciated as well ;) Cheers! Hernan anita kulshreshtha wrote: Before all these great ideas get lost in the mailing list, I would like to add them to wiki. There is a RoadMap page, I would like to rename it to Features or something similar. Add a Roadmap and things to do page. I will list all the ideas along with the name of the originator(s) and hope that they will take time to break up the ideas into manageable work and create Jira issues. Please let me know if there any objections? Thanks Anita --- Bruce Snyder [EMAIL PROTECTED] wrote: This is great input from the entire community and I hope the ideas keep coming! I think it would be best if these were all entered as JIRA issues so that they can all be categorized and tracked. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Confluence or Moin Moin...let's put a stake in the heart of this monster.
Hi Matt, what is the official channel to talk with the infraestructure team? Cheers! Hernan Matt Hogstrom wrote: Guys, I want to update the Release manager doc on the Wiki but it occurred to me today that we have still not resolved the issue of Confluence or MoinMoin. We've been discussing this issue for about 3 months I think but have only succeeded in having created two environments and not pulling together a cohesive story for our users in terms of documentation. Hernan has been doing a great job of documenting on Confluence over at Atlassian and I saw Anita post today that she has graciously volunteered to update the Roadmap (I assume on the current G Wiki). Given that I'm ready to do some updating as well I wanted see what issues are in the way for us moving to a common infrastructure. From the e-mail vote started by Ken here were the votes: + 1 Votes for Confluence Erin Mulder Joe Bohn Dain Sundstrom Alan Cabrera David Jencks Bruce Snyder Jason Dillon Hernan Cunico David Blevins Matt Hogstrom Gianny Damour John Sisson Jacek Laskowski Kevan Miller Prasad Kashyap James Strachan Sachin Patel Paul McMahan +1 Votes for something else Geir +0 Votes: Jan Bartel 7 People volunteered for Infrastructure assignments Andrus Adamchik Hernan Cunico Rajith Atlapatto Jason Dillon Kevan Miller Paul McMahan Prasad Kashyap I apologize in advance for spelling mistakes above. At this point it looks like the clear winner is Confluence. So the question is what do we do from here? What makes sense to me is people do their current work at Atlassian to ease the transition (with appropriate updates on the Geronimo site to point there) and have the volunteers above start introducing themselves to the Infrastructure group and building some Karma to get Confluence setup (remembering that this is more than a Geronimo thing in terms of support; details to get worked out by infrastructure). Ken, do we need to do anything formal or can people start working with Infra now? It would seem to make sense to have one person coordinate the effort from the Geronimo side to start with. I nominate Hernan since he's been doing the Lion's share of our documentation. For now I'll move my Release Mgmt work over to Atlassian. Cheers. Matt
[jira] Commented: (GERONIMO-1569) improve packaging plugin control of logging.
[ http://issues.apache.org/jira/browse/GERONIMO-1569?page=comments#action_12364881 ] David Jencks commented on GERONIMO-1569: NOTE: this change adds a bit of functionality to the kernel class GeronimoLogging. This is not essential but convenient. Please review, if anyone objects I can remove it. Sendingetc/project.properties Sending modules/kernel/src/java/org/apache/geronimo/kernel/log/GeronimoLogging.java Sendingplugins/geronimo-packaging-plugin/plugin.jelly Sendingplugins/geronimo-packaging-plugin/plugin.properties Sendingplugins/geronimo-packaging-plugin/project.xml Sending plugins/geronimo-packaging-plugin/src/java/org/apache/geronimo/plugin/packaging/PackageBuilder.java Sending plugins/geronimo-packaging-plugin/src/java/org/apache/geronimo/plugin/packaging/PackageBuilderShell.java Transmitting file data ... Committed revision 374191. improve packaging plugin control of logging. Key: GERONIMO-1569 URL: http://issues.apache.org/jira/browse/GERONIMO-1569 Project: Geronimo Type: Bug Components: buildsystem Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 The packaging plugin should use GeronimoLogging to initialize and control the log4j system. -- 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: Confluence or Moin Moin...let's put a stake in the heart of this monster.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote: From the e-mail vote started by Ken here were the votes: 18 Votes for Confluence 1 Votes for something else 1 +0 Vote 7 People volunteered for Infrastructure assignments Andrus Adamchik Hernan Cunico Rajith Atlapatto Jason Dillon Kevan Miller Paul McMahan Prasad Kashyap Thanks, Matt; you beat me to it. At this point it looks like the clear winner is Confluence. So the question is what do we do from here? What makes sense to me is people do their current work at Atlassian to ease the transition (with appropriate updates on the Geronimo site to point there) and have the volunteers above start introducing themselves to the Infrastructure group and building some Karma to get Confluence setup (remembering that this is more than a Geronimo thing in terms of support; details to get worked out by infrastructure). Zigackly. Ken, do we need to do anything formal or can people start working with Infra now? It would seem to make sense to have one person coordinate the effort from the Geronimo side to start with. I nominate Hernan since he's been doing the Lion's share of our documentation. Sounds basically like the correct approach; let me check with the infra people to see how they'd like to handle the process and initiate^Whelp the new people.. Unless someone else would like to do that..? - -- #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 iQCVAwUBQ+ExlZrNPMCpn3XdAQIGNAQAkpHJd/GHHX/EeCmq73i+bCG7KVNSczKJ Ii4QLx/aNTuO3/a6maHLHbQ3FoUTEwshzhOaRcXmBB1OhhoovhRMlVLfnc/ic+yc eqKVTQulUdvZG6JOrdVIu+y1G8LnwEL/+7/olhMOudpBtMi0MddK9WpTyMnAELJO PAexM5iz/tc= =xhC8 -END PGP SIGNATURE-
[jira] Commented: (GERONIMO-1563) Make the JACC implementation pluggable
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12364883 ] David Jencks commented on GERONIMO-1563: Step one, make a separate gbean for our proprietary config info: Sending modules/j2ee-builder/src/java/org/apache/geronimo/j2ee/deployment/EARConfigBuilder.java Sending modules/jetty/src/test/org/apache/geronimo/jetty/AbstractWebModuleTest.java Sending modules/security/src/java/org/apache/geronimo/security/jacc/ApplicationPolicyConfigurationManager.java Adding modules/security/src/java/org/apache/geronimo/security/jacc/ApplicationPrincipalRoleConfigurationManager.java Adding modules/security/src/java/org/apache/geronimo/security/jacc/PrincipalRoleMapper.java Sending modules/tomcat/src/test/org/apache/geronimo/tomcat/AbstractWebModuleTest.java Sending modules/tomcat-builder/src/test/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilderTest.java Transmitting file data ... Committed revision 374193. Make the JACC implementation pluggable -- Key: GERONIMO-1563 URL: http://issues.apache.org/jira/browse/GERONIMO-1563 Project: Geronimo Type: Improvement Components: security Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Currently we are hardcoded into using our JACC implementation. This means we can't use third party authorization/security servers such as Tivoli AM. The runtime hardcoding is that the installation of the spec permissions into the policy configuration is mixed in with pushing our proprietary principal-role mapping into the policy configuration. The build time hardcoding is that the only proprietary security configuration we accept is our own xml for principal-role mapping, and we insist on it being present. Some steps for this: 1. make separate gbeans for the spec and proprietary access to the policy configuration. These should be connected by an interface, and the spec gbean should control the proprietary gbean and pass it the contextIds in the current application. 2. The security builder should be partly namespace driven, with the proprietary xml interpretation driven by the namespace. 2.a the base security builder should construct the ApplicationPolicyConfigurationGBean and hand off to the namespace-selected gbean for the proprietary stuff. 2.b the proprietary-xml builder should install the role-mapper gbean with the info needed for e.g. principal-role mapping. When we're done with this we should be able to support e.g. IBM pluggable JACC implementations that support their role-mapping capabilities by just writing an xml format and a gbean that pushes role mapping info into their interfaces. The ibm interfaces are explained here: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.express.doc/info/exp/ae/rsec_jaccspis.html If anyone knows how other app servers configure the non-spec part of JACC references would be very much appreciated. -- 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-1569) improve packaging plugin control of logging.
[ http://issues.apache.org/jira/browse/GERONIMO-1569?page=all ] David Jencks closed GERONIMO-1569: -- Resolution: Fixed bumped openejb plugin version. Also I've bumped the tck plugin versions Checking in etc/project.properties; new revision: 1.77; previous revision: 1.76 improve packaging plugin control of logging. Key: GERONIMO-1569 URL: http://issues.apache.org/jira/browse/GERONIMO-1569 Project: Geronimo Type: Bug Components: buildsystem Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 The packaging plugin should use GeronimoLogging to initialize and control the log4j system. -- 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-1471) Connector dependencies
[ http://issues.apache.org/jira/browse/GERONIMO-1471?page=all ] David Jencks updated GERONIMO-1471: --- Component: (was: connector) this does not relate to j2ca connectors Connector dependencies -- Key: GERONIMO-1471 URL: http://issues.apache.org/jira/browse/GERONIMO-1471 Project: Geronimo Type: Improvement Components: Clustering, Tomcat, web Environment: Deploying a web application in a cluster. Reporter: Greg Wilkins Assignee: Greg Wilkins Fix For: 1.1 It is highly desirable that the HTTP connectors can be made dependent on the correct startup of one or more webapplications. This is to prevent a server with failed webapps to join a cluster, or for it a server to join a cluster before required webapplications are fully deployed. It should be possible to add GBean dependancies in the web container plans, however an opinion has been expressed that this is not flexible enough and would be difficult to configure and update. So a specific mechanism has been proposed. Issues to consider are: + How should the dependencies be expressed: specific webapp, all webapps, number of webapps? + Where should they be expressed? In the container plan, or perhaps as some form or required webapp flag in the geronimo-web.xml ? + If the dependencies are not meet, what state should the connector be in? Should it be just not be started, or should it start, but have internal state (eg open/closed) as this would allow a future conversation with advanced load balancers. + Should the server port be opened - but no requests accepted? This will reserver the port and verify that no other resource is using it while the webapps are started. Need to verify that this will not upset any load balancers. -- 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: Confluence or Moin Moin...let's put a stake in the heart of this monster.
Hi Ken, I would't mind checking with the infraestructure team to find out the process of integrating confluence and formalizing the Volunteers. What is the formal communication channel with the infra guys? Cheers! Hernan Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote: From the e-mail vote started by Ken here were the votes: 18 Votes for Confluence 1 Votes for something else 1 +0 Vote 7 People volunteered for Infrastructure assignments Andrus Adamchik Hernan Cunico Rajith Atlapatto Jason Dillon Kevan Miller Paul McMahan Prasad Kashyap Thanks, Matt; you beat me to it. At this point it looks like the clear winner is Confluence. So the question is what do we do from here? What makes sense to me is people do their current work at Atlassian to ease the transition (with appropriate updates on the Geronimo site to point there) and have the volunteers above start introducing themselves to the Infrastructure group and building some Karma to get Confluence setup (remembering that this is more than a Geronimo thing in terms of support; details to get worked out by infrastructure). Zigackly. Ken, do we need to do anything formal or can people start working with Infra now? It would seem to make sense to have one person coordinate the effort from the Geronimo side to start with. I nominate Hernan since he's been doing the Lion's share of our documentation. Sounds basically like the correct approach; let me check with the infra people to see how they'd like to handle the process and initiate^Whelp the new people.. Unless someone else would like to do that..? - -- #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 iQCVAwUBQ+ExlZrNPMCpn3XdAQIGNAQAkpHJd/GHHX/EeCmq73i+bCG7KVNSczKJ Ii4QLx/aNTuO3/a6maHLHbQ3FoUTEwshzhOaRcXmBB1OhhoovhRMlVLfnc/ic+yc eqKVTQulUdvZG6JOrdVIu+y1G8LnwEL/+7/olhMOudpBtMi0MddK9WpTyMnAELJO PAexM5iz/tc= =xhC8 -END PGP SIGNATURE-
Re: Multiple servers sharing the same repo and config store
Some ideas.. Currently geronimo.sh/bat will invoke a setenv.sh script if present ( in the bin directory ). Maybe we could enhance geronimo.sh/bin to also invoke a setenv.sh script if present under var for a particular geronimo instance. So the setenv.sh script in geronimo/bin gets invoked first (allowing you to set env vars for all instances), followed by setenv.sh in myinstance/var/bin (allowing you to append or override the env vars that may have been set earlier). If we have multiple Geronimo instances, then shouldn't each instance need a J2EEServer name that is part of the JSR-77 J2EEManagedObject name? Could this name and maybe the server name be associated with names in the directory structure. How do we envision the J2EEServer name being specified? John Dave Colasurdo wrote: As far as directory structure, it seems that WebSphere separates the binaries (e.g. jars, scripts) from the instance data. Each instance has it's own copy of configuration data, installed applications, logs and properties. The scripts (e.g. startup/shutdown) are also available in each instance such that the user doesn't need to specify any environmental variables or parameters to indicate which instance when executing the scripts. -Dave- Dain Sundstrom wrote: Does anyone know how other J2EE servers structure their directories when they have multiple instances configured? -dain On Jan 30, 2006, at 5:04 AM, Aaron Mulder wrote: This sounds reasonable to me. I'd prefer to have resolveServer and always look for /var under there. If there are multiple config stores, we'll have to figure out how the deploy tool will know which one to use. Perhaps there should be something indicating whether the config store is writable at runtime (vs at server construction time) and only the server-specific one would be writeable? Or at least, the tools would default to writeable ones over not? (Right now they'd theoretically deploy to all available config stores, but I think there's an outstanding issue that the Deployer GBean doesn't let you specify a config store even if you wanted to.) Thanks, Aaron On 1/30/06, David Jencks [EMAIL PROTECTED] wrote: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are located outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to relocate. I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like resolveVar and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the var trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now var. Several people have suggested putting an additional config-store into var for private use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
[jira] Commented: (GERONIMO-1553) Provide commonj Timer and Work Manager.
[
http://issues.apache.org/jira/browse/GERONIMO-1553?page=comments#action_12364889
]
David Jencks commented on GERONIMO-1553:
I've been looking forward to commonj for a long time :-)
I started glancing at this very briefly. It's been a couple years since I
looked at the commonj specs ;-). IIUC we will need some spec jars to be able
to compile this. Should we write these from the specs? Are they available so
we can put them in our specs project? So far we have preferred to have source
code for all specs in an apache location.
Does the commonj timer spec include persistent timers in any form, and is it
transactional in any sense? How useful is it for implementing the
transactional persistent ejb timers?
BTW there might be a bug here for non-fixed rate in TimerImpl:
public synchronized void updateScheduledExecutionTime() {
if (fixedRate)
scheduledExecutionTime+=period;
else
scheduledExecutionTime+=System.currentTimeMillis()+period;
}
Provide commonj Timer and Work Manager.
---
Key: GERONIMO-1553
URL: http://issues.apache.org/jira/browse/GERONIMO-1553
Project: Geronimo
Type: New Feature
Components: general
Versions: Wish List
Environment: na
Reporter: Seth White
Attachments: commonj.jar
It would be nice if Geronimo provided an implementation of the Timer and Work
Manager APIs specified by commonj.
More information on these features can be found here:
http://dev2dev.bea.com/wlplatform/commonj/twm.html
--
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: Multiple servers sharing the same repo and config store
I'm not sure if you are suggesting it would be possible for two geronimo instances to share a var/config directory - that would not work as each instance would be attempting to do updates of the one config.xml file. This may also have problems with two instances trying to write log files, journal files of the same name etc. John Paul McMahan wrote: As a programmer type it seems intuitive to me that the presence of a subdir in an alternate server root overrides the default while its absence makes the server instance inherit the default. But its possible that I am mingling system administration with too much OO. At any rate I agree that having to examine the command line and then the alternate server root directory to figure out which repository directory (or var, or config-store, etc.) is in use could be error-prone for some. An informative message shown at the beginning of startup that shows which directories are mapped into the server instance could help. I can think of a few other ways to address this concern but they all tend to sacrifice flexibility or intuitiveness. BTW, I'm not suggesting that the subdirs of the alternate server root directory get weaved into the subdirs of geronimo_home, as that approach *does* seem too indeterminate to me. Oh, and one more thing I'm wondering is how Sachin's req for running applications from within a dev environment might play into this new feature. Seems that ideally the solution for the var subdir would be consistent with the solution for config-store, repository, and whatever else we decide to put in geronimo_home in the future. Here's the JIRA for that req: https://issues.apache.org/jira/browse/GERONIMO-1526 Best wishes, Paul On 1/30/06, *David Jencks* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'm not sure I like that, because IIUC it would mean that the main repository gbean for instance would be looking at different repos depending on both a command line switch and whether a particular directory existed. At the moment I think that is too indeterminate. I would prefer to have each repo gbean point to a single well defined location and to add more repositories for customization. You might be able to argue me out of this position. thanks david jencks
Re: Confluence or Moin Moin...let's put a stake in the heart of this monster.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hernan Cunico wrote: I would't mind checking with the infraestructure team to find out the process of integrating confluence and formalizing the Volunteers. What is the formal communication channel with the infra guys? Join [EMAIL PROTECTED] and send there. Maybe a bugzilla entry or chatting on #asfinfra on irc.freenode.net, too. But mail first. :-) - -- #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 iQCVAwUBQ+E+H5rNPMCpn3XdAQKTLgQAoFS9p31O6gGSq7D4YKIFnmjpjajYmkkK PnCUwsdggrDTShYmod/mKgYGcB3MilT6aHNfadT4fMioPh3pO4sNUjxkXUSZQVhL 867VpUk/Kn+zBEkCqwIyFqWFpVrAUgAYHPKM9IGbAc/cF9VjUduOdpy1fWQU254m M9540X1zrl8= =HE8D -END PGP SIGNATURE-
[jira] Commented: (GERONIMO-1553) Provide commonj Timer and Work Manager.
[ http://issues.apache.org/jira/browse/GERONIMO-1553?page=comments#action_12364900 ] Seth White commented on GERONIMO-1553: -- Thanks for taking a look! The source code for the specifications is available. I'd be happy to take a shot at adding it to the specs project and attach the results. It's also available at the link above. Is there an Apache legal review that needs to happen before the specification code can become part of Geronimo? Commonj timers aren't persistent or transactional. After an initial look at the current EJB timer code, my thought was that commonj timers could be used as a building block and layered underneath the EJB timer service. I'm still evaluating exactly what could be done there. You are right about the bug. I've been thinking about what to do and my current thought is to implement fixed delay timers as a sequence of one off timers, instead of the way it is done right now. Provide commonj Timer and Work Manager. --- Key: GERONIMO-1553 URL: http://issues.apache.org/jira/browse/GERONIMO-1553 Project: Geronimo Type: New Feature Components: general Versions: Wish List Environment: na Reporter: Seth White Attachments: commonj.jar It would be nice if Geronimo provided an implementation of the Timer and Work Manager APIs specified by commonj. More information on these features can be found here: http://dev2dev.bea.com/wlplatform/commonj/twm.html -- 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-1570) jetty is setting hosts instead of virtual hosts
jetty is setting hosts instead of virtual hosts --- Key: GERONIMO-1570 URL: http://issues.apache.org/jira/browse/GERONIMO-1570 Project: Geronimo Type: Bug Components: web Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1, 1.0.1 The virtual-host elements in jetty configuration are getting set as hosts, not virtual hosts, in the jetty web app context. -- 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-1570) jetty is setting hosts instead of virtual hosts
[ http://issues.apache.org/jira/browse/GERONIMO-1570?page=comments#action_12364901 ] David Jencks commented on GERONIMO-1570: branch 1.0: Sendingjetty/src/java/org/apache/geronimo/jetty/JettyWebAppContext.java Transmitting file data . Committed revision 374210. jetty is setting hosts instead of virtual hosts --- Key: GERONIMO-1570 URL: http://issues.apache.org/jira/browse/GERONIMO-1570 Project: Geronimo Type: Bug Components: web Reporter: David Jencks Assignee: David Jencks Fix For: 1.1, 1.0.1 The virtual-host elements in jetty configuration are getting set as hosts, not virtual hosts, in the jetty web app context. -- 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-1563) Make the JACC implementation pluggable
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12364902 ] David Jencks commented on GERONIMO-1563: Previous commit missed this file: Sending modules/security-builder/src/java/org/apache/geronimo/security/deployment/SecurityBuilder.java Transmitting file data . Committed revision 374211. Make the JACC implementation pluggable -- Key: GERONIMO-1563 URL: http://issues.apache.org/jira/browse/GERONIMO-1563 Project: Geronimo Type: Improvement Components: security Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Currently we are hardcoded into using our JACC implementation. This means we can't use third party authorization/security servers such as Tivoli AM. The runtime hardcoding is that the installation of the spec permissions into the policy configuration is mixed in with pushing our proprietary principal-role mapping into the policy configuration. The build time hardcoding is that the only proprietary security configuration we accept is our own xml for principal-role mapping, and we insist on it being present. Some steps for this: 1. make separate gbeans for the spec and proprietary access to the policy configuration. These should be connected by an interface, and the spec gbean should control the proprietary gbean and pass it the contextIds in the current application. 2. The security builder should be partly namespace driven, with the proprietary xml interpretation driven by the namespace. 2.a the base security builder should construct the ApplicationPolicyConfigurationGBean and hand off to the namespace-selected gbean for the proprietary stuff. 2.b the proprietary-xml builder should install the role-mapper gbean with the info needed for e.g. principal-role mapping. When we're done with this we should be able to support e.g. IBM pluggable JACC implementations that support their role-mapping capabilities by just writing an xml format and a gbean that pushes role mapping info into their interfaces. The ibm interfaces are explained here: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.express.doc/info/exp/ae/rsec_jaccspis.html If anyone knows how other app servers configure the non-spec part of JACC references would be very much appreciated. -- 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-1570) jetty is setting hosts instead of virtual hosts
[ http://issues.apache.org/jira/browse/GERONIMO-1570?page=all ] David Jencks closed GERONIMO-1570: -- Resolution: Fixed Fix on trunk is part of GERONIMO-1460. Adding modules/jetty/src/java/org/apache/geronimo/jetty/Host.java Sending modules/jetty/src/java/org/apache/geronimo/jetty/JettyWebAppContext.java Sending modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java Sendingmodules/jetty-builder/src/schema/geronimo-jetty-1.0.xsd Sendingmodules/jetty-builder/src/schema/geronimo-jetty-config-1.0.xsd Transmitting file data . Committed revision 374212. jetty is setting hosts instead of virtual hosts --- Key: GERONIMO-1570 URL: http://issues.apache.org/jira/browse/GERONIMO-1570 Project: Geronimo Type: Bug Components: web Reporter: David Jencks Assignee: David Jencks Fix For: 1.1, 1.0.1 The virtual-host elements in jetty configuration are getting set as hosts, not virtual hosts, in the jetty web app context. -- 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-1460) Tomcat web plan should take multiple hosts, create HostGBeans as necessary
[ http://issues.apache.org/jira/browse/GERONIMO-1460?page=comments#action_12364904 ] David Jencks commented on GERONIMO-1460: I've implemented a Host gbean for jetty. At the moment the only way to construct one is via host and virtual-host elements in a jetty specific plan. We still need a way to provide a gbean-link to a separate host gbean for jetty. As Jeff mentions this still requires more thought for tomcat. Adding modules/jetty/src/java/org/apache/geronimo/jetty/Host.java Sending modules/jetty/src/java/org/apache/geronimo/jetty/JettyWebAppContext.java Sending modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java Sendingmodules/jetty-builder/src/schema/geronimo-jetty-1.0.xsd Sendingmodules/jetty-builder/src/schema/geronimo-jetty-config-1.0.xsd Transmitting file data . Committed revision 374212. Tomcat web plan should take multiple hosts, create HostGBeans as necessary -- Key: GERONIMO-1460 URL: http://issues.apache.org/jira/browse/GERONIMO-1460 Project: Geronimo Type: Improvement Components: Tomcat, web Versions: 1.0 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 1.1 The Tomcat web plan should take multiple host elements, and for each one: - if a HostGBean is present, associate to that - if a HostGBean is not present, create a default one and start it, and then associate to that -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1553) Provide commonj Timer and Work Manager.
[ http://issues.apache.org/jira/browse/GERONIMO-1553?page=comments#action_12364905 ] David Jencks commented on GERONIMO-1553: license/review for specs: I have no idea, there's probably a form to fill out :-) relation to ejb timers: I think layering the commonj timers under ejb timers is a good idea. The current implementation of persistence for the ejb timers is really awful at least for ejbs. I think that if we want the timer service to be generic we need to provide some kind of factory/serializer service for each kind of thing we want to time rather than trying to be all things to all people. Dain may have some more ideas about this. bug: I thought that replacing += with = ought to fix it. Am I missing something? Provide commonj Timer and Work Manager. --- Key: GERONIMO-1553 URL: http://issues.apache.org/jira/browse/GERONIMO-1553 Project: Geronimo Type: New Feature Components: general Versions: Wish List Environment: na Reporter: Seth White Attachments: commonj.jar It would be nice if Geronimo provided an implementation of the Timer and Work Manager APIs specified by commonj. More information on these features can be found here: http://dev2dev.bea.com/wlplatform/commonj/twm.html -- 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
Ejbs are broken
After dain's big openejb refactoring ejbs are broken. The most visible problem is that many of the references in the openejb plan are wrong. For instance, the transactioncontext manager references want the TCM to be in the openejb configuration rather than the module they are actually in. This problem is fairly easy to see if you try to start say the jetty server. thanks david jencks
Supporting applications that need a database
Dain has been complaining that the default database is no more and IIUC suggesting that we reinstate it and by default hook at least ejb applications that don't have an explicit database configuration up to it. Since I removed the default database I'd like to somewhat preemptively explain my thinking. Based on my support experiences with another app server that did something like this, I think this is a really bad idea. What happened there was that no one knew how to connect their app to a non- default database, and we got zillions of problem reports based on the app using the default database rather than the one that was misconfigured :-) I also don't think that encouraging all applications to use the same database is a very good policy. It certainly invites collisions between applications and reduces portability. We have the capabilities to build a derby database for a particular schema, and package it , and to bundle a datasource configuration with a j2ee app plan. This is used for the daytrader and uddi server configurations. Rather than including a database no one should want :-) and encouraging people to use it, I would rather see us automate the construction of a configured database for an app, and the construction and bundling of a datasource configuration with the app's plan. thanks david jencks
Re: Need help with db2jcc_license_cu jar file deployment
FYI --- I attached a patch for the 1.0.1 branch to GERONIMO-1524 that
will allow multiple jars to be selected for a database pool. This
will allow the console to create database pools for DB2 using the extra
license jar.
Best wishes,
PaulOn 1/31/06, Hernan Cunico [EMAIL PROTECTED] wrote:
Hi All,ASAIK these two license files are to be used as follows:*db2jcc_license_cu.jar*for
Linux, UNIX and Windows servers (I guess all on Intel). This is the
standard license.*db2jcc_license_cisuz.jar*for z/OS and iSeries in addition to the other (standard) license.Cheers!HernanMatt Hogstrom wrote: Prakash, Here is the setup I am currently using.
I added the DB2 jars to my repository as follows: [EMAIL PROTECTED]:~/geronimo-1.0/repository/com.ibm.db2/jars ls -al total 1233 drwxr-xr-x3 hogstrom users 200 2006-01-31 14:02 .
drwxr-xr-x3 hogstrom users72 2006-01-11 09:15 .. -rw-r--r--1 hogstrom users 1249462 2006-01-11 09:16 db2jcc-10.1.jar -rwxr-xr-x1 hogstrom users2063 2006-01-11 09:17 db2jcc_license_cisuz-
10.1.jar -rwxr-xr-x1 hogstrom users1013 2006-01-11 09:17 db2jcc_license_cu-10.1.jar Ignore the version, I think I was using the Derby version number for some reason but these are from a DB2 UDB V8 distro.
I added the following lines to my application plan.This is for the DataSource definition: ext-module connectorTradeDataSource/connector
external-pathtranql/tranql-connector-db2-xa/1.0/rar/external-path connector xmlns=http://geronimo.apache.org/xml/ns/j2ee/connector
configId=TradeDataSource parentId=org/apache/geronimo/Server dependency
uricom.ibm.db2/db2jcc/10.1/jar/uri /dependency dependency
uricom.ibm.db2/db2jcc_license_cisuz/10.1/jar/uri /dependency dependency
uricom.ibm.db2/db2jcc_license_cu/10.1/jar/uri /dependency I see you do not refer to the cusiz license (and I don't know what it is) :)
Try this out. [EMAIL PROTECTED] wrote: Hello, I am very new to Geronimo, have installed Geronimo-Tomcat-J2EE-1.0
just last week on my Window-XP to evaluate it. I have DB2 UDB Workgroup server 8.2 running on another Windows server within my LAN and I am trying to add a database pool for this DB2 using Geronimo Web
Console. I could successfully add the two jar files db2jcc.jar and db2jcc_license_cu.jar to the Geronimo repository and they are now under ...\geronimo-1.0\repository\db2\jars
but renamed as db2jcc-8.2.jar and db2jcc_license_cu-8.2.jar respectively since I specified their version as 8.2. They are listed as db2/db2jcc/8.2/jar and db2/db2jcc_license_cu/8.2/jar respectively under the Current
Repository Entries. While adding the new database pool, I can successfully step through until the Test Connection which fails trying to find the appropriate
license file db2jcc_license_cu.jar. Below is the error message: == com.ibm.db2.jcc.b.SqlException: The version of the IBM Universal JDBC driver in use is not licensed for connectivity to DB2 for Unix/Windows
databases.To connect to this DB2 server, please obtain a licensed copy of the IBM DB2 Universal Driver for JDBC and SQLJ.An appropriate license file db2jcc_license_*.jar for this target platform
must be installed to the application classpath.Connectivity to DB2 for Unix/Windows databases is enabled by any of the following license files: { db2jcc_license_cu.jar, db2jcc_license_cisuz.jar }
at com.ibm.db2.jcc.b.o.db(o.java:3103)at com.ibm.db2.jcc.b.o.cb(o.java:3049)at com.ibm.db2.jcc.a.b.cb(b.java:629)at com.ibm.db2.jcc.a.b.init(b.java:306)at
com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:162)at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.attemptConnect(DatabasePoolPortlet.java:797)at
org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:321) ... ... ... ===
The DB2 license file nameis expected to be db2jcc_license_cu.jar, but the Web Console renames it to db2jcc_license_cu-8.2.jar due to its jar file naming rules. I have seen a posting by Mr. Young Skim (
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) on 01/12/2006 seeking help on the same problem and I have tried one of the solutions posted by Mr. Matt
Hogstrom i.e. add dependency to these jar files to the application's deployment plan. It did not work, may be because I am not sure exactly to which xml file, I should add this.
Please help me! Thanks a lot! Prakash
[jira] Commented: (GERONIMO-1553) Provide commonj Timer and Work Manager.
[ http://issues.apache.org/jira/browse/GERONIMO-1553?page=comments#action_12364908 ] Seth White commented on GERONIMO-1553: -- :) I'll look into adding the specification code and not worry about the license. There is a subtle problem with fixed delay timers right now. Because timers execute asynchronously, the underlying timer events should behave more like a fixed rate timer than a fixed delay timer. Sorry, since I was aware of this problem, I didn't look closely at the code you mentioned, just assumed you were referring to that. Provide commonj Timer and Work Manager. --- Key: GERONIMO-1553 URL: http://issues.apache.org/jira/browse/GERONIMO-1553 Project: Geronimo Type: New Feature Components: general Versions: Wish List Environment: na Reporter: Seth White Attachments: commonj.jar It would be nice if Geronimo provided an implementation of the Timer and Work Manager APIs specified by commonj. More information on these features can be found here: http://dev2dev.bea.com/wlplatform/commonj/twm.html -- 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: Supporting applications that need a database
David Jencks wrote: Dain has been complaining that the default database is no more and IIUC suggesting that we reinstate it and by default hook at least ejb applications that don't have an explicit database configuration up to it. Since I removed the default database I'd like to somewhat preemptively explain my thinking. Based on my support experiences with another app server that did something like this, I think this is a really bad idea. What happened there was that no one knew how to connect their app to a non-default database, and we got zillions of problem reports based on the app using the default database rather than the one that was misconfigured :-) I also don't think that encouraging all applications to use the same database is a very good policy. It certainly invites collisions between applications and reduces portability. We have the capabilities to build a derby database for a particular schema, and package it , and to bundle a datasource configuration with a j2ee app plan. This is used for the daytrader and uddi server configurations. Rather than including a database no one should want :-) and encouraging people to use it, I would rather see us automate the construction of a configured database for an app, and the construction and bundling of a datasource configuration with the app's plan. thanks david jencks I agree that it is preferable to automate the construction of databases rather than encouraging users/apps to use a default database. For demo type applications, complete automation of the creation of the database at deployment time would be nice. For non-demo applications deployed in an enterprise environment, the DBA would probably want to be involved in the creation of the database and possibly customize the DDL, security etc. John
Re: Supporting applications that need a database
I don't generally like default things when the default is a completely arbitrary choice, as is the case here. This is not like a default port number. If someone is having trouble configuring a database then he/she or someone else should write a tool that tries to configure out the settings, not dumb down the software for everyone else. On Wed, 1 Feb 2006, David Jencks wrote: Dain has been complaining that the default database is no more and IIUC suggesting that we reinstate it and by default hook at least ejb applications that don't have an explicit database configuration up to it. Since I removed the default database I'd like to somewhat preemptively explain my thinking. Based on my support experiences with another app server that did something like this, I think this is a really bad idea. What happened there was that no one knew how to connect their app to a non- default database, and we got zillions of problem reports based on the app using the default database rather than the one that was misconfigured :-) I also don't think that encouraging all applications to use the same database is a very good policy. It certainly invites collisions between applications and reduces portability. We have the capabilities to build a derby database for a particular schema, and package it , and to bundle a datasource configuration with a j2ee app plan. This is used for the daytrader and uddi server configurations. Rather than including a database no one should want :-) and encouraging people to use it, I would rather see us automate the construction of a configured database for an app, and the construction and bundling of a datasource configuration with the app's plan. thanks david jencks
Re: Supporting applications that need a database
David, I support not having a default database in the server. I think if we break the usage of the server into development and production (as John discusses in his note) we'll see that from a developer's perspective a DB is beneficial. However, if your deploying for production you penalize the administrator to remove things that are useful to developers. I think a good compromise is add some scripts / plans that one can easily modify to create various resources (DataSources, Queues, etc.). Matt David Jencks wrote: Dain has been complaining that the default database is no more and IIUC suggesting that we reinstate it and by default hook at least ejb applications that don't have an explicit database configuration up to it. Since I removed the default database I'd like to somewhat preemptively explain my thinking. Based on my support experiences with another app server that did something like this, I think this is a really bad idea. What happened there was that no one knew how to connect their app to a non- default database, and we got zillions of problem reports based on the app using the default database rather than the one that was misconfigured :-) I also don't think that encouraging all applications to use the same database is a very good policy. It certainly invites collisions between applications and reduces portability. We have the capabilities to build a derby database for a particular schema, and package it , and to bundle a datasource configuration with a j2ee app plan. This is used for the daytrader and uddi server configurations. Rather than including a database no one should want :-) and encouraging people to use it, I would rather see us automate the construction of a configured database for an app, and the construction and bundling of a datasource configuration with the app's plan. thanks david jencks
[jira] Assigned: (GERONIMO-1336) Setting the Max PoolSize on a DataBase pool with invalid information does not yield an error message and silently fails
[ http://issues.apache.org/jira/browse/GERONIMO-1336?page=all ] Matt Hogstrom reassigned GERONIMO-1336: --- Assign To: Matt Hogstrom (was: Aaron Mulder) Setting the Max PoolSize on a DataBase pool with invalid information does not yield an error message and silently fails --- Key: GERONIMO-1336 URL: http://issues.apache.org/jira/browse/GERONIMO-1336 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Matt Hogstrom Assignee: Matt Hogstrom Priority: Minor Fix For: 1.0.1, 1.1 Attachments: DBPoolValidate.patch, DBPoolValidate2.patch When attempting a set of the SystemDatabase pool to a negative value the save command executes and gives the appearance that the change was made. At least there is no information that indicates it failed. The following error is logged in the geronimo.log. The Console should detect this error and inform the user that an invalid value was specified. 13:38:37,813 ERROR [DatabasePoolPortlet] Unable to save connection pool java.lang.IllegalArgumentException: Max size must be positive, not -1 at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.setPartitionMaxSize(AbstractSinglePoolConnectionInterceptor.java:149) at org.apache.geronimo.connector.outbound.connectionmanagerconfig.SinglePool.setPartitionMaxSize(SinglePool.java:143) at org.apache.geronimo.connector.outbound.AbstractConnectionManager.setPartitionMaxSize(AbstractConnectionManager.java:104) at org.apache.geronimo.connector.outbound.AbstractConnectionManager$$FastClassByCGLIB$$80012030.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanAttribute.setValue(GBeanAttribute.java:403) at org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:698) at org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:683) at org.apache.geronimo.gbean.runtime.RawInvoker.setAttribute(RawInvoker.java:53) at org.apache.geronimo.kernel.basic.RawSetAttributeInvoker.invoke(RawSetAttributeInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.connector.outbound.ConnectionManagerContainer$$EnhancerByCGLIB$$813b4258.setPartitionMaxSize(generated) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:940) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:337) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) -- 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-1336) Setting the Max PoolSize on a DataBase pool with invalid information does not yield an error message and silently fails
[ http://issues.apache.org/jira/browse/GERONIMO-1336?page=all ] Matt Hogstrom closed GERONIMO-1336: --- Resolution: Fixed branches/1.0 svn commit -m Geronimo-1336 Corrected issue when specifying database pool sizes Sending applications/console-standard/src/webapp/WEB-INF/view/dbwizard/confirmURL.jsp Sending applications/console-standard/src/webapp/WEB-INF/view/dbwizard/edit.jsp Transmitting file data .. Committed revision 374252. trunk svn commit -m Geronimo-1336 Corrected issue when specifying database pool sizes Sending applications/console-standard/src/webapp/WEB-INF/view/dbwizard/confirmURL.jsp Sending applications/console-standard/src/webapp/WEB-INF/view/dbwizard/edit.jsp Transmitting file data .. Committed revision 374253. Setting the Max PoolSize on a DataBase pool with invalid information does not yield an error message and silently fails --- Key: GERONIMO-1336 URL: http://issues.apache.org/jira/browse/GERONIMO-1336 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Matt Hogstrom Assignee: Matt Hogstrom Priority: Minor Fix For: 1.0.1, 1.1 Attachments: DBPoolValidate.patch, DBPoolValidate2.patch When attempting a set of the SystemDatabase pool to a negative value the save command executes and gives the appearance that the change was made. At least there is no information that indicates it failed. The following error is logged in the geronimo.log. The Console should detect this error and inform the user that an invalid value was specified. 13:38:37,813 ERROR [DatabasePoolPortlet] Unable to save connection pool java.lang.IllegalArgumentException: Max size must be positive, not -1 at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.setPartitionMaxSize(AbstractSinglePoolConnectionInterceptor.java:149) at org.apache.geronimo.connector.outbound.connectionmanagerconfig.SinglePool.setPartitionMaxSize(SinglePool.java:143) at org.apache.geronimo.connector.outbound.AbstractConnectionManager.setPartitionMaxSize(AbstractConnectionManager.java:104) at org.apache.geronimo.connector.outbound.AbstractConnectionManager$$FastClassByCGLIB$$80012030.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanAttribute.setValue(GBeanAttribute.java:403) at org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:698) at org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:683) at org.apache.geronimo.gbean.runtime.RawInvoker.setAttribute(RawInvoker.java:53) at org.apache.geronimo.kernel.basic.RawSetAttributeInvoker.invoke(RawSetAttributeInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.connector.outbound.ConnectionManagerContainer$$EnhancerByCGLIB$$813b4258.setPartitionMaxSize(generated) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:940) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:337) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) -- 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-1571) Just a suggestion to state in the source distributin's BUILDING.txt file that compilation requires a JDK compatible with version 1.4, and that 1.5 will not work.
Just a suggestion to state in the source distributin's BUILDING.txt file that compilation requires a JDK compatible with version 1.4, and that 1.5 will not work. - Key: GERONIMO-1571 URL: http://issues.apache.org/jira/browse/GERONIMO-1571 Project: Geronimo Type: Improvement Versions: 1.0 Environment: All environments. Reporter: Steve Whitlatch Priority: Trivial Just a suggestion to state in the source distributin's BUILDING.txt file that compilation requires a JDK compatible with version 1.4, and that version 1.5 will not work. This fact is stated in various documents that help to document Geronimo, but the BUILDING.txt file is the most important place for this important piece of information. -- 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
[VOTE] 1.0.1 Release and the configId issue
There was some discussion on Irc earlier this week about the issue related to plans having to be changed due to module versions changing. This is clearly going to be a significant issues for customers as they will have to re-work all their plans on incremental server changes. Although these will most likely be tolerated in the short-term this is a serious shortcoming in the current design that needs to be addressed. During the discussion it was asserted tha given the magnitude of the change to the format of the plans and changes to G it was not appropriate for make this change in a maintenance release. The collective wisdom was to declare in the release notes this issue and give the user guidance with the assurance this is being addressed in 1.1 (or there abouts). Since there has been a lot of discussion about this already and it being such a significant issue I thought I'd request a vote to see where we stand. [ ] +1 Document issue in release notes and defer fix to 1.1 [ ] 0 Not that important one way or another [ ] -1 This is an issue that must be resolved in the 1.0.x branch [ ] Other...provide your reasons.
[jira] Closed: (GERONIMO-1571) Just a suggestion to state in the source distributin's BUILDING.txt file that compilation requires a JDK compatible with version 1.4, and that 1.5 will not work.
[ http://issues.apache.org/jira/browse/GERONIMO-1571?page=all ] Matt Hogstrom closed GERONIMO-1571: --- Fix Version: 1.0.1 1.1 Resolution: Fixed Assign To: Matt Hogstrom branches/1.0 SendingBUILDING.txt Transmitting file data . Committed revision 374274. trunk SendingBUILDING.txt Transmitting file data . Committed revision 374273. Just a suggestion to state in the source distributin's BUILDING.txt file that compilation requires a JDK compatible with version 1.4, and that 1.5 will not work. - Key: GERONIMO-1571 URL: http://issues.apache.org/jira/browse/GERONIMO-1571 Project: Geronimo Type: Improvement Versions: 1.0 Environment: All environments. Reporter: Steve Whitlatch Assignee: Matt Hogstrom Priority: Trivial Fix For: 1.0.1, 1.1 Just a suggestion to state in the source distributin's BUILDING.txt file that compilation requires a JDK compatible with version 1.4, and that version 1.5 will not work. This fact is stated in various documents that help to document Geronimo, but the BUILDING.txt file is the most important place for this important piece of information. -- 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-1572) Adjust the admin console app so that if the user does not have cookies enabled, the application presents a custom error page or popup telling the user that cookies must
Adjust the admin console app so that if the user does not have cookies enabled, the application presents a custom error page or popup telling the user that cookies must be enabled (instead of allowing the browser to present a default 408 error page) - Key: GERONIMO-1572 URL: http://issues.apache.org/jira/browse/GERONIMO-1572 Project: Geronimo Type: Improvement Components: console Versions: 1.0 Environment: All environments Reporter: Steve Whitlatch Priority: Minor Just a suggestion: In Geronimo's administration console application, adjust its behavior so that rather than dispalying an HTTP Status 408 error message, display a custom error page or popup with a message stating that for the application to work properly cookies must be enabled (that is, if that is actually the case). I found that to be the case. -- 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-1489) Minor fixes/updates to jUDDI webapp and Tomcat config
[ http://issues.apache.org/jira/browse/GERONIMO-1489?page=all ] Matt Hogstrom closed GERONIMO-1489: --- Resolution: Fixed Left the build information intact from patch2. Other hunks applied. Patches applied to branches/1.0 Sending1.0/applications/uddi-server/src/webapp/WEB-INF/web.xml Sending1.0/applications/uddi-server/src/webapp/happyjuddi.jsp Sending1.0/configs/uddi-tomcat/src/plan/plan.xml Transmitting file data ... Committed revision 374278. trunk Sendingapplications/uddi-server/src/webapp/WEB-INF/web.xml Sendingapplications/uddi-server/src/webapp/happyjuddi.jsp Sendingconfigs/uddi-tomcat/src/plan/plan.xml Transmitting file data ... Committed revision 374281. Minor fixes/updates to jUDDI webapp and Tomcat config - Key: GERONIMO-1489 URL: http://issues.apache.org/jira/browse/GERONIMO-1489 Project: Geronimo Type: Bug Components: sample apps, security Versions: 1.0 Environment: AG 1.0 on WinXP w/ Sun JDK 1.4.2_08 Reporter: Donald Woods Assignee: Donald Woods Priority: Minor Fix For: 1.0.1, 1.1 Attachments: Geronimo-1489_part1.patch, Geronimo-1489_part2.patch, Geronimo-1489_part3.patch When user accesses the console displayed webapp location of jUDDI at - http://localhost:8080/juddi Part 1 - they are presented with a directory listing with happyjuddi.jsp in it instead of the JSP automatically loading. Part 2 - when they click on the JSP, the page loads and shows system properties, which should not be displayed as any user has access to this JSP and some of the information could be used to try and hack into the system (like username and OS info) Part 3 - the uddi-tomcat configuration creates a uddi-jetty directory in the config store instead of the expected uddi-tomcat 3 separate patches will be attached for the above using the latest 1.0 branch code. -- 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-1456) geronimo-1.0-src.zip has a meta-inf folder in the root directory
[ http://issues.apache.org/jira/browse/GERONIMO-1456?page=all ] Matt Hogstrom closed GERONIMO-1456: --- Resolution: Fixed The src distribution was created with jar instead of zip. Doc will be updated to reflect this issue. geronimo-1.0-src.zip has a meta-inf folder in the root directory Key: GERONIMO-1456 URL: http://issues.apache.org/jira/browse/GERONIMO-1456 Project: Geronimo Type: Bug Components: buildsystem Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 The geronimo-1.0-src.zip has a meta-inf folder in the root directory that is at the same level as the geronimo-1.0-src directory. Needs to be fixed. All files extracted should be under the geronimo-1.0-src directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1441) Build path contains duplicate entry errors for some geronimo projects in eclipse
[ http://issues.apache.org/jira/browse/GERONIMO-1441?page=all ] John Sisson closed GERONIMO-1441: - Fix Version: 1.1 Resolution: Fixed Fixed. Tested importing projects generated from the following commands: cd geronimo maven m:eclipse -o cd .. cd assemblies maven -o -Dgoal=eclipse multiproject:goal cd .. cd configs maven -o -Dgoal=eclipse multiproject:goal cd .. cd plugins maven -o -Dgoal=eclipse multiproject:goal Build path contains duplicate entry errors for some geronimo projects in eclipse -- Key: GERONIMO-1441 URL: http://issues.apache.org/jira/browse/GERONIMO-1441 Project: Geronimo Type: Bug Components: buildsystem Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Fix For: 1.1, 1.0.1 Attachments: openejb_GERONIMO-1441.patch This error is due to project.xml files having duplicate dependencies in them. -- 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-1544) Installer - Straighten out licensing issues for IzPack sub-components.
[ http://issues.apache.org/jira/browse/GERONIMO-1544?page=all ] John Sisson updated GERONIMO-1544: -- Fix Version: 1.0.1 1.1 Installer - Straighten out licensing issues for IzPack sub-components. -- Key: GERONIMO-1544 URL: http://issues.apache.org/jira/browse/GERONIMO-1544 Project: Geronimo Type: Task Components: installer Versions: 1.0.1 Reporter: erik daughtrey Assignee: John Sisson Priority: Critical Fix For: 1.0.1, 1.1 Attachments: installer-icon-license-fix.patch, installer-icons.tgz Although IzPack itself is licensed under the ASF 2.0 license, apparently, some sub-components of IzPack are licensed under GPL or LGPL which is incompatible with the Apache Software Foundation licensing. Iron out the issues ASAP. -- 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-1544) Installer - Straighten out licensing issues for IzPack sub-components.
[ http://issues.apache.org/jira/browse/GERONIMO-1544?page=all ] John Sisson closed GERONIMO-1544: - Resolution: Fixed Installer - Straighten out licensing issues for IzPack sub-components. -- Key: GERONIMO-1544 URL: http://issues.apache.org/jira/browse/GERONIMO-1544 Project: Geronimo Type: Task Components: installer Versions: 1.0.1 Reporter: erik daughtrey Assignee: John Sisson Priority: Critical Fix For: 1.0.1, 1.1 Attachments: installer-icon-license-fix.patch, installer-icons.tgz Although IzPack itself is licensed under the ASF 2.0 license, apparently, some sub-components of IzPack are licensed under GPL or LGPL which is incompatible with the Apache Software Foundation licensing. Iron out the issues ASAP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] 1.0.1 Release and the configId issue
What's the timing? I ask with motivated by the thought that the sooner it happens, the fewer people will be affected... geir Matt Hogstrom wrote: There was some discussion on Irc earlier this week about the issue related to plans having to be changed due to module versions changing. This is clearly going to be a significant issues for customers as they will have to re-work all their plans on incremental server changes. Although these will most likely be tolerated in the short-term this is a serious shortcoming in the current design that needs to be addressed. During the discussion it was asserted tha given the magnitude of the change to the format of the plans and changes to G it was not appropriate for make this change in a maintenance release. The collective wisdom was to declare in the release notes this issue and give the user guidance with the assurance this is being addressed in 1.1 (or there abouts). Since there has been a lot of discussion about this already and it being such a significant issue I thought I'd request a vote to see where we stand. [ ] +1 Document issue in release notes and defer fix to 1.1 [ ] 0 Not that important one way or another [ ] -1 This is an issue that must be resolved in the 1.0.x branch [ ] Other...provide your reasons.
Re: License issues with commonj
I actually did read the spec and type in the classes once. (I think it was for the timer spec...?) I believe that if we do that, we have no problems because of the copyright notice in the spec. I've also discussed this issue regarding the lack of any recognizable license for their code w/ BEA and IBM, and they have made it very clear that they will provide one if needed. So the question is, type or wait for license? I say type geir David Jencks wrote: We have a patch with an implementation of the commonj timer spec. I'd like to get this into svn soon. One issue is straightening out the license provisions for the api and implementations. AFAICT commonj is a joint effort of BEA and IBM. The bea website discussing commonj is: http://dev2dev.bea.com/wlplatform/commonj/twm.html After the download links it states: This specification is being made available on an RF basis (as detailed in the Copyright notice of the specification); therefore, BEA does not require an implementation license. If you prefer, however, you may request a license from BEA to implement the specification. The specification pdf says: and earlier: (sorry about the pictures, I can't figure out how to copy out of a pdf otherwise) There is a link to a zip of source code for the api. These files contain the following license statement: /* Timer for Application Servers * Version 1.1 * Licensed Materials - Property of BEA and IBM * * © Copyright BEA Systems, Inc. and International Business Machines Corp 2003-2004. All rights reserved. */ My theory about this is that we might not need a license to write our own api classes from the javadoc, or to write implementations of the api, but that we can't simply check in the existing source code without some documentation/grants from IBM and BEA. Since there are only about 14 classes in the api it would undoubtedly be much quicker to simply write out the classes from the javadoc than seek documentations/grants. I assume that a patch to a jira issue containing apache licensed api classes, with permission granted to apache for inclusion, supported by CLA and CCLA, would also be fine. My interpretation of the statements about licensing are that we don't need a license. However I'm not at all confident I've interpreted this properly. How can we proceed? thanks david jencks
Re: [vote] XBean donation
Alan D. Cabrera wrote: Because it's a great technology that would make my life easier. A Ferrari is great technology that would make my life easier. :) (Ok, it would make it more enjoyable not easier) I encourage you to read the website for more details on the nifty things that it does. I'm sure it does great things. That wasn't my question. I'll continue this in the other thread on it... geir Regards, Alan Geir Magnusson Jr wrote, On 2/1/2006 7:53 AM: I asked a while ago and I think my question was never answered - why bring XBean into Geronimo? geir Dain Sundstrom wrote: The XBean project has voted to donate all of the code located at https://svn.codehaus.org/xbean (view with fisheye http://cvs.codehaus.org/viewrep/xbean) to Apache Geronimo. The completed IP clearance check list can be found here https://svn.codehaus.org/xbean/xbean-ip-clearance.html [+1/-1/0] Accept the XBean code donation -dain
