RTC Thoughts
I've been reading the RTC discussion here and I would like to express my thoughts about it. I'm not a comitter and not very familiar with the Apache house rules so forgive me if I raise some silly points :-) I think RTC will be good for maintaining a stable release. Keeping 1.1.x stable is extremely important for people running production on it and if RTC will improve that stability and conformity then I think it is a good procedure. Peer review always helps in that respect. I would call this 'Maintenance Mode RTC'. Commits in maintenance mode will probably be small and quick to the point. So review is easy and quick. Which is important because I think the team just decided to release 1.1.1 in about two weeks. On the other hand, I'm afraid that the possible burocracy and 'latancy' of RTC will put Geronimo much further behind than it already is in the app server world. As Aaron pointed out Geronimo is very innovative on certain areas while significantly behind in others. With EJB3 probably being the most important. (At least for industry/j2ee standards) Working on something big as EJB3 is imo only going to work if a small group of core developers can move some mountains of code and not be bothered by the RTC process while they are still playing around, discovring how to builld that new module, reaching a point where it can be called a first alpha release and thus committing many little changes. I would call this 'Sandbox Mode RTC'. Needing votes here delays things and also makes it very difficult to do patch management because while you are waiting for people to vote you have probably alreasy invalidated your patches since you did not stop working during that voting period. Geronimo does has some very strong features that should be used to make the 'Sandbox Mode RTC' process easier; gbeans and plugins. Many things, even the whole new Klustering and Kache architecture for example, can mostly be developed outside of the main project and then submitted as a new component as a whole. This just only requires a stable 'core'. A module or component can then be accepted / voted for as a whole when code is stable enough to be included in Geronimo. Does this make the process less open? Does this translate to monster commits that nobody is going to read? Personally I don't think so. The code is still available (also during development), people can still jump in and help and you can still follow the progress and express your opinion when you see things you don't like. There will still be someone who takes the lead (and responsibility!) for a component. From what I've seen the last 18 months the ocmmiters on this project have always been open for discussion and change. The trust is there. I think they have established that and proved that they can 'run' a large community project like Geronimo. I understand where Ken is coming from and how RTC works fine for a project like Apache's httpd. But just look at the number of sub-projects that Geronimo contains now, well over a hundred, and you might realize that the traditional Apache development model might not be suited anymore for a project of Geronimo's scale. I don't know what that should mean in practice though. But I know for sure that Geronimo is not going to be the last project of this scale. This is a somewhat deeper thought but I think very essential in a RTC discussion for a project this complex. S.
What to do in a GBean's doFail
public void doFail()
{
// TODO: What do we here? When is this called? Do we do cleanup here when
// doStart() failed somehwere half way and left things in an
unpredictable state?
}
:-)
S.
Re: Reloading GBeans during development
On 6/17/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: I haven't seen this before. Perhaps it would help to do "mvn clean package" instead of "mvn package" to make sure you always have the latest code in your JAR? That is not going to make a difference, I know for sure that the jar is up to date. I checked that a couple of times already. I'll try to investigate the Geronimo side next time it happens. S.
Reloading GBeans during development
I'm developing my first Geronimo plugin and so far all goes well, mostly thanks to all the great hints people are giving me here :-) My workflow is this: write code, mvn package, deployer.jar redeploy target/plugin.jar. This works most of the time, but what I see a lot is that I'm running old code, even though the redeploy happened without warnings or errors. The problem is rather vague and not reproducable but it does happen. I've seen my code print stuff to the log that simply isn't in the last version anymore. What helps is to do a full geronimo restart. Oh, my GBean only has a reference to the Kernel and the MBeanServer. Nobody references me. I think. Does this sound familiar? Anything I can do about it? S.
Re: Klustering and Kache
On 6/17/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Hey community, I just wanted to pass a note that some of us are working on the geronimo-cache which is a "first-pass" at clustering in the sandbox: http://svn.apache.org/repos/asf/geronimo/sandbox/geronimo-cache/ Its the beginning of a full replication implementation...its a start. I would like to invite any and all to feel free to jump in and chat about it on the lists. Its not fully functional but its a hopeful move in the right direction. Cool. Is this going to be a generic replicated cache service that can be used for things like apache sessions, EJB state or even my own custom code? S.
Re: Getting the JSR77 MEJB / ManagementHome
Thanks. That was a really good hint! Things ARE easier when you talk to the MBean server directly :-) S. On 6/16/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: I suggest you just go directly to the mbean server. It is much more powerful, and is what the MEJB uses under the covers. You can find an example of getting a reference to the MBean server in the OpenEJB MEJB code: http://fisheye.codehaus.org/browse/openejb/branches/v2_1/openejb2/ modules/core/src/java/org/openejb/mejb/MEJB.java?r=2675 and an example configuration of the mejb is here: http://svn.apache.org/viewvc/geronimo/branches/1.1.1/configs/ openejb/src/plan/plan.xml?view=markup Note that your plan will need a dependency on rmi-naming since that is where MBeanServerReference is defined. -dain On Jun 16, 2006, at 11:08 AM, Stefan Arentz wrote: > Is it possible to get a reference to the ManagementHome from a GBean? > (I'm try to install a notification listener). I see there is a > org.apache.geronimo.j2ee.mejb.MEJB but I cannot find the right object > name to look it up from my GBean. > > S.
Getting the JSR77 MEJB / ManagementHome
Is it possible to get a reference to the ManagementHome from a GBean? (I'm try to install a notification listener). I see there is a org.apache.geronimo.j2ee.mejb.MEJB but I cannot find the right object name to look it up from my GBean. S.
Re: Deployment events
On 6/16/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: In 1.1, your GBean just needs to implement DeploymentWatcher (from the kernel module) and declare that in its list of interfaces. Hmm. Good hint, but it only solves halve of my puzzle :-) The DeploymentWatcher is only called when a web app is deployed/undeployed. I would also like to listen to start/stop events. Is that defined in the app server or is it web container specific? Also, is there an easy way to get more specific information about an artifact? When I print the web app's artifact is looks like this: default/foo-webapp/1150467344244/war. Is the 1150467344244 some unique id that I can lookup somewhere? S.
Plugins - Wow!
I just installed the JSP examples through: java -jar $GERONIMO_HOME/bin/deployer.jar --user system --password manager \ search-plugins http://www.geronimoplugins.com/repository/geronimo-1.1 Which I accidentally found while catching up with this list. Wow. This is really nice! I can imagine telling the admins of my current customer to download Geronimo and pointing it to the internal plugin repository to turn a plain vanilla geronimo into a website cluster node or a backend component. This will make my life so much easier :-) Some questions though: Will standard components like ActiveMQ and Derby also become available as plugins? It would be really nice to simply start with geronimo-minimal and then just add those components that you need. When I installed the JSP Examples component it also installed commons-collections-.3.1. But when I undeployed the examples, it kept the commons-collections in the repository. I know this is very tricky, but maybe it is nice to have a 'uninstall-plugin' command that also purges dependencies that are not referenced anymore. Documentation :-) I have questions like what is a plugin, what does the repository look like, how do I build my own plugin, etc. Is there anything available now that I can start with? I have some ideas for plugins and I can easily document one of them on my blog. I just have no idea where to start now. S.
Deployment events
Is there a way to have a GBean receive events about deployment/undeployment? I'm interested in writing a plugin that runs some actions when a WAR is deployed or undeployed. S.
Article: Building Geronimo 1.1 GBeans with Maven 2.0
I wrote a little article about building a GBean on Geronimo 1.1. It would be nice if someone could read and review it. This is all pretty new for me so I'm sure I wrote something silly or plain wrong about it :-) http://stefan.arentz.nl/2006/06/16/building-geronimo-11-gbeans-with-maven-20/ S.
Re: Other items to clarify how releases are managed
On 6/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: ... To be honest, my big concern over feature / bug debates is that we seem to be on a multi-month release cycle. At that rate and pace it will be difficult to fix bugs / performance issues without making users wait a very long time in between stable drops. Do others have suggestions on how to handle this? Hi Matt, If I had a choice then I would like to see more frequent minor releases. With only bug fixes and performance improvements. While keeping the APIs/schemas/tools stable and compatible. JBoss is a good example of how it should not work. They had more than 300 issues open between 4.0.4 and 4.0.5. That is crazy and it will take them months to do releases like that. My choices are then to wait for that release or stay current with JBoss-HEAD and use daily development releases. Which are unstable. I think it is fine to have multi-month releases to plan bigger features and improvements. But for me as a user of the software it is annoying to wait for a very long time for minor releases. Also many times those minor fixes are pushed forward because the next big release is around the corner. I have of course no idea how the Geronimo team works and what kind of work is involved to do a release. I can image that apart from developing it also takes a substantial amount of energy and time to coordinate the release, run a test kit, etc. Oh also, take a look at how the Glassfish team is doing releases and weekly builds. That could also be an interesting model. S.
Re: Thoughts about what a release is
On 6/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Thoughts? Ahhh the version number game. Perception is reality :-) When I see a headline about Geronimo 1.2, I will probably think 'pfff still no EJB3 support, what are those slow coders doing all the time?!'. However, if it would see a 'Geronimo 2.0' headline then I would be immediately curious and check it out in detail because I know good stuff has happened in a major release. People will generally also think the product is more mature. (Which is is of course, a version number increment will just confirm that feeling more) S.
Re: Building 1.1-Minimal
On 6/10/06, Kevan Miller <[EMAIL PROTECTED]> wrote: The new5 assembly phase will build the j2ee and minimal distributions for both jetty and tomcat. So, 'maven new' will build the minimal release. It should be possible to assemble only the minimal release, by cd'ing into assemblies/minimal-jetty-server (or minimal-tomcat- server) Great. Takes a very long time though, and I see things like: Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. 16:12:54,598 INFO [DependencyVerifier] Attempting to download geronimo-common-1.1-SNAPSHOT.jar. is that normal behaviour? Is it really trying to get those artifacts from a whole bunch of mirrors and failing? The reason that I'm doing this is that I want to understand for example how the jetty-deployer module works. When I search in the svn checkout then I only find a deployment plan for this module. Not the actual source. And from what I see now during a 'maven new' it looks like it just gets binaries for those modules. I guess what I need to know is, how do I get the source code for modules? S.
Building 1.1-Minimal
Goedenmiddag! I have a couple of questions regarding the 1.1 minimal release. I would like to build it from source code but I don't know how. I could not find instructions on how to build the minimal profile with jetty. Does anyone have a recipe for that? Am I correct that I need to stay current with https://svn.apache.org/repos/asf/geronimo/branches/1.1/ until the 1.1 final release is tagged? I understand that I need to use Java 1.4 for building the full J2EE Geronimo. Due to some Corba incompatibilities with 1.5 or so. If I just build the minimal profile, can I then do everything with 1.5? Thanks :-) S.
Re: Module restructure
On May 27, 2005, at 8:25 PM, Brian K. Wallace wrote: ... I'm not a committer, nor have I been more than an observer to what Geronimo is doing and where it's going - primarily because everything I've seen has placed it in the JBoss realm. I've used JBoss for quite a while and am always amazed at the functionality it has ingrained in it for which I just have no use. Most of my time spent upgrading is in finding out how to turn things off that have changed. Security-wise it is also a nightmare. There is so much stuff running in the container that I have no idea of. I usually bind the instance to localhost and do port translation for those TCP/IP services that need to be exposed, but even then there are still many ways to connect to it from localhost that could potentially expose information or give control to unauthorized people. S.
Re: Module restructure
On May 27, 2005, at 6:07 PM, Jeremy Boynes wrote: Stefan brings up the question of whether we want to release sub- modules of Geronimo separately. I think this is a good idea and would propose the following restructure of the tree to move in this direction. Let me just explain my motivation a bit, maybe that will also help for the plan. In my original email I said something about not needing all the J2EE stuff. I exaggerated a bit of course, but most of the applications that I have been writing in the last couple of years are done mostly with a subset of the whole J2EE umbrella. Some apps were just some network service wrapped in (JMX) beans, a service exposed with Spring (Burlap, XML-RPC) other apps were simply a web app backed by a shared Spring context. I've never needed all the stuff in J2EE. So far I've always done this on JBoss. Their MBean stuff works ok, but I wish it was easier to 'downsize' jboss to just a container with the stuff I need. That never really seemed to be their goal however. The complexity of their configuration files shows that. So, what I would really like to see wrt Geronimo is an absolute minimal server with add-on packages for things like a web container, jms provider, etc. You want to host a web app? Throw in the Tomcat or Jetty personality. Need JMS too, add ActiveMQ. Persistence? Simply add a hibernate deployer. Mix and match so that it does what your app needs. This is where Geronimo could shine and even take away a large chunk of Tomcat; most people just want to deploy their web app and optionally add some more services without having to understand a full J2EE stack. Geronimo can fill that void extremely well I think. (Simple Web Container .. .. J2EE Monolith) Ok so just complaining doesn't work well for this project, so what I really would like to do is start figuring out how I can give Geronimo 'personalities' for popular combinations of technology. Like, - Geronimo Kernel + Tomcat + JSTL2.0 + Spring + Hibernate - Geronimo Kernel + Web Services - Geronimo Kernel + JMX Enabled custom network service and then do some writing about it on the wiki. Make recipes for people, or even complete packages that are downloadable. I really think this is how Geronimo can also get acceptance with a much larger crowd. S.
Testing
Ok cool, I did a build on OS X 10.4.1 / Java 1.4.2_07 took an hour (I was also watching a movie on my slow powerbook). The build works, and the server starts. So what is next? :-) I have a bunch of Spring applications that I would like to deploy. I think I'm just going to see how that works and give feedback. S.
Re: Geronimo M4
On May 26, 2005, at 9:26 PM, David Blevins wrote: That would be great. But a lot of our components are inseparable at the moment. Build-your-own-server is certainly a goal to shoot for, but we'd need a lot of help getting there. What kind of help? S.
Re: Geronimo M4
On May 26, 2005, at 5:39 AM, Jeff Genender wrote: Hi Philippe, We are currently working towards an official release, so thanks for inquiring. However, in the mean time, you are welcome to download the source and build a latest version for youself. The source tree will contain the closest-to-M4 version and you should be able to get started using Geronimo with the latest and greatest code. Would it make sense to split the release into two and have a 'Geronimo Core (or Kernel)' and 'Geronimo J2EE' part? I would really like to start doing some more serious work with Geronimo but I have absolutely no interest in a complete J2EE environment. I'm sure there are many people in the same situation. It could also make sense from a PR kind of view; right now it looks like the project is stalled ... it has been a long time since an official release was made. With a 'Geronimo Core' package that has a v1.0.x version number that could change. Perception is reality :-) S.
Hosting Spring Applications
Before I start asking my stupid newbie questions it is probably a good idea to explain what I am trying to achieve here :-) My goal is to create a Geronimo configuration to deploy Hibernate/Spring/Web applications in. Despite that Geronimo is 'marketed' as a J2EE container, I see it more like a generic application server that can be used to host any kind of application in. This will be an open source effort. Either as part of one of the two projects are simply published through sourceforge. Starting simple seemed like a good idea, so what I am trying to setup now is a Spring hosting platform that can deploy an EAR archive variant that contains SPR and WAR archives. I'll get back about the SPR archives later. My ideal setup would be this; you start Geronimo with a Spring Container configuration/personality. You can then deploy applications to it that have a structure like this: my-app.ear: my-spring-logic.spr my-web-app1.war: my-web-app2.war: The SPR would contain all the spring beans, business logic and persistence support (like hibernate mappings + domain classes). The WAR would simply be a 'client' of the logic deployed through the SPR, but also include its own spring configuration. When this EAR is deployed, the container first processes the SPR; a new bean factory is created and all the meta-inf/spring/*.xml files are processed. Then the WAR is deployed, which also has a meta-inf/spring directory. All its spring bean configurations are then also deployed in the context of the global bean factory for thie EAR deployment. So now my questions :-) 1) What do people think of this idea? :) 2) Am I right that a '*-plan.xml' is only used to give a Geronimo instance a 'personality' ? It is a bit confusing because the plans are now used as both personality configuration and deployment of (GBean) services. Or is the latter so because there is no simple way yet to deploy .sar like packages (as part of an EAR)? 3) Any hints on adding a new archive type (SPR) to Geronimo? What would be a good starting point to look at? Is the M3 API stable enough to start writing these kind of things? S.
