On Mar 3, 2007, at 4:41 PM, Joe Bohn wrote:
Jason Dillon wrote:
How modular is the existing console code? I'm thinking that some
work is probably needed to make it more modular, so that the
existing functionality could be split up into smaller domain-
specific modules and then deployed into the console app. Right
now it looks like a big app, would like to see each of the major
bits as a separate module... to help keep things orderly and
prevent spaghetti code (which I've already started to notice when
I looked at some Derby and AMQ-related console bits last).
What is there isn't very modular. We've discussed this before. We
need to make the console architecture a bit more modular so that
the console management components could added as functions that
they manage are added. For example, adding an EJB management
portlet with EJB functions to a minimal Geronimo assembly. The
down-side is that there are no standards here, so it would be
Geronimo specific.
Wouldn't using a more a more full-featured portal framework, like
Jetspeed2 solve this... or really move the problem from us having to
invent a solution to us being able to implement a solution based on
another's framework?
How much _heavier_ is Jetspeed2 vs. Pluto? I know that J2 now
uses Pluto (though not sure what version, hopefully its 1.1). I'm
all for lightweight... but I'm also okay with a little bit of
extra pounds if it makes the console application easier for app
developers/sysadmins to plugin/customize their own administration
bits.
I think that we need to keep things light-weight for the web
console. We're already catching grief for the footprint.
Sure... but how much _heavier_ is Jetspeed2 vs. Pluto? If its not
that much bigger, and provides things like the modularity/deploy
functionality already... then it might end up being less overall code
for us to maintain, and would move the impl of the modularity to
being specific to that vendors portal framework and not specific to
Geronimo.
The other aspect here is that users would like portal capability to
exploit for their purposes and not just for Geronimo
administration. There was some discussion on this in the past too.
Right. There is Geronimo admin, and then there is app-admin, and
then there is the app itself it is portal-based. My main focus would
be on G admin and app-admin, but if the same portal could be used to
handle everything (and isn't a massive dog) then... well... why not?
For customer use something like Jetspeed2 or Liferay may make more
sense. For an embedded administration console for Geronimo use
Pluto provides the necessary functions with a smaller footprint.
Again... how much _heavier_ is Jetspeed2 vs. Pluto? I'd imagine J2
is bigger... but does anyone know how much bigger? And how much more
overhead is our custom framework for modularity (and admin/
customization of those modules) going to add... in terms of resident
footprint, lines of code and complexity?
IMO... if using a more full-featured portal that fits our licensing
needs... that does not add a huge bloat to the assembly/footprint,
and provides some solutions to the framework needs we have (and/or
adding more useful features)... then seems like that makes more sense.
I'm not pushing for one or the other... just trying to gather some
real details from folks who know about this better than I do. But so
far, I've only heard that one is more lightweight... nothing specific
at all :-(
So, does anyone know? Does using J2 bloat the distro by like 10mb or
something? Or eat up 25m in heap when running, etc...
I'm all for light... but if a bit of extra fat adds support OOTB for
modularity features, reduces G-specific portal infrastructure, and
provides folks with a usable portal system for their own custom
administration or simple application, then I'd be happy with a little
extra grease on my bacon with my morning eggs. But if its more like
adding a tub of butter on my toast... I might not like that so much
(as good as it might taste) ;-)
--jason
