On Dec 30, 2008, at 2:47 PM, bongosdude wrote:


David,

I am still confused with your "predeploy" explanation. What do you mean "predeploy"? and what does "predeploy" do? After "predeploy", what do we do
next?

When you deploy a javaee app on an app server, the server has to resolve a lot of references, figure out what should be in the classloader for the app, set up some components that wrap application bits, etc etc etc. Finally after all this is done the app server starts your app.

In a geronimo plugin we try to do as much of this work as possible in the "create a plugin" stage so that there is very little work to do when you install the plugin and mostly you just have to start it. I often call this process of resolving references, figuring out the classloader, and wrapping stuff in geronimo components "predeployment". If you have a better word I'd love to hear it.

It looks to me as if the wiki is having some confusion and corruption in indexing but there is some documentation currently at
http://cwiki.apache.org/GMOxDOC22/buidlinginstalling-plugins-and-extracting-a-server-from-an-exsiting-server.html
http://cwiki.apache.org/GMOxDOC22/assembling-a-server-using-maven.html
http://cwiki.apache.org/GMOxDOC22/custom-server-assemblies.html

I thought there was some more documentation but I can't find it right now.

hope this helps
david jencks



-B


djencks wrote:


On Dec 27, 2008, at 6:31 PM, jamesdcarroll wrote:


Thank you very much for your quick reply. I saw mention of GBeans
and will
look at them more closely.

Gbeans are geronimo's idea of a (fine grained) service component.
Unless you are doing something very unusual you won't need to write
any additional gbeans. You may need to configure some for things like
security realms, but there are various wizards in the admin console
and GEP to help with this.

My initial concern, though, is that the apps
need to be portable (perhaps with minor changes) to other J2EE
containers.
That's why I was thinking that packaging them up as WAR/EARs. But
I'll look.
Maybe I can make a compelling case to my boss.

I might have been a bit unclear.  I'd recommend you start with your
javaee war/ear apps and "predeploy" them onto geronimo to create
geronimo plugins.  One way to look at this is that it encapsulates
everything geronimo-related needed to run your app on geronimo.  Then
you can use the plugin framework to either easily add these plugins
(your apps) to an existing geronimo server or construct a server that
just contains your apps and the geronimo bits needed to run them.

With this approach you'll still have the javaee apps available to
deploy on other containers -- we just try to make it so as much as
possible of the "deployment" step happens during your build process.

hope this is clearer :-)

david jencks



Thanks again,




djencks wrote:


On Dec 27, 2008, at 3:41 PM, jamesdcarroll wrote:


I'm really new to Geronimo/J2EE and was wondering if it is possible
to place
my own customer installer in front of geronimos. We want to create a
number
of products that do different things, but we need to have a central repository that tracks them, which will be its own product as well.

Basically the use case would be:
1. User opens our admin app on geronimo(a WAR/EAR)
2. User elects to add new component; the components would be WAR or
EAR
files
3. My program grabs it and parses a manifest or some other kind of
config
file in it
4. My program updates/does whatever it needs to
5. My program hands the WAR/EAR off to Geronimo for it to do its
thing

As I mentioned, I'm kinda new and I'm reading the doc fast as I
can.  If
there's something out there that I can maybe focus on, any point in
the
right direction would be greatly appreciated.


Geronimo is actually designed to make strategies like this fairly
easy.  You want to deploy your applications as geronimo plugins
(probably using a maven build and the car-maven-plugin).  You can
then
either assemble custom servers including your applications (and
leaving out stuff they don't need) or provide a basic geronimo server
and a plugin repository containing your plugins: in the latter case
you can use the existing plugin installer portlet to show the choices
and let people install the ones they want, or write your own front
end.

Plugins are a bit easier to work with in geronimo trunk/2.2- SNAPSHOT than in the released geronimo versions. We'll probably have 2.2 out
before you get too far with this project :-).

There is some documentation, especially for 2.2, on plugins, custom
server assemblies, and also dealing with both of these using eclipse/
GEP.

Let us know if you have more questions or need more capabilities in
the plugin system.

thanks
david jencks.

Thanks,


--
View this message in context:
http://www.nabble.com/Customizing-install-of-apps-tp21188762s134p21188762.html
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.





--
View this message in context:
http://www.nabble.com/Customizing-install-of-apps-tp21188762s134p21189639.html
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.






-----
B Amigo:super:
--
View this message in context: 
http://www.nabble.com/Customizing-install-of-apps-tp21188762s134p21224292.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.


Reply via email to