| Geronimo_MoinMoin_wiki > FrequentlyAskedQuestions |
Contents
You can either build from source, or download a pre-built distribution; instructions for both approaches are on the FrontPage. Assuming you've downloaded the pre-built distribution, unpack it and read README.txt for more instructions.
Geronimo support two web containers: Jetty
and Apache Tomcat
. While Jetty is not an apache project, it was initially selected for Geronimo as it is simpler to embed and Jetty developers are involved with the Geronimo project. As some users have specific requirements for Tomcat, an integration of tomcat is now also available. The ability to switch servlet containers is a demonstration of the flexibility of the geronimo architecture.
For users that stay within the J2EE specification, it is not important which web container is selected and the default will be suitable. For users with specific requirements or preferences for Jetty or Tomcat, Geronimo supports that choice.
The basic component of Geronimo is a GBean. Every service in Geronimo is a set of GBeans, be it Tomcat or OpenEJB. No OpenJMS GBeans exist.
eventually to provide Servlet/EJB/JMS/OtherAPIHere? And can we/are we distributing them?
Akin to disable access to 8080 in Tomcat, but for Geronimo stuff
Currently Geronimo has a very rudimentary console that allows you to get familiar with deployed GBeans. See org/apache/geronimo/DebugConsole
in http://wiki.apache.org/geronimo/Running#head-d04f6c597b07a27d544a57dcf772d70ded490750
See http://wiki.apache.org/geronimo/Deployment
See http://wiki.apache.org/geronimo/Deployment#head-5231c4dec658875a04e7d90b0a6214336f274627
See http://wiki.apache.org/geronimo/Running#head-d04f6c597b07a27d544a57dcf772d70ded490750
See OpenEJB itests module - Creating itests
This is the same issue as described at Assembly Hangs
of the Building. Internally, building and running a Geronimo configuration is almost the same process (with some minor file management like copying and jar'ing, they're alike). During the build a configuration is deployed to a Geronimo instance. If there're problems along the way, e.g. a stale, defunct Geronimo instance running, Apache Geronimo's build and startup won't succeed. It won't be able to bind to a port or will notice the RuntimeDeployer works, but other Deployers will not (a partially working Geronimo instance).
The easiest way is:
cd modules/assembly maven -o tomcat
then deploy your web app as usual.
This basically changes the contents of config.list and config.xml so deployments get routed to tomcat rather than jetty. You can make the same changes yourself.
See Problems?
of the Building
Every open source project needs some documentation and extensible QA checks. That's what people (seems to get) used to read when in trouble, after all. It's as important as having your hands dirty with the source code (some say it's even more important). That's also one of the easiest way to get familiar with the code. Therefore, it's much appreciated in any open source project, including Apache Geronimo, when people who want to contribute their time start with reading the project documentation
and make sure it's up-to-date. Since you're new and can easily look at the project from a different perspective, you might find it very easy to spot some mistakes or annoyances. When found, every task/issue/user request should be reported to an issue system. Go to Issue Tracking
to read about it. Once you're done with documentation, issue reports, you should try out to write some junit tests. They can take some time and once you're done, you will surely know what to do next.
You may also find interesting material at http://geronimo.apache.org/get-involved.html
or http://www.apache.org/dev
.
The FrontPage tells where to download binary distributions (for the latest packaged version) and get the source code from CVS (for the latest version).
There is a target m:idea in the geronimo build that will set up the Idea project.
There is a target m:eclipse in the geronimo as well.
$ cd geronimo $ maven m:eclipse
You may use this bash script on Linux box (or use Cygwin if you are unlucky enough to use Win$
) :
#!/bin/bash MODULES="$(find ./*/ -name project.xml | sed 's/project.xml//')"; for module in $MODULES; do echo $module; pushd $module &> /dev/null maven eclipse > /dev/null popd &> /dev/null done;
The equivalent for Win32 (Windows 2000 and later) without need for Cygwin :
cmd /c "for /r . %f in (project*.xml) do @( cd %~pf && maven eclipse )"
This assumes the only match to "project*.xml" in the tree is "project.xml" which you can check with :
for /r . %f in (project*.xml) do @echo %f
The following is just scary and wrong, but I don't like all those CVS directories in my Eclipse tree. I also don't want to keep adding the xmlbeans generated code to my projects.
#!/bin/bash
MODULES=$(find ./*/ -name project.xml | sed 's/project.xml//')
for module in $MODULES; do
echo $module
pushd $PWD &> /dev/null
cd $module
maven eclipse > /dev/null
perl -pi.bak -e 's/(kind="src")/excluding="**\/CVS\/" $1/' .classpath
/usr/bin/test -d target/xmlbeans && perl -pi.bak -e 's/<classpath>/<classpath>\n <classpathentry kind="src" path="target\\xmlbeans" \/>\n/' .classpath
popd &> /dev/null
done;
With Netbeans 4.0 :
You need to install a maven plugin like mevenide, http://mevenide.codehaus.org/mevenide-netbeans-project/index.html
. You also need to install the subversion profile, http://vcsgeneric.netbeans.org/profiles/
. Do an initial checkout in the subversion repository, http://wiki.apache.org/geronimo#head-f3a540e2ed8b06b7cfdff9c42f7de9b014f1c1b0
.
Open the geronimo project.
A GBean is a class or object that Geronimo the container can manage the lifecycle of. So, for example, when you deploy parts to a container you want to start and stop them, and they have dependencies, e.g. Bean A can only start up when Bean B is ready to go because Bean B provides services that Bean A needs. So, GBeans are Geronimo's way of packaging up things that need to be managed, and can express dependencies. The GBeans architecture lies at the heart of Geronimo's power to enable developers to move or work with their existing J2EE assets, whether open source or commercial.
GBeans are designed to let you take things you have, put a GBean wrapper around them, and use that to bridge the JSR 77 lifecycle requirements (which GBeans support via GBeanLifecycle interface). You can take anything lying around and get it to work with GBeans. In addition, the GBeans will let developers bring other existing open source projects into the Geronimo orbit.
For more information about GBeans see GBeans