geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erin Mulder <>
Subject Re: Plugin Enhancements
Date Thu, 15 Jun 2006 14:38:04 GMT
Here are some plugins that I would like to create or see created.  Many
of them would have both console portlets for configuration and
JNDI-accessible APIs for direct access from applications.

(BTW, I think it would be great to have a "Geronimo Plugins" space in
Confluence where we could flesh out these and other plugin ideas, not
just document existing plugins.)

File Poller:

File-based integration is extremely common, and yet I've found myself
writing the plumbing over and over again in different applications.  It
would be great to spend 30 seconds in the console wiring up a poller to
do something (call a method in a bundled class, call an EJB method,
generate a JMS message) every time a file shows up (or changes or is
deleted) at a particular location, with a polling interval of X seconds.
 Even better if it could eventually do some level of logging,
monitoring, error notification and/or retries.

File Archiver:

Another bit of code I write over and over again is a file cache/archiver
for generated reports and charts.  It would be great if my application
could just map a resource reference to a file archiver, grab it out of
JNDI and use a dirt simple store/retrieve API whenever I need to create
or access files.

Within configuration screens, I would be able to manage things like
where files are stored, time-based rollover or archive strategies,
space-based caching behavior, etc.

Classloader Visualizer:

I've written a simple SVG classloader visualizer for Geronimo that lays
out all the classloaders in a graph so that you can see how they relate.
 It still needs a little work to make it more interactive, but I'd like
to bundle it up as a plugin so that it's a one-click process to add it
to your console.

Web App Test Script Recorder/Runner:

Imagine you deploy a web application and want to set up a bit of
continuous functional or performance testing for it.  Once your app is
deployed, you just go into the console, click a button and the plugin
inserts/activates a few interceptors at the web tier.  Now, you open
another window and start using your application.  The plugin records
every request in a test script.  When you're done, you hit the stop
button and name your test, which you can then schedule to run on a
regular basis with pretty test reports.  You can also edit the
parameters for each request in the test and wire them up to CSV files or
SQL calls (using known data sources).  Finally, you can add a few
"response must contain XYZ" conditions to detect problems that don't
manifest as HTTP error codes.

That would be it for the first pass.  It wouldn't be nearly as
featureful as tools like JMeter or LoadRunner, but would be really
simple to use.  Hopefully the portlets would be so intuitive that
average developers with no knowledge of web testing would be able to
record and run scripts.  I've also known plenty of administrators who
would run something like this once an hour on production apps to make
sure that everything was healthy.

Later features could include exporting XML versions of the test scripts
(perhaps in a JMeter compatible format?) that could be distributed or
checked in to version control, communicating with other instances on a
network to run distributed tests, better reuse/integration of JMeter, etc.

Other Random Plugin Ideas:

 * Instrumentation and profiling support
 * Advanced integration with commercial security tools like SiteMinder
 * Advanced internationalization support (manage resources on the fly)
 * Commercial apps (e.g. JIRA, Confluence) available as G Plugins



Matt Hogstrom wrote:
> I've had similar discussions about Maven with folks.  One other area
> that people were interested about with plugins that I forgot about was
> configuration.  It's fine to develop an app that has a datasource that's
> local but there is little likelyhood that the same datasource will be
> used in production.  They wanted a way to be able to edit those
> attributes. Really, more of a structured list of attributes rather than
> looking in the console.  They wanted to know which ones the CAR depended
> on and a way to tweak them.

View raw message