Investigated the issue, the fix provided in
https://issues.apache.org/jira/browse/WICKET-6509 is not resolving the
problem.
Still In the generated manifest file the packages are present as it is
previously with out resolution : optional
Instead of setting the resolution:optional in the
Is this issue has been tested successfully by its reporter. Did i miss
anything?
We are using junit : 4.12, on bundle start getting the BundleException
Unresolved constraint in bundle org.apache.wicket.core [34]: Unable to
resolve 34.0: missing requirement [34.0] osgi.wiring.package;
Hi,
On Tue, Aug 21, 2018 at 12:13 PM SUBRA wrote:
> HI,
>
> I'm migrating to wicket-8, getting osgi wiring problem with junit framework
> osgi.wiring.package=junit.framework
>
> Jira issue, created with similar issue, is in resolved state but
> apparently
> it is not.
>
This issue has been
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
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
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
Hey Martin,
On Mon, Jul 4, 2011 at 10:24 PM, Martin Grigorov mgrigo...@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
Hey Harald,
On Mon, Jul 4, 2011 at 10:47 PM, Harald Wellmann harald.wellm...@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
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
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
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
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 harald.wellm...@gmx.de
There is now a new module wicket-osgi in wicketstuff/core at Github with
some glue code to adapt Wicket to OSGi
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
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
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
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
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
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
On Fri, Jun 24, 2011 at 2:41 AM, Igor Vaynberg igor.vaynb...@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
On Thu, Jun 23, 2011 at 11:09 PM, Martin Grigorov mgrigo...@apache.org wrote:
On Fri, Jun 24, 2011 at 2:41 AM, Igor Vaynberg igor.vaynb...@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
On Thu, Jun 23, 2011 at 11:30 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
On Thu, Jun 23, 2011 at 11:09 PM, Martin Grigorov mgrigo...@apache.org
wrote:
On Fri, Jun 24, 2011 at 2:41 AM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
something else to consider - where this gets even
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
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
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. :-)
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 wic...@leangen.net wrote:
IIUC, other frameworks allow for the injection of a classloader. Wouldn't
that be enough?
We could then
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
OsgiClassResolver will be in wicket-bundle.jar (the one in wicketstuff).
The user application will use it by:
MyApp#init() {
super.init();
getApplicationSettings.setClassResolver(new OsgiClassResolver());
}
On Fri, Jun 24, 2011 at 10:46 AM, Brian Topping topp...@codehaus.org wrote:
If by
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
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
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.
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
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
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 harald.wellm...@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
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
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
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
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
Hi,
On Wed, Jun 22, 2011 at 8:57 PM, 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: *
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?
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
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
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,
42 matches
Mail list logo
