OsgiClassResolver will be in wicket-bundle.jar (the one in wicketstuff).
The user application will use it by:
MyApp#init() {
super.init();
getApplicationSettings.setClassResolver(new OsgiClassResolver());
}
On Fri, Jun 24, 2011 at 10:46 AM, Brian Topping <topp...@codehaus.org> wrote:
> If by that you mean Wicket would be injected with something like the system
> classloader or wicket's classloader, it kind of breaks modularity. How would
> one upgrade wicket itself? There's no limitation to doing so, the new Wicket
> bundle can have dependencies in parallel with the old wicket bundle, but if
> the dependencies were holding on to the old wicket's classloader, seems like
> a problem.
>
> On Jun 24, 2011, at 12:39 AM, David Leangen wrote:
>
>>
>> IIUC, other frameworks allow for the injection of a classloader. Wouldn't
>> that be enough?
>>
>> We could then package an optional classloader just for that purpose.
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>> On Jun 24, 2011, at 4:34 PM, Brian Topping wrote:
>>
>>> It seems that Wicket should not be burdened with this tracking that is only
>>> used in OSGi configurations. Another issue is that an admin will use OSGi
>>> interfaces to swap out bundles, not wicket interfaces. OSGi is going to
>>> use the BundleActivator of the component bundle to stop it, and it won't
>>> know to tell the wicket core service anything about what it's doing to the
>>> component bundle. Thus it needs to know whether and/or when it can unload.
>>>
>>> Once a bundle is in the STOPPING state, it's no longer an active service,
>>> so it cannot call other services or be called by them. Yet, the tracking
>>> needs to be updated so the blocked call to stop can unblock, hence the weak
>>> reference collection.
>>>
>>> On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote:
>>>
>>>> i think the frameworks should track this. this way wicket can track
>>>> what it is serializing and when it is letting it go. jetty can keep
>>>> track of what it has in its http session.
>>>>
>>>> the serialization bundle should provide a way for bundles to tell it
>>>> "i am holding on to class A from bundle B" and i no longer care about
>>>> class C from bundle D"
>>>>
>>>> -igor
>>>>
>>>> On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping <topp...@codehaus.org>
>>>> wrote:
>>>>> Good point. This could be handled by the serializer maintaining a
>>>>> WeakHashMap of the sessions that use a particular bundle and blocking in
>>>>> the bundle activator's stop method until the list is empty.
>>>>>
>>>>> But if a user was busy for an extended period, like some kind of
>>>>> automated scraper or monitor that ended up having the session open for
>>>>> days, the check would have to be more granular than the session. Which
>>>>> seems like it's going to be different between 1.4 and 1.5 because of the
>>>>> migration from pagemaps.
>>>>>
>>>>> On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote:
>>>>>
>>>>>> something else to consider - where this gets even hairier :)
>>>>>>
>>>>>> user accesses a page that has a component from bundle A, the page is
>>>>>> serialized.
>>>>>> admin upgrades bundle A which has a new version of the component -
>>>>>> that is not compatible serialization-wise
>>>>>> user click back and the page needs to be serialized - error
>>>>>>
>>>>>> what is needed here i some way to veto a bundle/version removal until
>>>>>> all web sessions that access components in those bundles have timed
>>>>>> out. this is not really wicket-specific, more web specific as web apps
>>>>>> can stick objects into http session...
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping <topp...@codehaus.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote:
>>>>>>>
>>>>>>>>> what is really needed here is someone taking the time to build a
>>>>>>>>> generic serialization mechanism for osgi. wicket's serialization is
>>>>>>>>> pluggable so it can be hooked into that.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'll take a look at the patches, play around with the code and find
>>>>>>>> out if I'm one the wrong track or not... If I end up with anything
>>>>>>>> interesting enough, I'll get back or attach another patch.
>>>>>>>
>>>>>>> I'm also taking a look at it.
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
