You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2006/06/15 06:21:46 UTC
Plugin Enhancements
(Changing subject to make thread more generic)
So there are two ways to create a plugin. One is to get the module
running in Geronimo and then create the metadata file and export the
CAR -- there's an API for this (which the console uses) and the
Eclipse plugin could use too. The other way is to use the Maven
packaging plugin, copying in the plugin metadata file as part of the
build (this is what the examples do). I suppose you could also JAR up
the module directory in the repository, though I wouldn't recommend
that approach. I assume the API approach would be best for Eclipse
integration -- there's a call to get the default metadata (including
dependencies gleaned from the module itself), a data structure for the
metadata you can populate however you want, a call to update the saved
metadata for the plugin, and a call to get a packaged plugin
InputStream back out.
As far as distributing to a cluster, that would require push and so
far we've only implemented pull. There's no reason it can't be done.
I think it would make sense to start by defining a format that would
hold a plugin and all its dependencies in a single file (ZIP/JAR) so
the slaves don't need to separately download dependencies. Then we
can probably use the remote deploy application and the deploy tool/API
(with perhaps minor enhancements) to send the plugin out to many
servers.
As far as sensitivity to releases, currently you can omit the Geronimo
version entirely and it will run with any release. You can also list
many supported releases. I don't think it's worth doing more until we
have wider agreement on version wildcards or ranges, though perhaps we
do with the 1.1.* approach.
Thanks,
Aaron
On 6/15/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> I was talking to a set of folks that are looking at Geronimo and one of the unique things they are
> interested in that Geronimo has and others do not is the plugin support.
>
> They're view of the world is that their developers use Eclipse as their IDE and like the WTP work
> that has been done so far (koodos Sachin). What they would like the ability to do is from Eclipse
> be developing and testing and testing an application and when they get it right is to export that
> application in as a CAR (not from the Admin Console) directly out of Eclipse.
>
> There were several things that they asked about:
>
> One item was sensitivity to releases. From their perspective this would be useful if the CAR could
> tolerate several versions of Geronimo. If its only good for a specific version that limits the
> usefulness.
>
> Integration with Eclipse rather than having developers work the Geronimo console. It didn't seem as
> compelling.
>
> They would like the Geronimo infrastructure to be able to distribute CARs throughout a cluster.
>
> They had several other thoughts about G that would make it interesting as well but they are Geronimo
> server related so I'll post in another thread.
>
> Aaron, thoughts?
>
> Matt
>
Re: Plugin Enhancements
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 6/15/06, Sachin Patel <sp...@gmail.com> wrote:
> So this could be currently done independent of project structure?
I'm not sure what you mean. One issue is that this ("API approach")
only works if the server is running (at least j2ee-system and
rmi-naming), because you do it through the PluginInstaller which
relies on repositories, an artifact resolver, a thread pool, etc. But
if that's not a problem, then the functionality described below works
against the contents of the module directory in the repository. So if
there's a repository that the module is installed to, you can edit the
plugin metadata in that directory and then export a CAR from it.
Can you explain the project structure issue more? I'm not too
familiar with Eclipse, I'm afraid.
Thanks,
Aaron
> On Jun 15, 2006, at 12:21 AM, Aaron Mulder wrote:
>
> > I assume the API approach would be best for Eclipse
> > integration -- there's a call to get the default metadata (including
> > dependencies gleaned from the module itself), a data structure for the
> > metadata you can populate however you want, a call to update the saved
> > metadata for the plugin, and a call to get a packaged plugin
> > InputStream back out.
>
>
> -sachin
>
>
>
Re: Plugin Enhancements
Posted by Sachin Patel <sp...@gmail.com>.
So this could be currently done independent of project structure?
On Jun 15, 2006, at 12:21 AM, Aaron Mulder wrote:
> I assume the API approach would be best for Eclipse
> integration -- there's a call to get the default metadata (including
> dependencies gleaned from the module itself), a data structure for the
> metadata you can populate however you want, a call to update the saved
> metadata for the plugin, and a call to get a packaged plugin
> InputStream back out.
-sachin
Re: Plugin Enhancements
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 6/15/06, Guillaume Nodet <gn...@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.
> > >
> >
>
>
Re: Plugin Enhancements
Posted by David Blevins <da...@visi.com>.
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 < 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.
> >
>
Re: Plugin Enhancements
Posted by Guillaume Nodet <gn...@gmail.com>.
On 6/15/06, Aaron Mulder <am...@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 <me...@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.
> >
>
Re: Plugin Enhancements
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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.
Thanks,
Aaron
On 6/15/06, Erin Mulder <me...@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.
>
Re: Plugin Enhancements
Posted by Erin Mulder <me...@alumni.princeton.edu>.
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.
Re: Plugin Enhancements
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
So here's the thing with datasources. There just has to be one with a
matching name. We don't attempt to validate what it points to. So
you can have MyAppDataSource on dev, test, and prod servers, pointing
to a different database on each box. Then if you deploy an
application plugin that depends on MyAppDataSource, it will work on
all 3 environments, pointing to the database you'd expect in each.
There's one subtlety. If you define the MyAppDataSource as a
dependency, and it's not on the target server, the plugin installer
will attempt to download and install that data source (which you may
want if you normally clone from developer to developer). If you
define the MyAppDataSource as a prerequisite instead, then it must be
installed on the server before the plugin will attempt to install
(which you may want if you're talking about installing the plugin to
dev, test, and prod where it wouldn't be valid to copy a data source
from anywhere else).
As a side note, someone's also asked (I think at JavaOne) if we could
add more options around data source validation, so they could say
"depends on Oracle 9.x" as part of the data source dependency. I
think he blew a lot of time debugging only to find that test had
Oracle 9 and prod had Oracle 10, or something along those lines. I'm
certainly open to adding more options around data source dependencies.
Thanks,
Aaron
On 6/15/06, Matt Hogstrom <ma...@hogstrom.org> 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.
>
> Aaron Mulder wrote:
> > One of the folks at the Geronimo talk at the Enterprise Open Source
> > conference in NYC was from a university that uses Apt, RPM, and tools
> > like that to manage their patches and infrastructure. They were
> > especially interested in find ways like that to distribute plugins.
> > He mentioned a feature in (or going into) Maven that would let it use
> > a different kind of repository back end (jpackage I think? The
> > Java-on-Linux packaging effort).
> >
> > It would be nice to figure out how to better leverage the Maven code
> > to populate and access the repositories, and make that layer more
> > pluggable (Brett or Jason, can we talk about this?). It would
> > certainly also be nice to take advantage of tools like RPM and Apt to
> > install updates and plugins. That might be a better way to distribute
> > plugins to a cluster, if the end user is on Linux.
> >
> > Thanks,
> > Aaron
> >
> > On 6/15/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> >> (Changing subject to make thread more generic)
> >>
> >> So there are two ways to create a plugin. One is to get the module
> >> running in Geronimo and then create the metadata file and export the
> >> CAR -- there's an API for this (which the console uses) and the
> >> Eclipse plugin could use too. The other way is to use the Maven
> >> packaging plugin, copying in the plugin metadata file as part of the
> >> build (this is what the examples do). I suppose you could also JAR up
> >> the module directory in the repository, though I wouldn't recommend
> >> that approach. I assume the API approach would be best for Eclipse
> >> integration -- there's a call to get the default metadata (including
> >> dependencies gleaned from the module itself), a data structure for the
> >> metadata you can populate however you want, a call to update the saved
> >> metadata for the plugin, and a call to get a packaged plugin
> >> InputStream back out.
> >>
> >> As far as distributing to a cluster, that would require push and so
> >> far we've only implemented pull. There's no reason it can't be done.
> >> I think it would make sense to start by defining a format that would
> >> hold a plugin and all its dependencies in a single file (ZIP/JAR) so
> >> the slaves don't need to separately download dependencies. Then we
> >> can probably use the remote deploy application and the deploy tool/API
> >> (with perhaps minor enhancements) to send the plugin out to many
> >> servers.
> >>
> >> As far as sensitivity to releases, currently you can omit the Geronimo
> >> version entirely and it will run with any release. You can also list
> >> many supported releases. I don't think it's worth doing more until we
> >> have wider agreement on version wildcards or ranges, though perhaps we
> >> do with the 1.1.* approach.
> >>
> >> Thanks,
> >> Aaron
> >>
> >> On 6/15/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >> > I was talking to a set of folks that are looking at Geronimo and one
> >> of the unique things they are
> >> > interested in that Geronimo has and others do not is the plugin
> >> support.
> >> >
> >> > They're view of the world is that their developers use Eclipse as
> >> their IDE and like the WTP work
> >> > that has been done so far (koodos Sachin). What they would like the
> >> ability to do is from Eclipse
> >> > be developing and testing and testing an application and when they
> >> get it right is to export that
> >> > application in as a CAR (not from the Admin Console) directly out of
> >> Eclipse.
> >> >
> >> > There were several things that they asked about:
> >> >
> >> > One item was sensitivity to releases. From their perspective this
> >> would be useful if the CAR could
> >> > tolerate several versions of Geronimo. If its only good for a
> >> specific version that limits the
> >> > usefulness.
> >> >
> >> > Integration with Eclipse rather than having developers work the
> >> Geronimo console. It didn't seem as
> >> > compelling.
> >> >
> >> > They would like the Geronimo infrastructure to be able to distribute
> >> CARs throughout a cluster.
> >> >
> >> > They had several other thoughts about G that would make it
> >> interesting as well but they are Geronimo
> >> > server related so I'll post in another thread.
> >> >
> >> > Aaron, thoughts?
> >> >
> >> > Matt
> >> >
> >>
> >
> >
> >
>
Re: Plugin Enhancements
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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.
Aaron Mulder wrote:
> One of the folks at the Geronimo talk at the Enterprise Open Source
> conference in NYC was from a university that uses Apt, RPM, and tools
> like that to manage their patches and infrastructure. They were
> especially interested in find ways like that to distribute plugins.
> He mentioned a feature in (or going into) Maven that would let it use
> a different kind of repository back end (jpackage I think? The
> Java-on-Linux packaging effort).
>
> It would be nice to figure out how to better leverage the Maven code
> to populate and access the repositories, and make that layer more
> pluggable (Brett or Jason, can we talk about this?). It would
> certainly also be nice to take advantage of tools like RPM and Apt to
> install updates and plugins. That might be a better way to distribute
> plugins to a cluster, if the end user is on Linux.
>
> Thanks,
> Aaron
>
> On 6/15/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>> (Changing subject to make thread more generic)
>>
>> So there are two ways to create a plugin. One is to get the module
>> running in Geronimo and then create the metadata file and export the
>> CAR -- there's an API for this (which the console uses) and the
>> Eclipse plugin could use too. The other way is to use the Maven
>> packaging plugin, copying in the plugin metadata file as part of the
>> build (this is what the examples do). I suppose you could also JAR up
>> the module directory in the repository, though I wouldn't recommend
>> that approach. I assume the API approach would be best for Eclipse
>> integration -- there's a call to get the default metadata (including
>> dependencies gleaned from the module itself), a data structure for the
>> metadata you can populate however you want, a call to update the saved
>> metadata for the plugin, and a call to get a packaged plugin
>> InputStream back out.
>>
>> As far as distributing to a cluster, that would require push and so
>> far we've only implemented pull. There's no reason it can't be done.
>> I think it would make sense to start by defining a format that would
>> hold a plugin and all its dependencies in a single file (ZIP/JAR) so
>> the slaves don't need to separately download dependencies. Then we
>> can probably use the remote deploy application and the deploy tool/API
>> (with perhaps minor enhancements) to send the plugin out to many
>> servers.
>>
>> As far as sensitivity to releases, currently you can omit the Geronimo
>> version entirely and it will run with any release. You can also list
>> many supported releases. I don't think it's worth doing more until we
>> have wider agreement on version wildcards or ranges, though perhaps we
>> do with the 1.1.* approach.
>>
>> Thanks,
>> Aaron
>>
>> On 6/15/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>> > I was talking to a set of folks that are looking at Geronimo and one
>> of the unique things they are
>> > interested in that Geronimo has and others do not is the plugin
>> support.
>> >
>> > They're view of the world is that their developers use Eclipse as
>> their IDE and like the WTP work
>> > that has been done so far (koodos Sachin). What they would like the
>> ability to do is from Eclipse
>> > be developing and testing and testing an application and when they
>> get it right is to export that
>> > application in as a CAR (not from the Admin Console) directly out of
>> Eclipse.
>> >
>> > There were several things that they asked about:
>> >
>> > One item was sensitivity to releases. From their perspective this
>> would be useful if the CAR could
>> > tolerate several versions of Geronimo. If its only good for a
>> specific version that limits the
>> > usefulness.
>> >
>> > Integration with Eclipse rather than having developers work the
>> Geronimo console. It didn't seem as
>> > compelling.
>> >
>> > They would like the Geronimo infrastructure to be able to distribute
>> CARs throughout a cluster.
>> >
>> > They had several other thoughts about G that would make it
>> interesting as well but they are Geronimo
>> > server related so I'll post in another thread.
>> >
>> > Aaron, thoughts?
>> >
>> > Matt
>> >
>>
>
>
>
Re: Plugin Enhancements
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
One of the folks at the Geronimo talk at the Enterprise Open Source
conference in NYC was from a university that uses Apt, RPM, and tools
like that to manage their patches and infrastructure. They were
especially interested in find ways like that to distribute plugins.
He mentioned a feature in (or going into) Maven that would let it use
a different kind of repository back end (jpackage I think? The
Java-on-Linux packaging effort).
It would be nice to figure out how to better leverage the Maven code
to populate and access the repositories, and make that layer more
pluggable (Brett or Jason, can we talk about this?). It would
certainly also be nice to take advantage of tools like RPM and Apt to
install updates and plugins. That might be a better way to distribute
plugins to a cluster, if the end user is on Linux.
Thanks,
Aaron
On 6/15/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> (Changing subject to make thread more generic)
>
> So there are two ways to create a plugin. One is to get the module
> running in Geronimo and then create the metadata file and export the
> CAR -- there's an API for this (which the console uses) and the
> Eclipse plugin could use too. The other way is to use the Maven
> packaging plugin, copying in the plugin metadata file as part of the
> build (this is what the examples do). I suppose you could also JAR up
> the module directory in the repository, though I wouldn't recommend
> that approach. I assume the API approach would be best for Eclipse
> integration -- there's a call to get the default metadata (including
> dependencies gleaned from the module itself), a data structure for the
> metadata you can populate however you want, a call to update the saved
> metadata for the plugin, and a call to get a packaged plugin
> InputStream back out.
>
> As far as distributing to a cluster, that would require push and so
> far we've only implemented pull. There's no reason it can't be done.
> I think it would make sense to start by defining a format that would
> hold a plugin and all its dependencies in a single file (ZIP/JAR) so
> the slaves don't need to separately download dependencies. Then we
> can probably use the remote deploy application and the deploy tool/API
> (with perhaps minor enhancements) to send the plugin out to many
> servers.
>
> As far as sensitivity to releases, currently you can omit the Geronimo
> version entirely and it will run with any release. You can also list
> many supported releases. I don't think it's worth doing more until we
> have wider agreement on version wildcards or ranges, though perhaps we
> do with the 1.1.* approach.
>
> Thanks,
> Aaron
>
> On 6/15/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> > I was talking to a set of folks that are looking at Geronimo and one of the unique things they are
> > interested in that Geronimo has and others do not is the plugin support.
> >
> > They're view of the world is that their developers use Eclipse as their IDE and like the WTP work
> > that has been done so far (koodos Sachin). What they would like the ability to do is from Eclipse
> > be developing and testing and testing an application and when they get it right is to export that
> > application in as a CAR (not from the Admin Console) directly out of Eclipse.
> >
> > There were several things that they asked about:
> >
> > One item was sensitivity to releases. From their perspective this would be useful if the CAR could
> > tolerate several versions of Geronimo. If its only good for a specific version that limits the
> > usefulness.
> >
> > Integration with Eclipse rather than having developers work the Geronimo console. It didn't seem as
> > compelling.
> >
> > They would like the Geronimo infrastructure to be able to distribute CARs throughout a cluster.
> >
> > They had several other thoughts about G that would make it interesting as well but they are Geronimo
> > server related so I'll post in another thread.
> >
> > Aaron, thoughts?
> >
> > Matt
> >
>