You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Geir Magnusson Jr." <ge...@apache.org> on 2005/06/14 00:22:02 UTC
Summary checkpoint - Roadmap / Things-to-do
Here is a summary of what we saw on the list, and some other things
thrown in. The order is arbitrary, and we should discuss how to
prioritize. Of course, if something grabs your fancy, grab it.
Also, this is just a checkpoint - lets add more and clean this up,
prioritize and then put on the website?
Usability/Tooling
=================
- A nice usable, and polished management console.
- A GUI configuration tool that allows you to add/remove components,
where the result is a set of plans with your custom configuration.
(No more XML hacking for the newbies out there).
- True hot deploy/undeploy (is this working? or does it need work? I
have been somewhat unsuccessful without some form of restart)
- Sniffable deploy directory. It would be nice to drop EAR/WAR/etc
in a directory and have it auto deploy, at least for development
- Eclipse-based IDE (for J2EE code generation), with a geronimo test
environment embedded in eclipse.
- IDEA plugin
- NetBeans plugin
- Start defining APIs and Interfaces that will be supported at 1.0
timeframe and going forward.
- Come up with a reasonable solution to the desire to set ports, pool
sizes, etc when starting the server. To me this definitely does not
involve editing the contents of the original deployment plans or the
compiled configurations but some entirely separate solution such as a
configurable property database gbean.
- Good pluto or other portlet integration. Also a portlet based
management console.
Technical Features
==================
- Complete Jeremy's packaging and assembly plugins and use them as
much as possible in the build. I think this will make how geronimo
is intended to fit together a lot clearer and make the build make
more sense.
- Examine and stabilize the interfaces between geronimo modules (also
between geronimo/openejb etc). Ideally we could stabilize these to
the extent that no iterface changes would be necessary until geronimo 2.
- Review the contents of each module to make sure it makes sense.
For instance, I think that openejb core has at least 3 modules inside
it. I'm also not quite sure about the distribution of code between
the connector and transaction modules.
- Move to xmlbeans v2.
- Make sure tx recovery works and build a UI for reviewing problems
- True clustering with rolling deployments (i.e. deploy but don't
activate until I say I am ready).
- Performance - get performance suites to run
- Performance - once running, start looking at optimization and
enhancement for performance
Other
=====
- QA test plan
- QA test resources (people, computers)
- M4 milestone release
- nightly build generation and maintenance
- harvest good material from the wiki and add to website
- find donated access to platforms for CTS certification to build a
big compatibility matrix
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Summary checkpoint - Roadmap / Things-to-do
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 14, 2005, at 8:28 AM, Stephane Bailliez wrote:
> Geir Magnusson Jr. wrote:
>
>> Here is a summary of what we saw on the list, and some other
>> things thrown in. The order is arbitrary, and we should discuss
>> how to prioritize. Of course, if something grabs your fancy,
>> grab it.
>> Also, this is just a checkpoint - lets add more and clean this
>> up, prioritize and then put on the website?
>>
>
> It would be nice to have at least an idea of what you think about
> the roadmap ? What do you expect from the 1.0 ? A certified J2EE
> container with plumbing or a certified j2ee container with fancy
> consoles and features ? What do you expect from the M4 ?
M4 : I'd like to do that ASAP :)
1.0? I think that it should be certified of course to ensure that
the J2EE functionality is there, but also some bit of "fit and
finish" for basic tooling and usability.
>
>
>
> I'm assuming the 1.0 release to be the bare minimal so that
> developpers can start to develop on it seriously. Since the dev
> cycle is more on the 6-month range on J2EE projects, this gives
> time to do bug-fixes releases and enhance with priority 2 and 3
> features during that time once the 1.0 release is done.
Ye - but we want to make that bare minimum usable :)
>
> I'm setting the following priorities, for the sake of starting with
> something, but this needs more iteration on the definition of it:
>
> P1: Cannot have a 1.0 release without this feature
> P2: Nice to have. Can wait 1.0+ release
> P3: Very nice to have, can wait a 1.1+ release.
>
Ok - I'll recapture this and Aaron's feedback in another checkpoint
summary. Anyone else feel free to comment w/ P1, P2, P3 and we can
collect...
My comments inline
>
>
>> Usability/Tooling
>> =================
>> - A nice usable, and polished management console.
>>
>
> P3
>
> P2: would be for a minimal UI.
>
> A lot of low-end j2ee apps are deployed without ever using the
> admin ui, this is mostly a fire and forget deployment, so this is
> why I'm putting that as a non-P1
>
>
>> - A GUI configuration tool that allows you to add/remove
>> components, where the result is a set of plans with your custom
>> configuration. (No more XML hacking for the newbies out there).
>>
>
> P2
>
>
>> - True hot deploy/undeploy (is this working? or does it need
>> work? I have been somewhat unsuccessful without some form of
>> restart)
>>
>
> P1
>
>
>> - Sniffable deploy directory. It would be nice to drop EAR/WAR/
>> etc in a directory and have it auto deploy, at least for development
>>
>
> P1
>
>
>> - Eclipse-based IDE (for J2EE code generation), with a geronimo
>> test environment embedded in eclipse.
>>
>
> P3
>
>
>> - IDEA plugin
>>
>
> P3
>
>
>> - NetBeans plugin
>>
>
> P3
>
>
>> - Start defining APIs and Interfaces that will be supported at
>> 1.0 timeframe and going forward.
>>
>
> P1
>
>
>> - Come up with a reasonable solution to the desire to set ports,
>> pool sizes, etc when starting the server. To me this definitely
>> does not involve editing the contents of the original deployment
>> plans or the compiled configurations but some entirely separate
>> solution such as a configurable property database gbean.
>>
>
> P1
>
>
>> - Good pluto or other portlet integration. Also a portlet based
>> management console.
>>
>
> P3, but this has to be thought from the ground up as it could
> impact the UI console from an architecture POV. Who knows, the UI
> console could well be a pluto-based portal.
>
>
>> Technical Features
>> ==================
>> - Complete Jeremy's packaging and assembly plugins and use them
>> as much as possible in the build. I think this will make how
>> geronimo is intended to fit together a lot clearer and make the
>> build make more sense.
>>
>
> Could you please clarify from a feature point of view what it brings ?
I'll let the contributor of that one comment...
>
>
>> - Examine and stabilize the interfaces between geronimo modules
>> (also between geronimo/openejb etc). Ideally we could stabilize
>> these to the extent that no iterface changes would be necessary
>> until geronimo 2.
>>
>
> P2 (but it does no go as it does not involves breaking
> configuration for every release)
>
>
>> - Review the contents of each module to make sure it makes
>> sense. For instance, I think that openejb core has at least 3
>> modules inside it. I'm also not quite sure about the
>> distribution of code between the connector and transaction modules.
>>
>
> P1
>
>
>> - Move to xmlbeans v2.
>>
>
> P2. What is the move justification ? What does it brings ?
I think we have to do a few unnatural acts to work w/ xmlbeansV1.
IIRC V1 defines a few classes like QName that cause some havoc...?
>
>
>> - Make sure tx recovery works and build a UI for reviewing problems
>>
>
> P2. tx is of critical use in apps but I doubt anyone will use
> Geronimo for critical apps for a while. So this gives a bit of time
> to consolidate.
>
>
>> - True clustering with rolling deployments (i.e. deploy but don't
>> activate until I say I am ready).
>>
>
> P2. Same as above.
>
>
>> - Performance - get performance suites to run
>>
>
> P2+ .
>
>
>> - Performance - once running, start looking at optimization and
>> enhancement for performance
>>
>
> P2+
>
>
>> Other
>> =====
>> - QA test plan
>>
>
> P1+
>
>
>> - QA test resources (people, computers)
>>
>
> P1+. Can you clarify exactly what is your plan on this ? Does that
> mean that IBM plans to invest for some QA resources for Geronimo ?
Not only IBM. Anyone that wants to help -
For example, we could use systems w/ different OSs, JVMs, DBs that
are used for continuous integration testing.
>
>
>> - M4 milestone release
>>
>
> P1E999
>
>
>> - nightly build generation and maintenance
>>
>
> P1E9999999
>
>
>> - harvest good material from the wiki and add to website
>>
>
> Uh ? Is that necessary ? What kind of information do you want to
> harvest ? IMHO you should not duplicate the source of information.
Well, lots of the wiki is out of date. Cruft tends to accumulate.
There are things like "how to build" which are things that every new
developer wants to know, and we can have that available on the
website (or linked to the wiki from the website) as the website is
the first place people come to.
>
> The current problem with the website is that it is stalled
> information. It does not show real activity (it has been mentioned
> numerous times already) while there is a tremendous effort going
> on...but no one knows on what. This is the problem IMHI. We should
> avoid adding quantitative information, but qualitative and avoid if
> possible multiple sources.
Sorta. The website has just been re-done, and there should be no
more stall. If you have a suggestion for the site, throw it out and
we'll do it ASAP if reasonable, or - as always - send a patch.
>
>
>> - find donated access to platforms for CTS certification to build
>> a big compatibility matrix
>>
>
> External people cannot have any info on that. correct ?
Right - this would be for the use of the peeps doing cert, but the
matrix of where we certified is certainly public knowledge.
>
>
> I may add:
>
> * Add small samples demonstrating various configuration cases to
> help jumpstarting news users:
> - MDB
> - SLSB / SFSB
> - EB (simple one and different cases with relationships 1:1,
> 1:N, .., cascaded or not)
> - JAAS
> - TX
>
yes!
> P1
>
> * Add migration HOW-TOs from known app. servers (try to see if we
> could use a migration tool ?)
> P2
>
yes. And yes, having tools would be great.
>
> My 0.02 cents :)
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Summary checkpoint - Roadmap / Things-to-do
Posted by Stephane Bailliez <sb...@apache.org>.
Geir Magnusson Jr. wrote:
> Here is a summary of what we saw on the list, and some other things
> thrown in. The order is arbitrary, and we should discuss how to
> prioritize. Of course, if something grabs your fancy, grab it.
>
> Also, this is just a checkpoint - lets add more and clean this up,
> prioritize and then put on the website?
It would be nice to have at least an idea of what you think about the
roadmap ? What do you expect from the 1.0 ? A certified J2EE container
with plumbing or a certified j2ee container with fancy consoles and
features ? What do you expect from the M4 ?
I'm assuming the 1.0 release to be the bare minimal so that developpers
can start to develop on it seriously. Since the dev cycle is more on the
6-month range on J2EE projects, this gives time to do bug-fixes releases
and enhance with priority 2 and 3 features during that time once the 1.0
release is done.
I'm setting the following priorities, for the sake of starting with
something, but this needs more iteration on the definition of it:
P1: Cannot have a 1.0 release without this feature
P2: Nice to have. Can wait 1.0+ release
P3: Very nice to have, can wait a 1.1+ release.
> Usability/Tooling
> =================
>
> - A nice usable, and polished management console.
P3
P2: would be for a minimal UI.
A lot of low-end j2ee apps are deployed without ever using the admin ui,
this is mostly a fire and forget deployment, so this is why I'm putting
that as a non-P1
> - A GUI configuration tool that allows you to add/remove components,
> where the result is a set of plans with your custom configuration. (No
> more XML hacking for the newbies out there).
P2
> - True hot deploy/undeploy (is this working? or does it need work? I
> have been somewhat unsuccessful without some form of restart)
P1
> - Sniffable deploy directory. It would be nice to drop EAR/WAR/etc in
> a directory and have it auto deploy, at least for development
P1
> - Eclipse-based IDE (for J2EE code generation), with a geronimo test
> environment embedded in eclipse.
P3
> - IDEA plugin
P3
> - NetBeans plugin
P3
> - Start defining APIs and Interfaces that will be supported at 1.0
> timeframe and going forward.
P1
> - Come up with a reasonable solution to the desire to set ports, pool
> sizes, etc when starting the server. To me this definitely does not
> involve editing the contents of the original deployment plans or the
> compiled configurations but some entirely separate solution such as a
> configurable property database gbean.
P1
> - Good pluto or other portlet integration. Also a portlet based
> management console.
P3, but this has to be thought from the ground up as it could impact the
UI console from an architecture POV. Who knows, the UI console could
well be a pluto-based portal.
> Technical Features
> ==================
>
> - Complete Jeremy's packaging and assembly plugins and use them as much
> as possible in the build. I think this will make how geronimo is
> intended to fit together a lot clearer and make the build make more sense.
Could you please clarify from a feature point of view what it brings ?
> - Examine and stabilize the interfaces between geronimo modules (also
> between geronimo/openejb etc). Ideally we could stabilize these to the
> extent that no iterface changes would be necessary until geronimo 2.
P2 (but it does no go as it does not involves breaking configuration for
every release)
> - Review the contents of each module to make sure it makes sense. For
> instance, I think that openejb core has at least 3 modules inside it.
> I'm also not quite sure about the distribution of code between the
> connector and transaction modules.
P1
> - Move to xmlbeans v2.
P2. What is the move justification ? What does it brings ?
> - Make sure tx recovery works and build a UI for reviewing problems
P2. tx is of critical use in apps but I doubt anyone will use Geronimo
for critical apps for a while. So this gives a bit of time to consolidate.
> - True clustering with rolling deployments (i.e. deploy but don't
> activate until I say I am ready).
P2. Same as above.
> - Performance - get performance suites to run
P2+ .
> - Performance - once running, start looking at optimization and
> enhancement for performance
P2+
> Other
> =====
>
> - QA test plan
P1+
> - QA test resources (people, computers)
P1+. Can you clarify exactly what is your plan on this ? Does that mean
that IBM plans to invest for some QA resources for Geronimo ?
> - M4 milestone release
P1E999
> - nightly build generation and maintenance
P1E9999999
> - harvest good material from the wiki and add to website
Uh ? Is that necessary ? What kind of information do you want to harvest
? IMHO you should not duplicate the source of information.
The current problem with the website is that it is stalled information.
It does not show real activity (it has been mentioned numerous times
already) while there is a tremendous effort going on...but no one knows
on what. This is the problem IMHI. We should avoid adding quantitative
information, but qualitative and avoid if possible multiple sources.
> - find donated access to platforms for CTS certification to build a big
> compatibility matrix
External people cannot have any info on that. correct ?
I may add:
* Add small samples demonstrating various configuration cases to help
jumpstarting news users:
- MDB
- SLSB / SFSB
- EB (simple one and different cases with relationships 1:1, 1:N, ..,
cascaded or not)
- JAAS
- TX
P1
* Add migration HOW-TOs from known app. servers (try to see if we could
use a migration tool ?)
P2
My 0.02 cents :)
Re: Summary checkpoint - Roadmap / Things-to-do
Posted by Bruce Snyder <br...@gmail.com>.
On 6/14/05, Jeff Genender <jg...@savoirtech.com> wrote:
> >>Not sure what you had in mind here. I doubt
> >>you mean that XML hacking is not possible,
> >>or that is would be a high tech xml editor.
> >>Do you have more detailed description, or
> >>better yet, can you point to some tool that
> >>does what you are thinking of?
>
> This was one of my ideas...I can explain...
>
> It would be great to have a GUI tool...prefereably in Swing...that will
> build you a Geronimo configuration...
>
> i.e... I want OpenJB, with Tomcat, and no JMS. Click here...clik
> there...Press a button...and out pop the plans...and it launches into a
> quick assembly. At the end, I have my server.jar with my special
> configuration all built and wrapped for me.
>
> Advanced options would allow us to tweak down to the Gbean level.
>
> A great example is the Jetty vs Tomcat. It's a PITA to uncomment and
> comment many different Gbeans. It would be great to just have a GUI where I
> can choose a component(s), and the XML plans are complete.
This is exactly what I had in mind when you and I spoke about this
Jeff. I was thinking of starting with the JGoodies components. These
components give platform specific look and feel and are highly
optimized. I'm actually really interested to work on this and we can
begin by first tackling the Jetty or Tomcat option as a proof of
concept.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Summary checkpoint - Roadmap / Things-to-do
Posted by Jeremy Boynes <jb...@apache.org>.
Bill Stoddard wrote:
> Jeremy Boynes wrote:
>
>> Jeff Genender wrote:
>>
>>>>> Not sure what you had in mind here. I doubt you mean that XML
>>>>> hacking is not possible, or that is would be a high tech xml editor.
>>>>> Do you have more detailed description, or better yet, can you point
>>>>> to some tool that does what you are thinking of?
>>>
>>>
>>>
>>>
>>> This was one of my ideas...I can explain...
>>>
>>> It would be great to have a GUI tool...prefereably in Swing...that will
>>> build you a Geronimo configuration...
>>>
>>> i.e... I want OpenJB, with Tomcat, and no JMS. Click here...clik
>>> there...Press a button...and out pop the plans...and it launches into a
>>> quick assembly. At the end, I have my server.jar with my special
>>> configuration all built and wrapped for me.
>>>
>>> Advanced options would allow us to tweak down to the Gbean level.
>>>
>>> A great example is the Jetty vs Tomcat. It's a PITA to uncomment and
>>> comment many different Gbeans. It would be great to just have a GUI
>>> where I
>>> can choose a component(s), and the XML plans are complete.
>>>
>>
>> This would be cool - this would be very similar to a JSR-88 DConfig
>> tool so could be used for apps to. Should be easy to add into the
>> Eclipse WTP plugin as well.
>
>
> Eclipse RCP? http://www.eclipse.org/rcp/
>
That would work for a standalone one.
I was hoping that eventually the Web Tools Project would support JSR-88
DConfigBeans for editing deployment plans and that this kind of stuff
would be possible through that interface (making it easy for people to
add GBean definitions as they were configuring their applications).
--
Jeremy
Re: Summary checkpoint - Roadmap / Things-to-do
Posted by Bill Stoddard <bi...@wstoddard.com>.
Jeremy Boynes wrote:
> Jeff Genender wrote:
>
>>>> Not sure what you had in mind here. I doubt you mean that XML
>>>> hacking is not possible, or that is would be a high tech xml editor.
>>>> Do you have more detailed description, or better yet, can you point
>>>> to some tool that does what you are thinking of?
>>
>>
>>
>> This was one of my ideas...I can explain...
>>
>> It would be great to have a GUI tool...prefereably in Swing...that will
>> build you a Geronimo configuration...
>>
>> i.e... I want OpenJB, with Tomcat, and no JMS. Click here...clik
>> there...Press a button...and out pop the plans...and it launches into a
>> quick assembly. At the end, I have my server.jar with my special
>> configuration all built and wrapped for me.
>>
>> Advanced options would allow us to tweak down to the Gbean level.
>>
>> A great example is the Jetty vs Tomcat. It's a PITA to uncomment and
>> comment many different Gbeans. It would be great to just have a GUI
>> where I
>> can choose a component(s), and the XML plans are complete.
>>
>
> This would be cool - this would be very similar to a JSR-88 DConfig tool
> so could be used for apps to. Should be easy to add into the Eclipse WTP
> plugin as well.
Eclipse RCP? http://www.eclipse.org/rcp/
Bill
Re: Summary checkpoint - Roadmap / Things-to-do
Posted by Jeremy Boynes <jb...@apache.org>.
Jeff Genender wrote:
>>>Not sure what you had in mind here. I doubt
>>>you mean that XML hacking is not possible,
>>>or that is would be a high tech xml editor.
>>>Do you have more detailed description, or
>>>better yet, can you point to some tool that
>>>does what you are thinking of?
>
>
> This was one of my ideas...I can explain...
>
> It would be great to have a GUI tool...prefereably in Swing...that will
> build you a Geronimo configuration...
>
> i.e... I want OpenJB, with Tomcat, and no JMS. Click here...clik
> there...Press a button...and out pop the plans...and it launches into a
> quick assembly. At the end, I have my server.jar with my special
> configuration all built and wrapped for me.
>
> Advanced options would allow us to tweak down to the Gbean level.
>
> A great example is the Jetty vs Tomcat. It's a PITA to uncomment and
> comment many different Gbeans. It would be great to just have a GUI where I
> can choose a component(s), and the XML plans are complete.
>
This would be cool - this would be very similar to a JSR-88 DConfig tool
so could be used for apps to. Should be easy to add into the Eclipse WTP
plugin as well.
I would also like to simplify things by having the Jetty, Tomcat etc.
bits as separate configuration bundles that could be included in the
mix. So instead of re-generating the XML each time you would install
Server, Tomcat and OpenEJB /binaries/ into the runtime and ... hey
presto, are up and running. Stop Tomcat, install and start Jetty and you
switched web layer without hacking any XML or even stopping OpenEJB.
This replaces the single huge bundle definition with a set of small
pre-built ones people can just assemble as needed.
--
Jeremy
RE: Summary checkpoint - Roadmap / Things-to-do
Posted by Jeff Genender <jg...@savoirtech.com>.
>>Not sure what you had in mind here. I doubt
>>you mean that XML hacking is not possible,
>>or that is would be a high tech xml editor.
>>Do you have more detailed description, or
>>better yet, can you point to some tool that
>>does what you are thinking of?
This was one of my ideas...I can explain...
It would be great to have a GUI tool...prefereably in Swing...that will
build you a Geronimo configuration...
i.e... I want OpenJB, with Tomcat, and no JMS. Click here...clik
there...Press a button...and out pop the plans...and it launches into a
quick assembly. At the end, I have my server.jar with my special
configuration all built and wrapped for me.
Advanced options would allow us to tweak down to the Gbean level.
A great example is the Jetty vs Tomcat. It's a PITA to uncomment and
comment many different Gbeans. It would be great to just have a GUI where I
can choose a component(s), and the XML plans are complete.
Jeff
Re: Summary checkpoint - Roadmap / Things-to-do
Posted by Dain Sundstrom <da...@iq80.com>.
> I'm assuming the 1.0 release to be the bare minimal so that
> developpers can start to develop on it seriously. Since the dev
> cycle is more on the 6-month range on J2EE projects, this gives
> time to do bug-fixes releases and enhance with priority 2 and 3
> features during that time once the 1.0 release is done.
I'm hoping that we can move at a much faster pace then every 6
months. I personally would like to see a release every 6-8 weeks
with at least one big new feature. We have a lot of features to add
to it seem reasonable to me that we can focus on getting something
big to the users on a regular basis.
Immedately
----------
> - M4 milestone release
> - nightly build generation and maintenance
P1
-----
* Finish the debug console
We should be able to start and stop services, set properties and
invoke via the kernel interface. This shouldn't take more then a day
to finish. Maybe someone with some GUI skill could whip up a new
layout for it, as it is a bit ugly.
* reference docs
This is not really user docs. It is just a list of every
configuration option and what it does.
> - True hot deploy/undeploy (is this working? or does it need work?
> I have been somewhat unsuccessful without some form of restart)
> - Sniffable deploy directory. It would be nice to drop EAR/WAR/etc
> in a directory and have it auto deploy, at least for development
> - Provide a convenient way to redeploy a single JSP during
> development
> without redeploying the entire app
Yep. I think this goes with the hot deploy directory above and the
ability to support unpacked "in-place" deployments. The key part of
that description is in-place. Currently we support unpacked
deployments but copy all the files to another location.
> - Remote deployment and management (that is, developer on a different
> machine than server and not FTPing stuff back and forth)
> - Provide database support for at least Oracle, SQL Server,
> PostgreSQL,
> MySQL, Derby, DB2, Sybase
>
> - Implement more DBSyntaxFactory/EJBQLCompilerFactory
> alternatives, or
> list the database products that the Derby implementation works
> well
> for.
>
> - Implement the ExceptionSorterClass for various products
>
> - Ensure the Oracle XA drivers work
>
> - Create a CMP test suite that can be run on a database product to
> ensure that everything "works"
I think this is "table stakes" for CMP. I'm not sure if people are
willing to hold up 1.0 to do all of this, since almost no one uses
CMP, but before we claim we have usable CMP we need all of these.
> - Eliminate any remaining memory leaks, if at all possible
>
> - Ensure we allow 100+ redeployments of a non-trivial EAR
> (including JSP compilation) without OOM error
I'm working on this, so I planing on having it in anyway :)
> - Ship a "clean" server configuration (no test or extra database
> pools,
> JMS destinations, or applications, unless the user asked for demos
> to be
> installed)
> - Provide Ant task(s) for deployment
Most people use it and it should be a trivial conversion of our maven
plugin.
> - User documentation
>
> - Working Pet Store (procedures + deployment plans?)
>
> - Add small samples demonstrating various configuration cases to
> help jumpstarting news users:
> - MDB
> - SLSB / SFSB
> - EB (simple one and different cases with relationships 1:1,
> 1:N, .., cascaded or not)
> - JAAS
> - TX
P2
-----
* Alternate spring based assembly
I'd like to have an additional spring based assembly available
quickly, but I don't see reason why it should holdup a 1.0 release of
the normal server assembly. The spring based assembly removes the
desperate need to create tools to deal with the compiled
configurations, since the configurations are available for direct
access via a text editor.
> - Move to xmlbeans v2.
There may be a technical reason we have to move to xmlbean v2 before
Geronimo 1.0, but if not I'd put in the nice to have category.
> - Make sure tx recovery works and build a UI for reviewing problems
I would expect some minimal work in this area for 1.0, but I think we
should nail this one down in the 1.1 timeframe.
> - Implement CMP/CMR load groups, to control what fields/relationships
> are loaded when a finder is executed
> - Add migration HOW-TOs from known app. servers (try to see if we
> could use a migration tool ?)
P3
-----
> - A nice usable, and polished management console.
> - Good pluto or other portlet integration. Also a portlet based
> management console.
> - Eclipse-based IDE (for J2EE code generation), with a geronimo
> test environment embedded in eclipse.
> - IDEA plugin
> - NetBeans plugin
> - Examine and stabilize the interfaces between geronimo modules
> (also between geronimo/openejb etc). Ideally we could stabilize
> these to the extent that no iterface changes would be necessary
> until geronimo 2.
I completely agree with the sentiment, but I think you are setting
the goal way to high. Since people haven't been pounding on or
working with these apis much, I don't think it is possible not not
change the interfaces. Heck the discussion on shutdown hook ordering
in the Kernel will most likely require an API change, and this is one
of the most used an inspected interfaces in Geronimo.
> - Review the contents of each module to make sure it makes sense.
> For instance, I think that openejb core has at least 3 modules
> inside it. I'm also not quite sure about the distribution of code
> between the connector and transaction modules.
> - True clustering with rolling deployments (i.e. deploy but don't
> activate until I say I am ready).
> - Performance - get performance suites to run
> - Performance - once running, start looking at optimization and
> enhancement for performance
> - Coerce all use of threads into defined thread pools. Separate the
> pools into "short-term" (normal pooling) and "long-term" (consumer
> won't
> be letting this thread go but at least we can track it) pools
> - Faster install routine (current installer deploys all plans one
> at a
> time and takes a while)
> - Add self-signed certificate generation to the install routine,
> so every
> installation on earth doesn't default to the same cert
> - Provide a graceful solution to the Tomcat/Jetty problem (how does a
> user pick one, can both be run at the same time, what's certified,
> etc.)
A good installer would be cool to have.
> - Provide JSR-88 config beans for all deployment descriptors
Not sure we need this until there are some tools that support dd
beans. For all I know there could be some now, but I remember last
time we talked about dd beans there were no tools (other then netbeans).
Other
-----
> - A GUI configuration tool that allows you to add/remove
> components, where the result is a set of plans with your custom
> configuration. (No more XML hacking for the newbies out there).
Not sure what you had in mind here. I doubt you mean that XML
hacking is not possible, or that is would be a high tech xml editor.
Do you have more detailed description, or better yet, can you point
to some tool that does what you are thinking of?
> - Come up with a reasonable solution to the desire to set ports,
> pool sizes, etc when starting the server. To me this definitely
> does not involve editing the contents of the original deployment
> plans or the compiled configurations but some entirely separate
> solution such as a configurable property database gbean.
I think this goes with the above section. I don't mind editing xml.
Heck it works for Apache httpd and Apache Tomcat so I don't see why
we wouldn't support it. On the other hand, I don't think it should
be the only way. I'm just no clear on the other alternatives our
users want to see.
> - Start defining APIs and Interfaces that will be supported at 1.0
> timeframe and going forward.
I don't think this is something we can put on the road map; it is
just something we do.
-dain
Re: Summary checkpoint - Roadmap / Things-to-do
Posted by si...@insession.com.
Aaron Mulder <am...@alumni.princeton.edu> wrote on 14/06/2005 10:25:14
AM:
> I'd add (in no particular order, and not necessarily all for 1.0):
>
<snip>
> - Remote deployment and management (that is, developer on a different
> machine than server and not FTPing stuff back and forth)
>
I would like to see remote deployment supported in the 1.0 release as it
is particularly important for productive use of Geronimo on headless
servers, since the J2EE developer would be doing their development
remotely (e.g. using an IDE on their PC) due to lack of GUI on the server.
- Improve security with Derby Network Server (see GERONIMO-342) and allow
user to configure Derby Network Server security during Geronimo install
(e.g. whether to allow remote connections). There are some applications
that provide a GUI interface for creating/maintaining databases. Allowing
these applications to connect to the Derby Network Server (running on a
headless server) in a secure fashion is important.
John
<snip>
>
> Aaron
>
> On Mon, 13 Jun 2005, Geir Magnusson Jr. wrote:
> > Here is a summary of what we saw on the list, and some other things
> > thrown in. The order is arbitrary, and we should discuss how to
> > prioritize. Of course, if something grabs your fancy, grab it.
> >
> > Also, this is just a checkpoint - lets add more and clean this up,
> > prioritize and then put on the website?
> >
> >
> > Usability/Tooling
> > =================
> >
> > - A nice usable, and polished management console.
> >
> > - A GUI configuration tool that allows you to add/remove components,
> > where the result is a set of plans with your custom configuration.
> > (No more XML hacking for the newbies out there).
> >
> > - True hot deploy/undeploy (is this working? or does it need work? I
> > have been somewhat unsuccessful without some form of restart)
> >
> > - Sniffable deploy directory. It would be nice to drop EAR/WAR/etc
> > in a directory and have it auto deploy, at least for development
> >
> > - Eclipse-based IDE (for J2EE code generation), with a geronimo test
> > environment embedded in eclipse.
> >
> > - IDEA plugin
> >
> > - NetBeans plugin
> >
> > - Start defining APIs and Interfaces that will be supported at 1.0
> > timeframe and going forward.
> >
> > - Come up with a reasonable solution to the desire to set ports, pool
> > sizes, etc when starting the server. To me this definitely does not
> > involve editing the contents of the original deployment plans or the
> > compiled configurations but some entirely separate solution such as a
> > configurable property database gbean.
> >
> > - Good pluto or other portlet integration. Also a portlet based
> > management console.
> >
> >
> > Technical Features
> > ==================
> >
> > - Complete Jeremy's packaging and assembly plugins and use them as
> > much as possible in the build. I think this will make how geronimo
> > is intended to fit together a lot clearer and make the build make
> > more sense.
> >
> > - Examine and stabilize the interfaces between geronimo modules (also
> > between geronimo/openejb etc). Ideally we could stabilize these to
> > the extent that no iterface changes would be necessary until geronimo
2.
> >
> > - Review the contents of each module to make sure it makes sense.
> > For instance, I think that openejb core has at least 3 modules inside
> > it. I'm also not quite sure about the distribution of code between
> > the connector and transaction modules.
> >
> > - Move to xmlbeans v2.
> >
> > - Make sure tx recovery works and build a UI for reviewing problems
> >
> > - True clustering with rolling deployments (i.e. deploy but don't
> > activate until I say I am ready).
> >
> > - Performance - get performance suites to run
> >
> > - Performance - once running, start looking at optimization and
> > enhancement for performance
> >
> >
> > Other
> > =====
> >
> > - QA test plan
> >
> > - QA test resources (people, computers)
> >
> > - M4 milestone release
> >
> > - nightly build generation and maintenance
> >
> > - harvest good material from the wiki and add to website
> >
> > - find donated access to platforms for CTS certification to build a
> > big compatibility matrix
> >
> >
> > --
> > Geir Magnusson Jr +1-203-665-6437
> > geirm@apache.org
> >
> >
> >
Re: Summary checkpoint - Roadmap / Things-to-do
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I'd add (in no particular order, and not necessarily all for 1.0):
- Provide database support for at least Oracle, SQL Server, PostgreSQL,
MySQL, Derby, DB2, Sybase
- Implement more DBSyntaxFactory/EJBQLCompilerFactory alternatives, or
list the database products that the Derby implementation works well
for.
- Implement the ExceptionSorterClass for various products
- Ensure the Oracle XA drivers work
- Create a CMP test suite that can be run on a database product to
ensure that everything "works"
- Implement CMP/CMR load groups, to control what fields/relationships
are loaded when a finder is executed
- Coerce all use of threads into defined thread pools. Separate the
pools into "short-term" (normal pooling) and "long-term" (consumer won't
be letting this thread go but at least we can track it) pools
- Tomcat
- Jetty
- ActiveMQ
- CORBA
- Other?
- Provide a tool to generate web services WSDL (and if necessary JAX-RPC
mappings) from Session Bean Service Endpoint Interfaces. (Sun has
wscompile, but I'm not sure we have a similar tool -- maybe we already
do.)
- User documentation
- Working Pet Store (procedures + deployment plans?)
- Remote deployment and management (that is, developer on a different
machine than server and not FTPing stuff back and forth)
- Faster install routine (current installer deploys all plans one at a
time and takes a while)
- Add self-signed certificate generation to the install routine, so every
installation on earth doesn't default to the same cert
- Provide a graceful solution to the Tomcat/Jetty problem (how does a
user pick one, can both be run at the same time, what's certified, etc.)
- Eliminate any remaining memory leaks, if at all possible
- Ensure we allow 100+ redeployments of a non-trivial EAR
(including JSP compilation) without OOM error
- Provide JSR-88 config beans for all deployment descriptors
- Provide a convenient way to redeploy a single JSP during development
without redeploying the entire app
- Ship a "clean" server configuration (no test or extra database pools,
JMS destinations, or applications, unless the user asked for demos to be
installed)
- Provide Ant task(s) for deployment
Aaron
On Mon, 13 Jun 2005, Geir Magnusson Jr. wrote:
> Here is a summary of what we saw on the list, and some other things
> thrown in. The order is arbitrary, and we should discuss how to
> prioritize. Of course, if something grabs your fancy, grab it.
>
> Also, this is just a checkpoint - lets add more and clean this up,
> prioritize and then put on the website?
>
>
> Usability/Tooling
> =================
>
> - A nice usable, and polished management console.
>
> - A GUI configuration tool that allows you to add/remove components,
> where the result is a set of plans with your custom configuration.
> (No more XML hacking for the newbies out there).
>
> - True hot deploy/undeploy (is this working? or does it need work? I
> have been somewhat unsuccessful without some form of restart)
>
> - Sniffable deploy directory. It would be nice to drop EAR/WAR/etc
> in a directory and have it auto deploy, at least for development
>
> - Eclipse-based IDE (for J2EE code generation), with a geronimo test
> environment embedded in eclipse.
>
> - IDEA plugin
>
> - NetBeans plugin
>
> - Start defining APIs and Interfaces that will be supported at 1.0
> timeframe and going forward.
>
> - Come up with a reasonable solution to the desire to set ports, pool
> sizes, etc when starting the server. To me this definitely does not
> involve editing the contents of the original deployment plans or the
> compiled configurations but some entirely separate solution such as a
> configurable property database gbean.
>
> - Good pluto or other portlet integration. Also a portlet based
> management console.
>
>
> Technical Features
> ==================
>
> - Complete Jeremy's packaging and assembly plugins and use them as
> much as possible in the build. I think this will make how geronimo
> is intended to fit together a lot clearer and make the build make
> more sense.
>
> - Examine and stabilize the interfaces between geronimo modules (also
> between geronimo/openejb etc). Ideally we could stabilize these to
> the extent that no iterface changes would be necessary until geronimo 2.
>
> - Review the contents of each module to make sure it makes sense.
> For instance, I think that openejb core has at least 3 modules inside
> it. I'm also not quite sure about the distribution of code between
> the connector and transaction modules.
>
> - Move to xmlbeans v2.
>
> - Make sure tx recovery works and build a UI for reviewing problems
>
> - True clustering with rolling deployments (i.e. deploy but don't
> activate until I say I am ready).
>
> - Performance - get performance suites to run
>
> - Performance - once running, start looking at optimization and
> enhancement for performance
>
>
> Other
> =====
>
> - QA test plan
>
> - QA test resources (people, computers)
>
> - M4 milestone release
>
> - nightly build generation and maintenance
>
> - harvest good material from the wiki and add to website
>
> - find donated access to platforms for CTS certification to build a
> big compatibility matrix
>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>