[jira] Closed: (GERONIMO-1172) SecurityBuilder needs to use configuration classloader to construct principals.
[ http://issues.apache.org/jira/browse/GERONIMO-1172?page=all ] David Jencks closed GERONIMO-1172: -- Resolution: Fixed Apparently the original problem is in fact solved by this change. > SecurityBuilder needs to use configuration classloader to construct > principals. > --- > > Key: GERONIMO-1172 > URL: http://issues.apache.org/jira/browse/GERONIMO-1172 > Project: Geronimo > Type: Bug > Components: security > Versions: 1.0 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0 > > Currently it uses Class.forName which only works for geronimo-supplied > principal classes. We need to pass the configuration classloader into > SecurityBuilder.buildRolePrincipalMap. -- 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] Matt Hogstrom as Release Manager (Re: Getting V1.0 out the door - first step ;-P)
On 11/16/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> +1 for Matt as the Release Manager. Let's do it :)
+1
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: [VOTE] Matt Hogstrom as Release Manager (Re: Getting V1.0 out the door - first step ;-P)
+1 John Davanum Srinivas wrote: +1 for Matt as the Release Manager. Let's do it :) Matt, Please familiarize yourself with how other projects do it and how prev releases were done. First step would be a release plan. thanks, dims On 10/19/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: All, We got a couple of +1's about getting G out the door by ApacheCon. I'd like to start formalizing our thinking about it and I think the first step is getting someone to step up and volunteer to lead the effort. I'll throw my hat in the ring as, at least for me, it will be a good learning experience in pulling everything together. And for everyone else as well so they can see how badly I suck at all things administrative :) For those more experienced and knowledgable ones out there that don't want to miss out on this great opportunity here is your opportunity to say, "No, Matt, I would love to do it!!!" In the unlikely event that I end up with the opportunity I'll start preparing by reviewing what we did last time when Jeff lead the team to Release victory. Don't be shy - Matt -- Davanum Srinivas : http://wso2.com/blogs/
Re: Apache Geronimo V1 - Documentation Draft
Nice work Hernan. Looking at the site it isn't clear to those who wish to contribute Geroniomo documentation on the Atlassian hosted Confluence wiki what the license will be for the documentation. After looking around I found the following page that says the content of this site is made available under the Apache License, but it doesn't say which version of the ASF license: http://opensource2.atlassian.com/confluence/oss/homepage.action Do you or any Confluence users know if there is there a way to have a link to the specific ASF license at the bottom of every page in the Geronimo space? I think the licensing should be clear, as documentation shouldn't be treated any differently to code contributions AFAIK. Thanks, John Hernan Cunico wrote: Hi All, I updated the documentation and now it shows up as Apache Geronimo V1 Documentation Draft reflecting the upcoming, long waited, new release. Some additions for today are: - Apache Geronimo project overview - Security -> Concepts - Security -> Login into Geronimo - Troubleshooting There is still a huge list of topics to cover like Architecture, Administration, Development and Deployment. Is there anyone who volunteers to contribute to any of these topics? http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692 Cheers! Hernan
[jira] Commented: (GERONIMO-1172) SecurityBuilder needs to use configuration classloader to construct principals.
[ http://issues.apache.org/jira/browse/GERONIMO-1172?page=comments#action_12357837 ] James Liao commented on GERONIMO-1172: -- Previous test fail is caused by my wrong configuration. Now it works fine. This issue could be closed. Thanks! > SecurityBuilder needs to use configuration classloader to construct > principals. > --- > > Key: GERONIMO-1172 > URL: http://issues.apache.org/jira/browse/GERONIMO-1172 > Project: Geronimo > Type: Bug > Components: security > Versions: 1.0 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0 > > Currently it uses Class.forName which only works for geronimo-supplied > principal classes. We need to pass the configuration classloader into > SecurityBuilder.buildRolePrincipalMap. -- 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-1195) Present a Welcome Portlet with Geronimo information after login
Present a Welcome Portlet with Geronimo information after login --- Key: GERONIMO-1195 URL: http://issues.apache.org/jira/browse/GERONIMO-1195 Project: Geronimo Type: Improvement Components: console Versions: 1.0 Environment: all Reporter: Joe Bohn Assigned to: Joe Bohn Fix For: 1.0 Provide a Welcome portlet and have this launched when the user first logs in to the Geronimo Console. This should be similar to the Welcome Page and container similar 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
Re: Tomcat Examples in Geronimo - needed for v1
1 Is doable...I just need to wrap them up and place them in the Apache java-repo and they will get picked up by ibiblio automajically. I would want to hear from others before doing it though. Jeff Dave Colasurdo wrote: I'd like to pursue option 1 below.. Can someone please provide insight? If not, is option 2 acceptable? Does anyone care? :>) Thanks -Dave- Dave Colasurdo wrote: GERONIMO-1087 and GERONIMO-1088 JIRAs were opened to introduce the Tomcat examples into Geronimo. I believe it is important to get these introduced into the distributions (as default samples) for v1. There are a few different ways to approach this: 1) Ask Tomcat to create a war file for servlet-examples and jsp-examples and post it to http://www.ibiblio.org/maven/tomcat/ We pick up this dependency during our build and include it in the appropriate distributions. 2) We grab the exploded wars from the Tomcat binary (as there is no war file) and manually create the war files and place them in some repository where the geronimo build can find it. 3) We fork the tomcat source for these examples and build them within Geronimo. AFAIK, Tomcat uses ANT to build. Would need to massage this to work with maven accounting for the custom ant tasks and dependent jar files. 4) We grab the exploded wars (not source) from the Tomcat binary (as there is no war file) and create the war files within the geronimo build structure. Need to decide how to account for the jar files and whether to regenerate the class files. This is really a lightweight fork :>) I prefer option 1 as it seems the most straightforward and keeps Geronimo out of the business of maintaining tomcat examples. However, there is one small concern with this approach "There are a few words on the Tomcat examples that may need to be tweaked since these samples will run both with the Jetty and Tomcat web containers. Specifically, "These examples will only work when these pages are being served by a servlet engine; of course, we recommend Tomcat." AND "Please refer to the README file provide with this Tomcat release regarding how to configure and start the provided web server." It seems crazy to fork the samples due to a few minor words of text.. Perhaps our build can download the wars from ibiblio, crack them open and perform a quick regexp to remove the offending lines.. (or we can ask Tomcat to remove them). How do we approach Tomcat to get the wars placed in ibiblio? Can anyone help here? Thanks -Dave-
[jira] Created: (GERONIMO-1194) Installer should only install packs(features) selected at install time
Installer should only install packs(features) selected at install time -- Key: GERONIMO-1194 URL: http://issues.apache.org/jira/browse/GERONIMO-1194 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: Maven, installer runtime Reporter: erik daughtrey DJ: The installer currently works by installing everything in a full geronimo install, and not starting the pieces you don't want. This is rather unsatisfactory unless you sell disk space. The geronimo assembly is moving to use of the packaging and assembly plugins, and we can leverage that with the installer. What I am thinking of is including a maven repository inside the installer jar that includes everything from a full geronimo install with everything, including all the .car files for the configurations. Then we can imitate or use the assembly plugin to copy the configuration dependencies into the install target and install the actual configurations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Tomcat Examples in Geronimo - needed for v1
I'd like to pursue option 1 below.. Can someone please provide insight? If not, is option 2 acceptable? Does anyone care? :>) Thanks -Dave- Dave Colasurdo wrote: GERONIMO-1087 and GERONIMO-1088 JIRAs were opened to introduce the Tomcat examples into Geronimo. I believe it is important to get these introduced into the distributions (as default samples) for v1. There are a few different ways to approach this: 1) Ask Tomcat to create a war file for servlet-examples and jsp-examples and post it to http://www.ibiblio.org/maven/tomcat/ We pick up this dependency during our build and include it in the appropriate distributions. 2) We grab the exploded wars from the Tomcat binary (as there is no war file) and manually create the war files and place them in some repository where the geronimo build can find it. 3) We fork the tomcat source for these examples and build them within Geronimo. AFAIK, Tomcat uses ANT to build. Would need to massage this to work with maven accounting for the custom ant tasks and dependent jar files. 4) We grab the exploded wars (not source) from the Tomcat binary (as there is no war file) and create the war files within the geronimo build structure. Need to decide how to account for the jar files and whether to regenerate the class files. This is really a lightweight fork :>) I prefer option 1 as it seems the most straightforward and keeps Geronimo out of the business of maintaining tomcat examples. However, there is one small concern with this approach "There are a few words on the Tomcat examples that may need to be tweaked since these samples will run both with the Jetty and Tomcat web containers. Specifically, "These examples will only work when these pages are being served by a servlet engine; of course, we recommend Tomcat." AND "Please refer to the README file provide with this Tomcat release regarding how to configure and start the provided web server." It seems crazy to fork the samples due to a few minor words of text.. Perhaps our build can download the wars from ibiblio, crack them open and perform a quick regexp to remove the offending lines.. (or we can ask Tomcat to remove them). How do we approach Tomcat to get the wars placed in ibiblio? Can anyone help here? Thanks -Dave-
Startup Scripts - foreground and background
Have attached the patches for both unix (.sh) and windows (.bat) environments to GERONIMO-1166. Please test them out.. Thanks -Dave- Dave Colasurdo wrote: I've opened a JIRA for this issue and created a patch for the windows platform. Still investigating the unix environment... http://issues.apache.org/jira/browse/GERONIMO-1166 John Sisson wrote: Hi Dave, I don't think I had any objections to making the startup scripts follow Tomcat as much as possible. See the following discussions on scripts, I think there were a number of issues discussed that we need to cover: http://www.mail-archive.com/dev@geronimo.apache.org/msg05926.html http://www.mail-archive.com/dev@geronimo.apache.org/msg05851.html http://www.mail-archive.com/dev@geronimo.apache.org/msg06483.html Regards, John Dave Colasurdo wrote: Jeff Genender wrote: Dave Colasurdo wrote: The shutdown scripts are a step forward in usability over manually killing the java process via CTL-C. While quite simple, CTL-C does not seem very user friendly and should not be the default mechanism. I really don't believe there is a default mechanism, IMHO. I think we are offering multiple ways to do the same thing. The CTRL-C would be heavily used by developers. The shutdown script could be used by people using a daemon or backgrounding the server (which is easily done on both Windows and *nix systems) or a remote server. The console would/maybe be used by mouse-clicking administrators. I would surely hope that in a prod environment one is not running the server in a terminal window ;-) However, it does seem strange that a user needs to open a new window to shutdown the server. Seems like the initial startup command should return the command prompt back to the user so that shutdown can be issued from the same window. One way to accomplish this is to have the startup script launch a new window that controls the java process (and output the startup messages) while the initial prompt is returned to the user. This would allow the shutdown to be issued from the initial window. For a developer (and me being selfish), running in a terminal window is not strange and it seems to be the norm from a command line perspective, rather than the exception. IMHO, ss a developer, sending the server into the background is not appealing. I think if one wants control over their terminal, they could issue a startup.sh& (notice the ampersand) to background the process. Quite possibly we could also add another script called startup_background.sh (or bat) that could so this as well. We could also create daemon scripts for the different platforms. Wasn't there a JIRA issue for an NT Service for Windows? We could add init.d scripts for Unix too. I agree the current behavior is appropriate for a developer. I was thinking more about end users. Similar to your suggestion, should we consider adding an option to the startup.sh|bat script to put the process in background? Actually, I'm wondering if the default behavior (startup.sh|bat w/o any options) should be geared toward end users and would run the process in background. And specifying the option (-foreground) would allow the process to be run in the current window for developers. Of course, windows service and init.d are also useful. I think both proposals are worth pursuing Will look to see if there are current JIRAs open on these.. Also, if we ever support sharing one binary installation that can start multiple instances of geronimo (each with it's own unique configuration) then we will also likely need this behavior. -Dave-
[jira] Updated: (GERONIMO-1166) Enhance Startup scripts to allow process to be launched in background
[ http://issues.apache.org/jira/browse/GERONIMO-1166?page=all ] Dave Colasurdo updated GERONIMO-1166: - Attachment: startup.sh.patch Here is the patch for unix environments. > Enhance Startup scripts to allow process to be launched in background > - > > Key: GERONIMO-1166 > URL: http://issues.apache.org/jira/browse/GERONIMO-1166 > Project: Geronimo > Type: Improvement > Components: startup/shutdown > Versions: 1.0 > Reporter: Dave Colasurdo > Attachments: startup.patch, startup.sh.patch > > Add new keywords to startup scripts that control whether the process gets > launched in the current window/process or in a separate background > window/process. > New keywords are: > -foreground (or -fg) > -background (or -bg) > default is for a background session > For windows platform: Will launch process in a separate window. > For unix platforms: Will launch as a background process -- 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] Matt Hogstrom as Release Manager (Re: Getting V1.0 out the door - first step ;-P)
Oh yea! +1 for me not doing it ^H^H^H .. I mean for Matt. Go Matt! -David On Nov 16, 2005, at 2:19 PM, Davanum Srinivas wrote: +1 for Matt as the Release Manager. Let's do it :) Matt, Please familiarize yourself with how other projects do it and how prev releases were done. First step would be a release plan. thanks, dims On 10/19/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: All, We got a couple of +1's about getting G out the door by ApacheCon. I'd like to start formalizing our thinking about it and I think the first step is getting someone to step up and volunteer to lead the effort. I'll throw my hat in the ring as, at least for me, it will be a good learning experience in pulling everything together. And for everyone else as well so they can see how badly I suck at all things administrative :) For those more experienced and knowledgable ones out there that don't want to miss out on this great opportunity here is your opportunity to say, "No, Matt, I would love to do it!!!" In the unlikely event that I end up with the opportunity I'll start preparing by reviewing what we did last time when Jeff lead the team to Release victory. Don't be shy - Matt -- Davanum Srinivas : http://wso2.com/blogs/
Re: AMD Opteron Equipment for Development/Testing
On Nov 16, 2005, at 2:25 PM, Winston Damarillo wrote: Kyle, Very cool ! If the machines need to live in a datacenter with some admin support. we would be glad to host it at Simula's cage along with the other gbuild servers. That would actually be extremely convenient. Nice to have a fast switch between the boxes rather than a large span of internet. -David Best, Winston Simula Labs On 11/16/05, Barry van Someren <[EMAIL PROTECTED]> wrote: Send me some hardware, I'll really help with the testing ;-) Great job though :) On 11/16/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > Thanks for the infusion Kyle. This is excellent. > > Once the donation is made we should probably update our Website acknowledging > AMD's contribution and commitment :) > > David Blevins wrote: > > > > On Nov 15, 2005, at 5:19 PM, Bruce Snyder wrote: > >> > >> BTW, we should set up a page on the website that lists all the > >> hardware contributions as a thank you to the contributors. > >> > > > > Been meaning to do that. Thanks for the kick the pants. > > > > Here it is! > > > > http://wiki.apache.org/geronimo/GBuild > > > > We can definitely move that to the website, just threw that up for > > starters. > > > > -David > > > > > > > > > >
Re: m2: flushing out our dependencies
On Nov 16, 2005, at 2:59 PM, Prasad Kashyap wrote: OK.. with the latest run of mvn -U, here's the deal on these 3 jars activemq-core-test: dependency specified by activemq-core, activemq- optional and activemq-ra. It may be that that library isn't even required at runtime, in which case it can be left in but flagged as test. Hiram, you know? I'm not sure that this would fix the issue for us as in if we use the dep in test does it's test deps become requied too? Brett, any ideas? javacc: not needed anymore, I guess. I patched the activemq-core-3.2.pom to comment out javacc-2.1. That was kind of a hack on my part, but it was the only things standing in the way between me and using m2 in gbuild, so I did it. If you could create a pom.xml for javacc-2.1, you'd be a better man than I. xmlbeans-jsr173-api: not needed anymore, I guess. It was required by the stax-1.1.1-dev.pom. Carlos from the maven crew put in this exlusion for it, which is one of the many things I didn't know you could even do. Check it out: stax stax 1.1.1-dev xmlbeans xmlbeans-jsr173-api Kind of interesting. Might be useful to us for other deps. And while we are looking at activemq-core-3.2.pom, we should also fix the version number for smack and smackx. The specified version is 1.5 whereas version 1.5.0 exists in the m2 repo. The activemq-core-3.2.pom from the svn repo is using 1.5.0. Not sure your pom is current. This resolves all the deps I signed up for. Now I need to create patches and get them uploaded. Awesome. Excellent work! -David
Re: [VOTE] Matt Hogstrom as Release Manager (Re: Getting V1.0 out the door - first step ;-P)
+1 (from a non-committer)On 11/16/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote: +1 for Matt as the Release Manager. Let's do it :)Matt,Please familiarize yourself with how other projects do it and how prevreleases were done. First step would be a release plan.thanks,dims On 10/19/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote:> All,>> We got a couple of +1's about getting G out the door by ApacheCon. I'd like to> start formalizing our thinking about it and I think the first step is getting > someone to step up and volunteer to lead the effort.>> I'll throw my hat in the ring as, at least for me, it will be a good learning> experience in pulling everything together. And for everyone else as well so > they can see how badly I suck at all things administrative :)>> For those more experienced and knowledgable ones out there that don't want to> miss out on this great opportunity here is your opportunity to say, "No, Matt, I > would love to do it!!!">> In the unlikely event that I end up with the opportunity I'll start preparing by> reviewing what we did last time when Jeff lead the team to Release victory. >> Don't be shy>> - Matt>>--Davanum Srinivas : http://wso2.com/blogs/
Re: [VOTE] Matt Hogstrom as Release Manager (Re: Getting V1.0 out the door - first step ;-P)
+1 david jencks On Nov 16, 2005, at 2:19 PM, Davanum Srinivas wrote: +1 for Matt as the Release Manager. Let's do it :) Matt, Please familiarize yourself with how other projects do it and how prev releases were done. First step would be a release plan. thanks, dims On 10/19/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: All, We got a couple of +1's about getting G out the door by ApacheCon. I'd like to start formalizing our thinking about it and I think the first step is getting someone to step up and volunteer to lead the effort. I'll throw my hat in the ring as, at least for me, it will be a good learning experience in pulling everything together. And for everyone else as well so they can see how badly I suck at all things administrative :) For those more experienced and knowledgable ones out there that don't want to miss out on this great opportunity here is your opportunity to say, "No, Matt, I would love to do it!!!" In the unlikely event that I end up with the opportunity I'll start preparing by reviewing what we did last time when Jeff lead the team to Release victory. Don't be shy - Matt -- Davanum Srinivas : http://wso2.com/blogs/
Re: m2: flushing out our dependencies
OK.. with the latest run of mvn -U, here's the deal on these 3 jars activemq-core-test: dependency specified by activemq-core, activemq-optional and activemq-ra. javacc: not needed anymore, I guess. xmlbeans-jsr173-api: not needed anymore, I guess. And while we are looking at activemq-core-3.2.pom, we should also fix the version number for smack and smackx. The specified version is 1.5 whereas version 1.5.0 exists in the m2 repo. This resolves all the deps I signed up for. Now I need to create patches and get them uploaded. Cheers Prasad On 11/16/05, David Blevins <[EMAIL PROTECTED]> wrote: On Nov 16, 2005, at 9:13 AM, David Jencks wrote:>> On Nov 16, 2005, at 8:20 AM, Prasad Kashyap wrote: >>> org.apache.geronimo.fake || m2assembly || 1.0-SNAPSHOT || ???> no idea... obviously it is supposed to be something we control...That shouldn't be in the list. I created the m2assebly module just as convenience so people could have something to run and try out thepoms and see where things are at. Its just all the deps from ourassembly module thrown into an empty maven2 module. http://www.mail-archive.com/dev@geronimo.apache.org/msg11801.html-David
[jira] Commented: (GERONIMO-1184) Decouple the connector module from the kernel module
[ http://issues.apache.org/jira/browse/GERONIMO-1184?page=comments#action_12357829 ] Jason Dillon commented on GERONIMO-1184: Why does simply using a Geronimo class force the installation of its log factory? > Decouple the connector module from the kernel module > > > Key: GERONIMO-1184 > URL: http://issues.apache.org/jira/browse/GERONIMO-1184 > Project: Geronimo > Type: Bug > Components: connector > Reporter: Guillaume Nodet > Assignee: David Jencks > > Since revision 331909, the > o.a.g.connector.outbound.AbstractConnectionMaanager implements > o.a.g.gbean.GBeanLifeCycle. > Thus the whole connector module is dependant on the kernel module. > The jencks project now has to ship the kernel module also which has some > drawbacks : the geronimo log is used instead of > the default one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Apache Geronimo V1 - Documentation Draft
Hi All, I updated the documentation and now it shows up as Apache Geronimo V1 Documentation Draft reflecting the upcoming, long waited, new release. Some additions for today are: - Apache Geronimo project overview - Security -> Concepts - Security -> Login into Geronimo - Troubleshooting There is still a huge list of topics to cover like Architecture, Administration, Development and Deployment. Is there anyone who volunteers to contribute to any of these topics? http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692 Cheers! Hernan
Re: AMD Opteron Equipment for Development/Testing
Kyle, Very cool ! If the machines need to live in a datacenter with some admin support. we would be glad to host it at Simula's cage along with the other gbuild servers. Best, Winston Simula Labs On 11/16/05, Barry van Someren <[EMAIL PROTECTED]> wrote: Send me some hardware, I'll really help with the testing ;-)Great job though :)On 11/16/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote:> Thanks for the infusion Kyle. This is excellent. >> Once the donation is made we should probably update our Website acknowledging> AMD's contribution and commitment :)>> David Blevins wrote:> >> > On Nov 15, 2005, at 5:19 PM, Bruce Snyder wrote: > >>> >> BTW, we should set up a page on the website that lists all the> >> hardware contributions as a thank you to the contributors.> >>> >> > Been meaning to do that. Thanks for the kick the pants. > >> > Here it is!> >> > http://wiki.apache.org/geronimo/GBuild> >> > We can definitely move that to the website, just threw that up for > > starters.> >> > -David> >> >> >> >>>
Re: [VOTE] Matt Hogstrom as Release Manager (Re: Getting V1.0 out the door - first step ;-P)
+1 Davanum Srinivas wrote: +1 for Matt as the Release Manager. Let's do it :) Matt, Please familiarize yourself with how other projects do it and how prev releases were done. First step would be a release plan. thanks, dims On 10/19/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: All, We got a couple of +1's about getting G out the door by ApacheCon. I'd like to start formalizing our thinking about it and I think the first step is getting someone to step up and volunteer to lead the effort. I'll throw my hat in the ring as, at least for me, it will be a good learning experience in pulling everything together. And for everyone else as well so they can see how badly I suck at all things administrative :) For those more experienced and knowledgable ones out there that don't want to miss out on this great opportunity here is your opportunity to say, "No, Matt, I would love to do it!!!" In the unlikely event that I end up with the opportunity I'll start preparing by reviewing what we did last time when Jeff lead the team to Release victory. Don't be shy - Matt -- Davanum Srinivas : http://wso2.com/blogs/
[VOTE] Matt Hogstrom as Release Manager (Re: Getting V1.0 out the door - first step ;-P)
+1 for Matt as the Release Manager. Let's do it :) Matt, Please familiarize yourself with how other projects do it and how prev releases were done. First step would be a release plan. thanks, dims On 10/19/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > All, > > We got a couple of +1's about getting G out the door by ApacheCon. I'd like > to > start formalizing our thinking about it and I think the first step is getting > someone to step up and volunteer to lead the effort. > > I'll throw my hat in the ring as, at least for me, it will be a good learning > experience in pulling everything together. And for everyone else as well so > they can see how badly I suck at all things administrative :) > > For those more experienced and knowledgable ones out there that don't want to > miss out on this great opportunity here is your opportunity to say, "No, > Matt, I > would love to do it!!!" > > In the unlikely event that I end up with the opportunity I'll start preparing > by > reviewing what we did last time when Jeff lead the team to Release victory. > > Don't be shy > > - Matt > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Geronimo ORB progress
Sounds cool. Just to give you some direct guidance, you probably should have shot an email out to the group saying "what do you guys do for testing when more than one VM is involved" or "we have this idea for testing in more than one VM, what do you think?" Not a big deal, you're here, you want to do good work, we can work with that. Here is the reply I would have given to the above questions. I've Cc'ed James and Vincent as I know they are working on or have slightly similar things. Sounds like a neat idea. We have the itests plugin and the a bunch of tests that use the itest plugin. We definitely want more. Ideally we'd have them for all the major compoments aside from just ejb, persistence, and rmi stuff. The basic idea behind itests that makes them slightly different than plain junit tests ran by maven is that it's assumed that there are other systems (servers, databases, brokers, etc) that need to be started or connected to before the tests can run. The tests themselves don't setup the other systems themselves so that the tests don't become coupled with them and you can actually swap out various aspects of those systems behind the back of the tests; server version, protocol implementation, java version, VM implementation, database provider, operating systems, even using embedded servers and embedded databases. The idea actually evolved from the tests in OpenEJB that do this. It took a lot of work to get them to run as part of the build and the itest plugin was the result. So now we can easily boot up geronimo, derby, axion, activemq or whatever in whatever vm and on whatever OS and run the exact same tests to see how things are. Definitely give those a look at: http://cvs.openejb.org/viewrep/ openejb/openejb/modules/itests/src/java/org/openejb/test Those particular tests allow you to plug in facades for the server and the database so the client (the tests) can say "give me an initial context" or "create these tables i need" in a generic way. It's assumed that those systems were setup and guaranteed in working state in the itest setup phase. It's also guaranteed that the server and database facades know how to contact the server or database to carry out the "give me an initial context" and "create these tables" calls. Here are some implementations of the database provider for reference: http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/ itest/org/openejb/test/AxionTestDatabase.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/ itest/org/openejb/test/DerbyTestDatabase.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/ itest/org/openejb/test/InstantDbTestDatabase.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/ itest/org/openejb/test/PostgreSqlTestDatabase.java Here are some implementations for the server facades: http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/ itest/org/openejb/test/CorbaTestServer.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/ itest/org/openejb/test/RemoteTestServer.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/ itest/org/openejb/test/IvmTestServer.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/ itest/org/openejb/test/RiTestServer.java Using the itest concept you could setup any system you need before hand, then just provide an abstraction of that system to the actual tests. So it's not limited to just a server or a database. You could do queue, topic, clustering heartbeat agent, directory server, etc. Even with just what we have we can get quite far. In a perfect world, we would actually test against the full matrix: Server: Local, Database: Axion Server: Local, Database: Derby Server: Local, Database: PostgreSQL Server: Remote, Database: Axion Server: Remote, Database: Derby Server: Remote, Database: PostgreSQL Server: Corba, Database: Axion Server: Corba, Database: Derby Server: Corba, Database: PostgreSQL I had that going for a short while years ago but it was just too much infrastructure for me to keep running. It would be nice to get Oracle and MySQL in that list as well. In an even more perfect world we'd test against not just different Server and Database combinations, but JVM versions as well. Server: Local, Database: Axion, JVM: 1.3 Server: Local, Database: Axion, JVM: 1.4 Server: Local, Database: Axion, JVM: 1.5 Server: Local, Database: Derby, JVM: 1.3 Server: Local, Database: Derby, JVM: 1.4 Server: Local, Database: Derby, JVM: 1.5 Server: Local, Database: PostgreSQL, JVM: 1.3 Server: Local, Database: PostgreSQL, JVM: 1.4 Server: Local, Database: PostgreSQL, JVM: 1.5 Server: Remote, Database: Axion, JVM: 1.3 Server: Remote, Database: Axion, JVM: 1.4 Server: Remote, Database: Axion, JVM: 1.5 Server: Remote, Database: Der
Re: Contributors permission in JIRA
Do I have enough Karma to have JIRAs assigned to me? Specifically, I'm interested in 1188-1193 for the installer. Regards, erik On Tuesday 01 November 2005 18:24, Dain Sundstrom wrote: > Since on one objected, I added a geronimo-contributers group that can > assign, resolve and be assigned issues. If this is becomes an issue > the group can be removed just as easily as it was added. > > If you are a contributor (i.e. you have submitted some patches) and > would like to be able to be assigned issues, let us know and we can > grant you karma. Please, only ask if you have actually contributed > and need the ability to work on issues. > > Thanks, > > -dain > > On Oct 28, 2005, at 11:11 AM, Dain Sundstrom wrote: > > I'd like to create a geronimo-contributors group in jira. We would > > give contributors permission to assign, move, and resolve issues > > but not close them. This will let the committers know what > > everyone is working on, and will hopefully help those working on > > earning commit get used to JIRA. > > > > What do you think? > > > > -dain -- Regards, Erik
[jira] Updated: (GERONIMO-1189) Installer should be built from its own module in assemblies.
[ http://issues.apache.org/jira/browse/GERONIMO-1189?page=all ] David Jencks updated GERONIMO-1189: --- Attachment: installer.jar For those with archaeological curiousity I'm attaching an attempt I made to make an installer module that started with the output of our current assembly. There might or might not be anything useful in it for an installer based on something like the assembly plugin. > Installer should be built from its own module in assemblies. > > > Key: GERONIMO-1189 > URL: http://issues.apache.org/jira/browse/GERONIMO-1189 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0 > Environment: Maven > Reporter: erik daughtrey > Attachments: installer.jar > > It would be best to build using a Maven plugin. Otherwise, if impractical, > use jelly. There seems to be an installer plugin for Maven 2, but not for the > current build. -- 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-1193) Installer should include schema files for components included in the install target
Installer should include schema files for components included in the install target --- Key: GERONIMO-1193 URL: http://issues.apache.org/jira/browse/GERONIMO-1193 Project: Geronimo Type: New Feature Components: installer Versions: 1.0 Environment: Maven, installer runtime Reporter: erik daughtrey DJ: "This should proceed by fixing the xmlbeans plugin to put schemas in the same place the xmlbeans ant task does, and by extracting all such schemas from our dependencies. This needs to be added to the assembly plugin: it is not installer specific." -- 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-1192) Installer should create a config.xml for the target install
Installer should create a config.xml for the target install --- Key: GERONIMO-1192 URL: http://issues.apache.org/jira/browse/GERONIMO-1192 Project: Geronimo Type: New Feature Components: installer Versions: 1.0 Environment: Installer runtime Reporter: erik daughtrey DJ - "This could be done by adding bits associated with each configuration, or by removing chunks from a 'universal' config.xml for the configuations we didn't install." -- 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-1191) Installer should not allow conflicting configuration information
Installer should not allow conflicting configuration information Key: GERONIMO-1191 URL: http://issues.apache.org/jira/browse/GERONIMO-1191 Project: Geronimo Type: New Feature Components: installer Versions: 1.0 Environment: Installer runtime -- all platfoms Reporter: erik daughtrey Currently, the installer does not verify that conflicting ports may have been configured by the operator. Fixing this problem requires encoding of the potential field conflicts on an inter-panel and intra-panel basis. Ultimately, it would be great to factor environmental information into the equation, but that's "boiling the ocean". -- 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-1190) usability: Install should not display configuration screens for packs not being installed
usability: Install should not display configuration screens for packs not being installed - Key: GERONIMO-1190 URL: http://issues.apache.org/jira/browse/GERONIMO-1190 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: installer runtime on all platforms Reporter: erik daughtrey It's possible that the element, when properly leveraged, may allow this capability. -- 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-1189) Installer should be built from its own module in assemblies.
Installer should be built from its own module in assemblies. Key: GERONIMO-1189 URL: http://issues.apache.org/jira/browse/GERONIMO-1189 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: Maven Reporter: erik daughtrey It would be best to build using a Maven plugin. Otherwise, if impractical, use jelly. There seems to be an installer plugin for Maven 2, but not for the current build. -- 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-1188) Get necessary izpack jars into Maven repository for access during build
Get necessary izpack jars into Maven repository for access during build --- Key: GERONIMO-1188 URL: http://issues.apache.org/jira/browse/GERONIMO-1188 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: maven and maven repository Reporter: erik daughtrey As Aaron points out, there's probably only one jar needed. David J would like to see this in a public repository such as ibiblio. -- 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-1184) Decouple the connector module from the kernel module
[ http://issues.apache.org/jira/browse/GERONIMO-1184?page=all ] David Jencks closed GERONIMO-1184: -- Resolution: Fixed I think this should fix the problem without introducing other ones. Let me know if there are further difficulties. Sending modules/connector/src/java/org/apache/geronimo/connector/outbound/AbstractConnectionManager.java Sending modules/connector/src/java/org/apache/geronimo/connector/outbound/GenericConnectionManagerGBean.java Transmitting file data .. Committed revision 345097. > Decouple the connector module from the kernel module > > > Key: GERONIMO-1184 > URL: http://issues.apache.org/jira/browse/GERONIMO-1184 > Project: Geronimo > Type: Bug > Components: connector > Reporter: Guillaume Nodet > Assignee: David Jencks > > Since revision 331909, the > o.a.g.connector.outbound.AbstractConnectionMaanager implements > o.a.g.gbean.GBeanLifeCycle. > Thus the whole connector module is dependant on the kernel module. > The jencks project now has to ship the kernel module also which has some > drawbacks : the geronimo log is used instead of > the default one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: m2: flushing out our dependencies
On Nov 16, 2005, at 9:13 AM, David Jencks wrote: On Nov 16, 2005, at 8:20 AM, Prasad Kashyap wrote: org.apache.geronimo.fake || m2assembly || 1.0-SNAPSHOT || ??? no idea... obviously it is supposed to be something we control... That shouldn't be in the list. I created the m2assebly module just as convenience so people could have something to run and try out the poms and see where things are at. Its just all the deps from our assembly module thrown into an empty maven2 module. http://www.mail-archive.com/dev@geronimo.apache.org/msg11801.html -David
Re: m2: flushing out our dependencies
On Nov 16, 2005, at 11:01 AM, Prasad Kashyap wrote: castor 0.9.9: Maybe Blevins can answer this. It's in the pom.xml of the m2assembly project. This pom.xml is actually a compilation of all our project.xmls. But our project.xml has castor listed as 0.9.5.3 . Castor 0.9.5.3 will be fine. I though my old wsdl code in the webservices module was the only one using it so I took the liberty of upgrading the version to 0.9.9 as its more recent. I'm cool with whatever version. activemq-core-test: javacc: xmlbeans-jsr173-api: The above 3 are seen in the log generatd by the mvn -U command. They are not found in either the pom.xml or in any of our project.xmls. (http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/% [EMAIL PROTECTED] ) Run the m2assembly build again and see if they are still required. On 11/16/05, David H. DeWolf <[EMAIL PROTECTED]> wrote: Pluto's dependency is currently listed as: 0.9.5.3 I think 0.9.9 is from something else. David On 11/16/05, David Jencks <[EMAIL PROTECTED]> wrote: > > On Nov 16, 2005, at 8:20 AM, Prasad Kashyap wrote: > > > Of the 14 missing jars, I was able to track down all but 5. I had some > > Qs about those 5 - > > > > castor ||castor || 0.9.9 || 0.9.9.1 exists. Update pom to use this ? > what is using castor? I think pluto is, anything else? > > > org.apache.geronimo.fake ||m2assembly || 1.0-SNAPSHOT || ??? > no idea... obviously it is supposed to be something we control... > > > activemq || activemq-core-test || 3.2 || can't trace this yet. > I doubt we actually need this, can you figure out what tries to pull it > in? > > > javacc || javacc || 2.1 || [WARNING] This artifact has been relocated > > to javax.sql:jdbc-stdext:2.0. > It seems to me that this must be a mistake somewhere. > > > xmlbeans || xmlbeans-jsr173-api || 2.0-dev || can't trace this yet. > for the m1 build we are using stax/jars/stax- api-1.0.jar. Again, can > you trace where this requirement comes from? Is there a generic m2 > tool to trace where missing dependencies are required? > > thanks > david jencks > > > > > > Suggestions ? Advice ? > > > > Cheers > > Prasad > > > > On 11/11/05, Brett Porter <[EMAIL PROTECTED] > wrote: > >> Hi David, > >> > >> Certainly, they should be put into the main repository (via an > >> evangelism issue). For the specs ones, these are probably older than > >> trunk that has the poms - but I'd expect them to be the same or > >> similar - so definitely use those. They'll still need to be uploaded. > >> > >> - Brett > >> > >> On 11/12/05, David Jencks < [EMAIL PROTECTED]> wrote: > >> > > >> > On Nov 11, 2005, at 11:00 AM, Prasad Kashyap wrote: > >> > > >> > > I'm done creating poms for the 17 modules in the attached text > >> file. > >> > > > >> > >I was able to get some jars (same version and all) from the M1 > >> > > repository. I need to track down the other jars. > >> > > > >> > >Next I need to figure out how to create a patch from the > >> repository > >> > > jars. TortoiseSVN doesn't seem to help me there. Any tips here > >> would > >> > > be appreciated. > >> > > > >> > >Should I create 1 JIRA for all these 17 modules or should each > >> module > >> > > have it's own JIRA ? > >> > > > >> > >Cheers > >> > >Prasad > >> > > > >> > > > >> > > > >> > I'm worriedthat duplicate work is happening. The geronimo-specs > >> > already have an m2 build so I wouldthink they all have valid m2 > >> poms. > >> > I believe jeff genender has valid activemq poms from his work with > >> > wadi. > >> > > >> > I certainly don't know what should happen with these poms now that > >> they > >> > exist.I don't think keeping them private to geronimo is likely to > >> be > >> > the best practice.Should we open one issue/pom in maven > >> evangelism? > >> > Jason? Brett? > >> > > >> > thanks > >> > david jencks > >> > > >> > > >
[jira] Commented: (GERONIMO-1135) Keystore password in System.properties
[ http://issues.apache.org/jira/browse/GERONIMO-1135?page=comments#action_12357808 ] Kevan Miller commented on GERONIMO-1135: >From my scan of the code, looks like the properties are being set by >security\src\java\org\apache\geronimo\security\SecurityServiceImpl.java This isn't my cup-of-tea, but it seems that the properties are the only mechanism for specifying these passwords. I've seen some doc (http://java.sun.com/products/jsse/install.html) that implies the System properties are cleared when the default SSLContext and default TrustManagerFactory are initialized. So, it may be a matter of performing the appropriate initialization and the appropriate time. Barring that, we'd need to have the security manager block access. I'll have a look... > Keystore password in System.properties > -- > > Key: GERONIMO-1135 > URL: http://issues.apache.org/jira/browse/GERONIMO-1135 > Project: Geronimo > Type: Bug > Components: security > Versions: 1.0-M5 > Reporter: Aaron Mulder > Priority: Critical > Fix For: 1.0 > > If you look at the System properties, the keystore and trust store passwords > are in there. I'm not sure who puts them in there, but we need to find a way > to stop that -- or else prevent applications from reading 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
Re: m2: flushing out our dependencies
castor 0.9.9: Maybe Blevins can answer this. It's in the pom.xml of the m2assembly project. This pom.xml is actually a compilation of all our project.xmls. But our project.xml has castor listed as 0.9.5.3 . activemq-core-test: javacc: xmlbeans-jsr173-api:The above 3 are seen in the log generatd by the mvn -U command. They are not found in either the pom.xml or in any of our project.xmls. (http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL PROTECTED] ) Cheers Prasad On 11/16/05, David H. DeWolf <[EMAIL PROTECTED]> wrote: Pluto's dependency is currently listed as:0.9.5.3I think 0.9.9 is from something else.DavidOn 11/16/05, David Jencks <[EMAIL PROTECTED]> wrote:>> On Nov 16, 2005, at 8:20 AM, Prasad Kashyap wrote: >> > Of the 14 missing jars, I was able to track down all but 5. I had some> > Qs about those 5 -> >> > castor ||castor || 0.9.9 || 0.9.9.1 exists. Update pom to use this ? > what is using castor? I think pluto is, anything else?>> > org.apache.geronimo.fake ||m2assembly || 1.0-SNAPSHOT || ???> no idea... obviously it is supposed to be something we control... >> > activemq || activemq-core-test || 3.2 || can't trace this yet.> I doubt we actually need this, can you figure out what tries to pull it> in?>> > javacc || javacc || 2.1 || [WARNING] This artifact has been relocated > > to javax.sql:jdbc-stdext:2.0.> It seems to me that this must be a mistake somewhere.>> > xmlbeans || xmlbeans-jsr173-api || 2.0-dev || can't trace this yet.> for the m1 build we are using stax/jars/stax- api-1.0.jar. Again, can> you trace where this requirement comes from? Is there a generic m2> tool to trace where missing dependencies are required?>> thanks> david jencks> > > >> > Suggestions ? Advice ?> >> > Cheers> > Prasad> >> > On 11/11/05, Brett Porter <[EMAIL PROTECTED] > wrote:> >> Hi David,> >>> >> Certainly, they should be put into the main repository (via an> >> evangelism issue). For the specs ones, these are probably older than > >> trunk that has the poms - but I'd expect them to be the same or> >> similar - so definitely use those. They'll still need to be uploaded.> >>> >> - Brett> >> > >> On 11/12/05, David Jencks < [EMAIL PROTECTED]> wrote:> >> >> >> > On Nov 11, 2005, at 11:00 AM, Prasad Kashyap wrote: > >> >> >> > > I'm done creating poms for the 17 modules in the attached text> >> file.> >> > >> >> > >I was able to get some jars (same version and all) from the M1 > >> > > repository. I need to track down the other jars.> >> > >> >> > >Next I need to figure out how to create a patch from the> >> repository> >> > > jars. TortoiseSVN doesn't seem to help me there. Any tips here > >> would> >> > > be appreciated.> >> > >> >> > >Should I create 1 JIRA for all these 17 modules or should each> >> module> >> > > have it's own JIRA ? > >> > >> >> > >Cheers> >> > >Prasad> >> > >> >> > >> >> > >> >> > I'm worriedthat duplicate work is happening. The geronimo-specs > >> > already have an m2 build so I wouldthink they all have valid m2> >> poms.> >> > I believe jeff genender has valid activemq poms from his work with> >> > wadi. > >> >> >> > I certainly don't know what should happen with these poms now that> >> they> >> > exist.I don't think keeping them private to geronimo is likely to > >> be> >> > the best practice.Should we open one issue/pom in maven> >> evangelism?> >> > Jason? Brett?> >> >> >> > thanks> >> > david jencks > >> >> >> >>>
Re: jRockit and Geronimo - Dain, can you add Andy ?
Many thanks andy At 06:06 PM 11/16/2005, you wrote: Done. -dain
Re: jRockit and Geronimo - Dain, can you add Andy ?
Done. -dain On 11/16/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > Dain, > > Can you add Andy to JIRA so we can assign this issue to him? > > Andy Piper wrote: > > I have CR'd this internally. How do I assign the issue to myself? > > > > This is a fairly old version of JRockit (and geronimo) it may have > > already been resolved in a later version. > > > > andy > > > > At 03:35 PM 11/11/2005, Matt Hogstrom wrote: > >> Currently we haven't been able to test Geronimo on jRockit > >> successfully. There is an issue out there (GERONIMO-471) where there > >> is clearly some issue. I was wondering if anyone has tried this > >> recently and if Geronimo will fire up and run on jRockit? > >> > >> Matt > > > > > > > > > >
Re: The Installer
Thanks for the ibiblio information. I'm not keen on pushing changes into IZPack at this point. The statement was more of a nod at the possibility that IZPack may not have all the capability we'd like. After looking at the documentation a little more, I see that it probably won't be necessary. I'll plan on having the installer impose an either-or policy on web container installation. Regards, erik On Wednesday 16 November 2005 12:45, Aaron Mulder wrote: > I don't want to discourage you, but I don't think the timing will work > out too well on IzPack improvements. Their releases are pretty > infrequent and I think the main developer is on vacation at the > moment. I didn't have much luck getting other Geronimo folks > interested in using my custom hacked IzPack build, which is why it was > so nice to see 3.8.0 released. So let's make the best of what we've > got in the standard build, and perhaps keep a list of improvements > we'd like to see to IzPack in the post-Geronimo-1.0 time frame. (A > hook to validate an entire user entry screen at a time is on my list.) > > Anyway, the Maven instructions (from John Sission, sorry John) are: > > http://maven.apache.org/maven-1.x/reference/repository-upload.html > > And as for the radios, I think we should definitely enforce only 1 web > container through the installer. That will save us a whole world of > pain. If people want 2 web containers, let them take some manual > steps! > > Aaron > > On 11/16/05, Erik Daughtrey <[EMAIL PROTECTED]> wrote: > > I read the "Building an Installer" wiki page. It helped me get going. > > It's getting a little crusty, but it was still very helpful. > > > > I'd be interested in the ibiblio information. Please send it along. I > > had already figured that I'd be researching this based on David's post. > > > > I'll look into the port validation issues and see if there's something > > easily done from within IZPack. I'm not averse to helping improve IZPack > > if it can help both projects and there's actually time to do the work. > > > > I am assuming I should create JIRAs for each of the issues raised. Unless > > someone disagrees, I'll do this. > > > > Regards, > > > > erik > > > > On Wednesday 16 November 2005 11:03, Aaron Mulder wrote: > > > 1) I think the standalone compiler is the only necessary JAR, and I > > > had volunterred to try to get it onto iBiblio at one point, but didn't > > > actually get around to it. It would be great if someone else could do > > > that. Someone (Jacek?) pointed me to a writeup on how to get > > > arbitrary JARs onto ibiblio, and I can pass that along if it would be > > > helpful. > > > > > > 5) I think port validation was tricky, because IIRC, each field is > > > validated independently. I don't think there's a good way to validate > > > a whole screen at a time, much less a group of ports on a group of > > > screens, some of which you may not have seen yet. If this turns out > > > to be hard, I don't think it would be the end of the world to skip it > > > for now, since presumably the user knows not to create port conflicts. > > > > > > 7) I think we could safely install all the schemas if you install J2EE > > > features, and none of the schemas otherwise. It's not quite perfect, > > > but close enough. > > > > > > The other problem we need to think about, related to the port issue, > > > is setting the default web port. If you install only Jetty or Tomcat, > > > whichever one you install should default to 8080. But if you install > > > both, they should default to different ports. I would be OK saying > > > that the installer will not install both, which would make this > > > easier, but I don't think there's that kind of exclusivity in the > > > feature selection screen. > > > > > > Then again, I haven't worked with IzPack for a while now so my > > > information may be a little out of date. :) > > > > > > Aaron > > > > > > On 11/16/05, Erik Daughtrey <[EMAIL PROTECTED]> wrote: > > > > Hey David, I'll start working on these items. > > > > > > > > erik > > > > > > > > On Wednesday 16 November 2005 03:24, David Jencks wrote: > > > > > It would be good if we could get the installer working well for > > > > > 1.0. Here are some of the things I think need to happen. > > > > > > > > > > 1. The necessary izpack jars need to get into some maven repo, > > > > > preferably a public one such as ibiblio. They might be on there > > > > > way there already, otherwise we should figure out which jars are > > > > > needed and file an upload request. > > > > > > > > > > 2. Installer building should occur in its own module in assemblies. > > > > > It would be best if the installer can be built using a maven > > > > > plugin, but if that seems impractical we can use a bunch of jelly > > > > > for now. There is an izpack plugin but I think it is maven 2 only > > > > > (??). > > > > > > > > > > 3. The installer currently has a page where you check the major > > > > > features you
[jira] Resolved: (GERONIMO-1186) Illegal argument exception when returning from add listener to display list in web server page, network listeners portlet
[ http://issues.apache.org/jira/browse/GERONIMO-1186?page=all ] Aaron Mulder resolved GERONIMO-1186: Resolution: Fixed Assign To: Aaron Mulder Revision 345068 > Illegal argument exception when returning from add listener to display list > in web server page, network listeners portlet > - > > Key: GERONIMO-1186 > URL: http://issues.apache.org/jira/browse/GERONIMO-1186 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0 > Environment: Windows XP , IE 6.0.x > Reporter: Joe Bohn > Assignee: Aaron Mulder > Fix For: 1.0 > > Scenario: > From the console select the Web Server page. > Select any "Add new listener for " link > return to list by selecing list connectors > This exception is thrown: > 09:09:31,967 ERROR [Servlet] Exception caught: > java.lang.IllegalArgumentException: Render parameter key or value must not be > nu > ll. > at > org.apache.pluto.core.impl.ActionResponseImpl.setRenderParameter(Acti > onResponseImpl.java:164) > at > org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction > (ConnectorPortlet.java:68) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 > ) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 > ) > at > org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde > r.java:99) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( > WebApplicationHandler.java:830) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171 > ) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( > WebApplicationHandler.java:821) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati > onHandler.java:471) > at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) > at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke > rImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke > rImpl.java:68) > at > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon > tainerImpl.java:164) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP > ortletAction(PortletContainerWrapperImpl.java:82) > at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 > ) > at > org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde > r.java:99) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( > WebApplicationHandler.java:830) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171 > ) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( > WebApplicationHandler.java:821) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati > onHandler.java:471) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5 > 68) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplication > Context.java:633) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) > at org.mortbay.http.HttpServer.service(HttpServer.java:954) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java: > 244) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) > 09:09:32,198 WARN [BasicProxyManager] Could not load interface > org.apache.geron > imo.tomcat.TomcatWebConnector in provided ClassLoader for TomcatAJPConnector > 09:09:32,198 WARN [BasicProxyManager] Could not load interface > org.apache.geron > imo.tomcat.TomcatWebConnector in
[jira] Assigned: (GERONIMO-1184) Decouple the connector module from the kernel module
[ http://issues.apache.org/jira/browse/GERONIMO-1184?page=all ] David Jencks reassigned GERONIMO-1184: -- Assign To: David Jencks > Decouple the connector module from the kernel module > > > Key: GERONIMO-1184 > URL: http://issues.apache.org/jira/browse/GERONIMO-1184 > Project: Geronimo > Type: Bug > Components: connector > Reporter: Guillaume Nodet > Assignee: David Jencks > > Since revision 331909, the > o.a.g.connector.outbound.AbstractConnectionMaanager implements > o.a.g.gbean.GBeanLifeCycle. > Thus the whole connector module is dependant on the kernel module. > The jencks project now has to ship the kernel module also which has some > drawbacks : the geronimo log is used instead of > the default one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1148) Console/Tomcat application does not start
[ http://issues.apache.org/jira/browse/GERONIMO-1148?page=comments#action_12357801 ] David Jencks commented on GERONIMO-1148: We need to give the keystore portlet a normal gbean name, not something hardcoded. I could do this easily, but I imagine something has to be able to find it, and I'm not sure what that something is or how to detect it is broken. > Console/Tomcat application does not start > - > > Key: GERONIMO-1148 > URL: http://issues.apache.org/jira/browse/GERONIMO-1148 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0-M5 > Environment: Win XP, Sun JDK 1.4.2_08 > Reporter: Vamsavardhana Reddy > Fix For: 1.0 > > Geronimo Console application under Tomcat does not start. Upon clicking the > "start" link in "Application EARs" portlet, the message "Configuration not > found" is displayed in console. The following errors are logged to > geronimo.log > 11:23:27,292 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error > while dispatching portlet. > javax.portlet.PortletException: Configuration not found > at > org.apache.geronimo.console.configmanager.ConfigManagerPortlet.processAction(ConfigManagerPortlet.java:130) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) > at > org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) > at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) > at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) > at > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) > at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) > at > org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) > at org.mortbay.http.HttpServer.service(HttpServer.java:954) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) > Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Could > not extract gbean data from configuration > at > org.apache.geronimo.kernel.config.ConfigurationManagerImpl.loadGBeans(ConfigurationManagerImpl.java:125) > at > org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:130) > at > org.apache.geronimo.kernel.config.ConfigurationManagerImpl$
Re: The Installer
I don't want to discourage you, but I don't think the timing will work out too well on IzPack improvements. Their releases are pretty infrequent and I think the main developer is on vacation at the moment. I didn't have much luck getting other Geronimo folks interested in using my custom hacked IzPack build, which is why it was so nice to see 3.8.0 released. So let's make the best of what we've got in the standard build, and perhaps keep a list of improvements we'd like to see to IzPack in the post-Geronimo-1.0 time frame. (A hook to validate an entire user entry screen at a time is on my list.) Anyway, the Maven instructions (from John Sission, sorry John) are: http://maven.apache.org/maven-1.x/reference/repository-upload.html And as for the radios, I think we should definitely enforce only 1 web container through the installer. That will save us a whole world of pain. If people want 2 web containers, let them take some manual steps! Aaron On 11/16/05, Erik Daughtrey <[EMAIL PROTECTED]> wrote: > > I read the "Building an Installer" wiki page. It helped me get going. It's > getting a little crusty, but it was still very helpful. > > I'd be interested in the ibiblio information. Please send it along. I had > already figured that I'd be researching this based on David's post. > > I'll look into the port validation issues and see if there's something easily > done from within IZPack. I'm not averse to helping improve IZPack if it can > help both projects and there's actually time to do the work. > > I am assuming I should create JIRAs for each of the issues raised. Unless > someone disagrees, I'll do this. > > Regards, > > erik > > On Wednesday 16 November 2005 11:03, Aaron Mulder wrote: > > 1) I think the standalone compiler is the only necessary JAR, and I > > had volunterred to try to get it onto iBiblio at one point, but didn't > > actually get around to it. It would be great if someone else could do > > that. Someone (Jacek?) pointed me to a writeup on how to get > > arbitrary JARs onto ibiblio, and I can pass that along if it would be > > helpful. > > > > 5) I think port validation was tricky, because IIRC, each field is > > validated independently. I don't think there's a good way to validate > > a whole screen at a time, much less a group of ports on a group of > > screens, some of which you may not have seen yet. If this turns out > > to be hard, I don't think it would be the end of the world to skip it > > for now, since presumably the user knows not to create port conflicts. > > > > 7) I think we could safely install all the schemas if you install J2EE > > features, and none of the schemas otherwise. It's not quite perfect, > > but close enough. > > > > The other problem we need to think about, related to the port issue, > > is setting the default web port. If you install only Jetty or Tomcat, > > whichever one you install should default to 8080. But if you install > > both, they should default to different ports. I would be OK saying > > that the installer will not install both, which would make this > > easier, but I don't think there's that kind of exclusivity in the > > feature selection screen. > > > > Then again, I haven't worked with IzPack for a while now so my > > information may be a little out of date. :) > > > > Aaron > > > > On 11/16/05, Erik Daughtrey <[EMAIL PROTECTED]> wrote: > > > Hey David, I'll start working on these items. > > > > > > erik > > > > > > On Wednesday 16 November 2005 03:24, David Jencks wrote: > > > > It would be good if we could get the installer working well for 1.0. > > > > Here are some of the things I think need to happen. > > > > > > > > 1. The necessary izpack jars need to get into some maven repo, > > > > preferably a public one such as ibiblio. They might be on there way > > > > there already, otherwise we should figure out which jars are needed and > > > > file an upload request. > > > > > > > > 2. Installer building should occur in its own module in assemblies. It > > > > would be best if the installer can be built using a maven plugin, but > > > > if that seems impractical we can use a bunch of jelly for now. There > > > > is an izpack plugin but I think it is maven 2 only (??). > > > > > > > > 3. The installer currently has a page where you check the major > > > > features you want, and on the following pages you configure them. This > > > > seems like a basically acceptable paradigm to me, but there is a > > > > problem in that all the "following pages" display even if they are > > > > empty. I've been told that moving the element out one > > > > level to the panel element will fix this. > > > > > > > > 4. The installer currently works by installing everything in a full > > > > geronimo install, and not starting the pieces you don't want. This is > > > > rather unsatisfactory unless you sell disk space. The geronimo > > > > assembly is moving to use of the packaging and assembly plugins, and we > > > > can leverage
Re: The Installer
There's definitely a radio button capability. Do we want to enforce the configuration of only one web container? Regards, erik On Wednesday 16 November 2005 12:06, David Jencks wrote: > On Nov 16, 2005, at 8:03 AM, Aaron Mulder wrote: > > 1) I think the standalone compiler is the only necessary JAR, and I > > had volunterred to try to get it onto iBiblio at one point, but didn't > > actually get around to it. It would be great if someone else could do > > that. Someone (Jacek?) pointed me to a writeup on how to get > > arbitrary JARs onto ibiblio, and I can pass that along if it would be > > helpful. > > > > 5) I think port validation was tricky, because IIRC, each field is > > validated independently. I don't think there's a good way to validate > > a whole screen at a time, much less a group of ports on a group of > > screens, some of which you may not have seen yet. If this turns out > > to be hard, I don't think it would be the end of the world to skip it > > for now, since presumably the user knows not to create port conflicts. > > This was the demise of the M5 installer: it was very easy to get port > conflicts. I was thinking of some kind of verification class used at > the end that made sure no property values matching some pattern had the > same values. > > > 7) I think we could safely install all the schemas if you install J2EE > > features, and none of the schemas otherwise. It's not quite perfect, > > but close enough. > > True, but I am hoping to move this into the assembly plugin and use a > generic procedure to extract schemas rather than the somewhat custom > code we use today. > > > The other problem we need to think about, related to the port issue, > > is setting the default web port. If you install only Jetty or Tomcat, > > whichever one you install should default to 8080. But if you install > > both, they should default to different ports. I would be OK saying > > that the installer will not install both, which would make this > > easier, but I don't think there's that kind of exclusivity in the > > feature selection screen. > > I'd certainly like to know if there is some kind of "radio button" > functionality. > > > Then again, I haven't worked with IzPack for a while now so my > > information may be a little out of date. :) > > > > Aaron > > > > On 11/16/05, Erik Daughtrey <[EMAIL PROTECTED]> wrote: > >> Hey David, I'll start working on these items. > > Excellent > > > david jencks > > >> erik > >> > >> On Wednesday 16 November 2005 03:24, David Jencks wrote: > >>> It would be good if we could get the installer working well for 1.0. > >>> Here are some of the things I think need to happen. > >>> > >>> 1. The necessary izpack jars need to get into some maven repo, > >>> preferably a public one such as ibiblio. They might be on there way > >>> there already, otherwise we should figure out which jars are needed > >>> and > >>> file an upload request. > >>> > >>> 2. Installer building should occur in its own module in assemblies. > >>> It > >>> would be best if the installer can be built using a maven plugin, but > >>> if that seems impractical we can use a bunch of jelly for now. There > >>> is an izpack plugin but I think it is maven 2 only (??). > >>> > >>> 3. The installer currently has a page where you check the major > >>> features you want, and on the following pages you configure them. > >>> This > >>> seems like a basically acceptable paradigm to me, but there is a > >>> problem in that all the "following pages" display even if they are > >>> empty. I've been told that moving the element out > >>> one > >>> level to the panel element will fix this. > >>> > >>> 4. The installer currently works by installing everything in a full > >>> geronimo install, and not starting the pieces you don't want. This > >>> is > >>> rather unsatisfactory unless you sell disk space. The geronimo > >>> assembly is moving to use of the packaging and assembly plugins, and > >>> we > >>> can leverage that with the installer. What I am thinking of is > >>> including a maven repository inside the installer jar that includes > >>> everything from a full geronimo install with everything, including > >>> all > >>> the .car files for the configurations. Then we can imitate or use > >>> the > >>> assembly plugin to copy the configuration dependencies into the > >>> install > >>> target and install the actual configurations. > >>> > >>> 5. We should find a way to check that no port conflicts have been > >>> configured. > >>> > >>> 6. We need to construct a config.xml file for the target install. > >>> This > >>> could be done by adding bits associated with each configuration, or > >>> by > >>> removing chunks from a "universal" config.xml for the configurations > >>> we > >>> didnt' install. > >>> > >>> 7. Somewhat similarly, we need to include the schema files (for > >>> human > >>> reference, they aren't used by geronimo) for the bits that are > >>> included > >>> in the install t
Re: m2: flushing out our dependencies
Pluto's dependency is currently listed as: 0.9.5.3 I think 0.9.9 is from something else. David On 11/16/05, David Jencks <[EMAIL PROTECTED]> wrote: > > On Nov 16, 2005, at 8:20 AM, Prasad Kashyap wrote: > > > Of the 14 missing jars, I was able to track down all but 5. I had some > > Qs about those 5 - > > > > castor ||castor || 0.9.9 || 0.9.9.1 exists. Update pom to use this ? > what is using castor? I think pluto is, anything else? > > > org.apache.geronimo.fake ||m2assembly || 1.0-SNAPSHOT || ??? > no idea... obviously it is supposed to be something we control... > > > activemq || activemq-core-test || 3.2 || can't trace this yet. > I doubt we actually need this, can you figure out what tries to pull it > in? > > > javacc || javacc || 2.1 || [WARNING] This artifact has been relocated > > to javax.sql:jdbc-stdext:2.0. > It seems to me that this must be a mistake somewhere. > > > xmlbeans || xmlbeans-jsr173-api || 2.0-dev || can't trace this yet. > for the m1 build we are using stax/jars/stax-api-1.0.jar. Again, can > you trace where this requirement comes from? Is there a generic m2 > tool to trace where missing dependencies are required? > > thanks > david jencks > > > > > > Suggestions ? Advice ? > > > > Cheers > > Prasad > > > > On 11/11/05, Brett Porter <[EMAIL PROTECTED]> wrote: > >> Hi David, > >> > >> Certainly, they should be put into the main repository (via an > >> evangelism issue). For the specs ones, these are probably older than > >> trunk that has the poms - but I'd expect them to be the same or > >> similar - so definitely use those. They'll still need to be uploaded. > >> > >> - Brett > >> > >> On 11/12/05, David Jencks < [EMAIL PROTECTED]> wrote: > >> > > >> > On Nov 11, 2005, at 11:00 AM, Prasad Kashyap wrote: > >> > > >> > > I'm done creating poms for the 17 modules in the attached text > >> file. > >> > > > >> > >I was able to get some jars (same version and all) from the M1 > >> > > repository. I need to track down the other jars. > >> > > > >> > >Next I need to figure out how to create a patch from the > >> repository > >> > > jars. TortoiseSVN doesn't seem to help me there. Any tips here > >> would > >> > > be appreciated. > >> > > > >> > >Should I create 1 JIRA for all these 17 modules or should each > >> module > >> > > have it's own JIRA ? > >> > > > >> > >Cheers > >> > >Prasad > >> > > > >> > > > >> > > > >> > I'm worriedthat duplicate work is happening. The geronimo-specs > >> > already have an m2 build so I wouldthink they all have valid m2 > >> poms. > >> > I believe jeff genender has valid activemq poms from his work with > >> > wadi. > >> > > >> > I certainly don't know what should happen with these poms now that > >> they > >> > exist.I don't think keeping them private to geronimo is likely to > >> be > >> > the best practice.Should we open one issue/pom in maven > >> evangelism? > >> > Jason? Brett? > >> > > >> > thanks > >> > david jencks > >> > > >> > > >
Re: m2: flushing out our dependencies
On Nov 16, 2005, at 8:20 AM, Prasad Kashyap wrote: Of the 14 missing jars, I was able to track down all but 5. I had some Qs about those 5 - castor || castor || 0.9.9 || 0.9.9.1 exists. Update pom to use this ? what is using castor? I think pluto is, anything else? org.apache.geronimo.fake || m2assembly || 1.0-SNAPSHOT || ??? no idea... obviously it is supposed to be something we control... activemq || activemq-core-test || 3.2 || can't trace this yet. I doubt we actually need this, can you figure out what tries to pull it in? javacc || javacc || 2.1 || [WARNING] This artifact has been relocated to javax.sql:jdbc-stdext:2.0. It seems to me that this must be a mistake somewhere. xmlbeans || xmlbeans-jsr173-api || 2.0-dev || can't trace this yet. for the m1 build we are using stax/jars/stax-api-1.0.jar. Again, can you trace where this requirement comes from? Is there a generic m2 tool to trace where missing dependencies are required? thanks david jencks Suggestions ? Advice ? Cheers Prasad On 11/11/05, Brett Porter <[EMAIL PROTECTED]> wrote: Hi David, Certainly, they should be put into the main repository (via an evangelism issue). For the specs ones, these are probably older than trunk that has the poms - but I'd expect them to be the same or similar - so definitely use those. They'll still need to be uploaded. - Brett On 11/12/05, David Jencks < [EMAIL PROTECTED]> wrote: > > On Nov 11, 2005, at 11:00 AM, Prasad Kashyap wrote: > > > I'm done creating poms for the 17 modules in the attached text file. > > > > I was able to get some jars (same version and all) from the M1 > > repository. I need to track down the other jars. > > > > Next I need to figure out how to create a patch from the repository > > jars. TortoiseSVN doesn't seem to help me there. Any tips here would > > be appreciated. > > > > Should I create 1 JIRA for all these 17 modules or should each module > > have it's own JIRA ? > > > > Cheers > > Prasad > > > > > > > I'm worried that duplicate work is happening. The geronimo-specs > already have an m2 build so I would think they all have valid m2 poms. > I believe jeff genender has valid activemq poms from his work with > wadi. > > I certainly don't know what should happen with these poms now that they > exist. I don't think keeping them private to geronimo is likely to be > the best practice. Should we open one issue/pom in maven evangelism? > Jason? Brett? > > thanks > david jencks > >
Re: The Installer
I read the "Building an Installer" wiki page. It helped me get going. It's getting a little crusty, but it was still very helpful. I'd be interested in the ibiblio information. Please send it along. I had already figured that I'd be researching this based on David's post. I'll look into the port validation issues and see if there's something easily done from within IZPack. I'm not averse to helping improve IZPack if it can help both projects and there's actually time to do the work. I am assuming I should create JIRAs for each of the issues raised. Unless someone disagrees, I'll do this. Regards, erik On Wednesday 16 November 2005 11:03, Aaron Mulder wrote: > 1) I think the standalone compiler is the only necessary JAR, and I > had volunterred to try to get it onto iBiblio at one point, but didn't > actually get around to it. It would be great if someone else could do > that. Someone (Jacek?) pointed me to a writeup on how to get > arbitrary JARs onto ibiblio, and I can pass that along if it would be > helpful. > > 5) I think port validation was tricky, because IIRC, each field is > validated independently. I don't think there's a good way to validate > a whole screen at a time, much less a group of ports on a group of > screens, some of which you may not have seen yet. If this turns out > to be hard, I don't think it would be the end of the world to skip it > for now, since presumably the user knows not to create port conflicts. > > 7) I think we could safely install all the schemas if you install J2EE > features, and none of the schemas otherwise. It's not quite perfect, > but close enough. > > The other problem we need to think about, related to the port issue, > is setting the default web port. If you install only Jetty or Tomcat, > whichever one you install should default to 8080. But if you install > both, they should default to different ports. I would be OK saying > that the installer will not install both, which would make this > easier, but I don't think there's that kind of exclusivity in the > feature selection screen. > > Then again, I haven't worked with IzPack for a while now so my > information may be a little out of date. :) > > Aaron > > On 11/16/05, Erik Daughtrey <[EMAIL PROTECTED]> wrote: > > Hey David, I'll start working on these items. > > > > erik > > > > On Wednesday 16 November 2005 03:24, David Jencks wrote: > > > It would be good if we could get the installer working well for 1.0. > > > Here are some of the things I think need to happen. > > > > > > 1. The necessary izpack jars need to get into some maven repo, > > > preferably a public one such as ibiblio. They might be on there way > > > there already, otherwise we should figure out which jars are needed and > > > file an upload request. > > > > > > 2. Installer building should occur in its own module in assemblies. It > > > would be best if the installer can be built using a maven plugin, but > > > if that seems impractical we can use a bunch of jelly for now. There > > > is an izpack plugin but I think it is maven 2 only (??). > > > > > > 3. The installer currently has a page where you check the major > > > features you want, and on the following pages you configure them. This > > > seems like a basically acceptable paradigm to me, but there is a > > > problem in that all the "following pages" display even if they are > > > empty. I've been told that moving the element out one > > > level to the panel element will fix this. > > > > > > 4. The installer currently works by installing everything in a full > > > geronimo install, and not starting the pieces you don't want. This is > > > rather unsatisfactory unless you sell disk space. The geronimo > > > assembly is moving to use of the packaging and assembly plugins, and we > > > can leverage that with the installer. What I am thinking of is > > > including a maven repository inside the installer jar that includes > > > everything from a full geronimo install with everything, including all > > > the .car files for the configurations. Then we can imitate or use the > > > assembly plugin to copy the configuration dependencies into the install > > > target and install the actual configurations. > > > > > > 5. We should find a way to check that no port conflicts have been > > > configured. > > > > > > 6. We need to construct a config.xml file for the target install. This > > > could be done by adding bits associated with each configuration, or by > > > removing chunks from a "universal" config.xml for the configurations we > > > didnt' install. > > > > > > 7. Somewhat similarly, we need to include the schema files (for human > > > reference, they aren't used by geronimo) for the bits that are included > > > in the install target. This should proceed by fixing the xmlbeans > > > plugin to put schemas in the same place the xmlbeans ant task does, and > > > by extracting all such schemas from our dependencies. This needs to be > > > ad
Re: The Installer
On Nov 16, 2005, at 8:03 AM, Aaron Mulder wrote: 1) I think the standalone compiler is the only necessary JAR, and I had volunterred to try to get it onto iBiblio at one point, but didn't actually get around to it. It would be great if someone else could do that. Someone (Jacek?) pointed me to a writeup on how to get arbitrary JARs onto ibiblio, and I can pass that along if it would be helpful. 5) I think port validation was tricky, because IIRC, each field is validated independently. I don't think there's a good way to validate a whole screen at a time, much less a group of ports on a group of screens, some of which you may not have seen yet. If this turns out to be hard, I don't think it would be the end of the world to skip it for now, since presumably the user knows not to create port conflicts. This was the demise of the M5 installer: it was very easy to get port conflicts. I was thinking of some kind of verification class used at the end that made sure no property values matching some pattern had the same values. 7) I think we could safely install all the schemas if you install J2EE features, and none of the schemas otherwise. It's not quite perfect, but close enough. True, but I am hoping to move this into the assembly plugin and use a generic procedure to extract schemas rather than the somewhat custom code we use today. The other problem we need to think about, related to the port issue, is setting the default web port. If you install only Jetty or Tomcat, whichever one you install should default to 8080. But if you install both, they should default to different ports. I would be OK saying that the installer will not install both, which would make this easier, but I don't think there's that kind of exclusivity in the feature selection screen. I'd certainly like to know if there is some kind of "radio button" functionality. Then again, I haven't worked with IzPack for a while now so my information may be a little out of date. :) Aaron On 11/16/05, Erik Daughtrey <[EMAIL PROTECTED]> wrote: Hey David, I'll start working on these items. Excellent david jencks erik On Wednesday 16 November 2005 03:24, David Jencks wrote: It would be good if we could get the installer working well for 1.0. Here are some of the things I think need to happen. 1. The necessary izpack jars need to get into some maven repo, preferably a public one such as ibiblio. They might be on there way there already, otherwise we should figure out which jars are needed and file an upload request. 2. Installer building should occur in its own module in assemblies. It would be best if the installer can be built using a maven plugin, but if that seems impractical we can use a bunch of jelly for now. There is an izpack plugin but I think it is maven 2 only (??). 3. The installer currently has a page where you check the major features you want, and on the following pages you configure them. This seems like a basically acceptable paradigm to me, but there is a problem in that all the "following pages" display even if they are empty. I've been told that moving the element out one level to the panel element will fix this. 4. The installer currently works by installing everything in a full geronimo install, and not starting the pieces you don't want. This is rather unsatisfactory unless you sell disk space. The geronimo assembly is moving to use of the packaging and assembly plugins, and we can leverage that with the installer. What I am thinking of is including a maven repository inside the installer jar that includes everything from a full geronimo install with everything, including all the .car files for the configurations. Then we can imitate or use the assembly plugin to copy the configuration dependencies into the install target and install the actual configurations. 5. We should find a way to check that no port conflicts have been configured. 6. We need to construct a config.xml file for the target install. This could be done by adding bits associated with each configuration, or by removing chunks from a "universal" config.xml for the configurations we didnt' install. 7. Somewhat similarly, we need to include the schema files (for human reference, they aren't used by geronimo) for the bits that are included in the install target. This should proceed by fixing the xmlbeans plugin to put schemas in the same place the xmlbeans ant task does, and by extracting all such schemas from our dependencies. This needs to be added to the assembly plugin: it is not installer specific. There's probably more to do, but this is what I've thought of so far. thanks david jencks -- Regards, Erik
Re: Constructing deployment plans from Configuration GBeanData
On Nov 16, 2005, at 4:10 AM, Vamsavardhana Reddy wrote: I am trying to reconstruct deployment plan from the Configuration GBeanData. umm, why? I have a code segment like the following. ObjectName configName = Configuration.getConfigurationObjectName(configId); GBeanData configData = kernel.getGBeanData(configName); Once I have the GBeanData object, I am retreiving the attributes, references & any GBeans inside the configuration and printing out the information. With this procedure, I am able to reconstruct the deployment plan for some, but not all :(, of the configurations in Geronimo. Is there any other way of getting deployment plan out of configuration GBeanData object? this will probably work for gbeans that came from a configuration directly, rather than e.g. an ejb container gbean, and that do not have any xml-attributes. I don't think you will succeed in generating a gbean configuration for something like an ejb container. Again, what is your goal? This is very much akin to writing a java disassembler. thanks david jencks
Re: BasicProxyManager.java commit r344848
On 11/16/05, Kevan Miller <[EMAIL PROTECTED]> wrote:
> Aaron,
> Nice work getting to the bottom of this issue. However, I'm not sure that
> I'm happy with your fix. I'm confident that your fix will find a
> ClassLoaders which can load all of the classes/interfaces. However, there
> can be multiple of these and there's no guarantee that you're finding the
> most appropriate ClassLoader. For example imagine an application classloader
> with inverseClassLoading set to true. You're technique might find a parent
> ClassLoader, when the desired ClassLoader is the application classloader.
For my part, I don't really care which class loader is "ideal" so long
as we try to get one that can load all the classes. I'm not too
concerned that parent and child may be using different definitions of
the same class such that a different "master" CL might result in using
a different definition. We're only talking about GBean interfaces
here, and I think unlikely to have different versions in use by
different CLs (at present). Can you think of a specific use case in
Geronimo where we might run into a problem? I know David J is working
on fully versioned configurations, which might make a difference.
> I have an alternate fix which calculates a child ClassLoader from the
> potential list of ClassLoaders (my fix assumes that there is one ClassLoader
> to which all other ClassLoaders are ancestors). I've tested against Joe's
> test case. It too fixes the problem...
>
> As I'm typing this, I'm wondering if we have an even larger problem. Is
> there a guarantee that the list of ClassLoaders available to the
> BasicProxyManager constructor contains a single ClassLoader which is capable
> of loading of the given classes? Seems pretty easy to construct a
> scenario in which this is not true. I'd be interested in hearing what you or
> others might think...
Right, there's no guarantee this will solve all possible problems.
Right now it just falls through if it can't identify a "master" CL. I
suppose we could create a new multi-parent CL on the spot if we needed
to.
Aaron
> A problematic scenario would look like this:
>
> System ClassLoader
> / | \
> A B C
> \ | /
>My ClassLoader
>
> Assume that ClassLoader A is the loader for class a, etc. If the classes a,
> b, and c are passed to the BasicProxyManager constructor, it will not be
> able to determine a ClassLoader capable of loading a, b, c. Is this an
> invalid use case? Neither of our fixes will work in this case...
>
> --kevan
>
>
> On 11/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Author: ammulder
> > Date: Tue Nov 15 18:32:31 2005
> > New Revision: 344848
> >
> > URL: http://svn.apache.org/viewcvs?rev=344848&view=rev
> > Log:
> > Pick the best ClassLoader for the provided set of interfaces
> > (Fixes GERONIMO-1064)
> >
> > Modified:
> >
> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/kernel/basic/BasicProxyManager.java
> >
> > Modified:
> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/kernel/basic/BasicProxyManager.java
> > URL:
> http://svn.apache.org/viewcvs/geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/kernel/basic/BasicProxyManager.java?rev=344848&r1=344847&r2=344848&view=diff
> >
> ==
> > ---
> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/kernel/basic/BasicProxyManager.java
> (original)
> > +++
> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/kernel/basic/BasicProxyManager.java
> Tue Nov 15 18:32:31 2005
> > @@ -207,6 +207,24 @@
> > } else if(type.length == 1) { // Unlikely (as a result of
> GeronimoManagedBean)
> > enhancer.setSuperclass(type[0]);
> > } else {
> > +ClassLoader best = null;
> > +outer:
> > +for (int i = 0; i < type.length; i++) {
> > +ClassLoader test =
> type[i].getClassLoader();
> > +for (int j = 0; j < type.length; j++) {
> > +String className = type[j].getName();
> > +try {
> > +test.loadClass(className);
> > +} catch (ClassNotFoundException e) {
> > +continue outer;
> > +}
> > +}
> > +best = test;
> > +break;
> > +}
> > +if(best != null) {
> > +enhancer.setClassLoader(best);
> > +}
> > if(type[0].isInterface()) {
> > enhancer.setSuperclass(Object.class);
> > enhancer.setInterfaces(type);
> >
> >
> >
>
>
BasicProxyManager.java commit r344848
Aaron,
Nice work getting to the bottom of this issue. However, I'm not sure
that I'm happy with your fix. I'm confident that your fix will find a
ClassLoaders which can load all of the classes/interfaces. However,
there can be multiple of these and there's no guarantee that you're
finding the most appropriate ClassLoader. For example imagine an
application classloader with inverseClassLoading set to true. You're
technique might find a parent ClassLoader, when the desired ClassLoader
is the application classloader.
I have an alternate fix which calculates a child ClassLoader from the
potential list of ClassLoaders (my fix assumes that there is one
ClassLoader to which all other ClassLoaders are ancestors). I've tested
against Joe's test case. It too fixes the problem...
As I'm typing this, I'm wondering if we have an even larger problem. Is
there a guarantee that the list of ClassLoaders available to the
BasicProxyManager constructor contains a single ClassLoader which is
capable of loading of the given classes? Seems pretty easy
to construct a scenario in which this is not true. I'd be interested in
hearing what you or others might think...
A problematic scenario would look like this:
System ClassLoader
/ | \
A B C
\ | /
My ClassLoader
Assume that ClassLoader A is the loader for class a, etc. If the
classes a, b, and c are passed to the BasicProxyManager constructor, it
will not be able to determine a ClassLoader capable of loading a, b,
c. Is this an invalid use case? Neither of our fixes will
work in this case...
--kevan
On 11/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: ammulderDate: Tue Nov 15 18:32:31 2005New Revision: 344848URL:
http://svn.apache.org/viewcvs?rev=344848&view=revLog:Pick the best ClassLoader for the provided set of interfaces (Fixes GERONIMO-1064)
Modified:geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/kernel/basic/BasicProxyManager.javaModified: geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/kernel/basic/BasicProxyManager.java
URL: http://svn.apache.org/viewcvs/geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/kernel/basic/BasicProxyManager.java?rev=344848&r1=344847&r2=344848&view=diff
==--- geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/kernel/basic/BasicProxyManager.java (original)+++ geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/kernel/basic/BasicProxyManager.java Tue Nov 15 18:32:31 2005
@@ -207,6 +207,24 @@
} else if(type.length == 1) { // Unlikely (as a result of
GeronimoManagedBean)
enhancer.setSuperclass(type[0]); } else {+ClassLoader best = null;+outer:+for
(int i = 0; i < type.length; i++) {+ClassLoader
test = type[i].getClassLoader();+for
(int j = 0; j < type.length; j++) {+String
className = type[j].getName();+try
{+test.loadClass(className);+}
catch (ClassNotFoundException e) {+continue
outer;+}+}+best
= test;+break;+}+if(best != null) {+enhancer.setClassLoader(best);+} if(type[0].isInterface()) {
enhancer.setSuperclass(Object.class);
enhancer.setInterfaces(type);
[LONG] - Tomcat Examples in Geronimo - needed for v1
GERONIMO-1087 and GERONIMO-1088 JIRAs were opened to introduce the Tomcat examples into Geronimo. I believe it is important to get these introduced into the distributions (as default samples) for v1. There are a few different ways to approach this: 1) Ask Tomcat to create a war file for servlet-examples and jsp-examples and post it to http://www.ibiblio.org/maven/tomcat/ We pick up this dependency during our build and include it in the appropriate distributions. 2) We grab the exploded wars from the Tomcat binary (as there is no war file) and manually create the war files and place them in some repository where the geronimo build can find it. 3) We fork the tomcat source for these examples and build them within Geronimo. AFAIK, Tomcat uses ANT to build. Would need to massage this to work with maven accounting for the custom ant tasks and dependent jar files. 4) We grab the exploded wars (not source) from the Tomcat binary (as there is no war file) and create the war files within the geronimo build structure. Need to decide how to account for the jar files and whether to regenerate the class files. This is really a lightweight fork :>) I prefer option 1 as it seems the most straightforward and keeps Geronimo out of the business of maintaining tomcat examples. However, there is one small concern with this approach "There are a few words on the Tomcat examples that may need to be tweaked since these samples will run both with the Jetty and Tomcat web containers. Specifically, "These examples will only work when these pages are being served by a servlet engine; of course, we recommend Tomcat." AND "Please refer to the README file provide with this Tomcat release regarding how to configure and start the provided web server." It seems crazy to fork the samples due to a few minor words of text.. Perhaps our build can download the wars from ibiblio, crack them open and perform a quick regexp to remove the offending lines.. (or we can ask Tomcat to remove them). How do we approach Tomcat to get the wars placed in ibiblio? Can anyone help here? Thanks -Dave-
Re: m2: flushing out our dependencies
Of the 14 missing jars, I was able to track down all but 5. I had some Qs about those 5 - castor || castor || 0.9.9 || 0.9.9.1 exists. Update pom to use this ?org.apache.geronimo.fake || m2assembly || 1.0-SNAPSHOT || ???activemq || activemq-core-test || 3.2 || can't trace this yet.javacc || javacc || 2.1 || [WARNING] This artifact has been relocated to javax.sql:jdbc-stdext:2.0.xmlbeans || xmlbeans-jsr173-api || 2.0-dev || can't trace this yet. Suggestions ? Advice ? CheersPrasad On 11/11/05, Brett Porter <[EMAIL PROTECTED]> wrote: Hi David,Certainly, they should be put into the main repository (via anevangelism issue). For the specs ones, these are probably older than trunk that has the poms - but I'd expect them to be the same orsimilar - so definitely use those. They'll still need to be uploaded.- BrettOn 11/12/05, David Jencks < [EMAIL PROTECTED]> wrote:>> On Nov 11, 2005, at 11:00 AM, Prasad Kashyap wrote:>> > I'm done creating poms for the 17 modules in the attached text file.> >> > I was able to get some jars (same version and all) from the M1 > > repository. I need to track down the other jars.> >> > Next I need to figure out how to create a patch from the repository> > jars. TortoiseSVN doesn't seem to help me there. Any tips here would > > be appreciated.> >> > Should I create 1 JIRA for all these 17 modules or should each module> > have it's own JIRA ?> >> > Cheers> > Prasad> > > >> >> I'm worried that duplicate work is happening. The geronimo-specs> already have an m2 build so I would think they all have valid m2 poms.> I believe jeff genender has valid activemq poms from his work with > wadi.>> I certainly don't know what should happen with these poms now that they> exist. I don't think keeping them private to geronimo is likely to be> the best practice. Should we open one issue/pom in maven evangelism? > Jason? Brett?>> thanks> david jencks>>
Re: jRockit and Geronimo - Dain, can you add Andy ?
Dain, Can you add Andy to JIRA so we can assign this issue to him? Andy Piper wrote: I have CR'd this internally. How do I assign the issue to myself? This is a fairly old version of JRockit (and geronimo) it may have already been resolved in a later version. andy At 03:35 PM 11/11/2005, Matt Hogstrom wrote: Currently we haven't been able to test Geronimo on jRockit successfully. There is an issue out there (GERONIMO-471) where there is clearly some issue. I was wondering if anyone has tried this recently and if Geronimo will fire up and run on jRockit? Matt
Re: The Installer
1) I think the standalone compiler is the only necessary JAR, and I had volunterred to try to get it onto iBiblio at one point, but didn't actually get around to it. It would be great if someone else could do that. Someone (Jacek?) pointed me to a writeup on how to get arbitrary JARs onto ibiblio, and I can pass that along if it would be helpful. 5) I think port validation was tricky, because IIRC, each field is validated independently. I don't think there's a good way to validate a whole screen at a time, much less a group of ports on a group of screens, some of which you may not have seen yet. If this turns out to be hard, I don't think it would be the end of the world to skip it for now, since presumably the user knows not to create port conflicts. 7) I think we could safely install all the schemas if you install J2EE features, and none of the schemas otherwise. It's not quite perfect, but close enough. The other problem we need to think about, related to the port issue, is setting the default web port. If you install only Jetty or Tomcat, whichever one you install should default to 8080. But if you install both, they should default to different ports. I would be OK saying that the installer will not install both, which would make this easier, but I don't think there's that kind of exclusivity in the feature selection screen. Then again, I haven't worked with IzPack for a while now so my information may be a little out of date. :) Aaron On 11/16/05, Erik Daughtrey <[EMAIL PROTECTED]> wrote: > Hey David, I'll start working on these items. > > erik > > On Wednesday 16 November 2005 03:24, David Jencks wrote: > > It would be good if we could get the installer working well for 1.0. > > Here are some of the things I think need to happen. > > > > 1. The necessary izpack jars need to get into some maven repo, > > preferably a public one such as ibiblio. They might be on there way > > there already, otherwise we should figure out which jars are needed and > > file an upload request. > > > > 2. Installer building should occur in its own module in assemblies. It > > would be best if the installer can be built using a maven plugin, but > > if that seems impractical we can use a bunch of jelly for now. There > > is an izpack plugin but I think it is maven 2 only (??). > > > > 3. The installer currently has a page where you check the major > > features you want, and on the following pages you configure them. This > > seems like a basically acceptable paradigm to me, but there is a > > problem in that all the "following pages" display even if they are > > empty. I've been told that moving the element out one > > level to the panel element will fix this. > > > > 4. The installer currently works by installing everything in a full > > geronimo install, and not starting the pieces you don't want. This is > > rather unsatisfactory unless you sell disk space. The geronimo > > assembly is moving to use of the packaging and assembly plugins, and we > > can leverage that with the installer. What I am thinking of is > > including a maven repository inside the installer jar that includes > > everything from a full geronimo install with everything, including all > > the .car files for the configurations. Then we can imitate or use the > > assembly plugin to copy the configuration dependencies into the install > > target and install the actual configurations. > > > > 5. We should find a way to check that no port conflicts have been > > configured. > > > > 6. We need to construct a config.xml file for the target install. This > > could be done by adding bits associated with each configuration, or by > > removing chunks from a "universal" config.xml for the configurations we > > didnt' install. > > > > 7. Somewhat similarly, we need to include the schema files (for human > > reference, they aren't used by geronimo) for the bits that are included > > in the install target. This should proceed by fixing the xmlbeans > > plugin to put schemas in the same place the xmlbeans ant task does, and > > by extracting all such schemas from our dependencies. This needs to be > > added to the assembly plugin: it is not installer specific. > > > > There's probably more to do, but this is what I've thought of so far. > > > > thanks > > david jencks > > -- > > Regards, > > Erik >
Re: AMD Opteron Equipment for Development/Testing
Send me some hardware, I'll really help with the testing ;-) Great job though :) On 11/16/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > Thanks for the infusion Kyle. This is excellent. > > Once the donation is made we should probably update our Website acknowledging > AMD's contribution and commitment :) > > David Blevins wrote: > > > > On Nov 15, 2005, at 5:19 PM, Bruce Snyder wrote: > >> > >> BTW, we should set up a page on the website that lists all the > >> hardware contributions as a thank you to the contributors. > >> > > > > Been meaning to do that. Thanks for the kick the pants. > > > > Here it is! > > > > http://wiki.apache.org/geronimo/GBuild > > > > We can definitely move that to the website, just threw that up for > > starters. > > > > -David > > > > > > > > > >
Re: AMD Opteron Equipment for Development/Testing
Thanks for the infusion Kyle. This is excellent. Once the donation is made we should probably update our Website acknowledging AMD's contribution and commitment :) David Blevins wrote: On Nov 15, 2005, at 5:19 PM, Bruce Snyder wrote: BTW, we should set up a page on the website that lists all the hardware contributions as a thank you to the contributors. Been meaning to do that. Thanks for the kick the pants. Here it is! http://wiki.apache.org/geronimo/GBuild We can definitely move that to the website, just threw that up for starters. -David
Re: The Installer
Hey David, I'll start working on these items. erik On Wednesday 16 November 2005 03:24, David Jencks wrote: > It would be good if we could get the installer working well for 1.0. > Here are some of the things I think need to happen. > > 1. The necessary izpack jars need to get into some maven repo, > preferably a public one such as ibiblio. They might be on there way > there already, otherwise we should figure out which jars are needed and > file an upload request. > > 2. Installer building should occur in its own module in assemblies. It > would be best if the installer can be built using a maven plugin, but > if that seems impractical we can use a bunch of jelly for now. There > is an izpack plugin but I think it is maven 2 only (??). > > 3. The installer currently has a page where you check the major > features you want, and on the following pages you configure them. This > seems like a basically acceptable paradigm to me, but there is a > problem in that all the "following pages" display even if they are > empty. I've been told that moving the element out one > level to the panel element will fix this. > > 4. The installer currently works by installing everything in a full > geronimo install, and not starting the pieces you don't want. This is > rather unsatisfactory unless you sell disk space. The geronimo > assembly is moving to use of the packaging and assembly plugins, and we > can leverage that with the installer. What I am thinking of is > including a maven repository inside the installer jar that includes > everything from a full geronimo install with everything, including all > the .car files for the configurations. Then we can imitate or use the > assembly plugin to copy the configuration dependencies into the install > target and install the actual configurations. > > 5. We should find a way to check that no port conflicts have been > configured. > > 6. We need to construct a config.xml file for the target install. This > could be done by adding bits associated with each configuration, or by > removing chunks from a "universal" config.xml for the configurations we > didnt' install. > > 7. Somewhat similarly, we need to include the schema files (for human > reference, they aren't used by geronimo) for the bits that are included > in the install target. This should proceed by fixing the xmlbeans > plugin to put schemas in the same place the xmlbeans ant task does, and > by extracting all such schemas from our dependencies. This needs to be > added to the assembly plugin: it is not installer specific. > > There's probably more to do, but this is what I've thought of so far. > > thanks > david jencks -- Regards, Erik
Re: publish_build.sh converted to ant
David,
Did you plug in these ANT scripts with Continuum to build and publish G ? How did it work now ?
Cheers
Prasad
On 11/14/05, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
Blevins,
Here they are.
Updates:
1. properties variable ${maven.exe}
2. changed the command line syntax to skip tests.
Cheers
Prasad
On 11/11/05, Prasad Kashyap <[EMAIL PROTECTED]
> wrote:
1. Done. Moved the maven executable to the properties file.
2. Hmm.. The svn info command seems to work fine for me. In fact, it saves the output to a file which I then convert into the properties format. So yes, the info is readily available in a properties format. Need to figure out why/what is failing on your machine.
Cheers
Prasad
On 11/11/05, David Blevins <[EMAIL PROTECTED]
> wrote:
On Nov 10, 2005, at 9:59 AM, Prasad Kashyap wrote:> Hi David,>> Check out the ant files for the work publish_build.sh used to do.
> It does almost everything except for the remote cleanup > name="cleanupRemote">. I'm still thinking about a nice clean way of> doing this. Executing a remote script (ant or other) is one of the
> thoughts. Let me know what you think.>I gave it a whirl. Didn't quite work as-is on my machine. Couplenotes for you: 1. It has maven.bat hardcoded in there. Maybe you could make the
path to the maven executable a property. 2. The svn info command doesn't seem to work on URLs (i.e. http://
svn.apache.org//). Seems to just report the version and other info of your working copy. I can't see any other way to get theversion other than what I was doing, so I put that one-liner in ascript in my home dir that you can hit from the ant script:
http://people.apache.org/~dblevins/gbuild/svnversion.cgiNow that I think about it, you might want that version in a
properties file format. Let me know if you do or what else you need.Looks great so far! -David
[jira] Created: (GERONIMO-1187) Connection listeners for both Tomcat and Jetty not displayed
Connection listeners for both Tomcat and Jetty not displayed Key: GERONIMO-1187 URL: http://issues.apache.org/jira/browse/GERONIMO-1187 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: windows xp, IE 6.0.x Reporter: Joe Bohn Fix For: 1.0 Scenario: Select the Web Server page in the console and view the connections listed for both Jetty and Tomcat (when both Jetty and Tomcat are running when you start the server). Select the all configurations view and stop the tomcat server. Return to the Web Server page and the network listener view correctly shows just the connections for jetty. Return to the all configurations view and start the tomcat server again. Return to the Web Server page and the network listener view still only displays the connections for jetty. I stopped and started the tomcat container multiple times but could never get the tomcat entries to re-appear. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo ORB progress
David Blevins wrote:
So what kind of testing framework is this? Is it junit-based?
Yes, it is junit-based. Essentially, we have created a test superclass,
which inherits from junit.framework.Test.
So, assume we would like a Multi-JVM test with a single test case named
"Simple". We have two JVM's, a client and a server. The client and
server each needs to do some initialization, then the client initiates a
test, and finally the server needs to do some checks after the test.
A multi-JVM junit test would look something like this:
class MultiJvmTest extends RemoteTest {
public void setUp() {
// Starts a JVM named "server"
startTestAgent("server");
// Starts a JVM named "client"
startTestAgent("client");
}
public void serverBeforeSimple() {
// Setup the server for test case "Simple"
// This method will be invoked in the "server" JVM.
}
public void clientBeforeSimple() {
// Setup the client for test case "Simple".
// This method will be invoked in the "client" JVM.
}
public void clientTestSimple() {
// Run the test
}
public void serverAfterSimple() {
// Check server state after test.
}
}
When running this test, the framework would do the following:
- run setUp(). This starts the two JVM's identified by the strings
"server" and "client". Thus, there is three JVM's running in total, a
master JVM, and two slave JVMs.
- invoke the serverBeforeSimple() in the "server" JVM.
- invoke the clientBeforeSimple() in the "client" JVM.
- invoke the clientTestSimple() in the "client" JVM.
- invoke the serverAfterSimple() in the "server" JVM.
The whole thing integrates pretty well with junit. If an exception is
thrown in a slave JVM, it will be rethrown in the master JVM, resulting
in a correct stack trace identifying where the test failed. Furthermore,
it is possible to start an agent within the master JVM, so single-step
debugging is possible as well.
Communication between the JVM's takes place using plain RMI.
An agent can be given a Properties as argument. There is also a global
set of properties shared by all JVMs.
The framework uses reflection to collect the methods that is called when
the test is run. The methods must be named:
Before
Test
After
How does it related to our existing itests? Those are server (and
database) agnostic and can be ran across several vms and orbs. Don't
know if there is any overlap.
I don't know how the existing itests work. There may be some overlap.
Would these test be run as part of a normal build or would we set them
up to run periodically in continuum or something?
These tests are intended to be run as "normal" junit tests. Thus they
should be part of the normal build.
Are the tests focused on verifying corba compliance or is this somehow
more generic and applicable to testing in general?
The framework is quite general, but of course tailored with the features
we needed. There is nothing CORBA-specific in it.
I would be happy to know if there is code out there that does something
similar to this framework. We have looked around, but haven't really
found anything that seemed quite right to our purpose.
Anders
[jira] Created: (GERONIMO-1186) Illegal argument exception when returning from add listener to display list in web server page, network listeners portlet
Illegal argument exception when returning from add listener to display list in web server page, network listeners portlet - Key: GERONIMO-1186 URL: http://issues.apache.org/jira/browse/GERONIMO-1186 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: Windows XP , IE 6.0.x Reporter: Joe Bohn Fix For: 1.0 Scenario: >From the console select the Web Server page. Select any "Add new listener for " link return to list by selecing list connectors This exception is thrown: 09:09:31,967 ERROR [Servlet] Exception caught: java.lang.IllegalArgumentException: Render parameter key or value must not be nu ll. at org.apache.pluto.core.impl.ActionResponseImpl.setRenderParameter(Acti onResponseImpl.java:164) at org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction (ConnectorPortlet.java:68) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde r.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke rImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde r.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5 68) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplication Context.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java: 244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) 09:09:32,198 WARN [BasicProxyManager] Could not load interface org.apache.geron imo.tomcat.TomcatWebConnector in provided ClassLoader for TomcatAJPConnector 09:09:32,198 WARN [BasicProxyManager] Could not load interface org.apache.geron imo.tomcat.TomcatWebConnector in provided ClassLoader for TomcatWebConnector 09:09:32,208 WARN [BasicProxyManager] Could not load interface org.apache.geron imo.tomcat.TomcatWebConnector in provided ClassLoader for TomcatWebSSLConnector -- 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-1181) Add/Edit Tomcat HTTPS Connector does not address truststore parameters
[ http://issues.apache.org/jira/browse/GERONIMO-1181?page=all ] Vamsavardhana Reddy updated GERONIMO-1181: -- Attachment: GERONIMO-1181.patch > Add/Edit Tomcat HTTPS Connector does not address truststore parameters > -- > > Key: GERONIMO-1181 > URL: http://issues.apache.org/jira/browse/GERONIMO-1181 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0 > Environment: Win XP, Sun JDK 1.4.2_08 > Reporter: Vamsavardhana Reddy > Assignee: Vamsavardhana Reddy > Attachments: GERONIMO-1181.patch > > Adding/Editing Tomcat HTTPS Connectors through Connector portlet does not > provide fields to add/edit truststoreFileName, truststoreType and > truststorePassword attributes. -- 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-1181) Add/Edit Tomcat HTTPS Connector does not address truststore parameters
[ http://issues.apache.org/jira/browse/GERONIMO-1181?page=all ] Vamsavardhana Reddy updated GERONIMO-1181: -- Geronimo Info: [Patch Available] Assign To: Vamsavardhana Reddy > Add/Edit Tomcat HTTPS Connector does not address truststore parameters > -- > > Key: GERONIMO-1181 > URL: http://issues.apache.org/jira/browse/GERONIMO-1181 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0 > Environment: Win XP, Sun JDK 1.4.2_08 > Reporter: Vamsavardhana Reddy > Assignee: Vamsavardhana Reddy > Attachments: GERONIMO-1181.patch > > Adding/Editing Tomcat HTTPS Connectors through Connector portlet does not > provide fields to add/edit truststoreFileName, truststoreType and > truststorePassword attributes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo ORB progress
Just throwing out some questions in hopes to spur a conversation. Feel free combine questions or throw in details as you see fit. So what kind of testing framework is this? Is it junit-based? How does it related to our existing itests? Those are server (and database) agnostic and can be ran across several vms and orbs. Don't know if there is any overlap. Or is this somehow daytrader-like which is performance focused but also makes a great way to system test. Would these test be run as part of a normal build or would we set them up to run periodically in continuum or something? Are the tests focused on verifying corba compliance or is this somehow more generic and applicable to testing in general? Thanks, David On Nov 16, 2005, at 2:00 AM, Anders Hessellund Jensen wrote: Hi all, This is to let you all in on the progress with the Geronimo ORB implementation. We have been working on writing a test framework, that would allow us to coordinate and run ORBs in separate JVMs. The test framework is not 100% polished yet, but it works, and it facilitates very easy implementation of multiple-VM unit tests. We expect to contribute a patch within this week, which will contain a basic, working "Hello World" corba test. We have had some frustrations here at Trifork. It is very difficult to for us to work together on the code without being able to commit the code to a source repository, especially on a rapidly changing project like the ORB. Of course we can submit patches, but these will, in the optimal case, take at least a few hours and perhaps several days to get committed to the repo. Whats worse, this situation with the code in the repo is significantly behind, makes it virtually impossible for people other than us in Trifork to work on the orb. I would like to hear some community response to this. Optimally, we would like to gain commit access to the Geronimo repo. I understand that you will not just hand out commit access to everyone, and that this has to be deserved. I am confident that we at Trifork will contribute enough code to become committer on Geronimo in the future, however, we need a solution to this problem now. Do you have any suggestions to what we should do? Should we setup a separate source repository for example at Sourceforge? - We could then regularly sync this repo with the Geronimo repo, and everyone would be able to check out the very latest version of the code. Any other ideas? Best regards, Anders
[jira] Created: (GERONIMO-1185) Updated Web Access Log Viewer doesn't display any log records
Updated Web Access Log Viewer doesn't display any log records - Key: GERONIMO-1185 URL: http://issues.apache.org/jira/browse/GERONIMO-1185 Project: Geronimo Type: Bug Versions: 1.0 Environment: windows xp , IE, Firefox Reporter: Joe Bohn Fix For: 1.0 I tried various combinations of date ranges, ignore dates, record types, etc. I had both containers running and numerous log records in each. -- 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
Constructing deployment plans from Configuration GBeanData
I am trying to reconstruct deployment plan from the Configuration GBeanData. I have a code segment like the following. ObjectName configName = Configuration.getConfigurationObjectName(configId); GBeanData configData = kernel.getGBeanData(configName); Once I have the GBeanData object, I am retreiving the attributes, references & any GBeans inside the configuration and printing out the information. With this procedure, I am able to reconstruct the deployment plan for some, but not all :(, of the configurations in Geronimo. Is there any other way of getting deployment plan out of configuration GBeanData object?
Re: Java Adventure Builder Reference 1.0.1 webapp deployed
Preben Thorø wrote: Meanwhile, I hope our AB porting to the Trifork server can give you a few hints about where to go. I have attached our deployment plans (ie. server specific deployment desc.) to this mail I couldn't expect a better response! Thanks for the deployment descriptors. /Preben Jacek
RE: gbean look up exception
Thanks David, Its working. -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 16, 2005 1:15 PM To: dev@geronimo.apache.org Subject: Re: gbean look up exception I'm rather confused about what you are trying to do. Here are a couple of comments that I hope will be at least a little bit useful. I recommend putting all your code that does anything in classes rather than jsp pages. It is very difficult to trace problems back to code in jsp pages. If you wish to invoke a gbean, you need to know its complete name. ObjectName queries will not work. Whereever *:name=echoserver came from, you need to change it so it supplies the entire object name of your gbean. The easiest way to find out what that name is is to look in geronimo.log for notification that it has started. Search for name=echoServer. The full name has a lot more components. I believe you are trying to access a gbean in the same geronimo instance as your web app. Using the jmx connector is unnecessary and will require a lot of stuff you don't need, such as authenticating yourself to your gbean. You can get the kernel more directly with KernelRegistry.getSingleKernel(); thanks david jencks On Nov 15, 2005, at 9:37 PM, Ranjan, Rakesh ((Cognizant)) wrote: > Hi all, > > I have deployed a GBean. Then I am trying to look up that GBean > through Jsp page. But I am getting exception : > > > > GBean exception occurred during > initializationorg.apache.geronimo.kernel.GBeanNotFoundException: > *:name=echoserver not found > > org.apache.geronimo.kernel.GBeanNotFoundException: *:name=echoserver > not found > > at > org.apache.geronimo.kernel.basic.BasicRegistry.getGBeanInstance(BasicRe > gistry.java:110) > > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: > 179) > > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: > 175) > > at > org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:121) > > at > org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invo > ke() > > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodIn > voker.java:38) > > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation. > java:118) > > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.ja > va:795) > > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: > 180) > > at > org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDe > legate.java:117) > > at > mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java: > 219) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja > va:39) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso > rImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:324) > > at > mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34) > > at > mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectI > nvoker.java:99) > > at > mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionSub > jectInvoker.java:31) > > at > mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjectI > nvoker.java:90) > > at java.security.AccessController.doPrivileged(Native Method) > > at javax.security.auth.Subject.doAsPrivileged(Subject.java:500) > > at > mx4j.remote.MX4JRemoteUtils.subjectInvoke(MX4JRemoteUtils.java:163) > > at > mx4j.remote.rmi.RMIConnectionSubjectInvoker.subjectInvoke(RMIConnection > SubjectInvoker.java:86) > > at > mx4j.remote.rmi.RMIConnectionSubjectInvoker.invoke(RMIConnectionSubject > Invoker.java:80) > > at $Proxy1.invoke(Unknown Source) > > at > javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl. > java:221) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja > va:39) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso > rImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:324) > > at > sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) > > at sun.rmi.transport.Transport$1.run(Transport.java:148) > > at java.security.AccessController.doPrivileged(Native Method) > > at sun.rmi.transport.Transport.serviceCall(Transport.java:144) > > at > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTrans
[jira] Created: (GERONIMO-1184) Decouple the connector module from the kernel module
Decouple the connector module from the kernel module Key: GERONIMO-1184 URL: http://issues.apache.org/jira/browse/GERONIMO-1184 Project: Geronimo Type: Bug Components: connector Reporter: Guillaume Nodet Since revision 331909, the o.a.g.connector.outbound.AbstractConnectionMaanager implements o.a.g.gbean.GBeanLifeCycle. Thus the whole connector module is dependant on the kernel module. The jencks project now has to ship the kernel module also which has some drawbacks : the geronimo log is used instead of the default one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1182) Connector portlet improvement (delete connector confirmation, more form buttons)
[ http://issues.apache.org/jira/browse/GERONIMO-1182?page=all ] Vamsavardhana Reddy updated GERONIMO-1182: -- Assign To: Vamsavardhana Reddy > Connector portlet improvement (delete connector confirmation, more form > buttons) > > > Key: GERONIMO-1182 > URL: http://issues.apache.org/jira/browse/GERONIMO-1182 > Project: Geronimo > Type: Improvement > Components: console > Versions: 1.0-M5 > Environment: Win XP, Sun JDK 1.4.2_08 > Reporter: Vamsavardhana Reddy > Assignee: Vamsavardhana Reddy > Priority: Minor > Attachments: GERONIMO-1182.patch > > Minor improvements to Connector portlet. > 1. User confirmation on clicking "delete" link to delete a connector. > 2. Add "Reset" and "Cancel" buttons to edit pages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1183) Console/Tomcat: Add/Edit Jetty HTTPS Connector page does not provide "key password" field
[ http://issues.apache.org/jira/browse/GERONIMO-1183?page=all ] Vamsavardhana Reddy updated GERONIMO-1183: -- Component: console > Console/Tomcat: Add/Edit Jetty HTTPS Connector page does not provide "key > password" field > - > > Key: GERONIMO-1183 > URL: http://issues.apache.org/jira/browse/GERONIMO-1183 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0-M5 > Environment: Win XP, Sun JDK 1.4.2_08 > Reporter: Vamsavardhana Reddy > > Under "Console/Tomcat" application, add/edit Jetty HTTPS Connector page does > not provide "server key password" field. -- 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-1183) Console/Tomcat: Add/Edit Jetty HTTPS Connector page does not provide "key password" field
Console/Tomcat: Add/Edit Jetty HTTPS Connector page does not provide "key password" field - Key: GERONIMO-1183 URL: http://issues.apache.org/jira/browse/GERONIMO-1183 Project: Geronimo Type: Bug Versions: 1.0-M5 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Under "Console/Tomcat" application, add/edit Jetty HTTPS Connector page does not provide "server key password" field. -- 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: Java Adventure Builder Reference 1.0.1 webapp deployed
Hi I vaguely recall a similar problem trying to port AB to JBoss - I will try to dig into it. Meanwhile, I hope our AB porting to the Trifork server can give you a few hints about where to go. I have attached our deployment plans (ie. server specific deployment desc.) to this mail - they depend on a number of resources (jdbc/adventure/AdventureDB, jms/activity/QueueConnectionFactory, jms/lodging/QueueConnectionFactory, jms/airline/QueueConnectionFactory, jms/opc/QueueConnectionFactory, jms/activity/ActivityQueue, jms/lodging/LodgingQueue, jms/airline/AirlineQueue, jms/opc/WorkFlowMgrQueue, jms/opc/CRMQueue, jms/opc/WebServiceBrokerQueue, jms/opc/OrderFillerQueue, mail/opc/MailSession, principal: guest/guest, principal: j2ee/j2ee) /Preben Jacek Laskowski wrote: Arun Venugopal wrote: Hi Jacek, We tried to see if we can get Adventure builder to work on geronimo. We managed to get all the modules (ears) deployed. Currently we are dealing with an Axis fault (seems to be some sort of a url not found issue, we are yet to dig deep into it). We had an issue with "unknown primary key". We had to add a new primary key field (changed the EJB source to add getters and setters) and a key generator for solving it. Hopefully once we have resolved the axis fault we will have a fully working adventure builder. Hi Arun, Whow! That's excellent. Would you be able to share the plans so that I won't waste my time (and those who await the app fully running) figuring them out again? These mentioned issues seem very similar to what were showing up during the Pet Store deployment endeavour and hopefully two of us could achieve more working together than separately(there're tons of issues to work out and personally I wish I could finally take a look at the console). You could be able to see what's already available in the repository. Just check out sandbox/adventurebuilder if you don't need the rest. Arun Jacek OPC PurchaseOrderBean ejb/local/opc/po/PurchaseOrder PurchaseOrderBean true CreditCardBean ejb/local/opc/po/CreditCard CreditCardBean true ActivityBean ejb/local/opc/po/Activity ActivityBean true TransportationBean ejb/local/opc/po/Transportation TransportationBean true ContactInfoBean ejb/local/opc/po/ContactInfo ContactInfoBean true AddressBean ejb/local/opc/po/Address AddressBean true LodgingBean ejb/local/opc/po/Lodging LodgingBean true PoEndpointBean PoEndpointBean 60 0 jms/opc/QueueConnectionFactory jms/opc/QueueConnectionFactory guest guest jms/opc/WorkFlowMgrQueue jms/opc/WorkFlowMgrQueue PurchaseOrderIntfPort webservice/PoEndpointBean BrokerServiceBean BrokerServiceBean 60 0 jms/opc/QueueConnectionFactory jms/opc/QueueConnectionFactory guest guest jms/opc/WorkFlowMgrQueue jms/opc/WorkFlowMgrQueue BrokerServiceIntfPort webservice/WebServiceBroker OtEndpointBean OtEndpointBean 60 0 OrderTrackingIntfPort webservice/OtEndpointBean WorkFlowManagerBean jms/opc/WorkFlowMgrQueue jms/opc/QueueConnectionFactory guest guest param/CreditCardServiceURL java.lang.String http://localhost:8080/webservice3/CreditCardService jms/opc/QueueConnectionFactory jms/opc/QueueConnectionFactory
Geronimo ORB progress
Hi all, This is to let you all in on the progress with the Geronimo ORB implementation. We have been working on writing a test framework, that would allow us to coordinate and run ORBs in separate JVMs. The test framework is not 100% polished yet, but it works, and it facilitates very easy implementation of multiple-VM unit tests. We expect to contribute a patch within this week, which will contain a basic, working "Hello World" corba test. We have had some frustrations here at Trifork. It is very difficult to for us to work together on the code without being able to commit the code to a source repository, especially on a rapidly changing project like the ORB. Of course we can submit patches, but these will, in the optimal case, take at least a few hours and perhaps several days to get committed to the repo. Whats worse, this situation with the code in the repo is significantly behind, makes it virtually impossible for people other than us in Trifork to work on the orb. I would like to hear some community response to this. Optimally, we would like to gain commit access to the Geronimo repo. I understand that you will not just hand out commit access to everyone, and that this has to be deserved. I am confident that we at Trifork will contribute enough code to become committer on Geronimo in the future, however, we need a solution to this problem now. Do you have any suggestions to what we should do? Should we setup a separate source repository for example at Sourceforge? - We could then regularly sync this repo with the Geronimo repo, and everyone would be able to check out the very latest version of the code. Any other ideas? Best regards, Anders
[jira] Commented: (GERONIMO-1148) Console/Tomcat application does not start
[ http://issues.apache.org/jira/browse/GERONIMO-1148?page=comments#action_12357774 ] Vamsavardhana Reddy commented on GERONIMO-1148: --- In M5 release, both Console/Jetty and Console/Tomcat applications could run at the same time. This problem is noticed post M5. > Console/Tomcat application does not start > - > > Key: GERONIMO-1148 > URL: http://issues.apache.org/jira/browse/GERONIMO-1148 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0-M5 > Environment: Win XP, Sun JDK 1.4.2_08 > Reporter: Vamsavardhana Reddy > Fix For: 1.0 > > Geronimo Console application under Tomcat does not start. Upon clicking the > "start" link in "Application EARs" portlet, the message "Configuration not > found" is displayed in console. The following errors are logged to > geronimo.log > 11:23:27,292 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error > while dispatching portlet. > javax.portlet.PortletException: Configuration not found > at > org.apache.geronimo.console.configmanager.ConfigManagerPortlet.processAction(ConfigManagerPortlet.java:130) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) > at > org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) > at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) > at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) > at > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) > at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) > at > org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) > at org.mortbay.http.HttpServer.service(HttpServer.java:954) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) > Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Could > not extract gbean data from configuration > at > org.apache.geronimo.kernel.config.ConfigurationManagerImpl.loadGBeans(ConfigurationManagerImpl.java:125) > at > org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:130) > at > org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(F
[jira] Updated: (GERONIMO-1182) Connector portlet improvement (delete connector confirmation, more form buttons)
[ http://issues.apache.org/jira/browse/GERONIMO-1182?page=all ] Vamsavardhana Reddy updated GERONIMO-1182: -- Attachment: GERONIMO-1182.patch > Connector portlet improvement (delete connector confirmation, more form > buttons) > > > Key: GERONIMO-1182 > URL: http://issues.apache.org/jira/browse/GERONIMO-1182 > Project: Geronimo > Type: Improvement > Components: console > Versions: 1.0-M5 > Environment: Win XP, Sun JDK 1.4.2_08 > Reporter: Vamsavardhana Reddy > Priority: Minor > Attachments: GERONIMO-1182.patch > > Minor improvements to Connector portlet. > 1. User confirmation on clicking "delete" link to delete a connector. > 2. Add "Reset" and "Cancel" buttons to edit pages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1182) Connector portlet improvement (delete connector confirmation, more form buttons)
[ http://issues.apache.org/jira/browse/GERONIMO-1182?page=all ] Vamsavardhana Reddy updated GERONIMO-1182: -- Geronimo Info: [Patch Available] Description: Minor improvements to Connector portlet. 1. User confirmation on clicking "delete" link to delete a connector. 2. Add "Reset" and "Cancel" buttons to edit pages. was: Minor improvements to Connector portlet. 1. User confirmation on clicking "delete" link to delete a connector. 2. Add "Reset" and "Cancel" buttons edit pages. > Connector portlet improvement (delete connector confirmation, more form > buttons) > > > Key: GERONIMO-1182 > URL: http://issues.apache.org/jira/browse/GERONIMO-1182 > Project: Geronimo > Type: Improvement > Components: console > Versions: 1.0-M5 > Environment: Win XP, Sun JDK 1.4.2_08 > Reporter: Vamsavardhana Reddy > Priority: Minor > > Minor improvements to Connector portlet. > 1. User confirmation on clicking "delete" link to delete a connector. > 2. Add "Reset" and "Cancel" buttons to edit pages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1182) Connector portlet improvement (delete connector confirmation, more form buttons)
Connector portlet improvement (delete connector confirmation, more form buttons) Key: GERONIMO-1182 URL: http://issues.apache.org/jira/browse/GERONIMO-1182 Project: Geronimo Type: Improvement Components: console Versions: 1.0-M5 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Priority: Minor Minor improvements to Connector portlet. 1. User confirmation on clicking "delete" link to delete a connector. 2. Add "Reset" and "Cancel" buttons edit pages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Who Will Be At ApacheCon US in December?
I will be at ApacheCon.
Kresten Krab Thorup
[EMAIL PROTECTED]
"We do not inherit the Earth from our parents, we borrow it from our
children." Saint Exupery
On Nov 15, 2005, at 6:42 PM, Bruce Snyder wrote:
Please respond to this message if you will be at ApacheCon US in
December. There seems to be no clear indication of who will be there
and who will not because many people are missing from the hackathon
sign up doc. So far I see the following names from the Geronimo
committer and/or PMC lists:
Jeremy Boynes
Alan Cabrera
Jeff Genender
Matt Hogstrom
Geir Magnusson
Aaron Mulder
Bruce Snyder
Davanum Srinivas
Dain Sundstrom
If you're going to sign up for the hackathon, you've got until
Thursday to do it - so get on it! ;-)
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61EG;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
smime.p7s
Description: S/MIME cryptographic signature
The Installer
It would be good if we could get the installer working well for 1.0. Here are some of the things I think need to happen. 1. The necessary izpack jars need to get into some maven repo, preferably a public one such as ibiblio. They might be on there way there already, otherwise we should figure out which jars are needed and file an upload request. 2. Installer building should occur in its own module in assemblies. It would be best if the installer can be built using a maven plugin, but if that seems impractical we can use a bunch of jelly for now. There is an izpack plugin but I think it is maven 2 only (??). 3. The installer currently has a page where you check the major features you want, and on the following pages you configure them. This seems like a basically acceptable paradigm to me, but there is a problem in that all the "following pages" display even if they are empty. I've been told that moving the element out one level to the panel element will fix this. 4. The installer currently works by installing everything in a full geronimo install, and not starting the pieces you don't want. This is rather unsatisfactory unless you sell disk space. The geronimo assembly is moving to use of the packaging and assembly plugins, and we can leverage that with the installer. What I am thinking of is including a maven repository inside the installer jar that includes everything from a full geronimo install with everything, including all the .car files for the configurations. Then we can imitate or use the assembly plugin to copy the configuration dependencies into the install target and install the actual configurations. 5. We should find a way to check that no port conflicts have been configured. 6. We need to construct a config.xml file for the target install. This could be done by adding bits associated with each configuration, or by removing chunks from a "universal" config.xml for the configurations we didnt' install. 7. Somewhat similarly, we need to include the schema files (for human reference, they aren't used by geronimo) for the bits that are included in the install target. This should proceed by fixing the xmlbeans plugin to put schemas in the same place the xmlbeans ant task does, and by extracting all such schemas from our dependencies. This needs to be added to the assembly plugin: it is not installer specific. There's probably more to do, but this is what I've thought of so far. thanks david jencks
[jira] Commented: (GERONIMO-1175) Schema conversion problems in geronimo plans
[ http://issues.apache.org/jira/browse/GERONIMO-1175?page=comments#action_12357770 ] David Jencks commented on GERONIMO-1175: Yet another problem detected by Jian Liao, many thanks! Sending modules/j2ee-schema/src/java/org/apache/geronimo/schema/GBeanElementConverter.java Sending modules/web-builder/src/test/org/apache/geronimo/web/deployment/GenericToSpecificPlanConverterTest.java Adding modules/web-builder/src/test-resources/plans/tomcat-pre2.xml Transmitting file data ... Committed revision 344944. > Schema conversion problems in geronimo plans > > > Key: GERONIMO-1175 > URL: http://issues.apache.org/jira/browse/GERONIMO-1175 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0 > > Two similar and somewhat interrelated problems: > 1. GenericToSpecificPlanConverter converts all the elements inside gbean > elements to the new namespace, including contents of xml-attributes and > xml-references, which thus lose their namespace info. > 2. GBeanElementConverter doesn't convert the namespace of xml-attribute and > xml-reference elements. > Thanks to Jian Liao for discovering these problems -- 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
