geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: Plugin Enhancements
Date Thu, 15 Jun 2006 14:50:19 GMT
On 6/15/06, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
>
> You mentioned SiteMinder -- that would be great, but it might be
> easier to start with Yale CAS, since that's open source.  Also, one of
> the issues on the table for 1.1.1 is to make the security realm
> portlet more dynamic.  Right now, there's no way to plug in new
> configurations for it.  It will be easy enough to support that, but I
> think there was some opposition to including that in 1.1.
>
> Anyway, I think a JasperReports plugin would be good too -- so you
> could configure a report and either execute it on demand against a
> preconfigured data source, or execute it on demand by passing a big
> data structure to it.  That would logically hook into the file
> archiving plugin.
>
> Also, if we get the ServiceMix integration working, we may be able to
> leverage the ServiceMix file poller instead of implementing a separate
> one for Geronimo.


+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 ...

Cheers,
Guillaume Nodet

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