[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] Security in Virgo
- From: Glyn Normington <gnormington@xxxxxxxxxx>
- Date: Mon, 22 Nov 2010 08:51:43 -0800
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: email@example.com
- Thread-index: AcuKZYrzEfNKk8JZSIaMwO0WnGMrDw==
- Thread-topic: [virgo-dev] Security in Virgo
I hope you are aware of the thread context class loading support in Virgo which allows hibernate apps to be built without any dynamic imports. Essentially, any scoped application (PAR or scoped plan) gets an extra bundle generated by Virgo. This "synthetic context" bundle imports all the exports of the other bundles in the scoped application. The class loader of the synthetic context bundle is used as the TCCL when the scoped application calls out to bundles, such as hibernate, outside the scope. Then hibernate can use thread context class loading to load any of the classes of the exported packages of the bundles of the app. (Although I understand the general mechanism, I don't claim any hibernate expertise, so I'll leave it to others on the list to elaborate if necessary. ;-))
BTW there is no enhancement bug for a HttpService in Virgo, but please raise one if you would like to. We already support Tomcat via Gemini Web and we are planning to support Jetty in the next release, so HttpService won't be high priority, but someone in the community may care to implement it.
On 22 Nov 2010, at 16:36, Ric Klaren wrote:
> On 22 November 2010 16:09, Glyn Normington <gnormington@xxxxxxxxxx> wrote:
>> For the record, we do not recommend the use of "dynamic import *" as it represents unspecified dependencies on arbitrary packages which are not known until class load time. Sorry, but there we are.
> Indeed we are also very allergic for dynamic import as well (and
> require bundle *ugh*), so we like to keep it as contained as possible
> (small bundles that export *no* packages). So far we only need it for
> hibernate, wicket and this case (for all we actually restrict it to
> certain package hierarchies). As long as java has stuff as
> Class.forName and such you never know when stuff breaks at runtime ;)
> With these few dynamic imports we get the situation that we are able
> to do life upgrades of pieces of domain/services/webservices
> (including hibernate mappings, bits of UI). There are some glitches
> still, but the principle works. We mainly use it during development at
> the moment. But we hope to get to the situation that we can just push
> a few bundles out for an update.
> For normal (programmer) usage you just have to make sure you export
> the packages that should be visible and the rest just works.
> I guess there's alternatives. You could work around it with a load of
> fragments but that's a lot of extra maintenance. We started before the
> snaps stuff appeared so at that moment there was not really an
> alternative. Although I'd doubt we'd switch to snaps, the moment Virgo
> will provide a HttpService we will be a bunch of happy campers though,
> then we can get rid of that horrible web.xml.
> virgo-dev mailing list