On 6/15/06, Aaron Mulder <[EMAIL PROTECTED]> 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 ...
Cheers,
Guillaume Nodet
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 < [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.
>
