You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Harald Wellmann <ha...@gmx.de> on 2011/06/22 19:57:49 UTC
Wicket and OSGi
I'm currently trying to build an OSGi Enterprise stack using Wicket and
Apache Aries, and I have a couple of questions and suggestions:
1) Why does the official Wicket artifact include a Dynamic-Import: *
header? This should only be used as a last resort...
2) I'd like to @Inject OSGi services into Wicket components using an
IComponentInstantiationListener - is there a ready-to-go extension I
could use?
3) If not, would it be a good idea to create a wicket-osgi extension as
part of Wicket or Wicketstuff?
Regarding 1), I would assume that wrapping the bundle class loader
of the user's application in an IClassResolver and registering it in
Application.init() would do the trick, or doesn't it?
As for 2) and 3), I wrote similar bridges both for CDI and Spring,
building on wicket-ioc, so I do have an idea of what it takes, but of
course I don't want to reinvent the wheel.
Best regards,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Jun 23, 2011 at 11:30 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> On Thu, Jun 23, 2011 at 11:09 PM, Martin Grigorov <mg...@apache.org> wrote:
>> On Fri, Jun 24, 2011 at 2:41 AM, Igor Vaynberg <ig...@gmail.com> 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
>>>
>> This sounds like the problem solved with
>> http://www.tomcatexpert.com/blog/2011/05/31/parallel-deployment-tomcat-7
>
> the trick with that is
> a) having a webapp that actually undeploys quickly :)
s/quickly/cleanly/
-igor
> and b) having enough permgen allocated to another version concurrently
>
> -igor
>
>>>
>>> On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping <to...@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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Jun 23, 2011 at 11:09 PM, Martin Grigorov <mg...@apache.org> wrote:
> On Fri, Jun 24, 2011 at 2:41 AM, Igor Vaynberg <ig...@gmail.com> 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
>>
> This sounds like the problem solved with
> http://www.tomcatexpert.com/blog/2011/05/31/parallel-deployment-tomcat-7
the trick with that is
a) having a webapp that actually undeploys quickly :)
and b) having enough permgen allocated to another version concurrently
-igor
>>
>> On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping <to...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Brian Topping <to...@codehaus.org>.
On Jun 23, 2011, at 11:09 PM, Martin Grigorov wrote:
> This sounds like the problem solved with
> http://www.tomcatexpert.com/blog/2011/05/31/parallel-deployment-tomcat-7
Kind of assumes one is using Tomcat and not one of the other ways to deploy a web application with OSGi. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Jun 24, 2011 at 2:41 AM, Igor Vaynberg <ig...@gmail.com> 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
>
This sounds like the problem solved with
http://www.tomcatexpert.com/blog/2011/05/31/parallel-deployment-tomcat-7
>
> On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping <to...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Martin Grigorov <mg...@apache.org>.
Wicket has org.apache.wicket.application.IClassResolver.
The mentioned ticket earlier has OsgiClassResolver impl
On Fri, Jun 24, 2011 at 10:39 AM, David Leangen <wi...@leangen.net> 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 <to...@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 <to...@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-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Martin Grigorov <mg...@apache.org>.
Looks simpler solution. If it works OK then we can commit it in SVN.
You are right, wicket-bundle just combines -util.jar, -request.jar and
-core.jar into one.
We can create a new wicket-osgi project in wicketstuff that will
provide the integration code, like OsgiClassResolver and whatever else
is needed.
On Fri, Jun 24, 2011 at 11:22 AM, Brian Topping <to...@codehaus.org> wrote:
> wicket-bundle appears to be simply using assembly plugin to mash all the jars together.
>
> I haven't tested it yet, but I believe https://github.com/topping/wicket/commit/b120bdd4e6b7b085f2644aab1f77b3d40558c967 is a better solution.
>
> Haven't found OsgiClassResolver yet, but it's late here and I'm going to bed.
>
> On Jun 24, 2011, at 12:50 AM, Martin Grigorov wrote:
>
>> 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 <to...@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 <to...@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 <to...@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-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Brian Topping <to...@codehaus.org>.
wicket-bundle appears to be simply using assembly plugin to mash all the jars together.
I haven't tested it yet, but I believe https://github.com/topping/wicket/commit/b120bdd4e6b7b085f2644aab1f77b3d40558c967 is a better solution.
Haven't found OsgiClassResolver yet, but it's late here and I'm going to bed.
On Jun 24, 2011, at 12:50 AM, Martin Grigorov wrote:
> 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 <to...@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 <to...@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 <to...@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-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Martin Grigorov <mg...@apache.org>.
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 <to...@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 <to...@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 <to...@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-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Brian Topping <to...@codehaus.org>.
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 <to...@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 <to...@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-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by David Leangen <wi...@leangen.net>.
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 <to...@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 <to...@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-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Brian Topping <to...@codehaus.org>.
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 <to...@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 <to...@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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <to...@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 <to...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Brian Topping <to...@codehaus.org>.
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 <to...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <to...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Brian Topping <to...@codehaus.org>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Martin Grigorov <mg...@apache.org>.
Thank you, Harald!
Not sure which version of Wicket you use but I'd be happy to support
you for 1.5.
On Thu, Jun 23, 2011 at 8:11 PM, Harald Wellmann <ha...@gmx.de> wrote:
> Am 23.06.2011 18:48, schrieb Igor Vaynberg:
>>
>> there is a jira issue with a patch.
>
> That's probably the one that Martin mentioned:
> https://issues.apache.org/jira/browse/WICKET-3737
>
>
>> unfortunately someone has to build
>> the "classloader" that can see all bundles.
>>
>
>> 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.
>
> Thanks,
> Harald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Andreas Pieber <an...@gmail.com>.
Hey Martin,
On Mon, Jul 4, 2011 at 10:24 PM, Martin Grigorov <mg...@apache.org> wrote:
> Good work!
Thank you :)
> Do you have any plans to upgrade PAX-Wicket to Wicket 1.5 ?
> I saw that you have custom Output|Input ObjectStream impls.
> In Wicket 1.5 IObjectStreamFactory class is gone, so you'll need to
> use the new ISerializer interface.
Definitely. I know that there are some infrastructural changes in 1.5
which means that there will be a pax-wicket release for 1.4.x and one
for 1.5.x. TBH I'm not sure right now how I want to tackle this.
Either aligning the major (major.minor.micro) version to the
pax-wicket or provide two complete different versions (0.8.0.w15 and
0.8.0.w14). Anyhow I will provide a 1.5 compatible version within the
next 1-2 months.
> For more info you can check
> https://issues.apache.org/jira/browse/WICKET-3778
> https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/gae-initializer-parent/gae-initializer/src/main/java/org/wicketstuff/gae
> https://github.com/wicketstuff/core/tree/master/jdk-1.6-parent/serializer-kryo
>
> The GAE code is exactly what you'll need to do for PAX.
Thank you very much for those pointers. This does not look as it would
create any big problems if added to the pax-wicket model.
Kind regards,
Andreas
>
> On Mon, Jul 4, 2011 at 9:19 PM, pieber <an...@gmail.com> wrote:
>> Hey,
>>
>> Sorry that I jump in so late, but it needed some time to spread the news of
>> this list if you're not a subscriber of the wicket user list :)
>>
>> I've taken up the development of pax-wicket which is a framework for the
>> integration of wicket to the osgi platform. While pax-wicket provides
>> various other features at it's core we've solved the classloader,
>> serialization and injection (spring & blueprint). While most of you may
>> already know about pax-wicket
>> (http://ops4j1.jira.com/wiki/display/paxwicket/Pax+Wicket and
>> https://github.com/ops4j/org.ops4j.pax.wicket) there had been LOTS of
>> changes in the last months and it is much easier to use by now! OK, with
>> that said back to the problem at hand.
>>
>> @WICKET-3737: We've used a similar approach as you've described. We
>> automatically attache Classresolver and InjectionResolver services to each
>> bundle and delegate the classloading to the bundle which contains the class.
>> This also allows to use classes not exported :) In fact you use case is
>> quite simple to implement with pax-wicket.
>>
>> @SpringWicket annotation: We use the same approach as you've described. The
>> only difference is that we extend the model a little bit further to allow
>> import from the blueprint AND spring context from one bundle. Otherwise we
>> limit the import to the bundle creating the blueprint or spring context.
>>
>> Feel free to give it a look. I've registered again and stay here and at the
>> pax lists for help and further infos :) I'm also available in the wicket and
>> pax IRC channels (pieber). Feel free to ping me.
>>
>> Kind regards,
>> Andreas
>>
>> --
>> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-and-OSGi-tp3617698p3644390.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Martin Grigorov <mg...@apache.org>.
Andreas,
Good work!
Do you have any plans to upgrade PAX-Wicket to Wicket 1.5 ?
I saw that you have custom Output|Input ObjectStream impls.
In Wicket 1.5 IObjectStreamFactory class is gone, so you'll need to
use the new ISerializer interface.
For more info you can check
https://issues.apache.org/jira/browse/WICKET-3778
https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/gae-initializer-parent/gae-initializer/src/main/java/org/wicketstuff/gae
https://github.com/wicketstuff/core/tree/master/jdk-1.6-parent/serializer-kryo
The GAE code is exactly what you'll need to do for PAX.
On Mon, Jul 4, 2011 at 9:19 PM, pieber <an...@gmail.com> wrote:
> Hey,
>
> Sorry that I jump in so late, but it needed some time to spread the news of
> this list if you're not a subscriber of the wicket user list :)
>
> I've taken up the development of pax-wicket which is a framework for the
> integration of wicket to the osgi platform. While pax-wicket provides
> various other features at it's core we've solved the classloader,
> serialization and injection (spring & blueprint). While most of you may
> already know about pax-wicket
> (http://ops4j1.jira.com/wiki/display/paxwicket/Pax+Wicket and
> https://github.com/ops4j/org.ops4j.pax.wicket) there had been LOTS of
> changes in the last months and it is much easier to use by now! OK, with
> that said back to the problem at hand.
>
> @WICKET-3737: We've used a similar approach as you've described. We
> automatically attache Classresolver and InjectionResolver services to each
> bundle and delegate the classloading to the bundle which contains the class.
> This also allows to use classes not exported :) In fact you use case is
> quite simple to implement with pax-wicket.
>
> @SpringWicket annotation: We use the same approach as you've described. The
> only difference is that we extend the model a little bit further to allow
> import from the blueprint AND spring context from one bundle. Otherwise we
> limit the import to the bundle creating the blueprint or spring context.
>
> Feel free to give it a look. I've registered again and stay here and at the
> pax lists for help and further infos :) I'm also available in the wicket and
> pax IRC channels (pieber). Feel free to ping me.
>
> Kind regards,
> Andreas
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-and-OSGi-tp3617698p3644390.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Andreas Pieber <an...@gmail.com>.
Hey Harald,
On Mon, Jul 4, 2011 at 10:47 PM, Harald Wellmann <ha...@gmx.de> wrote:
> thanks for providing the pointers and the brand new intro in the Pax Wicket
> wiki.
I'm very sorry for the lack of documentation. But I planed to get it
done, provide the documentation and do the project marketing then. I
missed to recognize the BIG need for pax-wicket. Sorry for that.
> This is now at least something to get started, and I'm beginning to see that
> there is some overlap with wicket-osgi or even the chance of wicket-osgi
> becoming obsolete in the near future as Pax Wicket matures or just shifts
> its priorities a little from hacking to documenting all its goodies ;-)
You're highly welcomed to work out the problems with us together. I
would be very happy if I don't have to document everything from
top-to-bottom but could rather start at your special needs and extend
pax-wicket and the documentation where required. Any idea/discussion
on IRC/lists is highly welcomed. In addition, as typical for ops4j
projects, anyone is welcomed to create an account and start
hacking/writing docs :)
> Some points after a very quick first look and comparison:
>
> - Pax Wicket head does not compile
> (https://ops4j1.jira.com/browse/PAXWICKET-164)
Not true :) This is really a JDK bug. If you upgrade to the latest JDK
version it works.
> - Pax Wicket is based on Wicket 1.4.17, wicket-osgi on 1.5-SNAPSHOT
True for the moment. But I don't think that the upgrade will cost that
much and most of the user base is still on 1.4.x. In fact it is
possible to port your existing 1.4.x wicket app (typically) within
hours. I did this to several of the apps at my company and it worked
like a charm.
> - Wicket 1.4.17 uses DynamicImport-Package: * - are you sure Pax Wicket
> would work without that?
I'm because we do NOT use the standard wicket packages. We pack wicket
into the pax-wicket package and reexport them. If you're familiar with
the maven-bundle-plugin feel free to take a look here
(https://github.com/ops4j/org.ops4j.pax.wicket/blob/master/service/pom.xml)
and see what I mean.
> - The official Wicket 1.5 artifacts are not OSGi friendly, so if you upgrade
> Pax Wicket to 1.5, you'd have to use wicket-bundle from Wicketstuff, just
> like wicket-osgi. (Of course, I'd much prefer the Wicket core project to
> provide properly osgified artifacts without split packages and dynamic
> imports so we could scrap wicket-bundle...)
I'm completely with you. Since it doesn't make much sense to use a
different wicket version than pax-wicket I like our current approach
to repack all libs directly in pax-wicket. But I've no problem to be
convinced to use the wicketstuff wicket bundles or adapted wicket core
packages.
Kind regards,
Andreas
>
> Cheers,
> Harald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Harald Wellmann <ha...@gmx.de>.
Hi Andreas,
thanks for providing the pointers and the brand new intro in the Pax
Wicket wiki.
This is now at least something to get started, and I'm beginning to see
that there is some overlap with wicket-osgi or even the chance of
wicket-osgi becoming obsolete in the near future as Pax Wicket matures
or just shifts its priorities a little from hacking to documenting all
its goodies ;-)
Some points after a very quick first look and comparison:
- Pax Wicket head does not compile
(https://ops4j1.jira.com/browse/PAXWICKET-164)
- Pax Wicket is based on Wicket 1.4.17, wicket-osgi on 1.5-SNAPSHOT
- Wicket 1.4.17 uses DynamicImport-Package: * - are you sure Pax Wicket
would work without that?
- The official Wicket 1.5 artifacts are not OSGi friendly, so if you
upgrade Pax Wicket to 1.5, you'd have to use wicket-bundle from
Wicketstuff, just like wicket-osgi. (Of course, I'd much prefer the
Wicket core project to provide properly osgified artifacts without split
packages and dynamic imports so we could scrap wicket-bundle...)
Cheers,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by pieber <an...@gmail.com>.
Hey,
Sorry that I jump in so late, but it needed some time to spread the news of
this list if you're not a subscriber of the wicket user list :)
I've taken up the development of pax-wicket which is a framework for the
integration of wicket to the osgi platform. While pax-wicket provides
various other features at it's core we've solved the classloader,
serialization and injection (spring & blueprint). While most of you may
already know about pax-wicket
(http://ops4j1.jira.com/wiki/display/paxwicket/Pax+Wicket and
https://github.com/ops4j/org.ops4j.pax.wicket) there had been LOTS of
changes in the last months and it is much easier to use by now! OK, with
that said back to the problem at hand.
@WICKET-3737: We've used a similar approach as you've described. We
automatically attache Classresolver and InjectionResolver services to each
bundle and delegate the classloading to the bundle which contains the class.
This also allows to use classes not exported :) In fact you use case is
quite simple to implement with pax-wicket.
@SpringWicket annotation: We use the same approach as you've described. The
only difference is that we extend the model a little bit further to allow
import from the blueprint AND spring context from one bundle. Otherwise we
limit the import to the bundle creating the blueprint or spring context.
Feel free to give it a look. I've registered again and stay here and at the
pax lists for help and further infos :) I'm also available in the wicket and
pax IRC channels (pieber). Feel free to ping me.
Kind regards,
Andreas
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-and-OSGi-tp3617698p3644390.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Harald Wellmann <ha...@gmx.de>.
Am 28.06.2011 10:08, schrieb Daniël van 't Ooster:
>
> - This implementation assumes the web bundle knows about all bundles
> providing services;
wicket-osgi currently assumes that the web application bundle (WAB)
explicitly imports all packages or bundles which contribute Wicket
components used by the application.
Otherwise, for the injection stuff, the WAB only needs to import the
service interface packages, but not the implementation packages or bundles.
> in our case (the case attached to WICKET-3737 is a
> stripped down version), we have one 'web bundle', which hosts the Wicket
> application; individual bundles provide pages and their mount points (in the
> example case, bundles provide some panels).
Yes, I had a look at that example - it's a rather advanced scenario and
far more than what I'm currently aiming at with wicket-osgi.
The first major goal I would like to achieve is support for the
following scenario:
- OSGi Web Container and Web Application Bundles according to OSGi
Enterprise Spec 4.2.
- Wicket is deployed as a plain old OSGi bundle.
- One or more WABs are deployed as separate bundles. Each WAB provides a
Web Application according to the Servlet Spec. The WABs are completely
isolated from each other, just like plain old WARs.
I don't think that your scenario with other bundles contributing new
pages or resources to a running web application is currently covered by
the OSGi Enterprise Spec. A WAB is always a single bundle, which may of
course import packages and use services from other bundles, but for
anything related to the Web Context Path, there is a one-to-one relation
between context paths and bundles. At least that's my understanding, but
I'm not in any of the Java EE or OSGi expert groups...
Of course you can attach OSGi fragments to your WAB as bundle host, but
an independent bundle registering services that contribute to a web
context owned by some other bundle is currently out of scope, I'd say.
Mind you, I'm not saying that your scenario doesn't make sense or cannot
be done, but it sounds like the second or third step to me.
Do you have examples of any OSGi Web containers supports your flavour of
multi-bundle WABs? So far, I've looked at Pax Web, Eclipse Gemini Web
and Glassfish, and my impression is they all follow the rule "one web
context, one bundle".
> In cases like that, there is no
> single class loader which knows all classes, so you need one bundle with a
> DynamicImport-Package: *.
I'd say your assumption is right, but your conclusion is not... Let's
say your WAB retrieves WebPages from the service registry and mounts
them. To do so, it only needs to load the WebPage base class from
Wicket, but not the implementation class from some other bundle.
In this situation, page deserialization will fail, because neither the
Wicket bundle class loader nor your WAB nor the ThreadContextClassLoader
can load the class from the contributor bundle.
But even then, there are other and better solutions than
DynamicImport-Package, which I think is something like an emergency
amputation when you have to save your application's life and need to use
some third-party lib that simply doesn't play by OSGi rules.
> To reduce the number of bundle refreshes we
> delegate this job to a tiny 'class resolver bundle', which exposes an
> IClassResolver instance as OSGi service.
And this class resolver bundle still uses dynamic imports, right?
I'd suggest one of the following options:
1) Your contributor bundles provide an IContributor service for an
interface exported by your WAB. Your WAB tracks all implementations,
builds a composite ClassResolver from all their classloaders and
registers the ClassResolver with Wicket.
2) Extender Pattern: You define a special manifest header that all your
contributors need to include, then your WAB tracks bundle events,
identifies its contributors from the manifest header and builds a
composite ClassResolver as in 1).
In any case, I would leave wicket-bundle and wicket-osgi out of the
game. There may be more than one WAB, each with a number of contributor
bundles, and the Wicket bundle cannot decide how to match them up.
> While generating JDK / CGLib proxies, you need a class loader which can
> access all proxied classes, one way to solve this is a minor change to the
> IClassResolver interface to get access to the almightly class loader. I have
> added a method getClassLoader(), which is used in the DefaultClassResolver
> to load classes. This simple change will save some code duplication in OSGi
> compatible classResolvers.
>
What's your use case for these proxies? Do you create them at
application level, or is this something that Spring DM does at framework
level.
> - Another difference is how OSGi services are used; we are using Spring DM,
> which creates one applicationContext per bundle. Fields annotated with
> @SpringBean will be injected with beans (imported OSGi reference is also a
> bean) from the applicationContext of the bundle in which the component is
> created.
The wicket-osgi test bundles uses OSGi Blueprint. And Blueprint is
nothing but Spring DM standardized. However, wicket-osgi does NOT depend
on Blueprint.
wicket-osgi supports injection of OSGI service references via @Inject.
(This does not currently cover other Blueprint beans.)
I'm all in favour of injection by annotation - XML is not type safe and
violates the DRY principle. The problem is, there are too many competing
sets of annotations that all basically to the same thing:
- @Inject (JSR-330 and JSR-299 (CDI))
- @Autowired (Spring)
- @SpringBean (wicket-spring)
- @Inject + @OSGiService qualifier (Glassfish)
- @Reference, @Bean, @Service (Apache Aries)
I would love to see standardized annotations in the next version of the
OSGi Blueprint specification. Until then, I think the most portable
approach that does not tie you to any given implementation is @Inject +
@Qualifier (JSR-330).
> In my opinion, the advantage of this is that each bundle has to be
> explicit about the services it depends on, spring beans do not have to be
> unique, not all beans have to be exported as OSGi service and there is need
> to register ServiceTracker instances (Spring DM solves this problem).
>
Replace Spring DM by Blueprint and you're portable. And you can move
from Spring DM/Eclipse Gemini to Apache Aries which is the more solid
and innovative implementation, IMHO.
[This is an Apache mailing list, so I had to say that ;-) ]
> - Is it an idea to extend the wicket-osgi project with some classes which
> support this pattern?
Absolutely.
> So wicket-osgi will become the toolkit you need when
> combining OSGi and Wicket? I think it would be nice when it has injectors
> for services from the OSGi service registry, as well as the pattern in which
> spring beans from the bundle application context are used (more similar to
> wicket-spring, the only difference is you have multiple, small application
> contexts). One attachment to WICKET-3737 contains the injector stack
> required for wiring spring beans from the bundle application context into
> wicket components (not completely finished).
>
The first step is already made with the current @Inject support. This is
rather basic at the moment because it does not allow you to choose the
one you need when there's more than one service for a given interface.
Second step: support a JSR-330 qualifier (e.g. @OSGiService) that wraps
a filter and/or some service properties for service disambiguation.
Third step: additionally support injection of Blueprint Beans.
Any supporting framework classes for step 3 might have to move to a
separate bundle wicket-blueprint, because step 1 and 2 do not depend on
Blueprint. Service injection should work independent of the service
registration method (programmatically, DS, Blueprint, whatever...)
Cheers,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Daniël van 't Ooster <dv...@educator.eu>.
Hi all,
interesting discussion so far; it seems we're not the only ones trying to
combine Wicket and OSGi.
Related to the Wicketstuff wicket-osgi project, I would like to share some
comments:
- This implementation assumes the web bundle knows about all bundles
providing services; in our case (the case attached to WICKET-3737 is a
stripped down version), we have one 'web bundle', which hosts the Wicket
application; individual bundles provide pages and their mount points (in the
example case, bundles provide some panels). In cases like that, there is no
single class loader which knows all classes, so you need one bundle with a
DynamicImport-Package: *. To reduce the number of bundle refreshes we
delegate this job to a tiny 'class resolver bundle', which exposes an
IClassResolver instance as OSGi service.
While generating JDK / CGLib proxies, you need a class loader which can
access all proxied classes, one way to solve this is a minor change to the
IClassResolver interface to get access to the almightly class loader. I have
added a method getClassLoader(), which is used in the DefaultClassResolver
to load classes. This simple change will save some code duplication in OSGi
compatible classResolvers.
- Another difference is how OSGi services are used; we are using Spring DM,
which creates one applicationContext per bundle. Fields annotated with
@SpringBean will be injected with beans (imported OSGi reference is also a
bean) from the applicationContext of the bundle in which the component is
created. In my opinion, the advantage of this is that each bundle has to be
explicit about the services it depends on, spring beans do not have to be
unique, not all beans have to be exported as OSGi service and there is need
to register ServiceTracker instances (Spring DM solves this problem).
- Is it an idea to extend the wicket-osgi project with some classes which
support this pattern? So wicket-osgi will become the toolkit you need when
combining OSGi and Wicket? I think it would be nice when it has injectors
for services from the OSGi service registry, as well as the pattern in which
spring beans from the bundle application context are used (more similar to
wicket-spring, the only difference is you have multiple, small application
contexts). One attachment to WICKET-3737 contains the injector stack
required for wiring spring beans from the bundle application context into
wicket components (not completely finished).
To achieve this, I think the change to the IClassResolver API is required,
some patches have to be applied in wicket-ioc code and the
DynamicImport-Package header needs to be dropped from the wicket bundles.
What do you think?
grtz,
Daniël
** <http://www.educator.eu>
On Mon, Jun 27, 2011 at 10:36 PM, Harald Wellmann <ha...@gmx.de>wrote:
> Am 27.06.2011 22:13, schrieb Martin Grigorov:
>
> I also reviewed the code - good job!
>>
>>
> Thanks :-)
>
>
> I saw that you basically copy/pasted DefaultClassResolver to
>> OsgiClassResolver with minor modifications.
>> I think it will be better if we make DCR easier to extend so there is
>> no need to copy/paste its code.
>>
>>
> Actually, I'm no longer sure it is needed at all... The OsgiClassResolver
> uses the bundle class loader of the WAB, accessed via the current
> Application class.
>
> The DefaultClassResolver uses the ThreadContextClassLoader, or its own
> classloader as a fallback.
>
> I'd noticed before that my sample works on Jetty even without the
> OsgiClassResolver, and the same is true on GlassFish 3.1.
>
> Sahoo from the GlassFish team pointed out to me that any Servlet container
> is required to set the TCCL to the application classloader (see Servlet Spec
> 3.0, section 10.7.2) for loading resources and for any application
> callbacks.
>
> If everyone agrees that this covers all use cases where Wicket needs to
> load stuff from user bundles, then I think it's safe to scrap the
> OsgiClassResolver and let the unmodified DefaultClassResolver do the job.
>
>
>>> Could you also document the new module on wicketstuff wiki?
>>> https://github.com/**wicketstuff/core/wiki<https://github.com/wicketstuff/core/wiki>
>>>
>>
> Sure - that's the next thing on my list...
>
> I'm also planning to add some Surefire tests based on Pax Exam.
>
> Cheers,
>
> Harald
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket and OSGi
Posted by Harald Wellmann <ha...@gmx.de>.
Am 27.06.2011 22:13, schrieb Martin Grigorov:
> I also reviewed the code - good job!
>
Thanks :-)
> I saw that you basically copy/pasted DefaultClassResolver to
> OsgiClassResolver with minor modifications.
> I think it will be better if we make DCR easier to extend so there is
> no need to copy/paste its code.
>
Actually, I'm no longer sure it is needed at all... The
OsgiClassResolver uses the bundle class loader of the WAB, accessed via
the current Application class.
The DefaultClassResolver uses the ThreadContextClassLoader, or its own
classloader as a fallback.
I'd noticed before that my sample works on Jetty even without the
OsgiClassResolver, and the same is true on GlassFish 3.1.
Sahoo from the GlassFish team pointed out to me that any Servlet
container is required to set the TCCL to the application classloader
(see Servlet Spec 3.0, section 10.7.2) for loading resources and for any
application callbacks.
If everyone agrees that this covers all use cases where Wicket needs to
load stuff from user bundles, then I think it's safe to scrap the
OsgiClassResolver and let the unmodified DefaultClassResolver do the job.
>>
>> Could you also document the new module on wicketstuff wiki?
>> https://github.com/wicketstuff/core/wiki
Sure - that's the next thing on my list...
I'm also planning to add some Surefire tests based on Pax Exam.
Cheers,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Martin Grigorov <mg...@apache.org>.
I also reviewed the code - good job!
I saw that you basically copy/pasted DefaultClassResolver to
OsgiClassResolver with minor modifications.
I think it will be better if we make DCR easier to extend so there is
no need to copy/paste its code.
On Mon, Jun 27, 2011 at 10:53 PM, Attila Király
<ki...@gmail.com> wrote:
> Good work.
>
> Could you also document the new module on wicketstuff wiki?
> https://github.com/wicketstuff/core/wiki
>
> Thanks,
> Attila
>
> 2011/6/27 Harald Wellmann <ha...@gmx.de>
>
>> There is now a new module wicket-osgi in wicketstuff/core at Github with
>> some glue code to adapt Wicket to OSGi house rules.
>>
>> Summary:
>>
>> - wicket-osgi supports bootstrapping a WicketApplication from the OSGi
>> service registry, matching a property value specified as a WicketFilter init
>> parameter in web.xml.
>>
>> - OsgiClassResolver supports Wicket page deserialization.
>>
>> - OsgiComponentInjector lets you inject OSGi services into WIcket
>> components by annotating fields with JSR-330 @Inject.
>>
>> - wicket-bundle, the all-in-one OSGi-compliant packaging of Wicket, now has
>> a revised manifest without dynamic imports.
>>
>> - wicket-ioc-bundle (sibling of wicket-bundle) does the same for
>> wicket-ioc, which is required by wicket-osgi.
>>
>> - wicket-osgi-test-web and wicket-osgi-test-service are two simple test
>> bundles for testing the glue code in an OSGi web container (Pax Web). The
>> sample uses Aries Blueprint to interact with the service registry, but of
>> course you can also use Declarative Services or a BundleActivator.
>>
>> - To run the sample webapp:
>>
>> cd wicketstuff-core/jdk-1.5-**parent/wicket-osgi-parent
>> cd wicket-osgi-test-web
>> mvn install pax:run
>> Open http://localhost:8080/library in your browser.
>>
>> - To use wicket-osgi in your own projects, have a look at web.xml and
>> LibraryApplication.java in wicket-osgi-test-web, and at the Javadoc in
>> wicket-osgi.
>>
>> All of this is anything but final... Have a look at the code, give it a try
>> and let me know that you think.
>>
>> Thanks,
>> Harald
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Attila Király <ki...@gmail.com>.
Good work.
Could you also document the new module on wicketstuff wiki?
https://github.com/wicketstuff/core/wiki
Thanks,
Attila
2011/6/27 Harald Wellmann <ha...@gmx.de>
> There is now a new module wicket-osgi in wicketstuff/core at Github with
> some glue code to adapt Wicket to OSGi house rules.
>
> Summary:
>
> - wicket-osgi supports bootstrapping a WicketApplication from the OSGi
> service registry, matching a property value specified as a WicketFilter init
> parameter in web.xml.
>
> - OsgiClassResolver supports Wicket page deserialization.
>
> - OsgiComponentInjector lets you inject OSGi services into WIcket
> components by annotating fields with JSR-330 @Inject.
>
> - wicket-bundle, the all-in-one OSGi-compliant packaging of Wicket, now has
> a revised manifest without dynamic imports.
>
> - wicket-ioc-bundle (sibling of wicket-bundle) does the same for
> wicket-ioc, which is required by wicket-osgi.
>
> - wicket-osgi-test-web and wicket-osgi-test-service are two simple test
> bundles for testing the glue code in an OSGi web container (Pax Web). The
> sample uses Aries Blueprint to interact with the service registry, but of
> course you can also use Declarative Services or a BundleActivator.
>
> - To run the sample webapp:
>
> cd wicketstuff-core/jdk-1.5-**parent/wicket-osgi-parent
> cd wicket-osgi-test-web
> mvn install pax:run
> Open http://localhost:8080/library in your browser.
>
> - To use wicket-osgi in your own projects, have a look at web.xml and
> LibraryApplication.java in wicket-osgi-test-web, and at the Javadoc in
> wicket-osgi.
>
> All of this is anything but final... Have a look at the code, give it a try
> and let me know that you think.
>
> Thanks,
> Harald
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket and OSGi
Posted by Harald Wellmann <ha...@gmx.de>.
There is now a new module wicket-osgi in wicketstuff/core at Github with
some glue code to adapt Wicket to OSGi house rules.
Summary:
- wicket-osgi supports bootstrapping a WicketApplication from the OSGi
service registry, matching a property value specified as a WicketFilter
init parameter in web.xml.
- OsgiClassResolver supports Wicket page deserialization.
- OsgiComponentInjector lets you inject OSGi services into WIcket
components by annotating fields with JSR-330 @Inject.
- wicket-bundle, the all-in-one OSGi-compliant packaging of Wicket, now
has a revised manifest without dynamic imports.
- wicket-ioc-bundle (sibling of wicket-bundle) does the same for
wicket-ioc, which is required by wicket-osgi.
- wicket-osgi-test-web and wicket-osgi-test-service are two simple test
bundles for testing the glue code in an OSGi web container (Pax Web).
The sample uses Aries Blueprint to interact with the service registry,
but of course you can also use Declarative Services or a BundleActivator.
- To run the sample webapp:
cd wicketstuff-core/jdk-1.5-parent/wicket-osgi-parent
cd wicket-osgi-test-web
mvn install pax:run
Open http://localhost:8080/library in your browser.
- To use wicket-osgi in your own projects, have a look at web.xml and
LibraryApplication.java in wicket-osgi-test-web, and at the Javadoc in
wicket-osgi.
All of this is anything but final... Have a look at the code, give it a
try and let me know that you think.
Thanks,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Harald Wellmann <ha...@gmx.de>.
Hi Mike,
Am 26.06.2011 05:06, schrieb Michael O'Cleirigh:
> Hi Harald,
>
> Thanks for taking the time to implement your solution to the OSGi problem.
>
> If you could create a patch (or fork and then pull request; or commit
> directly) into the
> https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/wicket-bundle-parent
> module that would be ideal. I can't tell if it should be integrated into
> the existing wicket-bundle or beside it as a new module (You can decide).
>
Thanks for inviting me to commit. I think a new module wicket-osgi is
required at least for the dependency injection stuff, because that
depends on wicket-ioc. Only the configuration for the manifest minus
DynamicImport-Package should go into wicket-bundle.
> If you need commit access just post to the dev list with your github
> username and we can add you.
>
Will do so. My username is hwellmann.
> Once your changes are committed into wicketstuff the jenkins server (it
> polls github @hourly) will build them into wicketstuff-core 1.5-SNAPSHOT
> jars and other osgi users could run it and their feedback could be
> captured as project issues.
>
> Would it be possible to have a wicket-bundle-example project that is
> configured to launch itself using osgi to exercise the capabilities of
> the module? Maybe the maven-pax-plugin be used to accomplish this?
>
> I think since most wicket users don't seem to use osgi (me included) if
> an example could be created that anyone could run the amount of feedback
> would be greater.
>
Yeah, I know - dealing with all the environment setup is really the
hardest part and will probably take longer than writing the glue code
itself, so my intention was just to publish some ideas and work in
progress to get some early feedback and make sure I'm not on the wrong
track.
Maven and Pax are great for batch builds and integration tests for OSGi
projects, but IMHO Eclipse PDE is much easier for developing and
debugging. Unfortunately, the two approaches don't integrate very well.
Anyway, I'm going to set up another example project which should be as
self-contained as possible, leaving out all the JPA/JTA stuff which is
not really relevant for the Wicket-OSGi integration (but then again, the
larger goal is of course to create some kind of lightweight OSGi
Enterprise software stack with persistence, transactions and Wicket on top.)
Regards,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Michael O'Cleirigh <mi...@rivulet.ca>.
Hi Harald,
Thanks for taking the time to implement your solution to the OSGi problem.
If you could create a patch (or fork and then pull request; or commit
directly) into the
https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/wicket-bundle-parent
module that would be ideal. I can't tell if it should be integrated
into the existing wicket-bundle or beside it as a new module (You can
decide).
If you need commit access just post to the dev list with your github
username and we can add you.
Once your changes are committed into wicketstuff the jenkins server (it
polls github @hourly) will build them into wicketstuff-core 1.5-SNAPSHOT
jars and other osgi users could run it and their feedback could be
captured as project issues.
Would it be possible to have a wicket-bundle-example project that is
configured to launch itself using osgi to exercise the capabilities of
the module? Maybe the maven-pax-plugin be used to accomplish this?
I think since most wicket users don't seem to use osgi (me included) if
an example could be created that anyone could run the amount of feedback
would be greater.
Regards,
Mike
> It would be easier to contribute feedback to your project as well as easier to promote upstream if you forked the wicket-stuff project on github and added your project there.
>
> On Jun 25, 2011, at 11:24 AM, Harald Wellmann wrote:
>
>> Am 23.06.2011 19:11, schrieb Harald Wellmann:
>>> 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.
>>>
>> Ok, here is my first shot at a solution. The IClassResolver using the client bundle class loader works as expected. OSGi service injection into Wicket components along the lines of wicket-spring is also working, as long as the required services are unique.
>>
>> All the details are explained in a Wiki page [1], and the glue code can be browsed online [2], or you can clone my sample repository from Google Code.
>>
>> Any feedback welcome!
>>
>> [1] http://code.google.com/p/osgi-enterprise/wiki/WicketAndOsgi
>> [2] http://code.google.com/p/osgi-enterprise/source/browse/?name=0.1.0#hg%2Faries-pde%2Fcom.googlecode.osgienterprise.wicket.osgi%2Fsrc%2Fcom%2Fgooglecode%2Fosgienterprise%2Fwicket
>>
>> Regards,
>> Harald
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Brian Topping <to...@codehaus.org>.
It would be easier to contribute feedback to your project as well as easier to promote upstream if you forked the wicket-stuff project on github and added your project there.
On Jun 25, 2011, at 11:24 AM, Harald Wellmann wrote:
> Am 23.06.2011 19:11, schrieb Harald Wellmann:
>>
>> 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.
>>
>
> Ok, here is my first shot at a solution. The IClassResolver using the client bundle class loader works as expected. OSGi service injection into Wicket components along the lines of wicket-spring is also working, as long as the required services are unique.
>
> All the details are explained in a Wiki page [1], and the glue code can be browsed online [2], or you can clone my sample repository from Google Code.
>
> Any feedback welcome!
>
> [1] http://code.google.com/p/osgi-enterprise/wiki/WicketAndOsgi
> [2] http://code.google.com/p/osgi-enterprise/source/browse/?name=0.1.0#hg%2Faries-pde%2Fcom.googlecode.osgienterprise.wicket.osgi%2Fsrc%2Fcom%2Fgooglecode%2Fosgienterprise%2Fwicket
>
> Regards,
> Harald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Harald Wellmann <ha...@gmx.de>.
Am 23.06.2011 19:11, schrieb Harald Wellmann:
>
> 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.
>
Ok, here is my first shot at a solution. The IClassResolver using the
client bundle class loader works as expected. OSGi service injection
into Wicket components along the lines of wicket-spring is also working,
as long as the required services are unique.
All the details are explained in a Wiki page [1], and the glue code can
be browsed online [2], or you can clone my sample repository from Google
Code.
Any feedback welcome!
[1] http://code.google.com/p/osgi-enterprise/wiki/WicketAndOsgi
[2]
http://code.google.com/p/osgi-enterprise/source/browse/?name=0.1.0#hg%2Faries-pde%2Fcom.googlecode.osgienterprise.wicket.osgi%2Fsrc%2Fcom%2Fgooglecode%2Fosgienterprise%2Fwicket
Regards,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Harald Wellmann <ha...@gmx.de>.
Am 23.06.2011 18:48, schrieb Igor Vaynberg:
> there is a jira issue with a patch.
That's probably the one that Martin mentioned:
https://issues.apache.org/jira/browse/WICKET-3737
> unfortunately someone has to build
> the "classloader" that can see all bundles.
>
> 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.
Thanks,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Igor Vaynberg <ig...@gmail.com>.
there is a jira issue with a patch. unfortunately someone has to build
the "classloader" that can see all bundles.
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.
-igor
On Wed, Jun 22, 2011 at 11:59 PM, Harald Wellmann
<ha...@gmx.de> wrote:
> Am 22.06.2011 22:00, schrieb Igor Vaynberg:
>>>
>>> If the page class in bundle A directly references the component class C
>>> from
>>> bundle B (and not just an interface or base class of B from another
>>> bundle
>>> X), then the bundle class loader of A can load class C by delegation.
>>
>>
>> not sure if that is true.
>>
>> given Wicket lives in bundle W
>> we have a component bundle C which provides component CommentPanel and
>> imports W
>> we have an application bundle P which provides page PostPage and imports W
>> and C
>>
>> someone does
>>
>> class PostPage extends page { PostPage() { add(new CommentPanel("c")); }}
>>
>> so PostPage has a reference to class CommentPanel from C
>> wicket serializes PostPage.
>> now wicket deserializes PostPage from disk. W classloader now needs to
>> load PostPage and CommentPanel, but it sees neither of those because
>> it doesnt import them.
>>
>
> You're right, W's classloader cannot see the class from P or C. But the
> thing is, when Wicket deserializes the page, it could use a derived
> ObjectInputStream and override resolveClass() to use the class resolver
> registered by the application.
>
> This resolver wraps the bundle class loader P of the application, which is
> able to load both PostPage and CommentPanel.
>
> Regards,
> Harald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Harald Wellmann <ha...@gmx.de>.
Am 22.06.2011 22:00, schrieb Igor Vaynberg:
>> If the page class in bundle A directly references the component class C from
>> bundle B (and not just an interface or base class of B from another bundle
>> X), then the bundle class loader of A can load class C by delegation.
>
>
> not sure if that is true.
>
> given Wicket lives in bundle W
> we have a component bundle C which provides component CommentPanel and imports W
> we have an application bundle P which provides page PostPage and imports W and C
>
> someone does
>
> class PostPage extends page { PostPage() { add(new CommentPanel("c")); }}
>
> so PostPage has a reference to class CommentPanel from C
> wicket serializes PostPage.
> now wicket deserializes PostPage from disk. W classloader now needs to
> load PostPage and CommentPanel, but it sees neither of those because
> it doesnt import them.
>
You're right, W's classloader cannot see the class from P or C. But the
thing is, when Wicket deserializes the page, it could use a derived
ObjectInputStream and override resolveClass() to use the class resolver
registered by the application.
This resolver wraps the bundle class loader P of the application, which
is able to load both PostPage and CommentPanel.
Regards,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Jun 22, 2011 at 12:02 PM, Harald Wellmann
<ha...@gmx.de> wrote:
> Am 22.06.2011 20:23, schrieb Igor Vaynberg:
>>
>> On Wed, Jun 22, 2011 at 10:57 AM, Harald Wellmann
>> <ha...@gmx.de> wrote:
>>>
>>> I'm currently trying to build an OSGi Enterprise stack using Wicket and
>>> Apache Aries, and I have a couple of questions and suggestions:
>>>
>>> 1) Why does the official Wicket artifact include a Dynamic-Import: *
>>> header? This should only be used as a last resort...
>>
>> because the OSGI spec does not handle serialization.
>>
>> wicket serializes a page that has a reference to component from bundle B
>> later, wicket deserializes the page, it needs to deserialize component
>> that came from bundle B so it needs access to the classloader from
>> bundle B.
>>
>
> If the page class in bundle A directly references the component class C from
> bundle B (and not just an interface or base class of B from another bundle
> X), then the bundle class loader of A can load class C by delegation.
not sure if that is true.
given Wicket lives in bundle W
we have a component bundle C which provides component CommentPanel and imports W
we have an application bundle P which provides page PostPage and imports W and C
someone does
class PostPage extends page { PostPage() { add(new CommentPanel("c")); }}
so PostPage has a reference to class CommentPanel from C
wicket serializes PostPage.
now wicket deserializes PostPage from disk. W classloader now needs to
load PostPage and CommentPanel, but it sees neither of those because
it doesnt import them.
at least this is my understanding of the osgi problem and why we need
dynamic-import for the wicket bundle.
-igor
>
> If C is not a component class but the type of a field in a component
> injected from the service layer (just like an EJB, but in this case it's an
> OSGi service obtained from the service registry), then you can replace the
> object by a reference, e.g. a service filter, on serialization and reinject
> the object on deserialization - isn't that just what wicket-ioc is doing?
>
> Regards,
> Harald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Harald Wellmann <ha...@gmx.de>.
Am 22.06.2011 20:23, schrieb Igor Vaynberg:
> On Wed, Jun 22, 2011 at 10:57 AM, Harald Wellmann
> <ha...@gmx.de> wrote:
>> I'm currently trying to build an OSGi Enterprise stack using Wicket and
>> Apache Aries, and I have a couple of questions and suggestions:
>>
>> 1) Why does the official Wicket artifact include a Dynamic-Import: *
>> header? This should only be used as a last resort...
>
> because the OSGI spec does not handle serialization.
>
> wicket serializes a page that has a reference to component from bundle B
> later, wicket deserializes the page, it needs to deserialize component
> that came from bundle B so it needs access to the classloader from
> bundle B.
>
If the page class in bundle A directly references the component class C
from bundle B (and not just an interface or base class of B from another
bundle X), then the bundle class loader of A can load class C by delegation.
If C is not a component class but the type of a field in a component
injected from the service layer (just like an EJB, but in this case it's
an OSGi service obtained from the service registry), then you can
replace the object by a reference, e.g. a service filter, on
serialization and reinject the object on deserialization - isn't that
just what wicket-ioc is doing?
Regards,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Jun 22, 2011 at 10:57 AM, Harald Wellmann
<ha...@gmx.de> wrote:
> I'm currently trying to build an OSGi Enterprise stack using Wicket and
> Apache Aries, and I have a couple of questions and suggestions:
>
> 1) Why does the official Wicket artifact include a Dynamic-Import: *
> header? This should only be used as a last resort...
because the OSGI spec does not handle serialization.
wicket serializes a page that has a reference to component from bundle B
later, wicket deserializes the page, it needs to deserialize component
that came from bundle B so it needs access to the classloader from
bundle B.
-igor
>
> 2) I'd like to @Inject OSGi services into Wicket components using an
> IComponentInstantiationListener - is there a ready-to-go extension I
> could use?
>
> 3) If not, would it be a good idea to create a wicket-osgi extension as
> part of Wicket or Wicketstuff?
>
> Regarding 1), I would assume that wrapping the bundle class loader
> of the user's application in an IClassResolver and registering it in
> Application.init() would do the trick, or doesn't it?
>
> As for 2) and 3), I wrote similar bridges both for CDI and Spring, building
> on wicket-ioc, so I do have an idea of what it takes, but of course I don't
> want to reinvent the wheel.
>
> Best regards,
> Harald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Harald Wellmann <ha...@gmx.de>.
Am 22.06.2011 20:18, schrieb Martin Grigorov:
>>
>> 1) Why does the official Wicket artifact include a Dynamic-Import: *
>> header? This should only be used as a last resort...
> https://issues.apache.org/jira/browse/WICKET-3737
Thanks, there's a lot of useful information in that ticket.
>>
>> 2) I'd like to @Inject OSGi services into Wicket components using an
>> IComponentInstantiationListener - is there a ready-to-go extension I
>> could use?
> Yes. See how wicket-spring and wicket-guice use wicket-ioc
> There is also wicket-javaee at
> https://github.com/wicketstuff/core/tree/master/jdk-1.6-parent/javaee-inject-parent
>>
Yeah I know, but Spring is not OSGi.
> what do you mean ? you re-wrote wicket-spting ? why ?
No of course I didn't. I adapted wicket-spring to use the standard
@Inject annotation instead of @SpringBean. I never use @Autowired or
other non-standard annotations when I can avoid it.
> also there is wicket-seam at github which integrates with CDI
>>
Seam is not CDI. wicket-seam has too many transitive dependencies on
stuff I don't need. I'm using a modified version of org.wamblee.cdi -
see
http://apache-wicket.1842946.n4.nabble.com/Wicket-and-JEE6-td1893912i40.html
Regards,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and OSGi
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Wed, Jun 22, 2011 at 8:57 PM, Harald Wellmann <ha...@gmx.de> wrote:
> I'm currently trying to build an OSGi Enterprise stack using Wicket and
> Apache Aries, and I have a couple of questions and suggestions:
>
> 1) Why does the official Wicket artifact include a Dynamic-Import: *
> header? This should only be used as a last resort...
https://issues.apache.org/jira/browse/WICKET-3737
>
> 2) I'd like to @Inject OSGi services into Wicket components using an
> IComponentInstantiationListener - is there a ready-to-go extension I
> could use?
Yes. See how wicket-spring and wicket-guice use wicket-ioc
There is also wicket-javaee at
https://github.com/wicketstuff/core/tree/master/jdk-1.6-parent/javaee-inject-parent
>
> 3) If not, would it be a good idea to create a wicket-osgi extension as
> part of Wicket or Wicketstuff?
https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/wicket-bundle-parent
>
> Regarding 1), I would assume that wrapping the bundle class loader
> of the user's application in an IClassResolver and registering it in
> Application.init() would do the trick, or doesn't it?
>
> As for 2) and 3), I wrote similar bridges both for CDI and Spring, building
> on wicket-ioc, so I do have an idea of what it takes, but of course I don't
> want to reinvent the wheel.
what do you mean ? you re-wrote wicket-spting ? why ?
also there is wicket-seam at github which integrates with CDI
>
> Best regards,
> Harald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org