Re: Wicket and OSGi
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 (the case attached to WICKET-3737 is a stripped down version), we have one 'web bundle', which hosts the Wicket application; individual bundles provide pages and their mount points (in the example case, bundles provide some panels). In cases like that, there is no single class loader which knows all classes, so you need one bundle with a DynamicImport-Package: *. To reduce the number of bundle refreshes we delegate this job to a tiny 'class resolver bundle', which exposes an IClassResolver instance as OSGi service. While generating JDK / CGLib proxies, you need a class loader which can access all proxied classes, one way to solve this is a minor change to the IClassResolver interface to get access to the almightly class loader. I have added a method getClassLoader(), which is used in the DefaultClassResolver to load classes. This simple change will save some code duplication in OSGi compatible classResolvers. - Another difference is how OSGi services are used; we are using Spring DM, which creates one applicationContext per bundle. Fields annotated with @SpringBean will be injected with beans (imported OSGi reference is also a bean) from the applicationContext of the bundle in which the component is created. In my opinion, the advantage of this is that each bundle has to be explicit about the services it depends on, spring beans do not have to be unique, not all beans have to be exported as OSGi service and there is need to register ServiceTracker instances (Spring DM solves this problem). - Is it an idea to extend the wicket-osgi project with some classes which support this pattern? So wicket-osgi will become the toolkit you need when combining OSGi and Wicket? I think it would be nice when it has injectors for services from the OSGi service registry, as well as the pattern in which spring beans from the bundle application context are used (more similar to wicket-spring, the only difference is you have multiple, small application contexts). One attachment to WICKET-3737 contains the injector stack required for wiring spring beans from the bundle application context into wicket components (not completely finished). To achieve this, I think the change to the IClassResolver API is required, some patches have to be applied in wicket-ioc code and the DynamicImport-Package header needs to be dropped from the wicket bundles. What do you think? grtz, Daniël ** http://www.educator.eu On Mon, Jun 27, 2011 at 10:36 PM, Harald Wellmann harald.wellm...@gmx.dewrote: 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 its code. Actually, I'm no longer sure it is needed at all... The OsgiClassResolver uses the bundle class loader of the WAB, accessed via the current Application class. The DefaultClassResolver uses the ThreadContextClassLoader, or its own classloader as a fallback. I'd noticed before that my sample works on Jetty even without the OsgiClassResolver, and the same is true on GlassFish 3.1. Sahoo from the GlassFish team pointed out to me that any Servlet container is required to set the TCCL to the application classloader (see Servlet Spec 3.0, section 10.7.2) for loading resources and for any application callbacks. If everyone agrees that this covers all use cases where Wicket needs to load stuff from user bundles, then I think it's safe to scrap the OsgiClassResolver and let the unmodified DefaultClassResolver do the job. Could you also document the new module on wicketstuff wiki? https://github.com/**wicketstuff/core/wikihttps://github.com/wicketstuff/core/wiki Sure - that's the next thing on my list... I'm also planning to add some Surefire tests based on Pax Exam. Cheers, Harald --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
setting number of pages in the session
Hello, Ik would like to reduce the amount of pages maintained in the session to 1 in order to disable the back button. How can I set this in wicket 1.5RC2? With this I would like to avoid the possibility that after a logout, the user can come back to the previous logged in page via the back button. I already search the Internet archives, but found nothing useful (some hints seemed not for wicket 1.5RC2) Any help appreciated, Met hartelijke groet, Harrie Hazewinkel Software Architect - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: setting number of pages in the session
Hi Harrie, In RC5.1 (the latest one) there is IStoreSettings (application.getStoreSettings()) which provides methods for configuring the functionalities provided by the page stores. But if you decrease the in memory store size then the page will be looked up from the disk so it will be found again. The in-memory (http session) storage is used as perf optimization for faster retrieval. Better make your page either stateless (all components should have #getStatelessHint() == false) or unversioned (#setVersioned(false)). This way the page wont be stored at all in the page stores. On Tue, Jun 28, 2011 at 12:15 PM, Harrie Hazewinkel hhazewin...@iprofs.nl wrote: Hello, Ik would like to reduce the amount of pages maintained in the session to 1 in order to disable the back button. How can I set this in wicket 1.5RC2? With this I would like to avoid the possibility that after a logout, the user can come back to the previous logged in page via the back button. I already search the Internet archives, but found nothing useful (some hints seemed not for wicket 1.5RC2) Any help appreciated, Met hartelijke groet, Harrie Hazewinkel Software Architect - 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: using a different pagemap
I have a question then. What pagemap actually for? In javadoc there are only #FIXME javadoc. Is there some documentation on this? Also it is mentioned in multi window support but still no clues what impact does it have on modal windows on multiwindows at all.. Someone? Thank you. -- Best regards Alex - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: setting number of pages in the session
Isn't it possible to code a PageStore that ... does not store pages? Like DevNullPageStore ? :-) *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Tue, Jun 28, 2011 at 6:31 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi Harrie, In RC5.1 (the latest one) there is IStoreSettings (application.getStoreSettings()) which provides methods for configuring the functionalities provided by the page stores. But if you decrease the in memory store size then the page will be looked up from the disk so it will be found again. The in-memory (http session) storage is used as perf optimization for faster retrieval. Better make your page either stateless (all components should have #getStatelessHint() == false) or unversioned (#setVersioned(false)). This way the page wont be stored at all in the page stores. On Tue, Jun 28, 2011 at 12:15 PM, Harrie Hazewinkel hhazewin...@iprofs.nl wrote: Hello, Ik would like to reduce the amount of pages maintained in the session to 1 in order to disable the back button. How can I set this in wicket 1.5RC2? With this I would like to avoid the possibility that after a logout, the user can come back to the previous logged in page via the back button. I already search the Internet archives, but found nothing useful (some hints seemed not for wicket 1.5RC2) Any help appreciated, Met hartelijke groet, Harrie Hazewinkel Software Architect - 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
Strange issue with AjaxLink and AjaxRequest
Hi,
i'm having the strangest issue with an AjaxRequest on one of our pages. The
situation is as follows:
We have a page which contains a panel. That panel is initially rendered
invisible with setOutputMarkupPlaceholderTag(true):
(Note: redenWijzigeinPanel is dutch but it's the variable that holds the
panel)
redenWijzigenPanel.setVisible(false);
redenWijzigenPanel.setOutputMarkupPlaceholderTag(true);
We also add a AjaxLink to the page which, when clicked on will render the
page visible.
item.add(new AjaxLinkVoid(redenWijzigen)
{
@Override
public void onClick(AjaxRequestTarget target)
{
redenWijzigenPanel.setVisible(!redenWijzigenPanel.isVisible());
target.addComponent(redenWijzigenPanel);
}
});
Note that both redenwijzigenPanel and the AjaxLink are added to a ListView.
Now here's where it gets weird. This works perfectly fine on my local
machine, however, it goes wrong on one of our environments with the
following Ajax error(I've tried on both enviroments with Wicket
configuration on development or on production).
ERROR: Wicket.Ajax.Call.processComponent: Component with id
[[redenWijzigenPanel139]] a was not found while trying to perform markup
update. Make sure you called component.setOutputMarkupId(true) on the
component whose markup you are trying to update.
(See below for the entire AjaxMessage)
This is weird because when I look at the HTML being generated it looks like
this:
div id=redenWijzigenPanelf5 style=display:none/div
Which is what you expect except where does the wicket:id
redenwijzigenPanel139 come from?
So my problem is, why does this work on my local enviroment but not on the
other? Is there something I'm missing? Or does anyone know a workaround?
Entire Ajax message:
INFO:
INFO: Initiating Ajax GET request on
?wicket:interface=:4:dossierinfo:0:dossierPanel:contentContainer:panelContainer:fksMeldingenContainer:fksMeldingen:0:redenWijzigen::IBehaviorListener:0:-1random=0.04403882613405585
INFO: Invoking pre-call handler(s)...
INFO: Received ajax response (5798 characters)
INFO:
?xml version=1.0
encoding=UTF-8?ajax-responseevaluate/evaluateheader-contribution
encoding=wicket1 /header-contributioncomponent
id=redenWijzigenPanel139
/componentevaluate/evaluate/ajax-response
INFO: Response parsed. Now invoking steps...
ERROR: Wicket.Ajax.Call.processComponent: Component with id
[[redenWijzigenPanel139]] a was not found while trying to perform markup
update. Make sure you called component.setOutputMarkupId(true) on the
component whose markup you are trying to update.
INFO: Channel busy - postponing...
INFO: Response processed successfully.
INFO: Invoking post-call handler(s)...
INFO: Calling posponed function...
INFO:
INFO: Initiating Ajax GET request on
clienttime?clienttime=43url=%3Fwicket%3Ainterface%3D%3A4%3Adossierinfo%3A0%3AdossierPanel%3AcontentContainer%3ApanelContainer%3AfksMeldingenContainer%3AfksMeldingen%3A0%3AredenWijzigen%3A%3AIBehaviorListener%3A0%3A-1%26random%3D0.04403882613405585
random 0.51815887761741751309268735304random=0.5350335570983589
INFO: Invoking pre-call handler(s)...
INFO: refocus last focused component not needed/allowed
INFO: Received ajax response (0 characters)
INFO:
ERROR: Wicket.Ajax.Call.failure: Error while parsing response: Could not
find root ajax-response element
INFO: Invoking post-call handler(s)...
INFO: Invoking failure handler(s)...
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Strange-issue-with-AjaxLink-and-AjaxRequest-tp3630436p3630436.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
developers needed
Hi. Can use a wicket developer or two for a 3-4 week project. Needs to be able to work legally in US, sign a Non-Disclosure Agreement (NDA) and have an SSN# for a W9 form (to do 1099). Work from home. Gotta be able to show me some wicket work (with source samples) you did in the past. Work would start asap. Don't care if you work nights and weekends, but you gotta be available to do the work. Later on, there will be other projects and occasional maintenance work. Please send me your rates and source samples. Email directly to above address as I don't read all the messages in these forums all that often these days. We are a small company in NJ that does development. Mostly in Java. Sincerely, - Alex. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: setting number of pages in the session
Isn't the conventional logout operation destroying the session, thereby preventing access to any of the session's pages? Dan On Tue, Jun 28, 2011 at 2:15 AM, Harrie Hazewinkel hhazewin...@iprofs.nlwrote: Hello, Ik would like to reduce the amount of pages maintained in the session to 1 in order to disable the back button. How can I set this in wicket 1.5RC2? With this I would like to avoid the possibility that after a logout, the user can come back to the previous logged in page via the back button. I already search the Internet archives, but found nothing useful (some hints seemed not for wicket 1.5RC2) Any help appreciated, Met hartelijke groet, Harrie Hazewinkel Software Architect - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange issue with AjaxLink and AjaxRequest
Hi,
do you use the same Wicket version on development and production
environments? Anyway the problem could be due to ListView which by
default replaces all child components with new instances each time is
rendered.
Try calling setReuseItems(true) on your ListView.
Hi,
i'm having the strangest issue with an AjaxRequest on one of our pages. The
situation is as follows:
We have a page which contains a panel. That panel is initially rendered
invisible with setOutputMarkupPlaceholderTag(true):
(Note: redenWijzigeinPanel is dutch but it's the variable that holds the
panel)
redenWijzigenPanel.setVisible(false);
redenWijzigenPanel.setOutputMarkupPlaceholderTag(true);
We also add a AjaxLink to the page which, when clicked on will render the
page visible.
item.add(new AjaxLinkVoid(redenWijzigen)
{
@Override
public void onClick(AjaxRequestTarget target)
{
redenWijzigenPanel.setVisible(!redenWijzigenPanel.isVisible());
target.addComponent(redenWijzigenPanel);
}
});
Note that both redenwijzigenPanel and the AjaxLink are added to a ListView.
Now here's where it gets weird. This works perfectly fine on my local
machine, however, it goes wrong on one of our environments with the
following Ajax error(I've tried on both enviroments with Wicket
configuration on development or on production).
ERROR: Wicket.Ajax.Call.processComponent: Component with id
[[redenWijzigenPanel139]] a was not found while trying to perform markup
update. Make sure you called component.setOutputMarkupId(true) on the
component whose markup you are trying to update.
(See below for the entire AjaxMessage)
This is weird because when I look at the HTML being generated it looks like
this:
div id=redenWijzigenPanelf5 style=display:none/div
Which is what you expect except where does the wicket:id
redenwijzigenPanel139 come from?
So my problem is, why does this work on my local enviroment but not on the
other? Is there something I'm missing? Or does anyone know a workaround?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange issue with AjaxLink and AjaxRequest
It's the exact same build, so yeah same versions both time. I'll try your suggestions, thanks! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Strange-issue-with-AjaxLink-and-AjaxRequest-tp3630436p3630677.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: new user registration email verification
any suggestions ? Email verfication almost all aps needs this is there any generic way of doing this ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/new-user-registration-email-verification-tp3630379p3630679.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: new user registration email verification
This isn't really a wicket thing is it? This is a common pattern for all web applications that require a login. There is nothing inherently wickety about it On Tue, Jun 28, 2011 at 11:34 AM, fachhoch fachh...@gmail.com wrote: any suggestions ? Email verfication almost all aps needs this is there any generic way of doing this ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/new-user-registration-email-verification-tp3630379p3630679.html Sent from the Users forum mailing list archive at Nabble.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: new user registration email verification
yes its nothing about wicket sorry,but please suggest me how do we implement this in general I posted it here because mine is a wicket app and other wicket users might have had a similar requirement . -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/new-user-registration-email-verification-tp3630379p3630701.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Unwanted authentication persistence
We are using AuthenticatedWebSession without any persistence of anything. However, the session is persisting (user does not have to login after the first time) from one server restart to another. Is that expected behavior? Does anyone know how to prevent persistence of the session/data? Thanks, Scott -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Unwanted-authentication-persistence-tp3631027p3631027.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and OSGi
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 by the application. Otherwise, for the injection stuff, the WAB only needs to import the service interface packages, but not the implementation packages or bundles. in our case (the case attached to WICKET-3737 is a stripped down version), we have one 'web bundle', which hosts the Wicket application; individual bundles provide pages and their mount points (in the example case, bundles provide some panels). Yes, I had a look at that example - it's a rather advanced scenario and far more than what I'm currently aiming at with wicket-osgi. The first major goal I would like to achieve is support for the following scenario: - OSGi Web Container and Web Application Bundles according to OSGi Enterprise Spec 4.2. - Wicket is deployed as a plain old OSGi bundle. - One or more WABs are deployed as separate bundles. Each WAB provides a Web Application according to the Servlet Spec. The WABs are completely isolated from each other, just like plain old WARs. I don't think that your scenario with other bundles contributing new pages or resources to a running web application is currently covered by the OSGi Enterprise Spec. A WAB is always a single bundle, which may of course import packages and use services from other bundles, but for anything related to the Web Context Path, there is a one-to-one relation between context paths and bundles. At least that's my understanding, but I'm not in any of the Java EE or OSGi expert groups... Of course you can attach OSGi fragments to your WAB as bundle host, but an independent bundle registering services that contribute to a web context owned by some other bundle is currently out of scope, I'd say. Mind you, I'm not saying that your scenario doesn't make sense or cannot be done, but it sounds like the second or third step to me. Do you have examples of any OSGi Web containers supports your flavour of multi-bundle WABs? So far, I've looked at Pax Web, Eclipse Gemini Web and Glassfish, and my impression is they all follow the rule one web context, one bundle. In cases like that, there is no single class loader which knows all classes, so you need one bundle with a DynamicImport-Package: *. I'd say your assumption is right, but your conclusion is not... Let's say your WAB retrieves WebPages from the service registry and mounts them. To do so, it only needs to load the WebPage base class from Wicket, but not the implementation class from some other bundle. In this situation, page deserialization will fail, because neither the Wicket bundle class loader nor your WAB nor the ThreadContextClassLoader can load the class from the contributor bundle. But even then, there are other and better solutions than DynamicImport-Package, which I think is something like an emergency amputation when you have to save your application's life and need to use some third-party lib that simply doesn't play by OSGi rules. To reduce the number of bundle refreshes we delegate this job to a tiny 'class resolver bundle', which exposes an IClassResolver instance as OSGi service. And this class resolver bundle still uses dynamic imports, right? I'd suggest one of the following options: 1) Your contributor bundles provide an IContributor service for an interface exported by your WAB. Your WAB tracks all implementations, builds a composite ClassResolver from all their classloaders and registers the ClassResolver with Wicket. 2) Extender Pattern: You define a special manifest header that all your contributors need to include, then your WAB tracks bundle events, identifies its contributors from the manifest header and builds a composite ClassResolver as in 1). In any case, I would leave wicket-bundle and wicket-osgi out of the game. There may be more than one WAB, each with a number of contributor bundles, and the Wicket bundle cannot decide how to match them up. While generating JDK / CGLib proxies, you need a class loader which can access all proxied classes, one way to solve this is a minor change to the IClassResolver interface to get access to the almightly class loader. I have added a method getClassLoader(), which is used in the DefaultClassResolver to load classes. This simple change will save some code duplication in OSGi compatible classResolvers. What's your use case for these proxies? Do you create them at application level, or is this something that Spring DM does at framework level. - Another difference is how OSGi services are used; we are using Spring DM, which creates one applicationContext per bundle. Fields annotated with @SpringBean will be injected with beans (imported OSGi reference is also a bean) from the
PageExpiredException with multiple browser windows, ajaxformupdating behavior
I am getting a PageExpiredException. I believe it is related to a user
opening multiple browser windows. They are using the same session and
accessing the same page at the same time. I was thinking that the page
will expire in one window but not the other for some reason.
User actions;
1. Open a window (with that Page)
2. Open another (with that Page)
3. Click around in one window for a couple of minutes
4. Maybe the user will go BACK to the first window and click
5. Receive PageExpiredException when they click on an ajax component.
I can concede that maybe having having multiple windows and accessing
the same session is not a good idea. I can restrict the user such that
they only open one window.
But, I just wanted to know if anyone had this issue and why.
Here is the strange part, if the user clicks fast enough in both
windows, window-a and window-b then they DON'T get the
PageExpiredException. But if the user waits a minute or maybe around 30
seconds on one page, they get the PageExpiredException.
Maybe the page is written to disk after 30 seconds or so?
Here is essentially the page structure:
Version: Wicket 1.4.15
Error:
org.apache.wicket.protocol.http.PageExpiredException: Cannot find the
rendered page in session
[pagemap=null,componentPath=2:radio,versionNumber=0]
at
org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequ
estCycleProcessor.java:197)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484
)
at
org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:
160)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.ja
va:1146)
Most of the code:
import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;
import org.apache.wicket.PageParameters;
import org.apache.wicket.ajax.AjaxRequestTarget;
import
org.apache.wicket.ajax.form.AjaxFormChoiceComponentUpdatingBehavior;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.form.RadioChoice;
public class TestPage extends WebPage {
public static class OptionBean implements Serializable, Cloneable {
private String name;
private String value;
public OptionBean() {
this( null, null );
}
public OptionBean( final String name, final String value ) {
setName( name ); setValue( value );
}
public String getName() { return name; }
public void setName( final String name ) { this.name = name; }
public String getValue() {
return value;
}
public void setValue( final String value ) {
this.value = value;
}
}
final static List OptionBean yesNoList = new ArrayList
OptionBean ();
final static OptionBean YES_OPTION = new OptionBean();
final static OptionBean NO_OPTION = new OptionBean();
static {
YES_OPTION.setName( Yes ); YES_OPTION.setValue( 1 );
yesNoList.add( YES_OPTION );
NO_OPTION.setName( No ); NO_OPTION.setValue( 0 );
yesNoList.add( NO_OPTION );
}
public TestPage() {
this(null);
}
public TestPage(final PageParameters p) {
super(p);
final RadioChoice rc = new RadioChoice(radio, yesNoList);
rc.add(new AjaxFormChoiceComponentUpdatingBehavior() {
@Override
protected void onUpdate(AjaxRequestTarget target) {
}
});
this.add(rc);
}
}
Re: Unwanted authentication persistence
This is a feature of the web container. You have to check its user manual :-) On Tue, Jun 28, 2011 at 9:09 PM, sreed sr...@avacoda.com wrote: We are using AuthenticatedWebSession without any persistence of anything. However, the session is persisting (user does not have to login after the first time) from one server restart to another. Is that expected behavior? Does anyone know how to prevent persistence of the session/data? Thanks, Scott -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Unwanted-authentication-persistence-tp3631027p3631027.html Sent from the Users forum mailing list archive at Nabble.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: Unwanted authentication persistence
We are using Jetty which has no session persistence by default. Is it possible that Wicket is persisting sessions somehow? What else might be causing this? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Unwanted-authentication-persistence-tp3631027p3631188.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
jsp check AuthenticatedWebSession.get().isSignedIn()
I have very few jsp pages and for these pages I want to check that user is authenticated. I tried calling AuthenticatedWebSession.get().isSignedIn() and I getting this exception java.lang.IllegalStateException: you can only locate or create sessions in the context of a request cycle at org.apache.wicket.Session.findOrCreate(Session.java:208) at org.apache.wicket.Session.get(Session.java:252) at org.apache.wicket.authentication.AuthenticatedWebSession.get(AuthenticatedWebSession.java:40) at gov.hhs.acf.web.filter.JspSecurityFilter.doFilter(JspSecurityFilter.java:29) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:265) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:149) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:421) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:493) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:924) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:358) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:860) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:245) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113) at org.eclipse.jetty.server.Server.handle(Server.java:335) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:588) at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1029) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:549) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:418) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:476) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436) at java.lang.Thread.run(Thread.java:619) please suggest me how check if user is authenticated in case of jsp pages ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/jsp-check-AuthenticatedWebSession-get-isSignedIn-tp3631307p3631307.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketStuff artifacts naming strategy
I started to modify all JAR poms to have the wicketstuff- preffix.
Is anybody against this? Why?
:-)
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Sat, Mar 26, 2011 at 9:22 PM, Bruno Borges bruno.bor...@gmail.comwrote:
We could simply rename the artifactId property of projects, prepending with
wicketstuff-, like wicket does with their modules.
Still, I agree that this is will take some time and effort.
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
On Sat, Mar 26, 2011 at 12:36 PM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
This is more complicated than I first thought.
See this issue: http://jira.codehaus.org/browse/MDEPLOY-93
Essentially it seems that the deploy plugin does not honour the
finalName option and uploads in the original format when deploying.
I will investigate this further but it won't be part of the next point
releases unfortunately.
Mike
I'm planning on doing point releases this weekend for 1.4.16.1 and
1.5-rc2.1 and I'll make sure the artifacts generate using the longer name.
Thanks,
Mike
In the most parent wicketstuff pom.xml:
build
finalName${project.groupId}-${project.artifactId}-${project.version}.jar/finalName
On Fri, Mar 25, 2011 at 9:31 AM, Wilhelmsen Tor Ivertoriv...@arrive.no
wrote:
- jasperreports-1.4.16.jar
- jasperreports-3.7.2.jar
The first one is from WicketStuff, but still, it is confusing to see
this.
This one of my biggest peeves with Maven: It has this concept of a
groupId to namespace artifacts in the repository, but this is of no
consequence when the jar files appear in the classpath, since the
groupId
namespace is not part of the actual file name.
A workaround could be to prefix the jar file name with the groupId
namespace somehow.
- Tor Iver
-
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: WicketStuff artifacts naming strategy
Why not just just use wicket- as the prefix? The groupId shows that it is
org.wicketstuff.
-Clint
On Tue, Jun 28, 2011 at 4:27 PM, Bruno Borges bruno.bor...@gmail.comwrote:
I started to modify all JAR poms to have the wicketstuff- preffix.
Is anybody against this? Why?
:-)
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Sat, Mar 26, 2011 at 9:22 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
We could simply rename the artifactId property of projects, prepending
with
wicketstuff-, like wicket does with their modules.
Still, I agree that this is will take some time and effort.
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
On Sat, Mar 26, 2011 at 12:36 PM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
This is more complicated than I first thought.
See this issue: http://jira.codehaus.org/browse/MDEPLOY-93
Essentially it seems that the deploy plugin does not honour the
finalName option and uploads in the original format when deploying.
I will investigate this further but it won't be part of the next point
releases unfortunately.
Mike
I'm planning on doing point releases this weekend for 1.4.16.1 and
1.5-rc2.1 and I'll make sure the artifacts generate using the longer
name.
Thanks,
Mike
In the most parent wicketstuff pom.xml:
build
finalName${project.groupId}-${project.artifactId}-${project.version}.jar/finalName
On Fri, Mar 25, 2011 at 9:31 AM, Wilhelmsen Tor Iver
toriv...@arrive.no
wrote:
- jasperreports-1.4.16.jar
- jasperreports-3.7.2.jar
The first one is from WicketStuff, but still, it is confusing to see
this.
This one of my biggest peeves with Maven: It has this concept of a
groupId to namespace artifacts in the repository, but this is of no
consequence when the jar files appear in the classpath, since the
groupId
namespace is not part of the actual file name.
A workaround could be to prefix the jar file name with the groupId
namespace somehow.
- Tor Iver
-
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: WicketStuff artifacts naming strategy
because the JAR file does not come with the groupId, and some projects have
some very short names, like dojo, or yui.
If I look at a JAR file named wicket-dojo-1.5-RC5.1.jar, is that from
wicketstuff or wicket ?
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Tue, Jun 28, 2011 at 6:39 PM, Clint Checketts checke...@gmail.comwrote:
Why not just just use wicket- as the prefix? The groupId shows that it is
org.wicketstuff.
-Clint
On Tue, Jun 28, 2011 at 4:27 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
I started to modify all JAR poms to have the wicketstuff- preffix.
Is anybody against this? Why?
:-)
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Sat, Mar 26, 2011 at 9:22 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
We could simply rename the artifactId property of projects, prepending
with
wicketstuff-, like wicket does with their modules.
Still, I agree that this is will take some time and effort.
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
On Sat, Mar 26, 2011 at 12:36 PM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
This is more complicated than I first thought.
See this issue: http://jira.codehaus.org/browse/MDEPLOY-93
Essentially it seems that the deploy plugin does not honour the
finalName option and uploads in the original format when deploying.
I will investigate this further but it won't be part of the next point
releases unfortunately.
Mike
I'm planning on doing point releases this weekend for 1.4.16.1 and
1.5-rc2.1 and I'll make sure the artifacts generate using the longer
name.
Thanks,
Mike
In the most parent wicketstuff pom.xml:
build
finalName${project.groupId}-${project.artifactId}-${project.version}.jar/finalName
On Fri, Mar 25, 2011 at 9:31 AM, Wilhelmsen Tor Iver
toriv...@arrive.no
wrote:
- jasperreports-1.4.16.jar
- jasperreports-3.7.2.jar
The first one is from WicketStuff, but still, it is confusing to
see
this.
This one of my biggest peeves with Maven: It has this concept of a
groupId to namespace artifacts in the repository, but this is of
no
consequence when the jar files appear in the classpath, since the
groupId
namespace is not part of the actual file name.
A workaround could be to prefix the jar file name with the groupId
namespace somehow.
- Tor Iver
-
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: WicketStuff artifacts naming strategy
You convinced me. ;)
On Tue, Jun 28, 2011 at 4:45 PM, Bruno Borges bruno.bor...@gmail.comwrote:
because the JAR file does not come with the groupId, and some projects have
some very short names, like dojo, or yui.
If I look at a JAR file named wicket-dojo-1.5-RC5.1.jar, is that from
wicketstuff or wicket ?
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Tue, Jun 28, 2011 at 6:39 PM, Clint Checketts checke...@gmail.com
wrote:
Why not just just use wicket- as the prefix? The groupId shows that it is
org.wicketstuff.
-Clint
On Tue, Jun 28, 2011 at 4:27 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
I started to modify all JAR poms to have the wicketstuff- preffix.
Is anybody against this? Why?
:-)
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Sat, Mar 26, 2011 at 9:22 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
We could simply rename the artifactId property of projects,
prepending
with
wicketstuff-, like wicket does with their modules.
Still, I agree that this is will take some time and effort.
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
On Sat, Mar 26, 2011 at 12:36 PM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
This is more complicated than I first thought.
See this issue: http://jira.codehaus.org/browse/MDEPLOY-93
Essentially it seems that the deploy plugin does not honour the
finalName option and uploads in the original format when
deploying.
I will investigate this further but it won't be part of the next
point
releases unfortunately.
Mike
I'm planning on doing point releases this weekend for 1.4.16.1 and
1.5-rc2.1 and I'll make sure the artifacts generate using the
longer
name.
Thanks,
Mike
In the most parent wicketstuff pom.xml:
build
finalName${project.groupId}-${project.artifactId}-${project.version}.jar/finalName
On Fri, Mar 25, 2011 at 9:31 AM, Wilhelmsen Tor Iver
toriv...@arrive.no
wrote:
- jasperreports-1.4.16.jar
- jasperreports-3.7.2.jar
The first one is from WicketStuff, but still, it is confusing to
see
this.
This one of my biggest peeves with Maven: It has this concept of
a
groupId to namespace artifacts in the repository, but this is
of
no
consequence when the jar files appear in the classpath, since the
groupId
namespace is not part of the actual file name.
A workaround could be to prefix the jar file name with the
groupId
namespace somehow.
- Tor Iver
-
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: WicketStuff artifacts naming strategy
This can cause classpath collisions
Sent from my Android device. Please excuse typos and brevity.
On Jun 28, 2011 5:27 PM, Bruno Borges bruno.bor...@gmail.com wrote:
I started to modify all JAR poms to have the wicketstuff- preffix.
Is anybody against this? Why?
:-)
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Sat, Mar 26, 2011 at 9:22 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
We could simply rename the artifactId property of projects, prepending
with
wicketstuff-, like wicket does with their modules.
Still, I agree that this is will take some time and effort.
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
On Sat, Mar 26, 2011 at 12:36 PM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
This is more complicated than I first thought.
See this issue: http://jira.codehaus.org/browse/MDEPLOY-93
Essentially it seems that the deploy plugin does not honour the
finalName option and uploads in the original format when deploying.
I will investigate this further but it won't be part of the next point
releases unfortunately.
Mike
I'm planning on doing point releases this weekend for 1.4.16.1 and
1.5-rc2.1 and I'll make sure the artifacts generate using the longer
name.
Thanks,
Mike
In the most parent wicketstuff pom.xml:
build
finalName${project.groupId}-${project.artifactId}-${project.version}.jar/finalName
On Fri, Mar 25, 2011 at 9:31 AM, Wilhelmsen Tor Iver
toriv...@arrive.no
wrote:
- jasperreports-1.4.16.jar
- jasperreports-3.7.2.jar
The first one is from WicketStuff, but still, it is confusing to see
this.
This one of my biggest peeves with Maven: It has this concept of a
groupId to namespace artifacts in the repository, but this is of no
consequence when the jar files appear in the classpath, since the
groupId
namespace is not part of the actual file name.
A workaround could be to prefix the jar file name with the groupId
namespace somehow.
- Tor Iver
-
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: WicketStuff artifacts naming strategy
How can that happen if the purpose of this change is exactly to avoid
collisions ?
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Tue, Jun 28, 2011 at 6:59 PM, James Carman
jcar...@carmanconsulting.comwrote:
This can cause classpath collisions
Sent from my Android device. Please excuse typos and brevity.
On Jun 28, 2011 5:27 PM, Bruno Borges bruno.bor...@gmail.com wrote:
I started to modify all JAR poms to have the wicketstuff- preffix.
Is anybody against this? Why?
:-)
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Sat, Mar 26, 2011 at 9:22 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
We could simply rename the artifactId property of projects, prepending
with
wicketstuff-, like wicket does with their modules.
Still, I agree that this is will take some time and effort.
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
On Sat, Mar 26, 2011 at 12:36 PM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
This is more complicated than I first thought.
See this issue: http://jira.codehaus.org/browse/MDEPLOY-93
Essentially it seems that the deploy plugin does not honour the
finalName option and uploads in the original format when deploying.
I will investigate this further but it won't be part of the next point
releases unfortunately.
Mike
I'm planning on doing point releases this weekend for 1.4.16.1 and
1.5-rc2.1 and I'll make sure the artifacts generate using the longer
name.
Thanks,
Mike
In the most parent wicketstuff pom.xml:
build
finalName${project.groupId}-${project.artifactId}-${project.version}.jar/finalName
On Fri, Mar 25, 2011 at 9:31 AM, Wilhelmsen Tor Iver
toriv...@arrive.no
wrote:
- jasperreports-1.4.16.jar
- jasperreports-3.7.2.jar
The first one is from WicketStuff, but still, it is confusing to
see
this.
This one of my biggest peeves with Maven: It has this concept of a
groupId to namespace artifacts in the repository, but this is of
no
consequence when the jar files appear in the classpath, since the
groupId
namespace is not part of the actual file name.
A workaround could be to prefix the jar file name with the groupId
namespace somehow.
- Tor Iver
-
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: WicketStuff artifacts naming strategy
Are you changing artifact ids?
On Tue, Jun 28, 2011 at 6:26 PM, Bruno Borges bruno.bor...@gmail.com wrote:
How can that happen if the purpose of this change is exactly to avoid
collisions ?
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Tue, Jun 28, 2011 at 6:59 PM, James Carman
jcar...@carmanconsulting.comwrote:
This can cause classpath collisions
Sent from my Android device. Please excuse typos and brevity.
On Jun 28, 2011 5:27 PM, Bruno Borges bruno.bor...@gmail.com wrote:
I started to modify all JAR poms to have the wicketstuff- preffix.
Is anybody against this? Why?
:-)
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Sat, Mar 26, 2011 at 9:22 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
We could simply rename the artifactId property of projects, prepending
with
wicketstuff-, like wicket does with their modules.
Still, I agree that this is will take some time and effort.
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
On Sat, Mar 26, 2011 at 12:36 PM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
This is more complicated than I first thought.
See this issue: http://jira.codehaus.org/browse/MDEPLOY-93
Essentially it seems that the deploy plugin does not honour the
finalName option and uploads in the original format when deploying.
I will investigate this further but it won't be part of the next point
releases unfortunately.
Mike
I'm planning on doing point releases this weekend for 1.4.16.1 and
1.5-rc2.1 and I'll make sure the artifacts generate using the longer
name.
Thanks,
Mike
In the most parent wicketstuff pom.xml:
build
finalName${project.groupId}-${project.artifactId}-${project.version}.jar/finalName
On Fri, Mar 25, 2011 at 9:31 AM, Wilhelmsen Tor Iver
toriv...@arrive.no
wrote:
- jasperreports-1.4.16.jar
- jasperreports-3.7.2.jar
The first one is from WicketStuff, but still, it is confusing to
see
this.
This one of my biggest peeves with Maven: It has this concept of a
groupId to namespace artifacts in the repository, but this is of
no
consequence when the jar files appear in the classpath, since the
groupId
namespace is not part of the actual file name.
A workaround could be to prefix the jar file name with the groupId
namespace somehow.
- Tor Iver
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketStuff artifacts naming strategy
Sorry, hit send too soon.
Are you changing artifact ids? If you are, then Maven will think that
it's something different and will thus allow both the old and the new
jars on the same classpath. If the class names don't change, then
you've go the potential for a collision. Now, this might be an
acceptable risk when you consider how many folks are actually using
the wicketstuff code, but I thought I'd bring it up. We face this
same stuff at Apache Commons.
On Tue, Jun 28, 2011 at 6:48 PM, James Carman
ja...@carmanconsulting.com wrote:
Are you changing artifact ids?
On Tue, Jun 28, 2011 at 6:26 PM, Bruno Borges bruno.bor...@gmail.com wrote:
How can that happen if the purpose of this change is exactly to avoid
collisions ?
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Tue, Jun 28, 2011 at 6:59 PM, James Carman
jcar...@carmanconsulting.comwrote:
This can cause classpath collisions
Sent from my Android device. Please excuse typos and brevity.
On Jun 28, 2011 5:27 PM, Bruno Borges bruno.bor...@gmail.com wrote:
I started to modify all JAR poms to have the wicketstuff- preffix.
Is anybody against this? Why?
:-)
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Sat, Mar 26, 2011 at 9:22 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
We could simply rename the artifactId property of projects, prepending
with
wicketstuff-, like wicket does with their modules.
Still, I agree that this is will take some time and effort.
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
On Sat, Mar 26, 2011 at 12:36 PM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
This is more complicated than I first thought.
See this issue: http://jira.codehaus.org/browse/MDEPLOY-93
Essentially it seems that the deploy plugin does not honour the
finalName option and uploads in the original format when deploying.
I will investigate this further but it won't be part of the next point
releases unfortunately.
Mike
I'm planning on doing point releases this weekend for 1.4.16.1 and
1.5-rc2.1 and I'll make sure the artifacts generate using the longer
name.
Thanks,
Mike
In the most parent wicketstuff pom.xml:
build
finalName${project.groupId}-${project.artifactId}-${project.version}.jar/finalName
On Fri, Mar 25, 2011 at 9:31 AM, Wilhelmsen Tor Iver
toriv...@arrive.no
wrote:
- jasperreports-1.4.16.jar
- jasperreports-3.7.2.jar
The first one is from WicketStuff, but still, it is confusing to
see
this.
This one of my biggest peeves with Maven: It has this concept of a
groupId to namespace artifacts in the repository, but this is of
no
consequence when the jar files appear in the classpath, since the
groupId
namespace is not part of the actual file name.
A workaround could be to prefix the jar file name with the groupId
namespace somehow.
- Tor Iver
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketStuff artifacts naming strategy
I understand that, but as this is a 1.5 release, I thought it shouldn't be a
problem as it is mostly used for new projects.
I would take the risk. I prefer to have collision between 1.4 and 1.5
wicketstuff artifacts, instead of pushing jasperreports-version.jar to a lib
folder instead of the actual (official) jasperreports-version.jar, if you
know what I mean.
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Tue, Jun 28, 2011 at 8:02 PM, James Carman ja...@carmanconsulting.comwrote:
Sorry, hit send too soon.
Are you changing artifact ids? If you are, then Maven will think that
it's something different and will thus allow both the old and the new
jars on the same classpath. If the class names don't change, then
you've go the potential for a collision. Now, this might be an
acceptable risk when you consider how many folks are actually using
the wicketstuff code, but I thought I'd bring it up. We face this
same stuff at Apache Commons.
On Tue, Jun 28, 2011 at 6:48 PM, James Carman
ja...@carmanconsulting.com wrote:
Are you changing artifact ids?
On Tue, Jun 28, 2011 at 6:26 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
How can that happen if the purpose of this change is exactly to avoid
collisions ?
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Tue, Jun 28, 2011 at 6:59 PM, James Carman
jcar...@carmanconsulting.comwrote:
This can cause classpath collisions
Sent from my Android device. Please excuse typos and brevity.
On Jun 28, 2011 5:27 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
I started to modify all JAR poms to have the wicketstuff- preffix.
Is anybody against this? Why?
:-)
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Sat, Mar 26, 2011 at 9:22 PM, Bruno Borges
bruno.bor...@gmail.com
wrote:
We could simply rename the artifactId property of projects,
prepending
with
wicketstuff-, like wicket does with their modules.
Still, I agree that this is will take some time and effort.
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
On Sat, Mar 26, 2011 at 12:36 PM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
This is more complicated than I first thought.
See this issue: http://jira.codehaus.org/browse/MDEPLOY-93
Essentially it seems that the deploy plugin does not honour the
finalName option and uploads in the original format when
deploying.
I will investigate this further but it won't be part of the next
point
releases unfortunately.
Mike
I'm planning on doing point releases this weekend for 1.4.16.1 and
1.5-rc2.1 and I'll make sure the artifacts generate using the
longer
name.
Thanks,
Mike
In the most parent wicketstuff pom.xml:
build
finalName${project.groupId}-${project.artifactId}-${project.version}.jar/finalName
On Fri, Mar 25, 2011 at 9:31 AM, Wilhelmsen Tor Iver
toriv...@arrive.no
wrote:
- jasperreports-1.4.16.jar
- jasperreports-3.7.2.jar
The first one is from WicketStuff, but still, it is confusing
to
see
this.
This one of my biggest peeves with Maven: It has this concept of
a
groupId to namespace artifacts in the repository, but this is
of
no
consequence when the jar files appear in the classpath, since
the
groupId
namespace is not part of the actual file name.
A workaround could be to prefix the jar file name with the
groupId
namespace somehow.
- Tor Iver
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketStuff artifacts naming strategy
Just thought I'd bring it up. I have to have this conversation
periodically on the Commons mailing lists too. :)
On Tue, Jun 28, 2011 at 7:12 PM, Bruno Borges bruno.bor...@gmail.com wrote:
I understand that, but as this is a 1.5 release, I thought it shouldn't be a
problem as it is mostly used for new projects.
I would take the risk. I prefer to have collision between 1.4 and 1.5
wicketstuff artifacts, instead of pushing jasperreports-version.jar to a lib
folder instead of the actual (official) jasperreports-version.jar, if you
know what I mean.
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Tue, Jun 28, 2011 at 8:02 PM, James Carman
ja...@carmanconsulting.comwrote:
Sorry, hit send too soon.
Are you changing artifact ids? If you are, then Maven will think that
it's something different and will thus allow both the old and the new
jars on the same classpath. If the class names don't change, then
you've go the potential for a collision. Now, this might be an
acceptable risk when you consider how many folks are actually using
the wicketstuff code, but I thought I'd bring it up. We face this
same stuff at Apache Commons.
On Tue, Jun 28, 2011 at 6:48 PM, James Carman
ja...@carmanconsulting.com wrote:
Are you changing artifact ids?
On Tue, Jun 28, 2011 at 6:26 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
How can that happen if the purpose of this change is exactly to avoid
collisions ?
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Tue, Jun 28, 2011 at 6:59 PM, James Carman
jcar...@carmanconsulting.comwrote:
This can cause classpath collisions
Sent from my Android device. Please excuse typos and brevity.
On Jun 28, 2011 5:27 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
I started to modify all JAR poms to have the wicketstuff- preffix.
Is anybody against this? Why?
:-)
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Sat, Mar 26, 2011 at 9:22 PM, Bruno Borges
bruno.bor...@gmail.com
wrote:
We could simply rename the artifactId property of projects,
prepending
with
wicketstuff-, like wicket does with their modules.
Still, I agree that this is will take some time and effort.
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
On Sat, Mar 26, 2011 at 12:36 PM, Michael O'Cleirigh
michael.ocleir...@rivulet.ca wrote:
This is more complicated than I first thought.
See this issue: http://jira.codehaus.org/browse/MDEPLOY-93
Essentially it seems that the deploy plugin does not honour the
finalName option and uploads in the original format when
deploying.
I will investigate this further but it won't be part of the next
point
releases unfortunately.
Mike
I'm planning on doing point releases this weekend for 1.4.16.1 and
1.5-rc2.1 and I'll make sure the artifacts generate using the
longer
name.
Thanks,
Mike
In the most parent wicketstuff pom.xml:
build
finalName${project.groupId}-${project.artifactId}-${project.version}.jar/finalName
On Fri, Mar 25, 2011 at 9:31 AM, Wilhelmsen Tor Iver
toriv...@arrive.no
wrote:
- jasperreports-1.4.16.jar
- jasperreports-3.7.2.jar
The first one is from WicketStuff, but still, it is confusing
to
see
this.
This one of my biggest peeves with Maven: It has this concept of
a
groupId to namespace artifacts in the repository, but this is
of
no
consequence when the jar files appear in the classpath, since
the
groupId
namespace is not part of the actual file name.
A workaround could be to prefix the jar file name with the
groupId
namespace somehow.
- Tor Iver
-
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
-
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
