On Jun 15, 2006, at 7:43 AM, Aaron Mulder wrote:
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.
On Jun 15, 2006, at 7:50 AM, Guillaume Nodet 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.
Here is a cleaned up copy of Aaron's DirectoryMonitor.
http://svn.apache.org/repos/asf/geronimo/gbuild/trunk/gbuild-agent/
src/main/java/org/apache/geronimo/gbuild/agent/DirectoryMonitor.java
I was thinking of moving this over to XBean.
-David
On 6/15/06, Erin Mulder < [EMAIL PROTECTED]> 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.
>
