Re: [osgi] package org.apache.wicket.request exported either from core and request packages
Op 27 apr 2011, om 09:43 heeft Daniele Dellafiore het volgende geschreven: This is also my main point to conversation. We're talking about being somewhere really close to a nice out of the box OSGi support. Why not take a little effort to make it complete? Also, having packages that span through different jars is not really good to me, OSGi or not. Anyway, Daan, I'm really interested in the classloading problem you had. Actually I did succeed in making a wicket-spring webapp start and work 100%. But after the wicket package is reinstalled or just refreshed in the container, @SpringBean injection stop working with: My colleague created a JIRA ticket with an elaborate description of the problem. There's also a patch included. https://issues.apache.org/jira/browse/WICKET-3737 Regards, Daan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
A quick look in the patch shows two code duplications but otherwise looks OK. I'd like to ask other OSGi users to take a look as well and add a comment. On Tue, May 24, 2011 at 12:23 PM, Daan van Etten d...@stuq.nl wrote: Op 27 apr 2011, om 09:43 heeft Daniele Dellafiore het volgende geschreven: This is also my main point to conversation. We're talking about being somewhere really close to a nice out of the box OSGi support. Why not take a little effort to make it complete? Also, having packages that span through different jars is not really good to me, OSGi or not. Anyway, Daan, I'm really interested in the classloading problem you had. Actually I did succeed in making a wicket-spring webapp start and work 100%. But after the wicket package is reinstalled or just refreshed in the container, @SpringBean injection stop working with: My colleague created a JIRA ticket with an elaborate description of the problem. There's also a patch included. https://issues.apache.org/jira/browse/WICKET-3737 Regards, Daan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
its too late to be doing this for 1.5. i agree we should not have package namespaces split across the jars, but fixing it in 1.5 would touch almost every single file and a lot of user code would be broken as a result. a good example is IDetachable which is in wicket-util but i left it in the wicket package instead of wicket.util. moving that class into util would touch around 90% of core code, and about 90% of user code. lets save this change for 1.6. we tried to create the uber jar but it failed. maybe if we used something like gradle we couldve done it, but switching build systems just for this seems a little extreme. what the proponents of osgi should do is create a jira issue, targetted for 1.6 and start outlining all the changes we need to do to make using wicket in osgi easier. we will do our best to make them as long as they do not impact the framework too much. -igor On Wed, Apr 27, 2011 at 1:42 AM, Martin Grigorov mgrigo...@apache.org wrote: On Wed, Apr 27, 2011 at 11:19 AM, Daniele Dellafiore dani...@dellafiore.net wrote: On Wed, Apr 27, 2011 at 8:57 AM, Martin Grigorov mgrigo...@apache.orgwrote: I'm not against improving the current state. I'm saying that it want last long without your help. I said several times that the community can create the uber-jar project in wicketstuff but so far no one wanted to do it. I can do it for you but I wont test it in a real OSGi container. I'm just not interested in this. But we can apply your patches if they are reasonable. Let's try. As I told, the first move is to rename into .core.util and .core.request the packages in -core bundle. This is reasonable? If it is not, well, I'll go for a issue for 1.6 and move totally on the uber-jar solution. If it is reasonable, we can proceed. You said that broke some tests in your local build. See what are the problems. Create a ticket and attach patches. It will be easier to review this way. About testing - I don't see how unit tests will help to keep it working in the future. Any ideas/patches on this matter are welcome! Eh, this can totally be done with pax-runner, as integration tests, but I've not enough experience with this so far. My concerns are that we had similar issue with Portlets support. When we ran the vote whether to remove the support for Wicket 1.5 few people (~ 5) asked to move the related code in wicketstuff so the community can support it. Half an year later no one touched it so far. This is totally reasonable. Let's see which way we can take here. Regards. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - 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
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
On Tue, Apr 26, 2011 at 9:12 PM, Daan van Etten d...@stuq.nl wrote: Op 26 apr 2011, om 16:41 heeft Martin Grigorov het volgende geschreven: Not doing anything now because it can break in the future is not a really good argument..? Anything can break, that's why there are unit tests, release candidates, etcetera. With some small design improvements (no split packages, 'better' jar(s)) and a better manifest the 'Wicket OSGI support' will surpass many other frameworks or libraries. This is also my main point to conversation. We're talking about being somewhere really close to a nice out of the box OSGi support. Why not take a little effort to make it complete? Also, having packages that span through different jars is not really good to me, OSGi or not. Anyway, Daan, I'm really interested in the classloading problem you had. Actually I did succeed in making a wicket-spring webapp start and work 100%. But after the wicket package is reinstalled or just refreshed in the container, @SpringBean injection stop working with: java.lang.IllegalArgumentException: Can not set org.fenotipi.services.StudiService field org.fenotipi.web.general.HomePage.studiService to org.apache.wicket.proxy.$Proxy40 Any idea?
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
On Tue, Apr 26, 2011 at 11:48 PM, Eike Kettner n...@eknet.org wrote: Hi Daniele, This is not as bad as having to package the uber-jar with the war, sure. Better than keeping a separate wicket codebase, at least :) Anyway it's still a custom solution that I, and all wicket developers, have to do. More over, they have to discover that this has to be done, that wicket bundles are working bundles, but not usable. Wicket bundles are some sort of raw jars+metadata that can be assemled in a custom way to become a usable OSGI bundle. Whatever you consider the uber-jar solution to go good or not, this is a flaw. I totally agree with you. Wicket is such a great web framework and people who like to use it with osgi shouldn't have a hard time to get both workgin together. The fact that the three wicket modules have osgi related meta data but don't work as osgi bundles is really confusing. So a distributed uber-jar would be a quick fix for that. People can easily deploy wicket to an osgi container.f a day in thread like this to finally arrive to the wicket-stuff projects that solves your problem. Yeah but you know how things really works. You download/maven/something-else the wicket jars. They do not work in osgi. Then you start google around, it will take you hours, reading conversation like this one, before eventually landing to the wicket-stuff page where there is the solution. If that's the case. You will be not happy. Of course I can accept the wicket is not intended to be OSGi compliant explanation and go for the uber-jar in wicket-stuff. Maybe I want to ask: why wicket can't be OSGi compliant? I consider OSGi to be an important reference platform nowadays. Let's fill a jira issue and see what happen. I agree that you have to use -util -request and -core to make wicket work, but so, if they are so coupled, why to make different bundles at all? Alexandros already asked for this.You say modularization helps wicket developer.I would agree but what is the difference between the .request and .util package in -request, -util and in -core? As Martin pointed out, there are no more implementation of wicket, to date. So the -core is not a specific implementation of -request and -util. Maybe just more concret classes? Again I think that the package that span across different modules is a flawed design. For sure it is not OSGi-compliant. Again I agree with you. The uber jar is good to get wicket quickly running with osgi, but it is more a workaround. I'm not deep in wicket code, but it feels awkward to first package classes in one package and than split this package across modules (which is even harder grained). To me seems like that the split of .util and .request package into separate bundles is just not complete. This is totally understandable. I'm not seeing the point of splitting those two packages that, indeed, are always necessary to run a wicket app, but sure I do not have enough insight view of the project. Despite that, it took ten minutes straight to me to renamce -core packages into .wicket.util and .wicket.request and fix the confusion. Indeed, mvn test now fails in -core, I did not take any care of those in my tentative.
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
Hi, On Wed, Apr 27, 2011 at 10:43 AM, Daniele Dellafiore dani...@dellafiore.net wrote: On Tue, Apr 26, 2011 at 9:12 PM, Daan van Etten d...@stuq.nl wrote: Op 26 apr 2011, om 16:41 heeft Martin Grigorov het volgende geschreven: Not doing anything now because it can break in the future is not a really good argument..? Anything can break, that's why there are unit tests, release candidates, etcetera. With some small design improvements (no split packages, 'better' jar(s)) and a better manifest the 'Wicket OSGI support' will surpass many other frameworks or libraries. This is also my main point to conversation. We're talking about being somewhere really close to a nice out of the box OSGi support. Why not take a little effort to make it complete? Also, having packages that span through different jars is not really good to me, OSGi or not. I'm not against improving the current state. I'm saying that it want last long without your help. I said several times that the community can create the uber-jar project in wicketstuff but so far no one wanted to do it. I can do it for you but I wont test it in a real OSGi container. I'm just not interested in this. But we can apply your patches if they are reasonable. About testing - I don't see how unit tests will help to keep it working in the future. Any ideas/patches on this matter are welcome! My concerns are that we had similar issue with Portlets support. When we ran the vote whether to remove the support for Wicket 1.5 few people (~ 5) asked to move the related code in wicketstuff so the community can support it. Half an year later no one touched it so far. Anyway, Daan, I'm really interested in the classloading problem you had. Actually I did succeed in making a wicket-spring webapp start and work 100%. But after the wicket package is reinstalled or just refreshed in the container, @SpringBean injection stop working with: java.lang.IllegalArgumentException: Can not set org.fenotipi.services.StudiService field org.fenotipi.web.general.HomePage.studiService to org.apache.wicket.proxy.$Proxy40 Any idea? -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
On Wed, Apr 27, 2011 at 8:57 AM, Martin Grigorov mgrigo...@apache.orgwrote: I'm not against improving the current state. I'm saying that it want last long without your help. I said several times that the community can create the uber-jar project in wicketstuff but so far no one wanted to do it. I can do it for you but I wont test it in a real OSGi container. I'm just not interested in this. But we can apply your patches if they are reasonable. Let's try. As I told, the first move is to rename into .core.util and .core.request the packages in -core bundle. This is reasonable? If it is not, well, I'll go for a issue for 1.6 and move totally on the uber-jar solution. If it is reasonable, we can proceed. About testing - I don't see how unit tests will help to keep it working in the future. Any ideas/patches on this matter are welcome! Eh, this can totally be done with pax-runner, as integration tests, but I've not enough experience with this so far. My concerns are that we had similar issue with Portlets support. When we ran the vote whether to remove the support for Wicket 1.5 few people (~ 5) asked to move the related code in wicketstuff so the community can support it. Half an year later no one touched it so far. This is totally reasonable. Let's see which way we can take here. Regards.
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
On Wed, Apr 27, 2011 at 11:19 AM, Daniele Dellafiore dani...@dellafiore.net wrote: On Wed, Apr 27, 2011 at 8:57 AM, Martin Grigorov mgrigo...@apache.orgwrote: I'm not against improving the current state. I'm saying that it want last long without your help. I said several times that the community can create the uber-jar project in wicketstuff but so far no one wanted to do it. I can do it for you but I wont test it in a real OSGi container. I'm just not interested in this. But we can apply your patches if they are reasonable. Let's try. As I told, the first move is to rename into .core.util and .core.request the packages in -core bundle. This is reasonable? If it is not, well, I'll go for a issue for 1.6 and move totally on the uber-jar solution. If it is reasonable, we can proceed. You said that broke some tests in your local build. See what are the problems. Create a ticket and attach patches. It will be easier to review this way. About testing - I don't see how unit tests will help to keep it working in the future. Any ideas/patches on this matter are welcome! Eh, this can totally be done with pax-runner, as integration tests, but I've not enough experience with this so far. My concerns are that we had similar issue with Portlets support. When we ran the vote whether to remove the support for Wicket 1.5 few people (~ 5) asked to move the related code in wicketstuff so the community can support it. Half an year later no one touched it so far. This is totally reasonable. Let's see which way we can take here. Regards. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
the uber-jar is only concerning wicket, not any war bundle. while it would be of course nicer to have all wicket jars as separate bundles available out of the box. but one solution I find quite ok is creating one bundle out of core, request and util. this will then be a uber-jar that brings wicket into the osgi mix. It's just containing the core packages of wicket. I think the different jars help the wicket developers to cleaner dependencies (when creating a class the dependencies make you think about where to put it, so you don't create a RequestClass in the core package/module, for example) -- please correct me if this is wrong. But from the client or user point of view, the jars wicket-core,util and request are all kind of core modules. You'll need them all (I think) to use wicket. this makes it in my opinion ok to use the one big wicket jar. all others (auth-roles etc) are still separate bundles. regards Eike On [Mon, 25.04.2011 19:08], Daniele Dellafiore wrote: Are you referring to this conversation? http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-rc2-and-aggregate-jar-for-osgi-td3356667.html If so, I read it and answered that I'm not interested in any solution that involves the uber-jar. I do not see any advantage in that solution over a normal war. I do not find any other advice from you and Eike, maybe you can point me out the right conversation. On Mon, Apr 25, 2011 at 6:25 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi Daniele, Me and later Eike explained to you in the other thread you started few months ago how to solve exactly this problem. It seems you didn't read it at all. Please read again the part mentioning Wicket 1.5 RC1. On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore dani...@dellafiore.net wrote: I did it. Yes, the tough way but I did it. Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the 1.5-SNAPSHOT I built. Basically I renamed the .util and .request packages in -core bundle to be .core.util and .core.request. I had to make a class public in another package under -request bundle to make it visible, but it's a minor thing. I open a bug on jira now... wow, is down :) well, as soon as it get back online. On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore dani...@dellafiore.netwrote: it is not. I'm hacking on the trunk to make that work. Maybe a quick solution is just change org.apache.wicket to org.apache.wicket.core in the -core bundle. Of course there are some default scope classes that works through different packages but I can just make them public for now. On Mon, Apr 25, 2011 at 3:18 PM, James Carman ja...@carmanconsulting.comwrote: On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com wrote: I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. From an OSGi perspective, we should probably try to make sure that packages don't span jar files. Everything in org.apache,wicket.request should be in wicket-request.jar, for example. I don't know if that's the case, currently or not. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
On Tue, Apr 26, 2011 at 1:48 PM, Eike Kettner e...@eknet.org wrote: the uber-jar is only concerning wicket, not any war bundle. while it would be of course nicer to have all wicket jars as separate bundles available out of the box. but one solution I find quite ok is creating one bundle out of core, request and util. this will then be a uber-jar that brings wicket into the osgi mix. It's just containing the core packages of wicket. I think the different jars help the wicket developers to cleaner dependencies (when creating a class the dependencies make you think about where to put it, so you don't create a RequestClass in the core package/module, for example) -- please correct me if this is wrong. Correct. This was discussed recently in another thread. But from the client or user point of view, the jars wicket-core,util and request are all kind of core modules. You'll need them all (I think) to use wicket. this makes it in my opinion ok to use the one big wicket jar. all others (auth-roles etc) are still separate bundles. Again correct. regards Eike Stay tuned. On [Mon, 25.04.2011 19:08], Daniele Dellafiore wrote: Are you referring to this conversation? http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-rc2-and-aggregate-jar-for-osgi-td3356667.html If so, I read it and answered that I'm not interested in any solution that involves the uber-jar. I do not see any advantage in that solution over a normal war. I do not find any other advice from you and Eike, maybe you can point me out the right conversation. On Mon, Apr 25, 2011 at 6:25 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi Daniele, Me and later Eike explained to you in the other thread you started few months ago how to solve exactly this problem. It seems you didn't read it at all. Please read again the part mentioning Wicket 1.5 RC1. On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore dani...@dellafiore.net wrote: I did it. Yes, the tough way but I did it. Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the 1.5-SNAPSHOT I built. Basically I renamed the .util and .request packages in -core bundle to be .core.util and .core.request. I had to make a class public in another package under -request bundle to make it visible, but it's a minor thing. I open a bug on jira now... wow, is down :) well, as soon as it get back online. On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore dani...@dellafiore.netwrote: it is not. I'm hacking on the trunk to make that work. Maybe a quick solution is just change org.apache.wicket to org.apache.wicket.core in the -core bundle. Of course there are some default scope classes that works through different packages but I can just make them public for now. On Mon, Apr 25, 2011 at 3:18 PM, James Carman ja...@carmanconsulting.comwrote: On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com wrote: I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. From an OSGi perspective, we should probably try to make sure that packages don't span jar files. Everything in org.apache,wicket.request should be in wicket-request.jar, for example. I don't know if that's the case, currently or not. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner e...@eknet.org wrote: the uber-jar is only concerning wicket, not any war bundle. while it would be of course nicer to have all wicket jars as separate bundles available out of the box. but one solution I find quite ok is creating one bundle out of core, request and util. this will then be a uber-jar that brings wicket into the osgi mix. It's just containing the core packages of wicket. I think the different jars help the wicket developers to cleaner dependencies (when creating a class the dependencies make you think about where to put it, so you don't create a RequestClass in the core package/module, for example) -- please correct me if this is wrong. But from the client or user point of view, the jars wicket-core,util and request are all kind of core modules. You'll need them all (I think) to use wicket. this makes it in my opinion ok to use the one big wicket jar. all others (auth-roles etc) are still separate bundles. regards Eike This is not as bad as having to package the uber-jar with the war, sure. Better than keeping a separate wicket codebase, at least :) Anyway it's still a custom solution that I, and all wicket developers, have to do. More over, they have to discover that this has to be done, that wicket bundles are working bundles, but not usable. Wicket bundles are some sort of raw jars+metadata that can be assemled in a custom way to become a usable OSGI bundle. Whatever you consider the uber-jar solution to go good or not, this is a flaw. I agree that you have to use -util -request and -core to make wicket work, but so, if they are so coupled, why to make different bundles at all? Alexandros already asked for this.You say modularization helps wicket developer.I would agree but what is the difference between the .request and .util package in -request, -util and in -core? As Martin pointed out, there are no more implementation of wicket, to date. So the -core is not a specific implementation of -request and -util. Maybe just more concret classes? Again I think that the package that span across different modules is a flawed design. For sure it is not OSGi-compliant. I do not want to bother more, anyway. I'll go for the uber-jar with wicket 1.5. I'll open an issue to fix this flaw so maybe wicket 1.6 will work out of the box in OSGi.
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
Hi Danielle, On Tue, Apr 26, 2011 at 2:19 PM, Daniele Dellafiore dani...@dellafiore.net wrote: On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner e...@eknet.org wrote: the uber-jar is only concerning wicket, not any war bundle. while it would be of course nicer to have all wicket jars as separate bundles available out of the box. but one solution I find quite ok is creating one bundle out of core, request and util. this will then be a uber-jar that brings wicket into the osgi mix. It's just containing the core packages of wicket. I think the different jars help the wicket developers to cleaner dependencies (when creating a class the dependencies make you think about where to put it, so you don't create a RequestClass in the core package/module, for example) -- please correct me if this is wrong. But from the client or user point of view, the jars wicket-core,util and request are all kind of core modules. You'll need them all (I think) to use wicket. this makes it in my opinion ok to use the one big wicket jar. all others (auth-roles etc) are still separate bundles. regards Eike This is not as bad as having to package the uber-jar with the war, sure. Better than keeping a separate wicket codebase, at least :) Anyway it's still a custom solution that I, and all wicket developers, have to do. More over, they have to discover that this has to be done, that wicket bundles are working bundles, but not usable. Wicket bundles are some sort of raw jars+metadata that can be assemled in a custom way to become a usable OSGI bundle. Whatever you consider the uber-jar solution to go good or not, this is a flaw. Wicket is not OSGi complaint and it has never been built with OSGi in mind. You and Eike are the only users of OSGi that I know by name. Few years ago someone asked for better OSGi support in Wicket and the special entries in MANIFEST.MF were introduced with the help of bnd plugin. That's all Wicket ever supported explicitly for OSGi. I also remember that the same people used PAX-Wicket quite successfully. About I, and all wicket developers, have to do - I said it several times: WicketStuff is a community project. The OSGi users can create a new sub-project, e.g. wicket-osgi, which will pack -util, -request and -core in one. It will be automatically deployed in Maven repos. Let me know if you need help with this project if you want to create/maintain it. I agree that you have to use -util -request and -core to make wicket work, but so, if they are so coupled, why to make different bundles at all? Alexandros already asked for this.You say modularization helps wicket developer.I would agree but what is the difference between the .request and .util package in -request, -util and in -core? As Martin pointed out, there are no more implementation of wicket, to date. So the -core is not a specific implementation of -request and -util. Maybe just more concret classes? Again I think that the package that span across different modules is a flawed design. For sure it is not OSGi-compliant. I do not want to bother more, anyway. I'll go for the uber-jar with wicket 1.5. I'll open an issue to fix this flaw so maybe wicket 1.6 will work out of the box in OSGi. See my concerns related to Portlets in my previous mail. If there are just a few OSGi users out there and none of the core developers uses OSGi then the support for OSGi can and will break at any time in the future. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
Op 26 apr 2011, om 16:41 heeft Martin Grigorov het volgende geschreven: [..] Wicket bundles are some sort of raw jars+metadata that can be assemled in a custom way to become a usable OSGI bundle. Whatever you consider the uber-jar solution to go good or not, this is a flaw. Wicket is not OSGi complaint and it has never been built with OSGi in mind. You and Eike are the only users of OSGi that I know by name. If you don't know them, that doesn't mean they don't exist :-) We're also using OSGI with Wicket. We've made some changes to fix class loading issues and we use all the Wicket jars separately, with a generated manifest that explicitly imports and exports the right packages. We still have to get around to clean up our changes and try to get them committed. One of my 'OSGI expert' colleagues wrote the stuff. I agree that you have to use -util -request and -core to make wicket work, but so, if they are so coupled, why to make different bundles at all? Alexandros already asked for this.You say modularization helps wicket developer.I would agree but what is the difference between the .request and .util package in -request, -util and in -core? As Martin pointed out, there are no more implementation of wicket, to date. So the -core is not a specific implementation of -request and -util. Maybe just more concret classes? Again I think that the package that span across different modules is a flawed design. For sure it is not OSGi-compliant. I do not want to bother more, anyway. I'll go for the uber-jar with wicket 1.5. I'll open an issue to fix this flaw so maybe wicket 1.6 will work out of the box in OSGi. It would be a nice step forward to not have packages split across different Wicket jars. Some OSGI containers trip over this. See my concerns related to Portlets in my previous mail. If there are just a few OSGi users out there and none of the core developers uses OSGi then the support for OSGi can and will break at any time in the future. Not doing anything now because it can break in the future is not a really good argument..? Anything can break, that's why there are unit tests, release candidates, etcetera. With some small design improvements (no split packages, 'better' jar(s)) and a better manifest the 'Wicket OSGI support' will surpass many other frameworks or libraries. BTW: to all the Wicket people: keep up the good work! Regards, Daan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
Hi Daniele, On [Tue, 26.04.2011 12:19], Daniele Dellafiore wrote: On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner e...@eknet.org wrote: the uber-jar is only concerning wicket, not any war bundle. while it would be of course nicer to have all wicket jars as separate bundles available out of the box. but one solution I find quite ok is creating one bundle out of core, request and util. this will then be a uber-jar that brings wicket into the osgi mix. It's just containing the core packages of wicket. I think the different jars help the wicket developers to cleaner dependencies (when creating a class the dependencies make you think about where to put it, so you don't create a RequestClass in the core package/module, for example) -- please correct me if this is wrong. But from the client or user point of view, the jars wicket-core,util and request are all kind of core modules. You'll need them all (I think) to use wicket. this makes it in my opinion ok to use the one big wicket jar. all others (auth-roles etc) are still separate bundles. regards Eike This is not as bad as having to package the uber-jar with the war, sure. Better than keeping a separate wicket codebase, at least :) Anyway it's still a custom solution that I, and all wicket developers, have to do. More over, they have to discover that this has to be done, that wicket bundles are working bundles, but not usable. Wicket bundles are some sort of raw jars+metadata that can be assemled in a custom way to become a usable OSGI bundle. Whatever you consider the uber-jar solution to go good or not, this is a flaw. I totally agree with you. Wicket is such a great web framework and people who like to use it with osgi shouldn't have a hard time to get both workgin together. The fact that the three wicket modules have osgi related meta data but don't work as osgi bundles is really confusing. So a distributed uber-jar would be a quick fix for that. People can easily deploy wicket to an osgi container. I agree that you have to use -util -request and -core to make wicket work, but so, if they are so coupled, why to make different bundles at all? Alexandros already asked for this.You say modularization helps wicket developer.I would agree but what is the difference between the .request and .util package in -request, -util and in -core? As Martin pointed out, there are no more implementation of wicket, to date. So the -core is not a specific implementation of -request and -util. Maybe just more concret classes? Again I think that the package that span across different modules is a flawed design. For sure it is not OSGi-compliant. Again I agree with you. The uber jar is good to get wicket quickly running with osgi, but it is more a workaround. I'm not deep in wicket code, but it feels awkward to first package classes in one package and than split this package across modules (which is even harder grained). A while ago I tried to create different package names per module using wicket-trunk codebase. But it was more work than it seemed. Many classes rely on package visibility (also many test classes) on packages that are split across modules. I think, this is an indication that those modules are tightly coupled as you said. It's probably not an easy task to decouple them. But imho something to think about. Then it shouldn't be a problem to have different package names per module, which will solve the osgi problem right away;) Just my opinion... I do not want to bother more, anyway. I'll go for the uber-jar with wicket 1.5. I'll open an issue to fix this flaw so maybe wicket 1.6 will work out of the box in OSGi. -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
I've solved this removing org.apache.wicket.request from Export-Package in wicket.core bundle jars. This works only because I'm not using request.ClientInfo class. Probablhy during runtime there will be other problems. From the OSGI perspective, having duplicate packages exported by different bundles is wrong. Should I fill a issue for this? On Mon, Apr 25, 2011 at 1:01 PM, Daniele Dellafiore ilde...@gmail.comwrote: Hi. Whe I try to start my wicket webapp from Karaf, I receive a NoClassFoundException agains Request. The problem is that my app imports the package org.apache.wicket.request from wicke.core bundle that have the package, but not the class. The fact that the same package is exported from two bundles really does not fit well in OSGI. Any possible solution? -- Daniele Dellafiore http://danieledellafiore.net -- Daniele Dellafiore http://danieledellafiore.net
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
Again, org.apache.wicket.IClusterable is in the -util bundle but the webapp looks for it in the -core bundle. There's not workaroiund for this. I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. On Mon, Apr 25, 2011 at 2:51 PM, Daniele Dellafiore ilde...@gmail.comwrote: I've solved this removing org.apache.wicket.request from Export-Package in wicket.core bundle jars. This works only because I'm not using request.ClientInfo class. Probablhy during runtime there will be other problems. From the OSGI perspective, having duplicate packages exported by different bundles is wrong. Should I fill a issue for this? On Mon, Apr 25, 2011 at 1:01 PM, Daniele Dellafiore ilde...@gmail.comwrote: Hi. Whe I try to start my wicket webapp from Karaf, I receive a NoClassFoundException agains Request. The problem is that my app imports the package org.apache.wicket.request from wicke.core bundle that have the package, but not the class. The fact that the same package is exported from two bundles really does not fit well in OSGI. Any possible solution? -- Daniele Dellafiore http://danieledellafiore.net -- Daniele Dellafiore http://danieledellafiore.net -- Daniele Dellafiore http://danieledellafiore.net
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com wrote: I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. From an OSGi perspective, we should probably try to make sure that packages don't span jar files. Everything in org.apache,wicket.request should be in wicket-request.jar, for example. I don't know if that's the case, currently or not. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
it is not. I'm hacking on the trunk to make that work. Maybe a quick solution is just change org.apache.wicket to org.apache.wicket.core in the -core bundle. Of course there are some default scope classes that works through different packages but I can just make them public for now. On Mon, Apr 25, 2011 at 3:18 PM, James Carman ja...@carmanconsulting.comwrote: On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com wrote: I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. From an OSGi perspective, we should probably try to make sure that packages don't span jar files. Everything in org.apache,wicket.request should be in wicket-request.jar, for example. I don't know if that's the case, currently or not. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
I did it. Yes, the tough way but I did it. Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the 1.5-SNAPSHOT I built. Basically I renamed the .util and .request packages in -core bundle to be .core.util and .core.request. I had to make a class public in another package under -request bundle to make it visible, but it's a minor thing. I open a bug on jira now... wow, is down :) well, as soon as it get back online. On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore dani...@dellafiore.netwrote: it is not. I'm hacking on the trunk to make that work. Maybe a quick solution is just change org.apache.wicket to org.apache.wicket.core in the -core bundle. Of course there are some default scope classes that works through different packages but I can just make them public for now. On Mon, Apr 25, 2011 at 3:18 PM, James Carman ja...@carmanconsulting.comwrote: On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com wrote: I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. From an OSGi perspective, we should probably try to make sure that packages don't span jar files. Everything in org.apache,wicket.request should be in wicket-request.jar, for example. I don't know if that's the case, currently or not. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
Hi Daniele, Me and later Eike explained to you in the other thread you started few months ago how to solve exactly this problem. It seems you didn't read it at all. Please read again the part mentioning Wicket 1.5 RC1. On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore dani...@dellafiore.net wrote: I did it. Yes, the tough way but I did it. Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the 1.5-SNAPSHOT I built. Basically I renamed the .util and .request packages in -core bundle to be .core.util and .core.request. I had to make a class public in another package under -request bundle to make it visible, but it's a minor thing. I open a bug on jira now... wow, is down :) well, as soon as it get back online. On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore dani...@dellafiore.netwrote: it is not. I'm hacking on the trunk to make that work. Maybe a quick solution is just change org.apache.wicket to org.apache.wicket.core in the -core bundle. Of course there are some default scope classes that works through different packages but I can just make them public for now. On Mon, Apr 25, 2011 at 3:18 PM, James Carman ja...@carmanconsulting.comwrote: On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com wrote: I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. From an OSGi perspective, we should probably try to make sure that packages don't span jar files. Everything in org.apache,wicket.request should be in wicket-request.jar, for example. I don't know if that's the case, currently or not. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
Are you referring to this conversation? http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-rc2-and-aggregate-jar-for-osgi-td3356667.html If so, I read it and answered that I'm not interested in any solution that involves the uber-jar. I do not see any advantage in that solution over a normal war. I do not find any other advice from you and Eike, maybe you can point me out the right conversation. On Mon, Apr 25, 2011 at 6:25 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi Daniele, Me and later Eike explained to you in the other thread you started few months ago how to solve exactly this problem. It seems you didn't read it at all. Please read again the part mentioning Wicket 1.5 RC1. On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore dani...@dellafiore.net wrote: I did it. Yes, the tough way but I did it. Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the 1.5-SNAPSHOT I built. Basically I renamed the .util and .request packages in -core bundle to be .core.util and .core.request. I had to make a class public in another package under -request bundle to make it visible, but it's a minor thing. I open a bug on jira now... wow, is down :) well, as soon as it get back online. On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore dani...@dellafiore.netwrote: it is not. I'm hacking on the trunk to make that work. Maybe a quick solution is just change org.apache.wicket to org.apache.wicket.core in the -core bundle. Of course there are some default scope classes that works through different packages but I can just make them public for now. On Mon, Apr 25, 2011 at 3:18 PM, James Carman ja...@carmanconsulting.comwrote: On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com wrote: I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. From an OSGi perspective, we should probably try to make sure that packages don't span jar files. Everything in org.apache,wicket.request should be in wicket-request.jar, for example. I don't know if that's the case, currently or not. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
It is the same conversation. You need uber-jar. At least one that combines -util, -request and -core. Everything else is optional, depending on your app needs. Can you describe what is the problem to use the uber-jar? Or what are the benefits to deploy these three jars separately in the OSGi container ? On Mon, Apr 25, 2011 at 9:08 PM, Daniele Dellafiore dani...@dellafiore.net wrote: Are you referring to this conversation? http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-rc2-and-aggregate-jar-for-osgi-td3356667.html If so, I read it and answered that I'm not interested in any solution that involves the uber-jar. I do not see any advantage in that solution over a normal war. I do not find any other advice from you and Eike, maybe you can point me out the right conversation. On Mon, Apr 25, 2011 at 6:25 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi Daniele, Me and later Eike explained to you in the other thread you started few months ago how to solve exactly this problem. It seems you didn't read it at all. Please read again the part mentioning Wicket 1.5 RC1. On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore dani...@dellafiore.net wrote: I did it. Yes, the tough way but I did it. Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the 1.5-SNAPSHOT I built. Basically I renamed the .util and .request packages in -core bundle to be .core.util and .core.request. I had to make a class public in another package under -request bundle to make it visible, but it's a minor thing. I open a bug on jira now... wow, is down :) well, as soon as it get back online. On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore dani...@dellafiore.netwrote: it is not. I'm hacking on the trunk to make that work. Maybe a quick solution is just change org.apache.wicket to org.apache.wicket.core in the -core bundle. Of course there are some default scope classes that works through different packages but I can just make them public for now. On Mon, Apr 25, 2011 at 3:18 PM, James Carman ja...@carmanconsulting.comwrote: On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com wrote: I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. From an OSGi perspective, we should probably try to make sure that packages don't span jar files. Everything in org.apache,wicket.request should be in wicket-request.jar, for example. I don't know if that's the case, currently or not. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
On Mon, Apr 25, 2011 at 7:20 PM, Martin Grigorov mgrigo...@apache.orgwrote: It is the same conversation. You need uber-jar. At least one that combines -util, -request and -core. Everything else is optional, depending on your app needs. Ok. As you see I read and answered to that. Can you describe what is the problem to use the uber-jar? Or what are the benefits to deploy these three jars separately in the OSGi container ? That is basically a war. One of the advantage of OSGI is having separate bundles for every module, to start, stop, refresh etc. If I start packaging things in wars/jars, I lose the control of what is being used. Will be the bundle or the embedded jar? It's a JEE hell, so why not use a JEE? I want a clean, pure, osgi environment. The other way, I stay on JEE. Another advantage of deployng my bundle without any other jars is that my bundle is 60Kb, the uber-jar more than 1MB, maybe 2. And following this policy, will grow everytime there's a non-compliant library to deal with. In the ed, it's more OSGI-like and does not affect at all the rest of the framework. The only effort is to rename a package, in a major release. It took almost 10 minutes to do that to me. If problem is retro-compatibility well... it's a major release, it's a good time, isn't it? On Mon, Apr 25, 2011 at 9:08 PM, Daniele Dellafiore dani...@dellafiore.net wrote: Are you referring to this conversation? http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-rc2-and-aggregate-jar-for-osgi-td3356667.html If so, I read it and answered that I'm not interested in any solution that involves the uber-jar. I do not see any advantage in that solution over a normal war. I do not find any other advice from you and Eike, maybe you can point me out the right conversation. On Mon, Apr 25, 2011 at 6:25 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi Daniele, Me and later Eike explained to you in the other thread you started few months ago how to solve exactly this problem. It seems you didn't read it at all. Please read again the part mentioning Wicket 1.5 RC1. On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore dani...@dellafiore.net wrote: I did it. Yes, the tough way but I did it. Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the 1.5-SNAPSHOT I built. Basically I renamed the .util and .request packages in -core bundle to be .core.util and .core.request. I had to make a class public in another package under -request bundle to make it visible, but it's a minor thing. I open a bug on jira now... wow, is down :) well, as soon as it get back online. On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore dani...@dellafiore.netwrote: it is not. I'm hacking on the trunk to make that work. Maybe a quick solution is just change org.apache.wicket to org.apache.wicket.core in the -core bundle. Of course there are some default scope classes that works through different packages but I can just make them public for now. On Mon, Apr 25, 2011 at 3:18 PM, James Carman ja...@carmanconsulting.comwrote: On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com wrote: I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. From an OSGi perspective, we should probably try to make sure that packages don't span jar files. Everything in org.apache,wicket.request should be in wicket-request.jar, for example. I don't know if that's the case, currently or not. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
I would reverse the question and ask: why was wicket broken into multiple packages in the first place? I assume there are use cases where: - someone would need only the content of wicket-core and none of the extras - someone would need only wicket-core + wicket-request - someone would need only wicket-core + wicket-util - ... I suppose the above scenarios actually were needed and that lead to the split. If there is no practical use in having Wicket broken into multiple packages, then why do it in the first place? In any case, since I assume there is a reason for the split, I'd say that the same use-cases that apply in a non-osgi environment, also apply for the OSGi case. Projects that only need wicket-core should load only that and nothing else. Other than being leightweight for such cases, I don't see a reason why an uber-jar won't work. Now, assuming that this split is what the community and the developers want, it should be offered for both non-OSGi as well as OSGi environments. This means that we simply need to make sure there is at least one package that is unique per bundle and instruct OSGi people to do package-based imports using the non-common packages. For example, in Daniele's case, the package used in org.apache.wicket.request. However this exists in both the wicket-core and wicket-request bundles, causing the problem. A different package should be used. @Daniele: try importing org.apache.wicket.request.flow, which only exists in wicket-request. This should get you the correct bundle, without having to modify the distribution. Alternatively, you can import specific bundles rather than packages. Having said that, for what it's worth, I agree with Daniele that since this is a major release, it is a golden opportunity to do some OSGi-friendly package-renaming. On Mon, 25 Apr 2011 21:20:57 +0300, Martin Grigorov mgrigo...@apache.org wrote: It is the same conversation. You need uber-jar. At least one that combines -util, -request and -core. Everything else is optional, depending on your app needs. Can you describe what is the problem to use the uber-jar? Or what are the benefits to deploy these three jars separately in the OSGi container ? On Mon, Apr 25, 2011 at 9:08 PM, Daniele Dellafiore dani...@dellafiore.net wrote: Are you referring to this conversation? http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-rc2-and-aggregate-jar-for-osgi-td3356667.html If so, I read it and answered that I'm not interested in any solution that involves the uber-jar. I do not see any advantage in that solution over a normal war. I do not find any other advice from you and Eike, maybe you can point me out the right conversation. On Mon, Apr 25, 2011 at 6:25 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi Daniele, Me and later Eike explained to you in the other thread you started few months ago how to solve exactly this problem. It seems you didn't read it at all. Please read again the part mentioning Wicket 1.5 RC1. On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore dani...@dellafiore.net wrote: I did it. Yes, the tough way but I did it. Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the 1.5-SNAPSHOT I built. Basically I renamed the .util and .request packages in -core bundle to be .core.util and .core.request. I had to make a class public in another package under -request bundle to make it visible, but it's a minor thing. I open a bug on jira now... wow, is down :) well, as soon as it get back online. On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore dani...@dellafiore.netwrote: it is not. I'm hacking on the trunk to make that work. Maybe a quick solution is just change org.apache.wicket to org.apache.wicket.core in the -core bundle. Of course there are some default scope classes that works through different packages but I can just make them public for now. On Mon, Apr 25, 2011 at 3:18 PM, James Carman ja...@carmanconsulting.comwrote: On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com wrote: I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. From an OSGi perspective, we should probably try to make sure that packages don't span jar files. Everything in org.apache,wicket.request should be in wicket-request.jar, for example. I don't know if that's the case, currently or not. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
On Mon, Apr 25, 2011 at 9:29 PM, Daniele Dellafiore dani...@dellafiore.net wrote: On Mon, Apr 25, 2011 at 7:20 PM, Martin Grigorov mgrigo...@apache.orgwrote: It is the same conversation. You need uber-jar. At least one that combines -util, -request and -core. Everything else is optional, depending on your app needs. Ok. As you see I read and answered to that. Well, your statement there wasn't that hard against the uber jar. Can you describe what is the problem to use the uber-jar? Or what are the benefits to deploy these three jars separately in the OSGi container ? That is basically a war. One of the advantage of OSGI is having separate bundles for every module, to start, stop, refresh etc. If I start packaging things in wars/jars, I lose the control of what is being used. Will be the bundle or the embedded jar? It's a JEE hell, so why not use a JEE? I want a clean, pure, osgi environment. The other way, I stay on JEE. The idea of OSGi is to have interface and replaceable implementations. You can use this to replace Hibernate with EclipseLink as JPA implementation, or one JMS implementation with another. Can you do that with Wicket ? I don't think so. There is no specification, no interfaces. There is just one implementation (well, there is also Richard Emberson's work on Scala translation, but I wouldn't recommend you to add another new technology in your mix). For me you are wasting your time by trying to do it as the OSGi specification says. Another advantage of deployng my bundle without any other jars is that my bundle is 60Kb, the uber-jar more than 1MB, maybe 2. And following this policy, will grow everytime there's a non-compliant library to deal with. You need to add all Wicket classes from -util, -request and -core anyway. No matter whether you'll deploy the jars one by one or all-in-one (uber-jar) the final result will be the same - maybe 2MB. In the ed, it's more OSGI-like and does not affect at all the rest of the framework. The only effort is to rename a package, in a major release. It took almost 10 minutes to do that to me. If problem is retro-compatibility well... it's a major release, it's a good time, isn't it? It is not a problem to do this in 1.5. We already did it for wicket-auth-roles. The problem is similar to the one we have with Portlets support - very few users and no one of the dev team actually uses this technology. So we may apply your findings now but we can quite easy break it few days/weeks later by introducing another similar problem without noticing it. My personal opinion is that all this doesn't bring enough value. Using the uber-jar solution is much simpler. On Mon, Apr 25, 2011 at 9:08 PM, Daniele Dellafiore dani...@dellafiore.net wrote: Are you referring to this conversation? http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-rc2-and-aggregate-jar-for-osgi-td3356667.html If so, I read it and answered that I'm not interested in any solution that involves the uber-jar. I do not see any advantage in that solution over a normal war. I do not find any other advice from you and Eike, maybe you can point me out the right conversation. On Mon, Apr 25, 2011 at 6:25 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi Daniele, Me and later Eike explained to you in the other thread you started few months ago how to solve exactly this problem. It seems you didn't read it at all. Please read again the part mentioning Wicket 1.5 RC1. On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore dani...@dellafiore.net wrote: I did it. Yes, the tough way but I did it. Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the 1.5-SNAPSHOT I built. Basically I renamed the .util and .request packages in -core bundle to be .core.util and .core.request. I had to make a class public in another package under -request bundle to make it visible, but it's a minor thing. I open a bug on jira now... wow, is down :) well, as soon as it get back online. On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore dani...@dellafiore.netwrote: it is not. I'm hacking on the trunk to make that work. Maybe a quick solution is just change org.apache.wicket to org.apache.wicket.core in the -core bundle. Of course there are some default scope classes that works through different packages but I can just make them public for now. On Mon, Apr 25, 2011 at 3:18 PM, James Carman ja...@carmanconsulting.comwrote: On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com wrote: I think that the wicket package layout should be changed now that -util and -request bundles have been detached from -core. From an OSGi perspective, we should probably try to make sure that packages don't span jar files. Everything in org.apache,wicket.request should be in wicket-request.jar, for example. I don't
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
On Mon, Apr 25, 2011 at 8:00 PM, Martin Grigorov mgrigo...@apache.orgwrote: On Mon, Apr 25, 2011 at 9:29 PM, Daniele Dellafiore dani...@dellafiore.net wrote: The idea of OSGi is to have interface and replaceable implementations. You can use this to replace Hibernate with EclipseLink as JPA implementation, or one JMS implementation with another. Can you do that with Wicket ? I don't think so. There is no specification, no interfaces. There is just one implementation (well, there is also Richard Emberson's work on Scala translation, but I wouldn't recommend you to add another new technology in your mix). For me you are wasting your time by trying to do it as the OSGi specification says. I'm not using OSGi for that, but for the ability to deploy small packages, being there libraries, webapp or just some small portion of integration code, a JMS consumer... small packages, installed quickly, that does not make any sense in a JEE container. Also, Karaf offer a nice console and a web console also that I find superior to any tomcat/jetty out there. There are many reason for me to switch to OSGi as my default target environment. And none of this is related to switch implementations. Another advantage of deployng my bundle without any other jars is that my bundle is 60Kb, the uber-jar more than 1MB, maybe 2. And following this policy, will grow everytime there's a non-compliant library to deal with. You need to add all Wicket classes from -util, -request and -core anyway. No matter whether you'll deploy the jars one by one or all-in-one (uber-jar) the final result will be the same - maybe 2MB. It's not like this. It's: one time and only one I install wicket (2MB) All my app deployments (that in development can a log every day) I deploy a few KB and reload a single jar in less then a second. That's the main goal I'm achieving with all this webapp over OSGI thing. In the ed, it's more OSGI-like and does not affect at all the rest of the framework. The only effort is to rename a package, in a major release. It took almost 10 minutes to do that to me. If problem is retro-compatibility well... it's a major release, it's a good time, isn't it? It is not a problem to do this in 1.5. We already did it for wicket-auth-roles. The problem is similar to the one we have with Portlets support - very few users and no one of the dev team actually uses this technology. So we may apply your findings now but we can quite easy break it few days/weeks later by introducing another similar problem without noticing it. I'm sorry I do not understand what you mean here. You mean that fixing this issue cannot be a definitive solution? My personal opinion is that all this doesn't bring enough value. Using the uber-jar solution is much simpler. It's simpler releasing a package that force the developer to a specific solution that's not made the osgi way that they have to find out over and over again rather than renaming a package one time and for all in the distro and make it work out of the box for everyone? The uber-jar solution is not documentet anywhere. Even if documented, is more work that a developer with an OSGi target environment has to do and more than that, to discover. He will ask: why can I use, to say, spring and restlet just installing their bundle to Karaf but this does not apply with Wicket? Cause the wicket bundle are not really osgi compliant. Why? No reason. With my solution, wicket webapp over OSGI will work out-of-the-box. And can be made in a few minutes, as I did. And there is the advantage to deploy few Kb over 2MB every time. And there is the advantage of having something that is standard. I do not mean OSGi compliant, I mean standard in a more pragmatic way: all over OSGi I use external bundles, with wicket no, different solution, uber-jar. Why? No reason.
