On Wed, Jun 22, 2011 at 12:02 PM, Harald Wellmann
<harald.wellm...@gmx.de> wrote:
> Am 22.06.2011 20:23, schrieb Igor Vaynberg:
>>
>> On Wed, Jun 22, 2011 at 10:57 AM, Harald Wellmann
>> <harald.wellm...@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-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to