You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2007/08/31 02:12:46 UTC
[Discuss] What next?
Getting 2.0.1 out the door was a great step and now might be a good
time to start discussing where we want geronimo to head next. Here
are some ideas I've had or think are important. If I were to try to
write actual sentences about all of this I'd probably never send the
email so this is way too fragmentary but maybe can spark more
discussion. I'm hoping everyone will chime in with their interests
and viewpoints, this is just what I've been thinking about lately.
Modularity.
For a long time we've been on the brink of having an actually modular
server, not just a conceptually modular server. As reflected in a lot
of recent discussion on the dev list, I think we are so close we
should really work hard to make this a pleasant reality. Some of the
steps I see:
- enhance the plugin framework so bits of more config files can be
added, in particular artifact_aliases.properties and
config_substitutions.properties. IIUC Paul has some schema changes
and xml handling rewrites in the wings as well
- finish up the pluggable admin console work and actually split the
admin console into appropriate bits for the plugins
- rearrange the build so it is organized by plugin
- actually assemble the servers we ship using plugins, perhaps using
gshell scripts
- have more server-building tools. For instance, a "button" to push
that spits out a server with just what is needed for a set of apps
and nothing else.
Clustering
IIUC we have a lot of partial clustering solutions. For instance
there's WADI, native tomcat clustering, a terracotta integration, and
IIUC Jeff has been working on a clustering solution (my apologies if
I left any out). I'd like to know where these efforts are in terms
of actual functionality and reliability and what they can be extended
to do. We also need some kind of cluster admin tools.
Security
jaspi
triplesec
administration
beyond javaee security for jetspeed and roller
There are some good things about javaee security such as the idea of
using Permissions and evaluating them in a policy but there are also
a lot of limitations and problems such as no support for restricting
access to user generated content that didn't exist when the security
was originally configured. At least roller and jetspeed have run
into this problem. I think triplesec may provide a fairly generic
solution and it might be interesting to see if other projects are
interested in this.
Other apps
roller
jetspeed
proximity etc
It would be great to get "all popular apps" available as geronimo
plugins.
Management and troubleshooting
ARM
"trace on error" facility. Have a list of info that each component
can add to as the request moves through the system. If there's an
error, we can show the entire path taken with all data. Otherwise we
discared it.
server farm management (gshell?)
Transaction manager
implement a "do work in a new tx" interface, hook it up to openjpa.
IIUC IBM has proposed an interface that lets server pieces submit
work to be done in a new transaction, thus eliminating the need to
deal with suspend etc yourself. There's been some discussion on the
openjpa lists, and we should definitely do this. There may be more
commonj work to do also, but I've more or less lost track of that
project.
make sure recovery actually works
Core
Better Spring application management
Investigate OSGI and figure out how it is different from what we are
doing, what it can do better, and what is missing from it. Figure
out an integration strategy whether it be "run OSGI as an
application" or "replace the kernel with OSGI" Don't break stuff if
we start using OSGI more :-)
Figure out what to do with our "config.ser" in modules/
configurations. At least get it into real xml, maybe using something
like jaxb with schema/gbean.
Personally I'm interested in most of these projects but only have a
finite amount of time. Right now I'm concentrating on triplesec and
want to work on jetspeed integration after that.
thanks
david jencks
Re: [Discuss] What next?
Posted by Kevan Miller <ke...@gmail.com>.
Apologies for such a late response. This thread came out while I was
on vacation and got buried by a lot of other things...
This is a good list. Comments, below.
On Aug 30, 2007, at 8:12 PM, David Jencks wrote:
> Getting 2.0.1 out the door was a great step and now might be a good
> time to start discussing where we want geronimo to head next. Here
> are some ideas I've had or think are important. If I were to try
> to write actual sentences about all of this I'd probably never send
> the email so this is way too fragmentary but maybe can spark more
> discussion. I'm hoping everyone will chime in with their interests
> and viewpoints, this is just what I've been thinking about lately.
>
> Modularity.
>
> For a long time we've been on the brink of having an actually
> modular server, not just a conceptually modular server. As
> reflected in a lot of recent discussion on the dev list, I think we
> are so close we should really work hard to make this a pleasant
> reality. Some of the steps I see:
> - enhance the plugin framework so bits of more config files can be
> added, in particular artifact_aliases.properties and
> config_substitutions.properties. IIUC Paul has some schema changes
> and xml handling rewrites in the wings as well
> - finish up the pluggable admin console work and actually split the
> admin console into appropriate bits for the plugins
> - rearrange the build so it is organized by plugin
> - actually assemble the servers we ship using plugins, perhaps
> using gshell scripts
> - have more server-building tools. For instance, a "button" to
> push that spits out a server with just what is needed for a set of
> apps and nothing else.
I wouldn't go so far as saying G is a "conceptually modular server",
but would agree that the modularity can be a lot more user-friendly.
And would like to see us building our server assemblies from plugin
parts. Sounds like you've been making some good progress on this path.
One caveat -- I would not want our Java EE servers (or other assembly
flavors) to become harder to use. One concern I have is ending up
with a bunch of differently versioned server plugins that we have a
hard time managing... I'd really like us to keep a critical eye on
ease-of-use...
>
> Clustering
>
> IIUC we have a lot of partial clustering solutions. For instance
> there's WADI, native tomcat clustering, a terracotta integration,
> and IIUC Jeff has been working on a clustering solution (my
> apologies if I left any out). I'd like to know where these efforts
> are in terms of actual functionality and reliability and what they
> can be extended to do. We also need some kind of cluster admin tools.
>
> Security
> jaspi
> triplesec
> administration
> beyond javaee security for jetspeed and roller
> There are some good things about javaee security such as the idea
> of using Permissions and evaluating them in a policy but there are
> also a lot of limitations and problems such as no support for
> restricting access to user generated content that didn't exist when
> the security was originally configured. At least roller and
> jetspeed have run into this problem. I think triplesec may provide
> a fairly generic solution and it might be interesting to see if
> other projects are interested in this.
>
> Other apps
> roller
> jetspeed
> proximity etc
> It would be great to get "all popular apps" available as geronimo
> plugins.
>
> Management and troubleshooting
> ARM
> "trace on error" facility. Have a list of info that each component
> can add to as the request moves through the system. If there's an
> error, we can show the entire path taken with all data. Otherwise
> we discared it.
> server farm management (gshell?)
As Jason D has mentioned (and I really, really agree with him), we
need to address logging. We need to create a logging policy and need
to start addressing this in a consistent and rigorous manner...
>
> Transaction manager
> implement a "do work in a new tx" interface, hook it up to
> openjpa. IIUC IBM has proposed an interface that lets server
> pieces submit work to be done in a new transaction, thus
> eliminating the need to deal with suspend etc yourself. There's
> been some discussion on the openjpa lists, and we should definitely
> do this. There may be more commonj work to do also, but I've more
> or less lost track of that project.
> make sure recovery actually works
>
> Core
> Better Spring application management
I think our basic issues have been resolved... But there are some
follow on improvements that should be implemented <hidden-classes>
for children, a separate Spring module, etc.
> Investigate OSGI and figure out how it is different from what we
> are doing, what it can do better, and what is missing from it.
> Figure out an integration strategy whether it be "run OSGI as an
> application" or "replace the kernel with OSGI" Don't break stuff
> if we start using OSGI more :-)
I have yet to see what I'd call a compelling argument for moving our
kernel to an OSGI base. I can see motivations for allowing OSGI
bundles to be deployed into a Geronimo server and an OSGI kernel
would probably help, there, but don't see that it's necessary,
either... We also tend to get focused on 'OSGI'. IMO that's only a
part of the issue. Seems like the more fundamental question is what
are we using for IoC (Geronimo Gbeans, Spring, something else).
I'd be interested to hear from users what they would like to see in
the way of OSGI support... I'd also be interested in the current
status of JSR-277.
Important thing, IMO, is to continue to develop sound component
interfaces and dependencies.
> Figure out what to do with our "config.ser" in modules/
> configurations. At least get it into real xml, maybe using
> something like jaxb with schema/gbean.
I really like the sounds of that...
In addition to adding new capabilities, I think it's very important
that we not lose focus on addressing bugs and user issues (e.g.
answering questions, providing usability improvements, documentation,
samples, etc). This is where I've been spending most of my time,
lately... IMO, Geronimo 2.0 already gives a lot of users the
functional framework they want. We need to learn from user
experiences and apply them to improve our usability and functional core.
--kevan
Re: [Discuss] What next?
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 31/08/2007, at 10:12 AM, David Jencks wrote:
> Clustering
>
> IIUC we have a lot of partial clustering solutions. For instance
> there's WADI, native tomcat clustering, a terracotta integration,
> and IIUC Jeff has been working on a clustering solution (my
> apologies if I left any out). I'd like to know where these efforts
> are in terms of actual functionality and reliability and what they
> can be extended to do. We also need some kind of cluster admin tools.
Hi,
As a response to this query, I have quickly created a couple of WIKI
pages, http://docs.codehaus.org/display/WADI/Home, in order to
capture some of the technical aspects of WADI.
WADI's core functionalities are:
* group communication API - Reliable: cluster membership update
notifications; various message exchange patterns; and interception of
exchanged messages. Tribes is the actual group communication
libraries used under the cover of the WADI API. An in-vm
implementation is also provided for testing purposes.
* HttpSession migration - Reliable: if a session is hosted by a node
and an HttpRequest requesting this session is received by another
node, the session is migrated to the node receiving the HttpRequest.
* HttpSession replication - Reliable: each session is replicated to a
configurable number of peers so that the session can be recreated if
the node hosting the session dies.
* Persistence of HttpSessions between node restarts - Reliable
(Derby, MySQL, Postgres): sessions can be stored into a database
between node restarts.
* Distributed service infrastructure - Reliable: any class can be
registered as a distributed service, which can then be invoked and
monitored by clients on other nodes. More accurately, clients can
create dynamic proxies for a distributed service. Methods executed
against dynamic proxies are wrapped within messages and sent through
the group communication infrastructure. Methods can be made one-way;
method return values can be aggregated; Timeouts can be configured;
Targeted peers can be selected. Clients can also monitor distributed
services: they can received notifications when a distributed service
starts, stops or fails and retrieve the peers hosting the distributed
service.
* Singleton service infrastructure - Reliable: WADI can manage a
singleton service.
* Administration console - Reliable (deployed to standalone Jetty and
Geronimo 2.x): very basic admin console to browse cluster components.
* Partial replication of any objects - under progress: instead of
replicating the full session state each time that a session is
updated, only the updated fields are replicated. So far, delta
replication is working as long as the session is not migrated.
Prior the cut of the branch 2.0, I was working on a
ClusterAwareConfigurationManager which will coordinate deployment,
e.g. distribute, and managements, e.g. start, across multiple nodes.
I put it on hold as 2.0 was being cut. I think now is a good time to
restart this implementation.
Thanks,
Gianny
Re: [Discuss] What next?
Posted by Jason Dillon <ja...@planet57.com>.
Oh, one more thing which I think is also critical path for the health
of the server and its community...
LOGGING REFORM
We've talked about this here and there, most folks agree we need to
reform our logging usage... but so far its yet to happen. It is a
fairly simple task IMO, but its huge, since it pretty much touches
almost everything. But its something that can be easily staged and
then divided up amongst the surfs (and lords) for code weeding.
IMO, we need to...
1) Decide on slf4j or commons-cli
2) Define a general logging usage policy
3) Implement said policy on existing logging usage
4) Improve, add, augment, whatever, existing logging to be more
useful (for users and developers)
For #1 I'm obviously for slf4j... for a few reasons which I've
outlined in previous emails. I list this as the first step, as if we
do go for it, then it has some slight impact on the policy and
implementation work (like its varargs support instead of requiring
log.isDebugEnabled() guarding).
IMO, this is low handing fruit, which we can easily pick and which
our users (and developers) can feast upon the juicy flesh of... yummy.
--jason
On Aug 30, 2007, at 5:12 PM, David Jencks wrote:
> Getting 2.0.1 out the door was a great step and now might be a good
> time to start discussing where we want geronimo to head next. Here
> are some ideas I've had or think are important. If I were to try
> to write actual sentences about all of this I'd probably never send
> the email so this is way too fragmentary but maybe can spark more
> discussion. I'm hoping everyone will chime in with their interests
> and viewpoints, this is just what I've been thinking about lately.
>
> Modularity.
>
> For a long time we've been on the brink of having an actually
> modular server, not just a conceptually modular server. As
> reflected in a lot of recent discussion on the dev list, I think we
> are so close we should really work hard to make this a pleasant
> reality. Some of the steps I see:
> - enhance the plugin framework so bits of more config files can be
> added, in particular artifact_aliases.properties and
> config_substitutions.properties. IIUC Paul has some schema changes
> and xml handling rewrites in the wings as well
> - finish up the pluggable admin console work and actually split the
> admin console into appropriate bits for the plugins
> - rearrange the build so it is organized by plugin
> - actually assemble the servers we ship using plugins, perhaps
> using gshell scripts
> - have more server-building tools. For instance, a "button" to
> push that spits out a server with just what is needed for a set of
> apps and nothing else.
>
> Clustering
>
> IIUC we have a lot of partial clustering solutions. For instance
> there's WADI, native tomcat clustering, a terracotta integration,
> and IIUC Jeff has been working on a clustering solution (my
> apologies if I left any out). I'd like to know where these efforts
> are in terms of actual functionality and reliability and what they
> can be extended to do. We also need some kind of cluster admin tools.
>
> Security
> jaspi
> triplesec
> administration
> beyond javaee security for jetspeed and roller
> There are some good things about javaee security such as the idea
> of using Permissions and evaluating them in a policy but there are
> also a lot of limitations and problems such as no support for
> restricting access to user generated content that didn't exist when
> the security was originally configured. At least roller and
> jetspeed have run into this problem. I think triplesec may provide
> a fairly generic solution and it might be interesting to see if
> other projects are interested in this.
>
> Other apps
> roller
> jetspeed
> proximity etc
> It would be great to get "all popular apps" available as geronimo
> plugins.
>
> Management and troubleshooting
> ARM
> "trace on error" facility. Have a list of info that each component
> can add to as the request moves through the system. If there's an
> error, we can show the entire path taken with all data. Otherwise
> we discared it.
> server farm management (gshell?)
>
> Transaction manager
> implement a "do work in a new tx" interface, hook it up to
> openjpa. IIUC IBM has proposed an interface that lets server
> pieces submit work to be done in a new transaction, thus
> eliminating the need to deal with suspend etc yourself. There's
> been some discussion on the openjpa lists, and we should definitely
> do this. There may be more commonj work to do also, but I've more
> or less lost track of that project.
> make sure recovery actually works
>
> Core
> Better Spring application management
> Investigate OSGI and figure out how it is different from what we
> are doing, what it can do better, and what is missing from it.
> Figure out an integration strategy whether it be "run OSGI as an
> application" or "replace the kernel with OSGI" Don't break stuff
> if we start using OSGI more :-)
> Figure out what to do with our "config.ser" in modules/
> configurations. At least get it into real xml, maybe using
> something like jaxb with schema/gbean.
>
>
> Personally I'm interested in most of these projects but only have a
> finite amount of time. Right now I'm concentrating on triplesec
> and want to work on jetspeed integration after that.
>
> thanks
> david jencks
>
>
Re: [Discuss] What next?
Posted by Karl Pauls <ka...@gmail.com>.
On 9/2/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On 9/2/07, Karl Pauls <ka...@gmail.com> wrote:
>
> > > but to be honest I'd need a lot of support to get it done (mentor?).
> >
> > As I said previously on this list, I'd be willing to help. Alas, my
> > time is limited as well but I can provide help and insides where
> > necessary.
>
> Hi Karl,
>
> Oh, I see a mentor came up and am not alone to think about Geronimo as
> a reference implementation for project OSGi-fication. Thanks Karl!
>
> > At Apache Felix, we have developed a maven2 plugin that might be
> > helpful in migrating to OSGi. Maybe that can be a starting point:
> >
> > http://felix.apache.org/site/maven-bundle-plugin-bnd.html
> >
> > Felix itself is very small (~300k) and can be easily embedded:
> >
> > http://felix.apache.org/site/launching-and-embedding-apache-felix.html
>
> I think it's best to evaluate OSGi benefits with smaller projects like
> OpenEJB. I've used the bnd plugin and thought it might help with
> migrating OpenEJB to OSGi bundles (along the way EasyBeans did months
> ago). I'll start with openejb and then if it ends up fine I'll get
> back to Geronimo (the plugin framework should get better as far as
> modularization goes so it makes easier to make them osgi bundles).
Sure, there needs to be a starting point. Let me know when you need any help.
regards,
Karl
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>
--
Karl Pauls
karlpauls@gmail.com
Re: [Discuss] What next?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 9/2/07, Karl Pauls <ka...@gmail.com> wrote:
> > but to be honest I'd need a lot of support to get it done (mentor?).
>
> As I said previously on this list, I'd be willing to help. Alas, my
> time is limited as well but I can provide help and insides where
> necessary.
Hi Karl,
Oh, I see a mentor came up and am not alone to think about Geronimo as
a reference implementation for project OSGi-fication. Thanks Karl!
> At Apache Felix, we have developed a maven2 plugin that might be
> helpful in migrating to OSGi. Maybe that can be a starting point:
>
> http://felix.apache.org/site/maven-bundle-plugin-bnd.html
>
> Felix itself is very small (~300k) and can be easily embedded:
>
> http://felix.apache.org/site/launching-and-embedding-apache-felix.html
I think it's best to evaluate OSGi benefits with smaller projects like
OpenEJB. I've used the bnd plugin and thought it might help with
migrating OpenEJB to OSGi bundles (along the way EasyBeans did months
ago). I'll start with openejb and then if it ends up fine I'll get
back to Geronimo (the plugin framework should get better as far as
modularization goes so it makes easier to make them osgi bundles).
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: [Discuss] What next?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 9/2/07, Karl Pauls <ka...@gmail.com> wrote:
> > but to be honest I'd need a lot of support to get it done (mentor?).
>
> As I said previously on this list, I'd be willing to help. Alas, my
> time is limited as well but I can provide help and insides where
> necessary.
Hi Karl,
Oh, I see a mentor came up and am not alone to think about Geronimo as
a reference implementation for project OSGi-fication. Thanks Karl!
> At Apache Felix, we have developed a maven2 plugin that might be
> helpful in migrating to OSGi. Maybe that can be a starting point:
>
> http://felix.apache.org/site/maven-bundle-plugin-bnd.html
>
> Felix itself is very small (~300k) and can be easily embedded:
>
> http://felix.apache.org/site/launching-and-embedding-apache-felix.html
I think it's best to evaluate OSGi benefits with smaller projects like
OpenEJB. I've used the bnd plugin and thought it might help with
migrating OpenEJB to OSGi bundles (along the way EasyBeans did months
ago). I'll start with openejb and then if it ends up fine I'll get
back to Geronimo (the plugin framework should get better as far as
modularization goes so it makes easier to make them osgi bundles).
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: [Discuss] What next?
Posted by Karl Pauls <ka...@gmail.com>.
> > Getting 2.0.1 out the door was a great step and now might be a good
> > time to start discussing where we want geronimo to head next. Here
> > are some ideas I've had or think are important. If I were to try to
> > write actual sentences about all of this I'd probably never send the
> > email so this is way too fragmentary but maybe can spark more
> > discussion. I'm hoping everyone will chime in with their interests
> > and viewpoints, this is just what I've been thinking about lately.
> ...
> > Core
> > Better Spring application management
> > Investigate OSGI and figure out how it is different from what we are
> > doing, what it can do better, and what is missing from it. Figure
> > out an integration strategy whether it be "run OSGI as an
> > application" or "replace the kernel with OSGI" Don't break stuff if
> > we start using OSGI more :-)
In my experience, it makes sense to go down the "replace the kernel
with OSGi" route. Most projects start with the other approach but in
the end realize that it is a lot more work without many of the
benefits :-)
> > Figure out what to do with our "config.ser" in modules/
> > configurations. At least get it into real xml, maybe using something
> > like jaxb with schema/gbean.
>
> Great list Dave! I couldn't think of any functionality you left out in
> the list that I could throw in. It's great you added OSGi as well.
> I've always been thinking of OSGi-like kernel for Geronimo (and
> convert Geronimo plugins to be based on the OSGi plugin concept),
I'd love to see more Apache projects switch to OSGi. Geronimo would be
perfect as a starting point because it integrates a lot of other
projects (hence, might "convert" them along the way).
> but to be honest I'd need a lot of support to get it done (mentor?).
As I said previously on this list, I'd be willing to help. Alas, my
time is limited as well but I can provide help and insides where
necessary.
> I'm not an OSGi expert, but it seems the issues we're having with
> classloading could be easily sorted out with OSGi.
Not having to deal with classloaders is one of the benefits of OSGi
(not sure whether it would be easy :-).
> I wish I could afford more time and energy to the project to make an OSGi kernel
> done, but am now fully aware of my time incapabilities and with no
> other people interested in it I don't think I'll do any real
> developments in this area. I could be of some help, but to lead
> it...well...it'd be very challenging. I'd also appreciate to hear
> Dain's view on how OSGi could affect Geronimo as he's one of the very
> few who are not scared to make changes in the kernel as well as I seem
> to recall he's been developing xbean-osgi module. Dain?
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
At Apache Felix, we have developed a maven2 plugin that might be
helpful in migrating to OSGi. Maybe that can be a starting point:
http://felix.apache.org/site/maven-bundle-plugin-bnd.html
Felix itself is very small (~300k) and can be easily embedded:
http://felix.apache.org/site/launching-and-embedding-apache-felix.html
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: [Discuss] What next?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 8/31/07, David Jencks <da...@yahoo.com> wrote:
> Getting 2.0.1 out the door was a great step and now might be a good
> time to start discussing where we want geronimo to head next. Here
> are some ideas I've had or think are important. If I were to try to
> write actual sentences about all of this I'd probably never send the
> email so this is way too fragmentary but maybe can spark more
> discussion. I'm hoping everyone will chime in with their interests
> and viewpoints, this is just what I've been thinking about lately.
...
> Core
> Better Spring application management
> Investigate OSGI and figure out how it is different from what we are
> doing, what it can do better, and what is missing from it. Figure
> out an integration strategy whether it be "run OSGI as an
> application" or "replace the kernel with OSGI" Don't break stuff if
> we start using OSGI more :-)
> Figure out what to do with our "config.ser" in modules/
> configurations. At least get it into real xml, maybe using something
> like jaxb with schema/gbean.
Great list Dave! I couldn't think of any functionality you left out in
the list that I could throw in. It's great you added OSGi as well.
I've always been thinking of OSGi-like kernel for Geronimo (and
convert Geronimo plugins to be based on the OSGi plugin concept), but
to be honest I'd need a lot of support to get it done (mentor?). I'm
not an OSGi expert, but it seems the issues we're having with
classloading could be easily sorted out with OSGi. I wish I could
afford more time and energy to the project to make an OSGi kernel
done, but am now fully aware of my time incapabilities and with no
other people interested in it I don't think I'll do any real
developments in this area. I could be of some help, but to lead
it...well...it'd be very challenging. I'd also appreciate to hear
Dain's view on how OSGi could affect Geronimo as he's one of the very
few who are not scared to make changes in the kernel as well as I seem
to recall he's been developing xbean-osgi module. Dain?
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: [Discuss] What next?
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 30, 2007, at 5:12 PM, David Jencks wrote:
> Getting 2.0.1 out the door was a great step and now might be a good
> time to start discussing where we want geronimo to head next. Here
> are some ideas I've had or think are important. If I were to try
> to write actual sentences about all of this I'd probably never send
> the email so this is way too fragmentary but maybe can spark more
> discussion. I'm hoping everyone will chime in with their interests
> and viewpoints, this is just what I've been thinking about lately.
>
> Modularity.
>
> For a long time we've been on the brink of having an actually
> modular server, not just a conceptually modular server. As
> reflected in a lot of recent discussion on the dev list, I think we
> are so close we should really work hard to make this a pleasant
> reality. Some of the steps I see:
> - enhance the plugin framework so bits of more config files can be
> added, in particular artifact_aliases.properties and
> config_substitutions.properties. IIUC Paul has some schema changes
> and xml handling rewrites in the wings as well
> - finish up the pluggable admin console work and actually split the
> admin console into appropriate bits for the plugins
> - rearrange the build so it is organized by plugin
> - actually assemble the servers we ship using plugins, perhaps
> using gshell scripts
> - have more server-building tools. For instance, a "button" to
> push that spits out a server with just what is needed for a set of
> apps and nothing else.
Yay... modularity is my friend... and enemy :-P More modular server
means more build muck to assemble it :-P But IMO this is probably
the most important feature (if you can call it that) which we need to
implement to ensure the longevity and maintainability of Apache
Geronimo.
> Clustering
>
> IIUC we have a lot of partial clustering solutions. For instance
> there's WADI, native tomcat clustering, a terracotta integration,
> and IIUC Jeff has been working on a clustering solution (my
> apologies if I left any out). I'd like to know where these efforts
> are in terms of actual functionality and reliability and what they
> can be extended to do. We also need some kind of cluster admin tools.
Certainly a nice to have, and almost always on user's want to have
list, though from past places I've worked we never have really made
use (fully) of any application server's clustering facilities. I'd
like to see this added, and I'm sure we will get it sooner rather
than later, but I think that the modularity (and inevitable
decoupling) work is vastly more important to the project (perhaps not
users).
> Other apps
> roller
> jetspeed
> proximity etc
> It would be great to get "all popular apps" available as geronimo
> plugins.
Ya, would be nice to get the main G distribution to a point where you
can *easily* (as in my eyes are closed and I'm clicking the install
some neat feature button) get a fully functional, kick ass, easy to
use and admin server ;-)
> Management and troubleshooting
> ARM
No LEG?
> Otherwise we discared it.
> server farm management (gshell?)
This is definitely on my "in my head" roadmap for the shell, though
we need those clustering bits first to give it something to work
with. One thing we might want to add before then is some kind of
reboot facility to the server, which is possible using the GShell
launcher process. So a user can install some muck, tweak some
configuration, then tell the server to reboot and basically pick up a
pristine configuration and working environment. The same basic
mechanism could be used to create a rollback configuration, or named
configurations, etc.
I've been working on simplifying the GShell framework for the past
week, and will continue for a few more me thinks as I've been re-
inspired by the positive feedback I've heard so far, as well as my
renewed desire for GShell to rule the world and make me coffee in the
morning.
So expect to see some more GShell goodies on the way soon...
> Core
> Better Spring application management
> Investigate OSGI and figure out how it is different from what we
> are doing, what it can do better, and what is missing from it.
> Figure out an integration strategy whether it be "run OSGI as an
> application" or "replace the kernel with OSGI" Don't break stuff
> if we start using OSGI more :-)
I think some investigate is defs in order here, though I'd really
like to see the system split up into smaller manageable chunks before
this is considered for implementation. I don't think that the
current gbean framework is so inflexible to make that a non-option.
So lets split up the server, learn from that exercise, keeping in
mind how we can make it easier, require less code and perhaps even do
more... then lets do it. I'd personally like to see us using
annotations to define all those properties and operations and such on
our components... I fricken love annotations.
> Figure out what to do with our "config.ser" in modules/
> configurations. At least get it into real xml, maybe using
> something like jaxb with schema/gbean.
OOOOH HEEEELLLL YA!!!!
I'd really like to see the configuration for a module, in plain xml,
based on some schema that is descriptive and extensible enough to
handle pretty much any kinda of configuration we want to toss at a
set of beans (or anything users want to, and they will come up with
some crazy shiz for sure).
And... I want to see those XML files deployed into the repository
ASIS... IE... not in any *ucking jar/ear/war/whatever file.
And, on a related not... those damn CAR files that are expanded...
well, they shouldn't be. The repository should contain artifact
*files* only... so if we need to unpack them on the fly, then do it.
Or if users want to use an unpacked dir for their deployment, then
use the deploy/* directory or something, but leave the repository/*
as files.
* * *
So, based on what I've just babbled about so far... I'd like to see
2.1 focused on developer improvements (for us, and plugin
developers), more application support to get users going faster, and
administration support (that includes the xml stuff in the repo and
gshell bits).
Anyways... just my comments.
--jason
Re: [Discuss] What next?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 9/3/07, Jason Dillon <ja...@planet57.com> wrote:
> Aighty?
Done. Thanks!
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: [Discuss] What next?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Thanks for the CWiki ...
On Sep 3, 2007, at 2:30 PM, Jason Dillon wrote:
> FYI, I took a brief stab and making this into a wiki page here:
>
> http://cwiki.apache.org/confluence/display/GMOxDEV/Roadmap+for+2.1
>
> I've only really included my thoughts and davids, so please update
> this puppy... IMO this type of information is better captured in a
> wiki page, though its gotta start in an email and the discussion
> should remain here, but lets capture things in the page so we can
> have a living document to express what are general plans/desires
> are for the next major release.
>
> Aighty?
>
> --jason
Re: [Discuss] What next?
Posted by Jason Dillon <ja...@planet57.com>.
FYI, I took a brief stab and making this into a wiki page here:
http://cwiki.apache.org/confluence/display/GMOxDEV/Roadmap+for+2.1
I've only really included my thoughts and davids, so please update
this puppy... IMO this type of information is better captured in a
wiki page, though its gotta start in an email and the discussion
should remain here, but lets capture things in the page so we can
have a living document to express what are general plans/desires are
for the next major release.
Aighty?
--jason
On Aug 30, 2007, at 5:12 PM, David Jencks wrote:
> Getting 2.0.1 out the door was a great step and now might be a good
> time to start discussing where we want geronimo to head next. Here
> are some ideas I've had or think are important. If I were to try
> to write actual sentences about all of this I'd probably never send
> the email so this is way too fragmentary but maybe can spark more
> discussion. I'm hoping everyone will chime in with their interests
> and viewpoints, this is just what I've been thinking about lately.
>
> Modularity.
>
> For a long time we've been on the brink of having an actually
> modular server, not just a conceptually modular server. As
> reflected in a lot of recent discussion on the dev list, I think we
> are so close we should really work hard to make this a pleasant
> reality. Some of the steps I see:
> - enhance the plugin framework so bits of more config files can be
> added, in particular artifact_aliases.properties and
> config_substitutions.properties. IIUC Paul has some schema changes
> and xml handling rewrites in the wings as well
> - finish up the pluggable admin console work and actually split the
> admin console into appropriate bits for the plugins
> - rearrange the build so it is organized by plugin
> - actually assemble the servers we ship using plugins, perhaps
> using gshell scripts
> - have more server-building tools. For instance, a "button" to
> push that spits out a server with just what is needed for a set of
> apps and nothing else.
>
> Clustering
>
> IIUC we have a lot of partial clustering solutions. For instance
> there's WADI, native tomcat clustering, a terracotta integration,
> and IIUC Jeff has been working on a clustering solution (my
> apologies if I left any out). I'd like to know where these efforts
> are in terms of actual functionality and reliability and what they
> can be extended to do. We also need some kind of cluster admin tools.
>
> Security
> jaspi
> triplesec
> administration
> beyond javaee security for jetspeed and roller
> There are some good things about javaee security such as the idea
> of using Permissions and evaluating them in a policy but there are
> also a lot of limitations and problems such as no support for
> restricting access to user generated content that didn't exist when
> the security was originally configured. At least roller and
> jetspeed have run into this problem. I think triplesec may provide
> a fairly generic solution and it might be interesting to see if
> other projects are interested in this.
>
> Other apps
> roller
> jetspeed
> proximity etc
> It would be great to get "all popular apps" available as geronimo
> plugins.
>
> Management and troubleshooting
> ARM
> "trace on error" facility. Have a list of info that each component
> can add to as the request moves through the system. If there's an
> error, we can show the entire path taken with all data. Otherwise
> we discared it.
> server farm management (gshell?)
>
> Transaction manager
> implement a "do work in a new tx" interface, hook it up to
> openjpa. IIUC IBM has proposed an interface that lets server
> pieces submit work to be done in a new transaction, thus
> eliminating the need to deal with suspend etc yourself. There's
> been some discussion on the openjpa lists, and we should definitely
> do this. There may be more commonj work to do also, but I've more
> or less lost track of that project.
> make sure recovery actually works
>
> Core
> Better Spring application management
> Investigate OSGI and figure out how it is different from what we
> are doing, what it can do better, and what is missing from it.
> Figure out an integration strategy whether it be "run OSGI as an
> application" or "replace the kernel with OSGI" Don't break stuff
> if we start using OSGI more :-)
> Figure out what to do with our "config.ser" in modules/
> configurations. At least get it into real xml, maybe using
> something like jaxb with schema/gbean.
>
>
> Personally I'm interested in most of these projects but only have a
> finite amount of time. Right now I'm concentrating on triplesec
> and want to work on jetspeed integration after that.
>
> thanks
> david jencks
>
>