M4 Date and Axis
In GERONIMO-745 Move from Axis 1.3-SNAPSHOT to formal version, Dims said Have we decided on a date for M4 yet? i'd want to explore releasing Axis 1.3 final prior to M4 if possible. Are we close enough to be able to set a cutoff date for changes to the M4 QA branch, so we can answer his question? John
Re: HEAD broken?
Yep...all works now. Oh well...looks like the eBay deal for my Powerbook won't be happening after all. ;-) Thanks, Jeff David Jencks wrote: I missed adding a new file. should be fixed now. thanks david jencks On Jul 20, 2005, at 10:11 PM, Jeff Genender wrote: All the same since day one...(maven 1.0.2)...and no touchy service-builder ;-) Thanks...let me know if you see anything or if my powerbook is beginning to become possessed ;-) Jeff David Jencks wrote: I'm starting a build on a fresh machine... but meanwhile... that is set in etc/project.properties. Is there any chance you have modified your copy of service-builder to not inherit from etc? Are you using maven 1.0.2? thanks david jencks On Jul 20, 2005, at 9:58 PM, Jeff Genender wrote: Followed your directions and the error still is there... Jeff David Jencks wrote: I updated the maven-xmlbeans2-plugin in preparation for it moving to xmlbeans. You might have caught an update between the geronimo and openejb commits, or you might need to cd plugins/maven-xmlbeans2-plugin;maven -o plugin:install I will check again, but it works for me. thanks david jencks On Jul 20, 2005, at 9:39 PM, Jeff Genender wrote: I am getting this in the service-builder: Unable to obtain goal [default] -- /Users/powerbook/.maven/cache/xmlbeans-maven-plugin-2.0.0-beta1/ plugin.jelly:40:23: fail Missing required attribute: maven.xmlbeans2.targetdir
Re: Webdav admin interface
On Jul 20, 2005, at 7:09 PM, Lyndon Samson wrote: Just another wacky idea but... Webdav clients are becomming more common. Webdav is being used for admin like tasks ( http://metzner.org/projects/xincon/ ). I wonder if you could wrap webdav around Management GBeans/JMX/? and give access to Geronimos internals in a similar manner to the /proc interface in Linux. Would it add anything or just be a cool bit of code? :-) Oh my... that Linux davfs module has me drooling. I wrote a whole telnet implementation for OpenEJB 1.0 once with hopes of doing something like this. This is a whole other ballpark. So could we actually do something like execute components in the kernel from bash? (please say yes, please say yes) -David
Re: Change of JIRA
yep - I'll take another run at it this morning. Scary things were happening yesterday, and I figured they were infra related. geir On Jul 20, 2005, at 11:26 PM, David Jencks wrote: The security feature doesn't seem to be working yet (or else I can't find it on the page). Can you let us know if/when it is set up? thanks david jencks On Jul 20, 2005, at 3:20 AM, Geir Magnusson Jr. wrote: I'm trying to add an issue security scheme to JIRA for the Apache Geronimo project so we can have a private scheme for TCK issues that can't be public. I've also added a TCK component. Current issues will have no level attached to them, and going forward, we have a default of public (anyone can see) and for TCK issues, we make them non-public. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Comment in j2ee-server-plan.xml about jetty in M4
Should the comment below be removed from the file? If not, can someone explain where Jetty is involved here. Should we be able to run M4 with tomcat without any jetty use at all? !-- HTTP/SOAP Protocol is now run through jetty-- Thanks, John
Re: Comment in j2ee-server-plan.xml about jetty in M4
I would think it should be removed or at least moved to he appropriate config file if need be. Jeff [EMAIL PROTECTED] wrote: Should the comment below be removed from the file? If not, can someone explain where Jetty is involved here. Should we be able to run M4 with tomcat without any jetty use at all? !-- HTTP/SOAP Protocol is now run through jetty-- Thanks, John
Re: Comment in j2ee-server-plan.xml about jetty in M4
yes, remove it. that's very historical :-) At one time there was a primitive soap listener in openejb. Then there was a special port for ws on jetty. now ws runs through the normal web port, either jetty or tomcat. david jencks On Jul 20, 2005, at 11:30 PM, [EMAIL PROTECTED] wrote: Should the comment below be removed from the file? If not, can someone explain where Jetty is involved here. Should we be able to run M4 with tomcat without any jetty use at all? !-- HTTP/SOAP Protocol is now run through jetty-- Thanks, John
[jira] Closed: (GERONIMO-771) Move from custom cglib build version HEAD-06-06-05 to cglib-nodep-2.1_2.jar
[ http://issues.apache.org/jira/browse/GERONIMO-771?page=all ] David Jencks closed GERONIMO-771: - Fix Version: 1.0-M5 Resolution: Fixed changed to 2.1_2, build works. Move from custom cglib build version HEAD-06-06-05 to cglib-nodep-2.1_2.jar --- Key: GERONIMO-771 URL: http://issues.apache.org/jira/browse/GERONIMO-771 Project: Geronimo Type: Task Components: dependencies Versions: 1.0-M4 Reporter: John Sisson Assignee: David Jencks Priority: Minor Fix For: 1.0-M4, 1.0-M5 Attachments: openejb_cvs_head.patch, openejb_m4qa.patch Fixed in Geronimo HEAD rev 219982. Fixed in Geronimo M4 QA branch rev 219983 Waiting for attached OpenEJB patch to be applied to CVS HEAD. Waiting for attached OpenEJB patch to be applied to CVS M4 QA branch. -- 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: Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
Bruce Snyder wrote: On 7/20/05, Jeremy Boynes [EMAIL PROTECTED] wrote: Jeff Genender wrote: Ok...fair enough...then how far out would M5 be (estimates)? IMHO, waiting for the time between M3-M4 cannot be between M4- M5. If it is going to be that long, then +1000 to get it in now. If its a fairly short period, then waiting will not be a big deal. Blevins was talking about release early, often. Adding this change in can only delay M4 and as we are talking M5 in just a few weeks I would say stick with the current branch and use this as an incentive to get M5 out soon. I'd like to hear some opinions from community members who are not committers. If you are reading this message and you are not a committer, PLEASE SPEAK UP! We want to hear your opinion on this matter. Bruce In our projects we use tomcat as the web container of choice, so we'd be delighted with the new tomcat/jetty picker in geronimo. But, in the grand scheme of things I believe that getting a new milestone is more important right now, for various reasons (broken M3, TCK compliance, immense improvements all over). If M5 comes out in a month or so, then I guess everyone is going to be happy, even if the picker doesn't get in M4. In fact I would consider this an interesting goal for the project: learn how to release often. I would expect a milestone to take about a week to be released, after branching (for QA, TCK testing etc.). So I'd say take four weeks after M4 to bring in new stuff and fix bugs and then spend another week in QA, before releasing. If this schedule proves rather tight, next time increase the intervals by 25% or so. Perhaps, even appoint a release engineer to tag, branch, make the golden build and say no to new patches :-) As for poor old people like myself who would like a tomcat-integrated build rather sooner than later, perhaps we could beg Jeff to do an unsupported build with tomcat as default just once for M4? Regards, Panagiotis
Re: Webdav admin interface
We experimented with this with WLS, it worked pretty well. The nice thing about webdav is that you can mount it as a file system from windows and OSX. We also tried a similar experiment with ftp which also worked pretty well. However, you generally want to script admin commands and there are a lot of other java-based scripting options out there which can just use JMX directly. andy At 05:09 PM 7/20/2005, Lyndon Samson wrote: Just another wacky idea but... Webdav clients are becomming more common. Webdav is being used for admin like tasks ( http://metzner.org/projects/xincon/ ). I wonder if you could wrap webdav around Management GBeans/JMX/? and give access to Geronimos internals in a similar manner to the /proc interface in Linux. Would it add anything or just be a cool bit of code? :-) cheers lyndon -- Into RFID? www.rfidnewsupdate.com Simple, fast, news.
gbean.org - what is it?
Dain, Alan, Hiram, Aaron, The web site says The GBean architecture a minimalistic kernel and server framework for enterprise software. - What is gbean.org? - Is it related to geronimo? - Is it a fork of geronimo code? - Who should use gbean in geronimo? - Is the gbean in geronimo dead and buried? - why is there a fork? if it is one? - why can't you guys work on it here at Apache? - Shouldn't this be part and parcel of Geronimo? Isn't this what Geronimo was designed for? -- dims -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: gbean.org - what is it?
Good questions. --- Davanum Srinivas [EMAIL PROTECTED] wrote: Dain, Alan, Hiram, Aaron, The web site says The GBean architecture a minimalistic kernel and server framework for enterprise software. - What is gbean.org? - Is it related to geronimo? - Is it a fork of geronimo code? - Who should use gbean in geronimo? - Is the gbean in geronimo dead and buried? - why is there a fork? if it is one? - why can't you guys work on it here at Apache? - Shouldn't this be part and parcel of Geronimo? Isn't this what Geronimo was designed for? -- dims -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for future releases)
My 2c... On the issue of releases there are several different types of folks that are interested in using Geronimo. Off the top of my head they are: Techies that want an implementation to play around with and are very comfortable with an unstable, constantly evolving codebase. (Unstable is good enough) Developers that want a J2EE compliant container that is mostly stable (more stable than not) so they can quickly crank out some code. They are willing to accept bug fixes but their goal is more on getting applications coded than on coding the Application Server. (Milestones are good enough) ISVs. These folks need a stable infrastructure because they are most likely imbedding Geronimo and their application together. Their need for stability is significantly higher than the perceding two. They would choose to support the App Server themselves or pay someone for support. Their goal is to sell applications and make some money. (Vn.n is their preferred choice of delivery) Enterprise customers. They are in business to make money and technology is a business decsision. They want infrastructure that will not disrupt their business, provides a good function / per dollar spent. They want (Vn.1+ and support so they don't have to chase things down). They want N-1 or N-2 compatibility so things don't break and they have to rework their infrastructure. They are the most demanding. I'm a bit dismayed about the previous posts about assuming a release will suck. If thats your view then it will suck and one has to ask what is the relvance of the project? I think the goals in the past has been to get to J2EE 1.4 certification and you guys made it (well almost). IMHO the important item at this point is for the PMC to set a list of goals for a release and a target date. I know that the community doesn't operate on a schedule but I think its important to have a set of goals that folks are converging on as a team. Perhaps there is a model that Eclipse uses with their sub projects for additional function that might be worth considering. If my understanding is correct they have the Eclipse project and a number of sub projects that add value. (UML, EMF, etc.) What if we had a set of core J2EE functionality for Geronimo and a set of subprojects that could be bolted in (like clustering for instance). It would allow them to be a bit more independent in terms of development and delivery and would allow the Core to be more stable in terms of release. I agree with Jencks that a September deliverable makes sense if we can agree what the content should be. For my part I would like to add ARM support for the post V1.x product and some monitoring capability. (I'll open JIRA features today). There are a lot of excellent ideas on the table to make Geronimo immensely useful and widely adopted. The team has not built something that sucks; its just yound and it will grow up, if we want it to. Flamesuit state=on/ - Matt - Original Message - From: Aaron Mulder [EMAIL PROTECTED] To: dev@geronimo.apache.org Sent: Wednesday, July 20, 2005 12:06 PM Subject: Re: Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for future releases) For my part, I'm not convinced that September is realistic for 1.0. But I definitely hope to get 1.0 out by ApacheCon US (December). I need to spend some time on what I want to see in 1.0. Perhaps a 1.0 release number should be added to JIRA, so we can put things in there, and then mark them back to a sooner milestone where appropriate. Aaron On Tue, 19 Jul 2005, David Jencks wrote: Thanks for pushing on this issue. I think it is really important that we put out a 1.0 release very soon. I think it needs to work, and be tck compliant, but I don't think it has to be all that much more usable than what we have now. I'd rather get feedback and users than perfection. The features I think we need for 1.0 are: clean up some architectural problems. I think I'll get the ones I know about fixed by the end of this week. clean up the plan xml. I think this is a fairly quick job. Decide what we will continue to support from our 1.0 release. IMO this is only the plan xml schemas and possibly some interfaces exposed by some gbeans, primarily gbeans exposed by jsr-77 get the web console in, preferably with instructions on how to change the static page in which the portlets appear. I'd like to get 1.0 out by Sept 15th. Can everyone think carefully about what they really need to be in 1.0, what they will commit to actually implementing themselves, and when they think it can be done by? thanks david jencks On Jul 19, 2005, at 12:58 PM, David Blevins wrote: On Jul 19, 2005, at 7:06 AM, [EMAIL PROTECTED] wrote: Maybe after M4 is out we should look at creating some further milestone versions in JIRA and start assigning some of the tasks that were in the Roadmap that Geir discussed to them, so we
Re: Clustering (long)
Hi Jules It sounds like you've been working hard! I think you might find you run into reliability issues with a singleton coordinator. This is one of those well known Hard Problems and for session replication its not really necessary. In essence the coordinator is a single point of failure and making it reliable is provably non trivial. Cluster re-balancing is also a hairy issue in that its easy to run into cascading failures if you pro-actively move sessions when a server leaves the cluster. I'm happy to talk more about these issues off-line if you want. Thanks andy At 02:31 PM 6/30/2005, Jules Gosnell wrote: Guys, I thought that it was high time that I brought you up to date with my efforts in building a clustering layer for Geronimo. The project, wadi.codehaus.org, started as an effort to build a scalable clustered HttpSession implementation, but in doing this, I have built components that should be useful in clustering the state held in any tier of Geronimo e.g. OpenEJB SFSBs etc. WADI (Web Application Distribution Infrastructure) has two main elements - the vertical and the horizontal. Vertically, WADI comprises a stack of pluggable stores. Each store has a pluggable Evicter responsible for demoting aging Sessions downwards. Requests arriving at the container are fed into the top of the stack and progress downwards, until their corresponding Session is found and promoted to the top, where the request is correctly rendered in its presence. Typically the top-level store is in Memory. Aging Sessions are demoted downwards onto exclusively owned LocalDisc. The bottom-most store is a database shared between all nodes in the Cluster. The first node joining the Cluster promotes all Sessions from the database into exclusively-owned store - e.g. LocalDisc. The last node to leave the Cluster demotes all Sessions down back into the database. Horizontally, all nodes in a WADI Cluster are connected (p2p) via a Clustered Store component within this stack. This typically sits at the boundary between exclusive and shared Stores. As requests fall through the stack, looking for their corresponding Session they arrive at the Clustered store, where, if the Session is present anywhere in the Cluster, its location may be learnt. At this point, the Session may be migrated in, underneath the incoming request, or, if its current location is considered advantageous, the request may be proxied or redirected to its remote location. As a node leaves the Cluster, all its Sessions are evacuated to other nodes via this store, so that they may continue to be actively maintained. The space in which Session ids are allocated is divided into a fixed number of Buckets. This number should be large enough such that management of the Buckets may be divided between all nodes in the Cluster roughly evenly. As nodes leave and join the Cluster, a single node, the Coordinator, is responsible for re-Bucketing the Cluster - i.e. reorganising who manages which Buckets and ensuring the safe transfer of the minimum number of Buckets to implement the new layout. The Coordinator is elected via a Pluggable policy. If the Coordinator leaves or fails, a new one is elected. If a node leaves or joins, buckets emigrate from it or immigrate into it, under the control of the Coordinator, to/from the rest of the Cluster. A Session may be efficiently mapped to a Bucket by simply %-ing its ID's hashcode() by the number of Buckets in the Cluster. A Bucket is a map of SessionID:Location, kept up to date with the Location of every Session in the Cluster, of which the id falls into its space. i.e. as Sessions are created, destroyed or moved around the Cluster notifications are sent to the node managing the relevant Bucket, informing it of the change. In this way, if a node receives a request for a Session which it does not own locally, it may pass a message to it, in a maximum of typically two hops, by sending the message to the Bucket owner, who then does a local lookup of the Sessions actual location and forwards the message to it. If Session and Bucket can be colocated, this can reduced to a single hop. Thus, WADI provides a fixed and scalable substrate over the more fluid arrangement that Cluster membership comprises, on top of which further Clustered services may be built. The above functionality exists in WADI CVS and I am currently working on hardening it to the point that I would consider it production strength. I will then consider the addition of some form of state replication, so that, even with the catastrophic failure of a member node, no state is lost from the Cluster. I plan to begin integrating WADI with Geronimo as soon as a certified 1.0-based release starts to settle down. Certification is the most immediate goal and clustering is not really part of the spec, so I think it best to satisfy the first before starting on subsequent goals. Further down the road we need to consider the unification of session id spaces used
[jira] Closed: (GERONIMO-769) TCL not correct when setting connector properties
[ http://issues.apache.org/jira/browse/GERONIMO-769?page=all ] David Jencks closed GERONIMO-769: - Fix Version: 1.0-M4 1.0-M5 Resolution: Fixed fixed in m4 Sending modules/connector/src/java/org/apache/geronimo/connector/outbound/ManagedConnectionFactoryWrapper.java Transmitting file data . Committed revision 220120. TCL not correct when setting connector properties - Key: GERONIMO-769 URL: http://issues.apache.org/jira/browse/GERONIMO-769 Project: Geronimo Type: Bug Components: connector Reporter: Jeremy Boynes Assignee: David Jencks Fix For: 1.0-M4, 1.0-M5 Attachments: MCFWrapper.diff I have a connector which has a property that takes a classname. When that property's setter is called it attempts to load the class using the TCL and gets a ClassNotFoundException even when the class is present in the connector and is loadable with Class.forName(). The connector is able to load classes using the TCL when creating managed connections. -- 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
xfire jar files needed at runtime?
Hi all, I noticed that the latest binary distribution of geronimo (1.0-169186) contains the following 2 xfire jar files: xfire-20050202.jar xfire-java-20050202.jar Do we really need them at runtime? Any info is appreciated. thanks, Lin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: xfire jar files needed at runtime?
no, their use has been removed from head. In the interests of greater stability the files that depend on them, although not actually used, will not be removed from m4. We do hope to eventually create a working xfire ws implementation, but I hope we would do that as separate geronimo modules rather than embedded inside openejb core. thanks david jencks On Jul 21, 2005, at 10:51 AM, lin sun wrote: Hi all, I noticed that the latest binary distribution of geronimo (1.0-169186) contains the following 2 xfire jar files: xfire-20050202.jar xfire-java-20050202.jar Do we really need them at runtime? Any info is appreciated. thanks, Lin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: xfire jar files needed at runtime?
David, Thanks so much for your answer. Correct me if I understand incorrectly So we will need the two jar files to build the files you mentioned below, but we don't need the two jar files at runtime. Lin --- David Jencks [EMAIL PROTECTED] wrote: no, their use has been removed from head. In the interests of greater stability the files that depend on them, although not actually used, will not be removed from m4. We do hope to eventually create a working xfire ws implementation, but I hope we would do that as separate geronimo modules rather than embedded inside openejb core. thanks david jencks On Jul 21, 2005, at 10:51 AM, lin sun wrote: Hi all, I noticed that the latest binary distribution of geronimo (1.0-169186) contains the following 2 xfire jar files: xfire-20050202.jar xfire-java-20050202.jar Do we really need them at runtime? Any info is appreciated. thanks, Lin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com thanks, Lin Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: xfire jar files needed at runtime?
I think that is the case for the rev you mention, and I'm fairly sure of it for the current m4 branch. Best way is to try it to find out :-). I'm 99% sure you will run into no problems as long as you don't use web services, and 90% sure even if you do use web services. thanks david jencks On Jul 21, 2005, at 11:25 AM, lin sun wrote: David, Thanks so much for your answer. Correct me if I understand incorrectly So we will need the two jar files to build the files you mentioned below, but we don't need the two jar files at runtime. Lin --- David Jencks [EMAIL PROTECTED] wrote: no, their use has been removed from head. In the interests of greater stability the files that depend on them, although not actually used, will not be removed from m4. We do hope to eventually create a working xfire ws implementation, but I hope we would do that as separate geronimo modules rather than embedded inside openejb core. thanks david jencks On Jul 21, 2005, at 10:51 AM, lin sun wrote: Hi all, I noticed that the latest binary distribution of geronimo (1.0-169186) contains the following 2 xfire jar files: xfire-20050202.jar xfire-java-20050202.jar Do we really need them at runtime? Any info is appreciated. thanks, Lin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com thanks, Lin Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: Web Console Status
Does this process still apply for Pluto 1.0.1-rc3? It looks like they are now producing 3 JAR files. If we are spending time integrating the web console into the sandbox, shouldn't we at least be using the latest Pluto version and use their file names as provided? -Donald --- Dave Colasurdo [EMAIL PROTECTED] wrote: The JIRA entry for the console (GERONIMO-762) has been updated with the instructions for creating pluto-portal.jar (actually the JIRA contains the jar as well). Is the required fix as simple as: 1) Rename pluto-portal-1.0.1-rc2.jar to geronimo-pluto-portal.jar 2) Publish the new jar to the Apache maven repository 3) Change the console dependency references to use the new name Any issues with this approach? Are special privileges required to publish to the Apache maven repository (http://cvs.apache.org/repository/)? Thanks -Dave- Aaron Mulder wrote: So it seems that the Pluto problem is pretty serious. We're actually dependent on an artifact that Pluto does not produce. There is no pluto-portal output from the Pluto build. I think that means we shouldn't be calling it pluto-portal, but instead geronimo-package-of-pluto-portal-code or something along those lines (but perhaps shorter). No wonder the Pluto fellow is not putting it in Maven! :) Aaron __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (GERONIMO-789) builder tests are ridiculously overcomplicated
builder tests are ridiculously overcomplicated -- Key: GERONIMO-789 URL: http://issues.apache.org/jira/browse/GERONIMO-789 Project: Geronimo Type: Improvement Components: deployment Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Most of the builder tests jump through endless hoops setting up 99% of a running geronimo implementation, only to check the count of gbeans at the end. Perhaps we could redesign the builders so they can be tested by supplying a spec dd, a plan (XmlObjects) , and a classloader. -- 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-788) Improved look feel for web console
[ http://issues.apache.org/jira/browse/GERONIMO-788?page=all ] pat heard updated GERONIMO-788: --- Attachment: reflection.zip Template for the console. Improved look feel for web console Key: GERONIMO-788 URL: http://issues.apache.org/jira/browse/GERONIMO-788 Project: Geronimo Type: Improvement Components: management Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.0 Attachments: reflection.zip It would be great to apply a nicer look to the web console. -- 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-788) Improved look feel for web console
[ http://issues.apache.org/jira/browse/GERONIMO-788?page=comments#action_12316419 ] Aaron Mulder commented on GERONIMO-788: --- Thanks! (I had asked Pat whether he'd be willing to donate his template under the ASL since it was the best free one I found with a bit of searching.) Improved look feel for web console Key: GERONIMO-788 URL: http://issues.apache.org/jira/browse/GERONIMO-788 Project: Geronimo Type: Improvement Components: management Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.0 Attachments: reflection.zip It would be great to apply a nicer look to the web console. -- 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: gbean.org - what is it?
Not being the one who created GBean.org I can speak for what it is but I'll throw in my 2c about what I think it could be. One of the areas that seems to confuse people I've talked to is that Geronimo is really two things. One the one hand it is a runtime framework that is independent of J2EE. I think the idea is to provide the services and infrastructure so that a variety of server personalities can be created that may or may not be J2EE centric. The other Geronimo is the J2EE 1.4 personality that I think is the high level focus of the group at this point. IMHO there will eventually be a break in terms of the kernel infrastructure versus the J2EE personality so I'm not too shocked at the creation of GBean.org. I think the low level of activity was because Geronimo is getting to its logical J2EE certification. In the future I would agree with GBean being the core of Geronimo and would become a component of the personality just like Active MQ or Jetty is part of the personality and can also stand alone today. Personally, I think the GBean effort would best be an Apache project based on its own merit as the effort began at Apache and is part of the Apache family under the Apache license. Moving to Codehaus permanently I think gives the impression of a divided community and one lacking synergy. Although I imagine that the right place will be found. So, I vote +1 for GBean.org, server personalities and all this to take place after V1.0. :) Matt - Original Message - From: Thomas P. Fuller [EMAIL PROTECTED] To: dev@geronimo.apache.org; [EMAIL PROTECTED] Sent: Thursday, July 21, 2005 9:07 AM Subject: Re: gbean.org - what is it? Good questions. --- Davanum Srinivas [EMAIL PROTECTED] wrote: Dain, Alan, Hiram, Aaron, The web site says The GBean architecture a minimalistic kernel and server framework for enterprise software. - What is gbean.org? - Is it related to geronimo? - Is it a fork of geronimo code? - Who should use gbean in geronimo? - Is the gbean in geronimo dead and buried? - why is there a fork? if it is one? - why can't you guys work on it here at Apache? - Shouldn't this be part and parcel of Geronimo? Isn't this what Geronimo was designed for? -- dims -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Management API
Dain, David J, and I talked about management options on IRC. I put a writeup on the Wiki (top of the page, with the original proposal below): http://wiki.apache.org/geronimo/Geronimo_Management_API I also have an IRC log if anyone cares, but I think the writeup is more coherent. :) Also, to address the JSR-77 point in the message below, this in no way reduces our JSR-77 compliance. It's just adding a friendlier option in addition to JSR-77. You can always use pure JSR-77 if you're a masochist (or just really really need portable code). Thanks, Aaron On Mon, 18 Jul 2005, Bruce Snyder wrote: On 7/16/05, Aaron Mulder [EMAIL PROTECTED] wrote: So after looking at the web console code and the JSR-77 spec, I got the idea in my head that we could use a management API made up of actual classes and interfaces, instead of object names and attribute names. This is not meant to replace JSR-77 as a portable interface across servers and protocols, and not meant to replace GBeans and the Kernel as a method to inspect and tweak every last property of any object available in any Geronimo configuration. It is meant to make it easier to develop management tools (such as the web console) against the common case of the Geronimo J2EE server. Anyway, since I've gotten trouble over long e-mails before, I wrote up what I have in mind and why I think it's a good idea (compared to the management options we have now) on the Wiki: http://wiki.apache.org/geronimo/Geronimo_Management_API Geez, that's just as bad as a long email ;-). Taken from the URL above: [And if we're going to be reusing code across tools, I would much rather it be an API layer like this, not copying and pasting kernel invocations with string arguments and so on.] I agree completely and have always thought this when looking at that code. It just seems very brittle. But I share the same concerns as David and so I pose these questions: Aren't we just prolonging the period of instability by continuing to change APIs as it suits us? What if this work is undertaken and then someone else pops up with a valid reason to provide strict JSR-77 compliance? Also taken from the URL above: [Suggestion... create this layer in a reusable(extensible?) manner, to enable the creation of other G-management APIs applicable when Geronimo assumes other personalities (J2EE subset, J2EE superset, no J2EE - purely embedded, etc)] Couldn't this be accomplished in some way by using the dependency system provided by the kernel? E.g., upon startup of management console, check to see if web container X is running; if yes then deploy the web container X management portlet, else don't deploy it, etc. Just a thought. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: Web Console Status
Where in maven would this appear? I wonder if we should create a geronimo-dependencies virtual project or something, as opposed to putting something like this side by side with the proper geronimo artifacts. What do others think? geronimo/jars (our output) geronimo/wars (our demo apps) geronimo-spec/jars (our spec output) geronimo-dependencies/jars/(put pluto thing here) Aaron On Thu, 21 Jul 2005, Dave Colasurdo wrote: The JIRA entry for the console (GERONIMO-762) has been updated with the instructions for creating pluto-portal.jar (actually the JIRA contains the jar as well). Is the required fix as simple as: 1) Rename pluto-portal-1.0.1-rc2.jar to geronimo-pluto-portal.jar 2) Publish the new jar to the Apache maven repository 3) Change the console dependency references to use the new name Any issues with this approach? Are special privileges required to publish to the Apache maven repository (http://cvs.apache.org/repository/)? Thanks -Dave- Aaron Mulder wrote: So it seems that the Pluto problem is pretty serious. We're actually dependent on an artifact that Pluto does not produce. There is no pluto-portal output from the Pluto build. I think that means we shouldn't be calling it pluto-portal, but instead geronimo-package-of-pluto-portal-code or something along those lines (but perhaps shorter). No wonder the Pluto fellow is not putting it in Maven! :) Aaron
[jira] Resolved: (GERONIMO-156) DEV-02 Release of Console-Web Module
[ http://issues.apache.org/jira/browse/GERONIMO-156?page=all ] Aaron Mulder resolved GERONIMO-156: --- Fix Version: 1.0-M3 Resolution: Won't Fix This web console seems to be defunct; current efforts are on donated web console DEV-02 Release of Console-Web Module Key: GERONIMO-156 URL: http://issues.apache.org/jira/browse/GERONIMO-156 Project: Geronimo Type: Improvement Components: management Environment: Apache Geronimo, Servlet 2.3 Reporter: N. Alex Rupp Assignee: Dain Sundstrom Fix For: 1.0-M3 Attachments: console-web-DEV-02.tar.gz Here's the DEV-02 release of the console-web module. I tested it on the last stable build of the Geronimo-Jetty installation. This build will allow you to invoke primitive operations. By primitive I mean ones that take a String input. Type converters and the like are on the way in a future release. You might want to tune the logging output to suit your tastes. You can do this in the standard log configuration file for the server. Please let me know if you have any questions. Cheers, -- N. Alex Rupp ([EMAIL PROTECTED]) -- 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-782) ejb ws deployment system does not use gbean builder references
[ http://issues.apache.org/jira/browse/GERONIMO-782?page=comments#action_12316425 ] David Jencks commented on GERONIMO-782: --- Step 3 use a template gbean for the WSContainer link. The web service builder fills in part, the ebj builder fills in part. Remaining work is to collect all the modified locations at once. Sendingmodules/assembly/src/plan/j2ee-deployer-plan.xml Sendingmodules/assembly/src/plan/j2ee-runtime-deployer-plan.xml Transmitting file data .. Committed revision 220198. Checking in modules/core/src/java/org/openejb/server/axis/WSContainer.java; new revision: 1.13; previous revision: 1.12 Checking in modules/core/src/java/org/openejb/server/axis/WSContainerGBean.java; new revision: 1.7; previous revision: 1.6 Checking in modules/openejb-builder/src/java/org/openejb/deployment/OpenEJBModuleBuilder.java; new revision: 1.48; previous revision: 1.47 Checking in modules/openejb-builder/src/java/org/openejb/deployment/SessionBuilder.java; new revision: 1.29; previous revision: 1.28 Checking in modules/openejb-builder/src/test/org/openejb/deployment/CMPEntityBuilderTest.java; new revision: 1.16; previous revision: 1.15 Checking in modules/openejb-builder/src/test/org/openejb/deployment/DeploymentTestSuite.java; new revision: 1.12; previous revision: 1.11 Checking in modules/openejb-builder/src/test/org/openejb/deployment/PlanParsingTest.java; new revision: 1.9; previous revision: 1.8 Checking in modules/openejb-builder/src/test/org/openejb/deployment/entity/cmp/cmr/AbstractCMRTest.java; new revision: 1.24; previous revision: 1.23 Checking in modules/openejb-builder/src/test/org/openejb/deployment/entity/cmp/ejbql/EJBQLTest.java; new revision: 1.15; previous revision: 1.14 ejb ws deployment system does not use gbean builder references -- Key: GERONIMO-782 URL: http://issues.apache.org/jira/browse/GERONIMO-782 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0-M5 The ejb builder uses static methods on AxisServiceBuilder rather than the gbean interface exposed by AxisBuilder. Fixing this in a reasonable amount of time will require removing xfire support. David Blevins has indicated that the xfire support needs to be completely rewritten anyway so I will proceed with this. -- 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: Web Console Status
On Jul 21, 2005, at 7:00 PM, Aaron Mulder wrote: Where in maven would this appear? I wonder if we should create a geronimo-dependencies virtual project or something, as opposed to putting something like this side by side with the proper geronimo artifacts. What do others think? geronimo/jars (our output) geronimo/wars (our demo apps) geronimo-spec/jars (our spec output) geronimo-dependencies/jars/(put pluto thing here) I think that this is confusing, because things like openejb, mx4j, tomcat... are dependencies too. can we just put the things we create in geronimo/jars? geir Aaron On Thu, 21 Jul 2005, Dave Colasurdo wrote: The JIRA entry for the console (GERONIMO-762) has been updated with the instructions for creating pluto-portal.jar (actually the JIRA contains the jar as well). Is the required fix as simple as: 1) Rename pluto-portal-1.0.1-rc2.jar to geronimo-pluto-portal.jar 2) Publish the new jar to the Apache maven repository 3) Change the console dependency references to use the new name Any issues with this approach? Are special privileges required to publish to the Apache maven repository (http://cvs.apache.org/repository/)? Thanks -Dave- Aaron Mulder wrote: So it seems that the Pluto problem is pretty serious. We're actually dependent on an artifact that Pluto does not produce. There is no pluto-portal output from the Pluto build. I think that means we shouldn't be calling it pluto-portal, but instead geronimo-package-of-pluto-portal-code or something along those lines (but perhaps shorter). No wonder the Pluto fellow is not putting it in Maven! :) Aaron -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Web Console Status
On Thu, 21 Jul 2005, Geir Magnusson Jr wrote: geronimo/jars (our output) geronimo/wars (our demo apps) geronimo-spec/jars (our spec output) geronimo-dependencies/jars/(put pluto thing here) I think that this is confusing, because things like openejb, mx4j, tomcat... are dependencies too. can we just put the things we create in geronimo/jars? It just seems weird to me to put both our code and other people's code that we packaged in the same directory. Aaron
[jira] Created: (GERONIMO-790) JettyModuleBuilder should use references to templates, not their names
JettyModuleBuilder should use references to templates, not their names -- Key: GERONIMO-790 URL: http://issues.apache.org/jira/browse/GERONIMO-790 Project: Geronimo Type: Improvement Components: web Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.0-M5 Dain showed me how to go from a proxy back to its object name, so the JettyModuleBuilder should use this for its servlet templates. (shown to work in the ejb ws link template) -- 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-791) Remove GBeanInstance support for J2EEManagedObject methods
Remove GBeanInstance support for J2EEManagedObject methods -- Key: GERONIMO-791 URL: http://issues.apache.org/jira/browse/GERONIMO-791 Project: Geronimo Type: Bug Components: kernel Versions: 1.0-M3 Reporter: Aaron Mulder Assigned to: Dain Sundstrom The current GBean Framework provides support for the methods of J2EEManagedObject, meaning they're effectively implemented for every GBean regardless of whether the GBean itself implements them. This happens in GBeanInstace.addManagedObjectAttributes, and the attributes in question are: objectName (String, special) stateManageable (boolean, framework) statisticsProvider (boolean, framework) eventProvider (boolean, framework) At least the last three should be removed. It's not clear to me that the objectName attribute should be removed. In any case, if a GBean wants to implement J2EEManagedObject, it should provide its own implementation of this stuff. I'm just unsure what it's expected to return from getObjectName, since it's not clear that a GBean implementation has any way to get its own ObjectName. -- 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-791) Remove GBeanInstance support for J2EEManagedObject methods
[ http://issues.apache.org/jira/browse/GERONIMO-791?page=all ] Aaron Mulder updated GERONIMO-791: -- Description: The current GBean Framework provides support for the methods of J2EEManagedObject, meaning they're effectively implemented for every GBean regardless of whether the GBean itself implements them. This happens in GBeanInstace.addManagedObjectAttributes, and the attributes in question are: objectName (String, special) stateManageable (boolean, framework) statisticsProvider (boolean, framework) eventProvider (boolean, framework) These should be removed. If a GBean wants to implement J2EEManagedObject, it should provide its own implementation of this stuff. (It can get its ObjectName injected as a magic attribute.) was: The current GBean Framework provides support for the methods of J2EEManagedObject, meaning they're effectively implemented for every GBean regardless of whether the GBean itself implements them. This happens in GBeanInstace.addManagedObjectAttributes, and the attributes in question are: objectName (String, special) stateManageable (boolean, framework) statisticsProvider (boolean, framework) eventProvider (boolean, framework) At least the last three should be removed. It's not clear to me that the objectName attribute should be removed. In any case, if a GBean wants to implement J2EEManagedObject, it should provide its own implementation of this stuff. I'm just unsure what it's expected to return from getObjectName, since it's not clear that a GBean implementation has any way to get its own ObjectName. Remove GBeanInstance support for J2EEManagedObject methods -- Key: GERONIMO-791 URL: http://issues.apache.org/jira/browse/GERONIMO-791 Project: Geronimo Type: Bug Components: kernel Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Dain Sundstrom The current GBean Framework provides support for the methods of J2EEManagedObject, meaning they're effectively implemented for every GBean regardless of whether the GBean itself implements them. This happens in GBeanInstace.addManagedObjectAttributes, and the attributes in question are: objectName (String, special) stateManageable (boolean, framework) statisticsProvider (boolean, framework) eventProvider (boolean, framework) These should be removed. If a GBean wants to implement J2EEManagedObject, it should provide its own implementation of this stuff. (It can get its ObjectName injected as a magic attribute.) -- 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: Web Console Status
On Jul 21, 2005, at 7:19 PM, Aaron Mulder wrote: On Thu, 21 Jul 2005, Geir Magnusson Jr wrote: geronimo/jars (our output) geronimo/wars (our demo apps) geronimo-spec/jars (our spec output) geronimo-dependencies/jars/(put pluto thing here) I think that this is confusing, because things like openejb, mx4j, tomcat... are dependencies too. can we just put the things we create in geronimo/jars? It just seems weird to me to put both our code and other people's code that we packaged in the same directory. Why? That code is our release of it, not theirs, and it's our goal to get rid of these weird cases, right? I don't feel overly strong about this, but it seems cleaner. Our code, our directory. Its our code at that point. geir Aaron -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for future releases)
On Jul 21, 2005, at 8:44 AM, Matt Hogstrom wrote: I'm a bit dismayed about the previous posts about assuming a release will suck. If thats your view then it will suck and one has to ask what is the relvance of the project? I think the goals in the past has been to get to J2EE 1.4 certification and you guys made it (well almost). Don't be dismayed. The actual quote, every release is going to 'suck' to some degree (i.e. not be perfect) and it's better to work on getting them out faster, not slower is more of a call to get people to not put releases on a pedestal such that they never come. -David
Build Failed
Hi, When I run $ maven m:build -Dmaven.test.skip=true -Dmaven.itest.skip=true and got some errors and build failed in the end. see screen shot: Please let me how to fix them. Thanks, Joe Qiao
Need some assistance
I am having a bit of a hard time with some webservices in Tomcat deployment. This appears to be an issue with servlet end points only as EJBs seem to deploy fine. The issue seems to occur when the TomcatWebContext is being deployed. The error occurs on lone 78 in the GeronimoStandardContext when setting up the ReadOnlyContext. This is the call: ((ClassLoaderAwareReference) value).setClassLoader(ctx.getWebClassLoader()); The issue is I get the stack trace shown below. I am having a hard time understanding why I am getting this...so before I pull every hair out of my head and go blind staring into my powerbook...I was hoping someone could lend an idea or two as to why this occurs. Ultimately the DeserializingReference can't find the CGLib generated class...blah! Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.axis.client.ServiceImpl$$EnhancerByCGLIB$$d4ba7d5a at org.apache.geronimo.kernel.ClassLoading.loadClass(ClassLoading.java:101) at org.apache.geronimo.kernel.ObjectInputStreamExt.resolveClass(ObjectInputStreamExt.java:45) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at org.apache.geronimo.naming.reference.DeserializingReference.setClassLoader(DeserializingReference.java:47)
[jira] Resolved: (GERONIMO-792) Typo in ToolsJarHack message at startup in M4
[ http://issues.apache.org/jira/browse/GERONIMO-792?page=all ] John Sisson resolved GERONIMO-792: -- Resolution: Fixed Fixed in rev 220241 in M4 branch. Fix in head not required as the toolsjarhack has been removed. Typo in ToolsJarHack message at startup in M4 - Key: GERONIMO-792 URL: http://issues.apache.org/jira/browse/GERONIMO-792 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0-M4 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0-M4 This should be fixed as it doesn't give a good impression when it is in the 2nd line of output when you start Geronimo up :-) Booting Geronimo Kernel (in Java 1.4.2_08)... 12:49:08,750 WARN [ToolsJarHack] Could not all find java compiler: lib\tools.jar file not found in C:\Program Files\Java\j2re1.4. 2_08 or C:\Program Files\Java Starting Geronimo Application Server The word all needs to be removed. -- 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
