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
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.
https://issues.apache.org/jira/browse/WICKET-6509
<https://issues.apache.org/jira/bro
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
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
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
:)
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
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
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
kiralyattila...@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 harald.wellm...@gmx.de
There is now a new module wicket-osgi in wicketstuff/core at Github with
some glue
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
-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
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
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
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 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
, 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
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
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
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
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
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
: *
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
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
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
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
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,
Hi,
I register a wicket application in an OSGi http service using for that
a WicketServlet with applicationClassName set to the name of my main
application class. My problem now is that I don't know how to serve
static files as CSS and so.
Is there any place used by default to contain the static
I see two options:
1-Use Wicket default machinery for serving resources (see
IResourceSettings).
2-Mount a dedicated servlet: the same way you register wicket servlet.
Ernesto
On Wed, Mar 24, 2010 at 12:19 PM, Jaime Soriano Pastor
jsorianopas...@gmail.com wrote:
Hi,
I register a wicket
Put then in the top-level directory of a web module.
http://java.sun.com/javaee/5/docs/tutorial/doc/bnadx.html#bnadz
A web module has a specific structure. The top-level directory of a web
module is the *document root* of the application. The document root is where
JSP pages, *client-side*
*document root* on an OSGI environment?
Ernesto
On Wed, Mar 24, 2010 at 12:46 PM, Pedro Santos pedros...@gmail.com wrote:
Put then in the top-level directory of a web module.
http://java.sun.com/javaee/5/docs/tutorial/doc/bnadx.html#bnadz
A web module has a specific structure. The
On Wed, Mar 24, 2010 at 12:57 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
*document root* on an OSGI environment?
Yes, it's what I was just trying and it worked :)
Many thanks!
-
To unsubscribe, e-mail:
Are you using bridge servlet approach?
On Wed, Mar 24, 2010 at 12:59 PM, Jaime Soriano Pastor
jsorianopas...@gmail.com wrote:
On Wed, Mar 24, 2010 at 12:57 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
*document root* on an OSGI environment?
Yes, it's what I was just trying and
On Wed, Mar 24, 2010 at 1:05 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Are you using bridge servlet approach?
I don't think so... Is it needed to have several Servlets? I have only one.
What I do is to launch Apache Felix Http Jetty as implementation of
the OSGi HTTP service and
Interesting but that is not the same as a document root as in mentioned
link. Isn't it? So, your document root is the root of the class-path?
Best,
Ernesto
On Wed, Mar 24, 2010 at 1:18 PM, Jaime Soriano Pastor
jsorianopas...@gmail.com wrote:
On Wed, Mar 24, 2010 at 1:05 PM, Ernesto Reinaldo
Hi,
I have tried this with equinox and it works too. For instance I'm able to
read file
http://localhost:8080/hibernate.cfg.xml
which is on root of the class path. They are just served by
WicketServlet.fallback method.
Ernesto
On Wed, Mar 24, 2010 at 1:24 PM, Ernesto Reinaldo Barreiro
But it won't work if you mount the Servlet to something different than /.
E.g. mounting on /manager then
http://localhost:8080/manager/hibernate.cfg.xml
will not work. Just curious about what are the implications of mounting on
/ and what the OSGi specification says about this?
Ernesto
On Wed,
Weird, I have also tried to register the application on /foo instead
of on / and, as you said, I cannot access to static files.
I haven't seen anything special about root alias on OSGi specification
(only that is the only alias allowed to end with /)
Jaime.
Haven't had time to check the specification but this behavior (mounting on
/) might pose a security risk as you can fetch invisible things form the
class path (e.g. configuration files containing sensitive information like
passwords). On the other hand I see HttpService class has a
On Wed, Mar 24, 2010 at 3:08 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Haven't had time to check the specification but this behavior (mounting on
/) might pose a security risk as you can fetch invisible things form the
class path (e.g. configuration files containing sensitive
57 matches
Mail list logo
