geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Plugin Enhancements
Date Thu, 15 Jun 2006 14:53:49 GMT
On 6/15/06, Guillaume Nodet <gnodet@gmail.com> wrote:
> +1, that was exactly what i was about to answer :)
> We already have a set of beans that work nicely and i was planning
> to raise a JIRA to import these in geronimo trunk.  I guess it would do a
> nice plugin
> by itself.
> Still need to find a good way to build plugin with maven though ...

There's a Maven 1 plugin (the Geronimo packaging plugin) that can
build a Geronimo plugin.  I assume that is or will be ported to Maven
2 shortly as the Geronimo build is migrated to Maven 2.

Thanks,
    Aaron

> > On 6/15/06, Erin Mulder < meara@alumni.princeton.edu> wrote:
> > > 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
> > >
> > > Thoughts?
> > >
> > > Cheers,
> > > Erin
> > >
> > > 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.
> > >
> >
>
>

Mime
View raw message