Wicket and OSGi

[hwellmann]

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: [hidden email]
For additional commands, e-mail: [hidden email]

[Martin Grigorov-4]

Hi,

On Wed, Jun 22, 2011 at 8:57 PM, Harald Wellmann <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Igor Vaynberg-2]

On Wed, Jun 22, 2011 at 10:57 AM, Harald Wellmann
<[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[hwellmann]

Am 22.06.2011 20:23, schrieb Igor Vaynberg:

> On Wed, Jun 22, 2011 at 10:57 AM, Harald Wellmann
> <[hidden email]>  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: [hidden email]
For additional commands, e-mail: [hidden email]

[hwellmann]

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: [hidden email]
For additional commands, e-mail: [hidden email]

[Igor Vaynberg-2]

On Wed, Jun 22, 2011 at 12:02 PM, Harald Wellmann
<[hidden email]> wrote:

> Am 22.06.2011 20:23, schrieb Igor Vaynberg:
>>
>> On Wed, Jun 22, 2011 at 10:57 AM, Harald Wellmann
>> <[hidden email]>  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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[hwellmann]

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: [hidden email]
For additional commands, e-mail: [hidden email]

[Igor Vaynberg-2]

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
<[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[hwellmann]

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: [hidden email]
For additional commands, e-mail: [hidden email]

[Martin Grigorov-4]

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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Brian Topping]

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: [hidden email]
For additional commands, e-mail: [hidden email]

[Igor Vaynberg-2]

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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Brian Topping]

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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Igor Vaynberg-2]

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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Martin Grigorov-4]

On Fri, Jun 24, 2011 at 2:41 AM, Igor Vaynberg <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Igor Vaynberg-2]

On Thu, Jun 23, 2011 at 11:09 PM, Martin Grigorov <[hidden email]> wrote:

> On Fri, Jun 24, 2011 at 2:41 AM, Igor Vaynberg <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Igor Vaynberg-2]

On Thu, Jun 23, 2011 at 11:30 PM, Igor Vaynberg <[hidden email]> wrote:

> On Thu, Jun 23, 2011 at 11:09 PM, Martin Grigorov <[hidden email]> wrote:
>> On Fri, Jun 24, 2011 at 2:41 AM, Igor Vaynberg <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Brian Topping]

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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[David Leangen-8]

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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Brian Topping]

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: [hidden email]
For additional commands, e-mail: [hidden email]