Firstly, I'm absolutely loving this, good fun to play with and allows some interesting new features in apps. I'm in the middle of playing with Jolokia on Eclipse Virgo and wanted to ask a question/make a request. Virgo doesn't have a HTTPService available and I don't want to add one for just the admin app I'm developing. Virgo has an embedded and OSGi-ified version of Tomcat.
Looking at the source code for the OSGi bundle (not the all inclusive one) I think I can just define an AgentServlet in my own app and all will work just fine and will be within my own security and context path etc... Am I right, if so could I request that the org.jolokia.http.AgentServlet be exported so I can consume it, or something similar to support this kind of embedding.
this is no problem at all, however I still have to iron a small issue with a private type, which the JolokiaActivator uses to intantiate the AgentServlet (a small, private LogHandler abstraction).
I will push a new 0.83-SNAPSHOT out as soon as possible with finishing 0.83 probably at the end of next week (just working on a Roo addon for Jolokia, too).
BTW, while working on a better Virgo integration, it seems, that the virgo kernel doesn't contain a bundle which exports the osgi.service.LogService which in turn is used by the various httpservice bundles (pax, felix). Equinox and Felix come with such an exported interface out of the box, but Virgo doesn't. So I tend to embedd the LogService as well in the jolokia-osgi-bundle, but I'm afraid this will open a can of worms on those systems, which not only have this interface exported but also have an LogService in place. Well, need probably still more testing (and frankly, I don't like this monster bundle anyway)
Uff, and I thought the logging disasters from the last decade are already history ;-)
BTW, do you know about osgish ? --> http://vimeo.com/9800210 I updated it recently (its currently on master in github) to the recent Aries and Jolokia releases. Needs a bit of effort for installation (and a litte Perl installation experience), but it is a good shell ;-)
I will let you know when I have a new Snapshot available.
Thanks for the quick response, I can easily use the Jolokia war while playing with it all so I can easily wait for 0.83. Definitely just at the playing stage, our Admin app is due for some major improvements but nothing has been planned out yet but I think Jolokia will allow me to so some cool things.
I'm hoping to get this going without using httpService, just brining up Jolokia as another servlet in the admin app. The LogService interface is available as Virgo ships with the org.eclipse.osgi.services bundle and it's a pretty simple interface so I'd be tempted to just write my own implementation that passes log messages on to Virgo (which uses Logback & SLF4J), just wouldn't want anything other than Jolokia to consume my LogService though. Would make for a very tight embedding scenario, I realise I'm being picky now.
P.S. ha, everyone is doing ROO addons it seems, Rod will be happy.
for 0.83. Definitely just at the playing stage, our Admin app is due for some major improvements but nothing has been planned out yet but I think Jolokia will allow me to so some cool things.
Sounds interesting, let me know, whether I can help you in the one way or the other when it comes to Jolokia
I'm hoping to get this going without using httpService, just bringing up Jolokia as another servlet in the admin app. The LogService interface is available as Virgo ships with the org.eclipse.osgi.services ...
Sorry, but I couldn't find a bundle exporting org.osgi.service.log neither in Virgo kernel/web nor in Equinox 3.6.1 itself. The system bundle exports only
Can you please point me to the bundle containing the interface definition for the LogService ?
I just pushed out the latest 0.83-SNAPSHOT to our maven repository which includes now an exported
org.jolokia.osgi.servlet.JolokiaServlet. This can be use for programmatic registration and comes with two constructors: A no-arg one and one taking a BundleContext as argument. Using the constructor with the bundle context has the adavantage, that it will use a LogService as soon as it kicks in. Otherwise it simply uses Servlet.log() for its logging needs (which are minimal anyway). Also this variant enables the OSGI based server detectors, which allows for a server detection facility when using the version command (http://localhost:8080/jolokia/version).
While we are at it, it would be nice to have a deticated Virgo detector as well. Since the system bundle is a plain Equinox bundle, do you have a recommendation at which canonical bundle to look for detecting a Virgo server ? (symbolic bundle name, ideally with the version contained in the header info)
BTW, when using jolokia-osgi with the servlet mentioned above, please dont start it, otherwise it will register automatically an agent servlet as soon as an OSGi HttpService registers. State 'resolved' should be enough.
P.S. ha, everyone is doing ROO addons it seems, Rod will be happy.
Well, since writing a roo addon is really dead simple, it would be a shame not to do so ;-)
Sorry for the slow response, weekend and social life got in the way.
There have been some changes to the logging since Virgo 2.1 was released, Felix has been removed and replaced with Equinox implementations and the system bundle now exports the org.osgi.service.log package. I am developing against builds from the Virgo source tree, I should of mentioned that, apologies. 3.0.0.M01 of Virgo will be released this week with these changes in it.
Also, I've finally gotten my prototype going and it is retrieving a little data via AJAX + Jolokia so that's good. It's enough to let me play with some of the new features I want to add that require Jolokia. I'll give the 0.83 snapshot a go at the same time. Will keep you updated on the snapshot.
As for a Virgo detector, go with org.eclipse.virgo.kernel.core. It's version should always be correct as well. The definitive version is stored in a file (/lib/.version). The server version will also be exported via an MBean soon as well I hope :)
I'm going to have to figure out how to bring a bundle in without starting it fully, the Virgo deployer doesn't have any support for it. I'm sure it can be done though.
Thanks again for all the help, it's really appreciated.
I'm running with the 0.83 snapshot now and it works great, just another servlet in my app covered by my existing security etc... I'm only using the null constructor so I need to improve the logging support by providing a LogService in the future but for now this is awesome.
Nice to hear this, thanks. BTW, you can already use the constructor with BundleContext, since it will simply fallback to the plain old Servlet.log() when no LogService is available (which is the same behavior when using the no arg constructor). Additionally you will have access to the version info since I added a Virgo detector which results in an answer like
when pointing directly to http://localhost:9090/jolokia and the jolokia-osgi-bundle is installed (running on port 9090). But using the no arg constructor is ok, of course (otherwise it wouldn't be there ;-)
BTW, since I'm still using 2.1.0, there is no such bundle like org.eclipse.virgo.kernel.core
For 2.1.0 I stick to org.eclipse.virgo.kernel.agent.dm for detecting the existance of Virgo and org.eclipse.gemini.web.core for detecting the server's type (kernel or web). 'hope this is ok.
I will try 3.0.0.M01 as soon as it comes out.
That's awesome, will save me some work in retrieving the Virgo server version. It doesn't make much difference but 'org.eclipse.virgo.kernel.userregion' might be a bit better and I promise it will still be there in the 3.0 milestones. I need to figure out a proper place to expose the Virgo version, might just add it to the Kernel MBean but that's a discussion for another day. Let me know when you do another snapshot and I'll try consuming the extra info property. As for showing the type as either kernel or web, I'm not sure that is that useful and to give you a heads up, with 3.0 there will also be a web build available with Jetty instead of Gemini.
Thanks for the info. I deployed the lates Snapshot 0.83-SNAPSHOT to our repository, with the following changes:
* VirgoDetector now uses the org.eclipse.virgo.kernel.userregion for detecting the Version
* Changed to type => "gemini" (instead of "web") when a bundle named org.eclipse.gemini.web.core is detected (should be save even in 3.0.0 ?).
Please remember for using this detector you need to use the Servlet Constructor with BundleContext argument, otherwise the detectors wont have access to the OSGi system for detecting other bundles.
That's great. Yeah Gemini core will still be there for a long time to come. The Jetty version is still being worked on so I can't give you a bundle for that one with any certainty it'll be around for long. I'll grab the snapshot and try it out.
So I had ago at using the BundleContext constructor and found out there is no way to pass constructor args in from web.xml. How are you doing it, I'm puzzled?
I did a little digging around and found a standard way to do this that will also give your detectors more flexibility. Both our web containers Jetty and Gemini Web (Tomcat really) are implementations of an OSGi web spec (RFC66). This basically means you can do a:
If this doesn't return null then you know you are in an OSGi Web Application Container and then just figure out which one, possibly the same way you already are and if you can't then at least you have an idea about your environment. This will also remove the issue of a Servlet constructor with arguments.
F.Y.I The web app is slowly filling up with Jolokia query strings. Need to start playing with the bulk requests feature soon :)
Ah, ok. Sorry, this was a misunderstanding, I thought, you construct the servlet on your own programatically somewhere (not declaratively within web.xml). You suggestion to obtain the bundle context from the servlet context sounds to be a nice solution for this case. I will check this out, thanks.
I can report 0.83 release is working fine on Virgo 3.0.0.M01, I shouted about it on twitter . I'm just defining it in my web.xml and the Virgo detector is working fine, I'm getting the additional info down from the Jolokia version request. Thank you so much for all your help.
My app is coming on nicely it's just a case of filling out the functionality and it'll be a very nice Jolokia powered app. One last question, do you have any feeling as to when you might reach 1.0, just wondering?
Thank you for the feedback and thanks for spreading the word on twitter. I guess, Jolokia is not very well known yet (although its sister 'jmx4perl' is used here in really large Nagios installations (>500 Server) and also at some other large installations, too (e.g. at CERN)). Feedback is, that it runs very stable and non-intruisive (e.g no known memory leaks).
About the version: Typically I don't care much about versioning and I used to adopt the notion, that a 1.0 is 'finished' (like my Cron::Schedule perl module reached 1.0 after 10 years when I declared it as finished). Not so bizarre like the TeX or LaTeX versioning, but admittedly still a bit quirky ;-)
Seriously, I intend to release 1.0 as soon as I applied the final touches to the protocol. There are some (backwards compatible) changes in the pipeline, i.e. an improved meta data handling (the 'list' command) and some changes in serialization when setting attributes and executing operations with arguments.
Maybe Jolokia will support JMX notifications, too, before 1.0, don't know it yet.
You can expect 1.0 in summer or autumn this year (no promises, though).
Thanks for the info, long live the perpetual beta. I'm not too bothered about things breaking that much as we are a way off releasing yet either, having just done M01. I'm sure there are plenty of other users though.