[jira] [Closed] (WICKET-1404) Investigate default focus support (on Page or RequestCycle)
[ https://issues.apache.org/jira/browse/WICKET-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman closed WICKET-1404. A very old request that didn't gain any traction. > Investigate default focus support (on Page or RequestCycle) > --- > > Key: WICKET-1404 > URL: https://issues.apache.org/jira/browse/WICKET-1404 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.1 >Reporter: James Carman >Priority: Minor > Attachments: WICKET-1404.patch > > > We need something which gives a component the focus when the page loads. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WICKET-1404) Investigate default focus support (on Page or RequestCycle)
[ https://issues.apache.org/jira/browse/WICKET-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169481#comment-14169481 ] James Carman commented on WICKET-1404: -- Yeah, seems like the right thing to do. Cheers > Investigate default focus support (on Page or RequestCycle) > --- > > Key: WICKET-1404 > URL: https://issues.apache.org/jira/browse/WICKET-1404 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.1 >Reporter: James Carman >Priority: Minor > Attachments: WICKET-1404.patch > > > We need something which gives a component the focus when the page loads. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] Commented: (WICKET-3263) Allow AjaxRequestTarget.IListeners to be Registered at the WebApplication Level
[ https://issues.apache.org/jira/browse/WICKET-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975801#action_12975801 ] James Carman commented on WICKET-3263: -- No problem. Thanks for taking care of this. How did you end up addressing the confusing setup (with both an overridable factory method and providers)? > Allow AjaxRequestTarget.IListeners to be Registered at the WebApplication > Level > --- > > Key: WICKET-3263 > URL: https://issues.apache.org/jira/browse/WICKET-3263 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman >Assignee: Martin Grigorov > Fix For: 1.5-M4 > > Attachments: WICKET-3263.patch > > > Right now, in order to register an AjaxRequestTarget.IListener, you have to > override WebApplication.newAjaxRequestTarget(Page p). That does make Wicket > very "pluggable." What if multiple frameworks need to add in that hook? So, > why not allow a global, application-level, registry of those listeners. Each > AjaxRequestTarget would have those listeners added to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973030#action_12973030 ] James Carman commented on WICKET-3274: -- Agreed > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972997#action_12972997 ] James Carman commented on WICKET-3274: -- Well, it looks like they're trying to address two different problems. WICKET-1312 seems to be trying to address loosely-coupled, inter-component communication. This aims to be more of a lifecycle event communication mechanism for the overall framework. > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972992#action_12972992 ] James Carman commented on WICKET-3274: -- We may also need to introduce the concept of a "chain" here (like we had in HiveMind). Basically, a "chain" would allow you to have non-void return types. We return the first non-default return value from the items in the chain. So, the exception handling stuff would be a chain, since we have to get an IRequestHandler return value. > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972985#action_12972985 ] James Carman commented on WICKET-3274: -- The proxy stuff isn't really that bad in this case. The proxies aren't used to do drastic, crazy logic. All they're used for is to dispatch the events to all registered listeners, allowing you to merely call the listener method you want with the arguments you want and it will be multicast out to all of the registered listeners. As for the unregister part, I don't really see where you would need to unregister these types of listeners. This is for application-level, cross-cutting concerns, basically all of the "hooks" where plugin/framework developers would need to be able to integrate. Right now, this is very difficult because you have to override factory methods or (with providers) do some sort of wrapping/decorating to allow more than one framework to join in. > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-3274) Application-Scoped EventBus
Application-Scoped EventBus --- Key: WICKET-3274 URL: https://issues.apache.org/jira/browse/WICKET-3274 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.5-M3 Reporter: James Carman It would be nice if Wicket had an application-scoped "event bus" that users could plug into to receive event notifications. Right now, there are multiple points where you can subscribe to events (and no "global" place to subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if you could just do: Application.get().getEventBus().subscribe(IRequestCycleListener.class, myListener); or perhaps: Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); To fire events, you would do something like: Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); or Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); Or course, this approach uses proxies (the publish methods return proxies which let you fire the events to all listeners) and I know they are considered somewhat taboo, but I think this is a good use of them and I really don't see how debugging this could be that difficult really. It would only need to use JDK proxies, because we'd be dealing with listener interfaces only. The benefit of this is that there's just one way to publish/subscribe events in Wicket and it makes it easier for folks to "plug in." They don't have to override a factory method somewhere to make sure they add their listener or anything. They just ask for the bus and subscribe by listener interface. Now, I like the idea of subscribing to a "channel" by means of the listener interface, but I'm open to suggestions if other folks don't really like that idea. I like the type-safety of it. I have some code, but I'm waiting for more discussion here before I submit a patch. I'd have to get rid of all of the listener lists that are lying around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3263) Allow AjaxRequestTarget.IListeners to be Registered at the WebApplication Level
[ https://issues.apache.org/jira/browse/WICKET-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972846#action_12972846 ] James Carman commented on WICKET-3263: -- The trick is making sure the users who override the factory method don't forget add the listeners. The factory method should be final. Then users can supply their own provider if they need to customize further. > Allow AjaxRequestTarget.IListeners to be Registered at the WebApplication > Level > --- > > Key: WICKET-3263 > URL: https://issues.apache.org/jira/browse/WICKET-3263 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > Attachments: WICKET-3263.patch > > > Right now, in order to register an AjaxRequestTarget.IListener, you have to > override WebApplication.newAjaxRequestTarget(Page p). That does make Wicket > very "pluggable." What if multiple frameworks need to add in that hook? So, > why not allow a global, application-level, registry of those listeners. Each > AjaxRequestTarget would have those listeners added to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3263) Allow AjaxRequestTarget.IListeners to be Registered at the WebApplication Level
[ https://issues.apache.org/jira/browse/WICKET-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-3263: - Attachment: WICKET-3263.patch Here's a patch (with test case this time :). > Allow AjaxRequestTarget.IListeners to be Registered at the WebApplication > Level > --- > > Key: WICKET-3263 > URL: https://issues.apache.org/jira/browse/WICKET-3263 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > Attachments: WICKET-3263.patch > > > Right now, in order to register an AjaxRequestTarget.IListener, you have to > override WebApplication.newAjaxRequestTarget(Page p). That does make Wicket > very "pluggable." What if multiple frameworks need to add in that hook? So, > why not allow a global, application-level, registry of those listeners. Each > AjaxRequestTarget would have those listeners added to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-3263) Allow AjaxRequestTarget.IListeners to be Registered at the WebApplication Level
Allow AjaxRequestTarget.IListeners to be Registered at the WebApplication Level --- Key: WICKET-3263 URL: https://issues.apache.org/jira/browse/WICKET-3263 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.5-M3 Reporter: James Carman Right now, in order to register an AjaxRequestTarget.IListener, you have to override WebApplication.newAjaxRequestTarget(Page p). That does make Wicket very "pluggable." What if multiple frameworks need to add in that hook? So, why not allow a global, application-level, registry of those listeners. Each AjaxRequestTarget would have those listeners added to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972488#action_12972488 ] James Carman commented on WICKET-3256: -- I added a RequestCycleListener to the application in the test case and it wasn't notified either of the exception. > Use a Provider for IExceptionMapper > --- > > Key: WICKET-3256 > URL: https://issues.apache.org/jira/browse/WICKET-3256 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman >Assignee: Martin Grigorov > Attachments: WICKET-3256-test.patch, WICKET-3256.patch > > > Currently, in order to plug in your own IExceptionMapper, you have to > override a method. This makes developing "frameworks" difficult, since your > client code has to do a method override in order to get everything working. > It would be nicer if the IExceptionManager was created via a "provider." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972480#action_12972480 ] James Carman commented on WICKET-3256: -- I can do it. I just need to find a few cycles. My morning is shot today (I'm on EDT), but I can probably address it this afternoon. > Use a Provider for IExceptionMapper > --- > > Key: WICKET-3256 > URL: https://issues.apache.org/jira/browse/WICKET-3256 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman >Assignee: Martin Grigorov > Attachments: WICKET-3256-test.patch, WICKET-3256.patch > > > Currently, in order to plug in your own IExceptionMapper, you have to > override a method. This makes developing "frameworks" difficult, since your > client code has to do a method override in order to get everything working. > It would be nicer if the IExceptionManager was created via a "provider." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972473#action_12972473 ] James Carman commented on WICKET-3256: -- I meant more in line with the way other stuff is set up on the Application. All of the other setBlahBlahProvider stuff. > Use a Provider for IExceptionMapper > --- > > Key: WICKET-3256 > URL: https://issues.apache.org/jira/browse/WICKET-3256 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > Attachments: WICKET-3256-test.patch, WICKET-3256.patch > > > Currently, in order to plug in your own IExceptionMapper, you have to > override a method. This makes developing "frameworks" difficult, since your > client code has to do a method override in order to get everything working. > It would be nicer if the IExceptionManager was created via a "provider." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972463#action_12972463 ] James Carman commented on WICKET-3256: -- It's usually good to let the original reporter close their own JIRA issues. The development team should resolve it, but the reporter should close it themselves (unless they completely disappear, which I did not). Yes, this can be done with the IRequestCycleListener, but the way I set it up does make it fall more in line with how the other stuff works (the "providery" way). > Use a Provider for IExceptionMapper > --- > > Key: WICKET-3256 > URL: https://issues.apache.org/jira/browse/WICKET-3256 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman >Assignee: Pedro Santos > Attachments: WICKET-3256-test.patch, WICKET-3256.patch > > > Currently, in order to plug in your own IExceptionMapper, you have to > override a method. This makes developing "frameworks" difficult, since your > client code has to do a method override in order to get everything working. > It would be nicer if the IExceptionManager was created via a "provider." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972319#action_12972319 ] James Carman commented on WICKET-3256: -- I don't want my users to have to substitute anything. I will take care of that for them. I'm providing a simplification API on top of Wicket. The only thing I want my users to have to do to plug in my framework is this (in the application's init method): new WicketopiaPlugin().install(this); > Use a Provider for IExceptionMapper > --- > > Key: WICKET-3256 > URL: https://issues.apache.org/jira/browse/WICKET-3256 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman >Assignee: Pedro Santos > Attachments: WICKET-3256.patch > > > Currently, in order to plug in your own IExceptionMapper, you have to > override a method. This makes developing "frameworks" difficult, since your > client code has to do a method override in order to get everything working. > It would be nicer if the IExceptionManager was created via a "provider." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3257) Add restartResponseAtSignInPage() Method to AuthenticatedWebApplication
[ https://issues.apache.org/jira/browse/WICKET-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-3257: - Attachment: WICKET-3257.patch Here's the patch. > Add restartResponseAtSignInPage() Method to AuthenticatedWebApplication > --- > > Key: WICKET-3257 > URL: https://issues.apache.org/jira/browse/WICKET-3257 > Project: Wicket > Issue Type: Improvement > Components: wicket-auth-roles >Affects Versions: 1.5-M3 >Reporter: James Carman > Attachments: WICKET-3257.patch > > > I have a situation where I need to be able to get the sign in page class > outside the context of the AuthenticatedWebApplication class itself (or a > subclass). Basically, I've got a Spring Security framework that's going to > register a custom exception mapper (that wraps the default one). If it sees > an AuthenticationCredentialsNotFoundException, it needs to throw a > RestartResponseAtInterceptPage(getSignInPage()). Can we add a method that > does that? Patch coming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3257) Make getSignInPage() Method Public
[ https://issues.apache.org/jira/browse/WICKET-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-3257: - Attachment: (was: WICKET-3257.patch) > Make getSignInPage() Method Public > -- > > Key: WICKET-3257 > URL: https://issues.apache.org/jira/browse/WICKET-3257 > Project: Wicket > Issue Type: Improvement > Components: wicket-auth-roles >Affects Versions: 1.5-M3 >Reporter: James Carman > > I have a situation where I need to be able to get the sign in page class > outside the context of the AuthenticatedWebApplication class itself (or a > subclass). Basically, I've got a Spring Security framework that's going to > register a custom exception mapper (that wraps the default one). If it sees > an AuthenticationCredentialsNotFoundException, it needs to throw a > RestartResponseAtInterceptPage(getSignInPage()). But, getSignInPage() is > protected in AuthenticatedWebApplication. Unless there are very compelling > reasons not to do so, can we open that up? Patch coming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3257) Add restartResponseAtSignInPage() Method to AuthenticatedWebApplication
[ https://issues.apache.org/jira/browse/WICKET-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-3257: - Description: I have a situation where I need to be able to get the sign in page class outside the context of the AuthenticatedWebApplication class itself (or a subclass). Basically, I've got a Spring Security framework that's going to register a custom exception mapper (that wraps the default one). If it sees an AuthenticationCredentialsNotFoundException, it needs to throw a RestartResponseAtInterceptPage(getSignInPage()). Can we add a method that does that? Patch coming... (was: I have a situation where I need to be able to get the sign in page class outside the context of the AuthenticatedWebApplication class itself (or a subclass). Basically, I've got a Spring Security framework that's going to register a custom exception mapper (that wraps the default one). If it sees an AuthenticationCredentialsNotFoundException, it needs to throw a RestartResponseAtInterceptPage(getSignInPage()). But, getSignInPage() is protected in AuthenticatedWebApplication. Unless there are very compelling reasons not to do so, can we open that up? Patch coming...) Summary: Add restartResponseAtSignInPage() Method to AuthenticatedWebApplication (was: Make getSignInPage() Method Public) > Add restartResponseAtSignInPage() Method to AuthenticatedWebApplication > --- > > Key: WICKET-3257 > URL: https://issues.apache.org/jira/browse/WICKET-3257 > Project: Wicket > Issue Type: Improvement > Components: wicket-auth-roles >Affects Versions: 1.5-M3 >Reporter: James Carman > > I have a situation where I need to be able to get the sign in page class > outside the context of the AuthenticatedWebApplication class itself (or a > subclass). Basically, I've got a Spring Security framework that's going to > register a custom exception mapper (that wraps the default one). If it sees > an AuthenticationCredentialsNotFoundException, it needs to throw a > RestartResponseAtInterceptPage(getSignInPage()). Can we add a method that > does that? Patch coming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3257) Make getSignInPage() Method Public
[ https://issues.apache.org/jira/browse/WICKET-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-3257: - Attachment: WICKET-3257.patch Here's my patch. > Make getSignInPage() Method Public > -- > > Key: WICKET-3257 > URL: https://issues.apache.org/jira/browse/WICKET-3257 > Project: Wicket > Issue Type: Improvement > Components: wicket-auth-roles >Affects Versions: 1.5-M3 >Reporter: James Carman > Attachments: WICKET-3257.patch > > > I have a situation where I need to be able to get the sign in page class > outside the context of the AuthenticatedWebApplication class itself (or a > subclass). Basically, I've got a Spring Security framework that's going to > register a custom exception mapper (that wraps the default one). If it sees > an AuthenticationCredentialsNotFoundException, it needs to throw a > RestartResponseAtInterceptPage(getSignInPage()). But, getSignInPage() is > protected in AuthenticatedWebApplication. Unless there are very compelling > reasons not to do so, can we open that up? Patch coming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-3257) Make getSignInPage() Method Public
Make getSignInPage() Method Public -- Key: WICKET-3257 URL: https://issues.apache.org/jira/browse/WICKET-3257 Project: Wicket Issue Type: Improvement Components: wicket-auth-roles Affects Versions: 1.5-M3 Reporter: James Carman I have a situation where I need to be able to get the sign in page class outside the context of the AuthenticatedWebApplication class itself (or a subclass). Basically, I've got a Spring Security framework that's going to register a custom exception mapper (that wraps the default one). If it sees an AuthenticationCredentialsNotFoundException, it needs to throw a RestartResponseAtInterceptPage(getSignInPage()). But, getSignInPage() is protected in AuthenticatedWebApplication. Unless there are very compelling reasons not to do so, can we open that up? Patch coming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972224#action_12972224 ] James Carman commented on WICKET-3256: -- Pedro, In my "framework", I've got some initialization code where I'm basically going to wrap around the default IProvider with my own. I've got a situation where I want to be able to register "handlers" for specific exception types (in a security situation). So, if I have a registered handler, I want to use that. If not, I'll be just letting the request flow through to the default exception mapper. Again, my "framework" does this automatically. User code can call: addExceptionHandler(MyExceptionType.class, new MyHandler()); Thanks, James > Use a Provider for IExceptionMapper > --- > > Key: WICKET-3256 > URL: https://issues.apache.org/jira/browse/WICKET-3256 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > Attachments: WICKET-3256.patch > > > Currently, in order to plug in your own IExceptionMapper, you have to > override a method. This makes developing "frameworks" difficult, since your > client code has to do a method override in order to get everything working. > It would be nicer if the IExceptionManager was created via a "provider." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-3256: - Attachment: (was: WICKET-3256.patch) > Use a Provider for IExceptionMapper > --- > > Key: WICKET-3256 > URL: https://issues.apache.org/jira/browse/WICKET-3256 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > Attachments: WICKET-3256.patch > > > Currently, in order to plug in your own IExceptionMapper, you have to > override a method. This makes developing "frameworks" difficult, since your > client code has to do a method override in order to get everything working. > It would be nicer if the IExceptionManager was created via a "provider." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-3256: - Attachment: WICKET-3256.patch Oops! Left my renamed method in there. This patch deletes it. Use this one, please. > Use a Provider for IExceptionMapper > --- > > Key: WICKET-3256 > URL: https://issues.apache.org/jira/browse/WICKET-3256 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > Attachments: WICKET-3256.patch > > > Currently, in order to plug in your own IExceptionMapper, you have to > override a method. This makes developing "frameworks" difficult, since your > client code has to do a method override in order to get everything working. > It would be nicer if the IExceptionManager was created via a "provider." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-3256: - Attachment: WICKET-3256.patch Here's a patch that provides an implementation of what I have in mind. It introduces a field of type IProvider rather than creating a new interface called IExceptionMapperProvider (doesn't add value IMHO). I didn't add a test case, but the build finishes successfully and all test cases pass. > Use a Provider for IExceptionMapper > --- > > Key: WICKET-3256 > URL: https://issues.apache.org/jira/browse/WICKET-3256 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > Attachments: WICKET-3256.patch > > > Currently, in order to plug in your own IExceptionMapper, you have to > override a method. This makes developing "frameworks" difficult, since your > client code has to do a method override in order to get everything working. > It would be nicer if the IExceptionManager was created via a "provider." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-3256) Use a Provider for IExceptionMapper
Use a Provider for IExceptionMapper --- Key: WICKET-3256 URL: https://issues.apache.org/jira/browse/WICKET-3256 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.5-M3 Reporter: James Carman Currently, in order to plug in your own IExceptionMapper, you have to override a method. This makes developing "frameworks" difficult, since your client code has to do a method override in order to get everything working. It would be nicer if the IExceptionManager was created via a "provider." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3125) Add IRequestListener interface to allow easier framework extension points
[ https://issues.apache.org/jira/browse/WICKET-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923215#action_12923215 ] James Carman commented on WICKET-3125: -- I would say we just need to add listeners anywhere where we commonly tell folks to "just implement your own custom X and override method Y" > Add IRequestListener interface to allow easier framework extension points > - > > Key: WICKET-3125 > URL: https://issues.apache.org/jira/browse/WICKET-3125 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M2.1 >Reporter: Jeremy Thomerson >Priority: Minor > > See > http://apache-wicket.1842946.n4.nabble.com/Session-attach-tp3004389p3004681.html > Basically, add an interface for onBeginRequest and onEndRequest that can be > plugged into the WebRequestCycle. This allows framework extensions to plugin > their listeners rather than extending WRC, and requiring that you then extend > them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1936) Client-Side Image Map
[ https://issues.apache.org/jira/browse/WICKET-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914542#action_12914542 ] James Carman commented on WICKET-1936: -- That is more "wickety"! I like it. I've never understood RepeatingViews, so that's why I didn't use them I guess. This seems much cleaner. Although, I don't like that a behavior is named "Area". I'd probably rename it. A behavior does something (i.e. AttributeModifier, etc.) I'd name it something like AddAreaAttributes or something. > Client-Side Image Map > - > > Key: WICKET-1936 > URL: https://issues.apache.org/jira/browse/WICKET-1936 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.5, 1.4-RC1 >Reporter: James Carman >Assignee: Igor Vaynberg > Fix For: 1.5-M2.1 > > Attachments: ClientSideImageMape.patch, WICKET-1936.patch > > > The existing ImageMap implementation does not allow you to "attach" it to any > Image component. Also, it only works with Link objects (and thus not > AjaxLinks or ExternalLinks). The new client-side image map implementation > attaches itself to any existing image and supports any AbstractLink object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1936) Client-Side Image Map
[ https://issues.apache.org/jira/browse/WICKET-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914516#action_12914516 ] James Carman commented on WICKET-1936: -- Sven Meier, Are you saying you don't like the ClientSideImageMap implementation? > Client-Side Image Map > - > > Key: WICKET-1936 > URL: https://issues.apache.org/jira/browse/WICKET-1936 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.5, 1.4-RC1 >Reporter: James Carman >Assignee: Igor Vaynberg > Fix For: 1.5-M2.1 > > Attachments: ClientSideImageMape.patch, WICKET-1936.patch > > > The existing ImageMap implementation does not allow you to "attach" it to any > Image component. Also, it only works with Link objects (and thus not > AjaxLinks or ExternalLinks). The new client-side image map implementation > attaches itself to any existing image and supports any AbstractLink object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2846) Store Application in InheritableThreadLocal instead of ThreadLocal
[
https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated WICKET-2846:
-
Attachment: wicket-application-leak.tar.gz
Here's a quickstart that can be used to show the "leak" of the Application
object into the Java2D Disposer thread. You have to use jvisualvm heap dump to
see it, but it's there:
1. Go to the "Classes" view.
2. Find the java.lang.Thread class.
3. Click on it and it will bring up a list of instances.
4. Find the thread with the name "Java2D Disposer" (#13 for me).
5. Look for the field called "inheritableThreadLocals" and look in its "table"
6. In there, you'll find a reference to the WicketApplication object.
The Java2D Disposer thread runs for the duration of the VM and it will keep
that reference to the application object.
> Store Application in InheritableThreadLocal instead of ThreadLocal
> --
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Reporter: Alexandru Objelean
>Assignee: Igor Vaynberg
>Priority: Minor
> Fix For: 1.4.9
>
> Attachments: wicket-application-leak.tar.gz
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Use case example:
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
> The following example won't work well if the Application is not stored in
> InheritableThreadLocal. The reason why it doesn't work, as I understand that,
> is because @SpringBean lookup depends on Application instance which is not
> accessible from within the thread. Having it stored inside of ITL would solve
> the problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2620) DataTable generates two
[
https://issues.apache.org/jira/browse/WICKET-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861020#action_12861020
]
James Carman commented on WICKET-2620:
--
I believe the fix for this issue has caused a regression in my code. I have a
custom subclass of DataTable with markup:
[cell]
In 1.4.6, my page fails to render. In 1.4.5, it works fine.
> DataTable generates two
> ---
>
> Key: WICKET-2620
> URL: https://issues.apache.org/jira/browse/WICKET-2620
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Affects Versions: 1.4.3
>Reporter: Stefan Schueffler
>Assignee: Juergen Donnerstag
>Priority: Minor
> Fix For: 1.4.6, 1.5-M1
>
>
> The tables generated by DataTable component in the current version of Wicket
> (1.4.3) do not contain in the output HTML.
> It was working correctly in wicket 1.4.0 but there were some changes to fix
> other issues - see WICKET-2436
> To replicate - launch the wicket-examples-1.4.3.war and look at the DataTable
> example:
> http://localhost:8081/wicket-examples-1.4.3/repeater/?wicket:bookmarkablePage=:org.apache.wicket.examples.repeater.DataTablePage
> If you check the HTML source you will see it does not contain thead tag:
> {html}
>
>
> {html}
> When you look at
> http://www.wicket-library.com/wicket-examples/repeater/?wicket:bookmarkablePage=:org.apache.wicket.examples.repeater.DataTablePage
> it shows:
> {html}
>
>
>
> {html}
> Must be a previous version? :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2821) More "IModel
[ https://issues.apache.org/jira/browse/WICKET-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2821: - Attachment: WICKET-2821.patch > More "IModel - > > Key: WICKET-2821 > URL: https://issues.apache.org/jira/browse/WICKET-2821 > Project: Wicket > Issue Type: Improvement > Components: wicket, wicket-extensions >Affects Versions: 1.4.7 >Reporter: James Carman >Priority: Minor > Fix For: 1.5-M1 > > Attachments: WICKET-2821.patch > > > I searched the code for all occurrences of "IModel all that I thought could be replaced with "IModel
[jira] Created: (WICKET-2821) More IModel> Fixes
More IModel> Fixes Key: WICKET-2821 URL: https://issues.apache.org/jira/browse/WICKET-2821 Project: Wicket Issue Type: Improvement Components: wicket, wicket-extensions Affects Versions: 1.4.7 Reporter: James Carman Fix For: 1.5-M1 I searched the code for all occurrences of "IModel
[jira] Updated: (WICKET-2821) More "IModel
[ https://issues.apache.org/jira/browse/WICKET-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2821: - Priority: Minor (was: Major) Summary: More "IModel> Fixes) > More "IModel - > > Key: WICKET-2821 > URL: https://issues.apache.org/jira/browse/WICKET-2821 > Project: Wicket > Issue Type: Improvement > Components: wicket, wicket-extensions >Affects Versions: 1.4.7 >Reporter: James Carman >Priority: Minor > Fix For: 1.5-M1 > > > I searched the code for all occurrences of "IModel all that I thought could be replaced with "IModel
[jira] Commented: (WICKET-2817) ChoiceGroup's Constructor Should Accept IModel>
[ https://issues.apache.org/jira/browse/WICKET-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852860#action_12852860 ] James Carman commented on WICKET-2817: -- Thanks again! > ChoiceGroup's Constructor Should Accept IModel> > --- > > Key: WICKET-2817 > URL: https://issues.apache.org/jira/browse/WICKET-2817 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.7 >Reporter: James Carman >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.4.8, 1.5-M1 > > Attachments: WICKET-2817.patch > > > This is very similar to ListMultipleChoice's constructor situation. Changing > the constructor signature won't break any existing code, but it will make it > easier to use (for times when you have a set-based property). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2817) ChoiceGroup's Constructor Should Accept IModel>
[ https://issues.apache.org/jira/browse/WICKET-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2817: - Attachment: WICKET-2817.patch Here's a patch. > ChoiceGroup's Constructor Should Accept IModel> > --- > > Key: WICKET-2817 > URL: https://issues.apache.org/jira/browse/WICKET-2817 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.7 >Reporter: James Carman >Priority: Minor > Fix For: 1.5-M1 > > Attachments: WICKET-2817.patch > > > This is very similar to ListMultipleChoice's constructor situation. Changing > the constructor signature won't break any existing code, but it will make it > easier to use (for times when you have a set-based property). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2817) ChoiceGroup's Constructor Should Accept IModel>
[ https://issues.apache.org/jira/browse/WICKET-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2817: - Priority: Minor (was: Major) Summary: ChoiceGroup's Constructor Should Accept IModel> (was: ChoiceGroup's Constructor should take IModel>) > ChoiceGroup's Constructor Should Accept IModel> > --- > > Key: WICKET-2817 > URL: https://issues.apache.org/jira/browse/WICKET-2817 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.7 >Reporter: James Carman >Priority: Minor > Fix For: 1.5-M1 > > > This is very similar to ListMultipleChoice's constructor situation. Changing > the constructor signature won't break any existing code, but it will make it > easier to use (for times when you have a set-based property). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2817) ChoiceGroup's Constructor should take IModel>
ChoiceGroup's Constructor should take IModel> - Key: WICKET-2817 URL: https://issues.apache.org/jira/browse/WICKET-2817 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.7 Reporter: James Carman Fix For: 1.5-M1 This is very similar to ListMultipleChoice's constructor situation. Changing the constructor signature won't break any existing code, but it will make it easier to use (for times when you have a set-based property). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2803) ListMultipleChoice's Constructors Should Accept IModel>
[ https://issues.apache.org/jira/browse/WICKET-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849988#action_12849988 ] James Carman commented on WICKET-2803: -- Thank you, sir! > ListMultipleChoice's Constructors Should Accept IModel Collection> > --- > > Key: WICKET-2803 > URL: https://issues.apache.org/jira/browse/WICKET-2803 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.7 >Reporter: James Carman >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.4.8, 1.5-M1 > > Attachments: WICKET-2803.patch > > > Currently, the constructors accept IModel> for the "model" of > the ListMultipleChoice. Thus, you can't pass in an IModel>. The > constructors should be modified to take IModel> > instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2803) ListMultipleChoice's Constructors Should Accept IModel>
[ https://issues.apache.org/jira/browse/WICKET-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2803: - Priority: Minor (was: Major) Adjusting priority. This isn't major, but it is annoying. > ListMultipleChoice's Constructors Should Accept IModel Collection> > --- > > Key: WICKET-2803 > URL: https://issues.apache.org/jira/browse/WICKET-2803 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.7 >Reporter: James Carman >Priority: Minor > Attachments: WICKET-2803.patch > > > Currently, the constructors accept IModel> for the "model" of > the ListMultipleChoice. Thus, you can't pass in an IModel>. The > constructors should be modified to take IModel> > instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2803) ListMultipleChoice's Constructors Should Accept IModel>
[ https://issues.apache.org/jira/browse/WICKET-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2803: - Attachment: WICKET-2803.patch Here's a patch that opens up the constructors a bit. Unfortunately, I had to just cast the IModel> to IModel>. I couldn't monkey with the generics declaration on the class to say that it takes IModel> because the class definition doesn't accept wildcards. I think this is okay, though. > ListMultipleChoice's Constructors Should Accept IModel Collection> > --- > > Key: WICKET-2803 > URL: https://issues.apache.org/jira/browse/WICKET-2803 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.7 >Reporter: James Carman > Attachments: WICKET-2803.patch > > > Currently, the constructors accept IModel> for the "model" of > the ListMultipleChoice. Thus, you can't pass in an IModel>. The > constructors should be modified to take IModel> > instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2803) ListMultipleChoice's Constructors Should Accept IModel>
ListMultipleChoice's Constructors Should Accept IModel> --- Key: WICKET-2803 URL: https://issues.apache.org/jira/browse/WICKET-2803 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.7 Reporter: James Carman Currently, the constructors accept IModel> for the "model" of the ListMultipleChoice. Thus, you can't pass in an IModel>. The constructors should be modified to take IModel> instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2393) Passwords should not be trimmed
[ https://issues.apache.org/jira/browse/WICKET-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770124#action_12770124 ] James Carman commented on WICKET-2393: -- Is the consensus that the password field should never trim? I don't know about that. What if you copy/paste a password from your email and you accidentally include a space at the end or something? I have never used a leading/trailing space on my passwords (or a space in the middle for that matter). Is this a common practice? I like Juergen's suggestion of having the user override shouldTripInput() if they want a non-trimming password field. > Passwords should not be trimmed > --- > > Key: WICKET-2393 > URL: https://issues.apache.org/jira/browse/WICKET-2393 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.0 >Reporter: Olivier Ribardière >Assignee: Juergen Donnerstag >Priority: Minor > Fix For: 1.4.2 > > Attachments: WICKET-2393-fix.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > When using the SignInPanel, if password input field contains spaces at the > begining or at the end, they are trimmed by the PasswordTextField class. > Passwords should not be trimed. > Resolution is probably to override the convertValue method in the > PasswordTextField class. I provided a patch (attached to this issue), please > indicate if any problem with it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2165) Improve the API's Consistency and Flexibility With Respect to Generics and Collections
[ https://issues.apache.org/jira/browse/WICKET-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2165: - Attachment: WICKET-2165.patch Here's a patch that fixes Palette's second constructor. The "model" collection should not have been "widened". Thank you, Igor, for pointing that out. > Improve the API's Consistency and Flexibility With Respect to Generics and > Collections > -- > > Key: WICKET-2165 > URL: https://issues.apache.org/jira/browse/WICKET-2165 > Project: Wicket > Issue Type: Improvement > Components: wicket, wicket-extensions >Affects Versions: 1.4-RC2 >Reporter: James Carman > Attachments: WICKET-2165.patch > > > There have been discussions about how collections are treated inconsistently > in the Wicket API. For example, DropDownChoice allows a model of type > IModel> and ListView only allows a model of type > IModel>. The most flexible approach for these situations (for the > client code) is to allow IModel>. However, > merely synchronizing these two particular classes would leave other parts of > the API inconsistent (Palette, ListChoice, ListMultipleChoice, etc.). What > we need is a consistent approach to this situation across the entire API so > that the API is more cohesive and understandable (if the user sees this weird > syntax once they'll understand it everywhere). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2165) Improve the API's Consistency and Flexibility With Respect to Generics and Collections
[ https://issues.apache.org/jira/browse/WICKET-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2165: - Attachment: (was: WICKET-2165.patch) > Improve the API's Consistency and Flexibility With Respect to Generics and > Collections > -- > > Key: WICKET-2165 > URL: https://issues.apache.org/jira/browse/WICKET-2165 > Project: Wicket > Issue Type: Improvement > Components: wicket, wicket-extensions >Affects Versions: 1.4-RC2 >Reporter: James Carman > Attachments: WICKET-2165.patch > > > There have been discussions about how collections are treated inconsistently > in the Wicket API. For example, DropDownChoice allows a model of type > IModel> and ListView only allows a model of type > IModel>. The most flexible approach for these situations (for the > client code) is to allow IModel>. However, > merely synchronizing these two particular classes would leave other parts of > the API inconsistent (Palette, ListChoice, ListMultipleChoice, etc.). What > we need is a consistent approach to this situation across the entire API so > that the API is more cohesive and understandable (if the user sees this weird > syntax once they'll understand it everywhere). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2137) Synchronize generics between ListView and DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681622#action_12681622 ] James Carman commented on WICKET-2137: -- The problem was that some of the classes that I had changed (that would have fixed the errors) didn't get included in the patch because I created my patch from a specific "change list" in IDEA. I was working on patches for multiple issues today and I just got a bit confused (blame it on the bronchitis). I'm developing against trunk, so I hope I'm in sync. > Synchronize generics between ListView and DropDownChoice > > > Key: WICKET-2137 > URL: https://issues.apache.org/jira/browse/WICKET-2137 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-RC3 > Environment: 1.4-SNAPSHOT as of 2009-01-28 >Reporter: Brill Pappin > Attachments: TestGenerics.java > > > DropDownChoice has a generics definition of List in its > constructor. > This causes trouble with existing models that may be used in a DropDownChoice > and is not consistant with ListView which uses >. > Change DropDownChoice to match the other list type components so that their > models can be used across components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2165) Improve the API's Consistency and Flexibility With Respect to Generics and Collections
[ https://issues.apache.org/jira/browse/WICKET-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2165: - Attachment: WICKET-2165.patch Here's my first crack at the proposed API changes. Note that no unit test code had to be changed, so this appears to not "break" the API at all. The potential API break is where a user tries to modify the List model object. However, that appears to be an obscure usecase. > Improve the API's Consistency and Flexibility With Respect to Generics and > Collections > -- > > Key: WICKET-2165 > URL: https://issues.apache.org/jira/browse/WICKET-2165 > Project: Wicket > Issue Type: Improvement > Components: wicket, wicket-extensions >Affects Versions: 1.4-RC2 >Reporter: James Carman > Attachments: WICKET-2165.patch > > > There have been discussions about how collections are treated inconsistently > in the Wicket API. For example, DropDownChoice allows a model of type > IModel> and ListView only allows a model of type > IModel>. The most flexible approach for these situations (for the > client code) is to allow IModel>. However, > merely synchronizing these two particular classes would leave other parts of > the API inconsistent (Palette, ListChoice, ListMultipleChoice, etc.). What > we need is a consistent approach to this situation across the entire API so > that the API is more cohesive and understandable (if the user sees this weird > syntax once they'll understand it everywhere). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2137) Synchronize generics between ListView and DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681605#action_12681605 ] James Carman commented on WICKET-2137: -- Well, Brill, that's just the thing. In my IDE right now (I'm working on my patch), I haven't changed one test class at all. The existing test code works with the new API with no changes. All I've done is change some variable/parameter types here and there (there's a weird cast in ListView's . I don't think you want to release the "genericized wicket" version (which is what 1.4 is supposed to be) without getting the generics "right." > Synchronize generics between ListView and DropDownChoice > > > Key: WICKET-2137 > URL: https://issues.apache.org/jira/browse/WICKET-2137 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-RC3 > Environment: 1.4-SNAPSHOT as of 2009-01-28 >Reporter: Brill Pappin > Attachments: TestGenerics.java > > > DropDownChoice has a generics definition of List in its > constructor. > This causes trouble with existing models that may be used in a DropDownChoice > and is not consistant with ListView which uses >. > Change DropDownChoice to match the other list type components so that their > models can be used across components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2165) Improve the API's Consistency and Flexibility With Respect to Generics and Collections
Improve the API's Consistency and Flexibility With Respect to Generics and Collections -- Key: WICKET-2165 URL: https://issues.apache.org/jira/browse/WICKET-2165 Project: Wicket Issue Type: Improvement Components: wicket, wicket-extensions Affects Versions: 1.4-RC2 Reporter: James Carman There have been discussions about how collections are treated inconsistently in the Wicket API. For example, DropDownChoice allows a model of type IModel> and ListView only allows a model of type IModel>. The most flexible approach for these situations (for the client code) is to allow IModel>. However, merely synchronizing these two particular classes would leave other parts of the API inconsistent (Palette, ListChoice, ListMultipleChoice, etc.). What we need is a consistent approach to this situation across the entire API so that the API is more cohesive and understandable (if the user sees this weird syntax once they'll understand it everywhere). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2137) Synchronize generics between ListView and DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681600#action_12681600 ] James Carman commented on WICKET-2137: -- I've deleted my patch. I guess I didn't have all the necessary files in my "change list" in IDEA for this issue. Sorry for the mix-up. However, I'm working on a more pervasive change to the API that changes *all* instances where we have these issues to adhere to my proposal (the more I kept pulling, the more I had to change!). I'm going to create another issue and attach my patch there. If the core devs don't like my API change ideas, they can scrap it. I will also send an email to the users list asking for feedback on the proposed changes. I understand that my proposal doesn't exactly match what folks voted on, but I don't think all of the options were on the table at the time and the most vocal folks seemed to agree with my idea. Again, Jeremy, sorry for giving you a bad patch and wasting your time. That was totally my bad. > Synchronize generics between ListView and DropDownChoice > > > Key: WICKET-2137 > URL: https://issues.apache.org/jira/browse/WICKET-2137 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-RC3 > Environment: 1.4-SNAPSHOT as of 2009-01-28 >Reporter: Brill Pappin > Attachments: TestGenerics.java > > > DropDownChoice has a generics definition of List in its > constructor. > This causes trouble with existing models that may be used in a DropDownChoice > and is not consistant with ListView which uses >. > Change DropDownChoice to match the other list type components so that their > models can be used across components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2137) Synchronize generics between ListView and DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2137: - Attachment: (was: WICKET-2137.patch) > Synchronize generics between ListView and DropDownChoice > > > Key: WICKET-2137 > URL: https://issues.apache.org/jira/browse/WICKET-2137 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-RC3 > Environment: 1.4-SNAPSHOT as of 2009-01-28 >Reporter: Brill Pappin > Attachments: TestGenerics.java > > > DropDownChoice has a generics definition of List in its > constructor. > This causes trouble with existing models that may be used in a DropDownChoice > and is not consistant with ListView which uses >. > Change DropDownChoice to match the other list type components so that their > models can be used across components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2161) DropDownChoice NO_SELECTION_VALUE static field is final
[
https://issues.apache.org/jira/browse/WICKET-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681325#action_12681325
]
James Carman commented on WICKET-2161:
--
Better yet, the NO_SELECTION_VALUE should be a special type of object. Perhaps
an inner static class?
> DropDownChoice NO_SELECTION_VALUE static field is final
> ---
>
> Key: WICKET-2161
> URL: https://issues.apache.org/jira/browse/WICKET-2161
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.4
>Reporter: Ulrik Hagberg
>Priority: Minor
> Fix For: 1.3.6
>
>
> Lets say I do this:
> List _options = getOptions();
> someRenderer = new ChoiceRenderer() {
> ...
> }
> DropDownChoice _ddc = new DropDownChoice("dropDown", new Model((Serializable)
> _option),options, someRenderer);
> The Option class looks like this:
> public class Option {
> private String display_name;
> private String id;
> gettersAndSetters...
> }
> If I select an Option from the DDC, and that Option has id = -1, the
> AbstractSingleSelectChoice#getDefaultChoice(final Object selected) will
> interpret my choice as the protected static final String NO_SELECTION_VALUE =
> "-1" in AbstractSingleSelectChoice.java.
> The result will be that the "Choose one" option is visible in the DDC.
> Shouldn't the NO_SELECTION_VALUE be customizable?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2162) REGRESSION: PageParameters.put() No Longer Accepts Integers as Values
[
https://issues.apache.org/jira/browse/WICKET-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681307#action_12681307
]
James Carman commented on WICKET-2162:
--
You'd have to add instanceof Boolean, too.
> REGRESSION: PageParameters.put() No Longer Accepts Integers as Values
> -
>
> Key: WICKET-2162
> URL: https://issues.apache.org/jira/browse/WICKET-2162
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
>Reporter: James Carman
> Attachments: WICKET-2162.patch
>
>
> In 1.4-rc1 (and before) it was possible to do this:
> PageParameters params = new PageParameters();
> params.put("myint", 12345);
> In 1.4-rc2, it is not. This code change happened in revision 735338 which
> has the log message "changed IndexSharedResourceCodingStrategy.encode to use
> LinkedHashMap to avoid difference between Java 5 and 6. Tests should now pass
> irrespective of the jdk version" and was checked in by "jdonnerstag."
> I see no reason to be so strict on the types you can add to the
> PageParameters object, especially since the toRequestParameters() method
> already contains logic to convert the values to strings for types which it
> supports and it has the getInt() and getAsInteger() methods. Can we please
> back this out?
> I could perhaps see adding logic to check that it is indeed a type that is
> supported by the get*() methods, however.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2137) Synchronize generics between ListView and DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2137: - Attachment: WICKET-2137.patch Here's a patch that changes the API as I proposed. Notice that I didn't have to change any of the test code and the API still supported it. > Synchronize generics between ListView and DropDownChoice > > > Key: WICKET-2137 > URL: https://issues.apache.org/jira/browse/WICKET-2137 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-RC3 > Environment: 1.4-SNAPSHOT as of 2009-01-28 >Reporter: Brill Pappin > Attachments: TestGenerics.java, WICKET-2137.patch > > > DropDownChoice has a generics definition of List in its > constructor. > This causes trouble with existing models that may be used in a DropDownChoice > and is not consistant with ListView which uses >. > Change DropDownChoice to match the other list type components so that their > models can be used across components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2163) Make Palette's "Choices" Model More Generics Friendly
[ https://issues.apache.org/jira/browse/WICKET-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2163: - Attachment: (was: WICKET-2163.patch) > Make Palette's "Choices" Model More Generics Friendly > - > > Key: WICKET-2163 > URL: https://issues.apache.org/jira/browse/WICKET-2163 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4-RC2 >Reporter: James Carman > > The Palette class suffers from the same issues as ListView and > DropDownChoice. It should be fixed similarly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1936) Client-Side Image Map
[ https://issues.apache.org/jira/browse/WICKET-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1936: - Attachment: (was: ClientSideImageMap.patch) > Client-Side Image Map > - > > Key: WICKET-1936 > URL: https://issues.apache.org/jira/browse/WICKET-1936 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.5, 1.4-RC1 >Reporter: James Carman > Fix For: 1.5-M1 > > Attachments: WICKET-1936.patch > > > The existing ImageMap implementation does not allow you to "attach" it to any > Image component. Also, it only works with Link objects (and thus not > AjaxLinks or ExternalLinks). The new client-side image map implementation > attaches itself to any existing image and supports any AbstractLink object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1936) Client-Side Image Map
[ https://issues.apache.org/jira/browse/WICKET-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1936: - Attachment: WICKET-1936.patch Here's the implementation with test cases provided. > Client-Side Image Map > - > > Key: WICKET-1936 > URL: https://issues.apache.org/jira/browse/WICKET-1936 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.5, 1.4-RC1 >Reporter: James Carman > Fix For: 1.5-M1 > > Attachments: WICKET-1936.patch > > > The existing ImageMap implementation does not allow you to "attach" it to any > Image component. Also, it only works with Link objects (and thus not > AjaxLinks or ExternalLinks). The new client-side image map implementation > attaches itself to any existing image and supports any AbstractLink object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2162) REGRESSION: PageParameters.put() No Longer Accepts Integers as Values
[
https://issues.apache.org/jira/browse/WICKET-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated WICKET-2162:
-
Attachment: WICKET-2162.patch
Here's a patch that just removes the overridden put() method altogether. If
we're not changing the functionality, we don't need to override it. This also
removes the comment that says to put this logic back in 1.4.
> REGRESSION: PageParameters.put() No Longer Accepts Integers as Values
> -
>
> Key: WICKET-2162
> URL: https://issues.apache.org/jira/browse/WICKET-2162
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
>Reporter: James Carman
> Attachments: WICKET-2162.patch
>
>
> In 1.4-rc1 (and before) it was possible to do this:
> PageParameters params = new PageParameters();
> params.put("myint", 12345);
> In 1.4-rc2, it is not. This code change happened in revision 735338 which
> has the log message "changed IndexSharedResourceCodingStrategy.encode to use
> LinkedHashMap to avoid difference between Java 5 and 6. Tests should now pass
> irrespective of the jdk version" and was checked in by "jdonnerstag."
> I see no reason to be so strict on the types you can add to the
> PageParameters object, especially since the toRequestParameters() method
> already contains logic to convert the values to strings for types which it
> supports and it has the getInt() and getAsInteger() methods. Can we please
> back this out?
> I could perhaps see adding logic to check that it is indeed a type that is
> supported by the get*() methods, however.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2162) REGRESSION: PageParameters.put() No Longer Accepts Integers as Values
[
https://issues.apache.org/jira/browse/WICKET-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated WICKET-2162:
-
Description:
In 1.4-rc1 (and before) it was possible to do this:
PageParameters params = new PageParameters();
params.put("myint", 12345);
In 1.4-rc2, it is not. This code change happened in revision 735338 which has
the log message "changed IndexSharedResourceCodingStrategy.encode to use
LinkedHashMap to avoid difference between Java 5 and 6. Tests should now pass
irrespective of the jdk version" and was checked in by "jdonnerstag."
I see no reason to be so strict on the types you can add to the PageParameters
object, especially since the toRequestParameters() method already contains
logic to convert the values to strings for types which it supports and it has
the getInt() and getAsInteger() methods. Can we please back this out?
I could perhaps see adding logic to check that it is indeed a type that is
supported by the get*() methods, however.
was:
In 1.4-rc1 (and before) it was possible to do this:
PageParameters params = new PageParameters();
params.put("myint", 12345);
In 1.4-rc2, it is not. This code change happened in revision 735338 which has
the log message "changed IndexSharedResourceCodingStrategy.encode to use
LinkedHashMap to avoid difference between Java 5 and 6. Tests should now pass
irrespective of the jdk version" and was checked in by "jdonnerstag."
I see no reason to be so strict on the types you can add to the PageParameters
object, especially since ValueMap already contains logic to check which types
it supports (PageParameters overrides that for some reason) and it has the
getInt() and getAsInteger() methods. Can we please back this out?
> REGRESSION: PageParameters.put() No Longer Accepts Integers as Values
> -
>
> Key: WICKET-2162
> URL: https://issues.apache.org/jira/browse/WICKET-2162
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
>Reporter: James Carman
>
> In 1.4-rc1 (and before) it was possible to do this:
> PageParameters params = new PageParameters();
> params.put("myint", 12345);
> In 1.4-rc2, it is not. This code change happened in revision 735338 which
> has the log message "changed IndexSharedResourceCodingStrategy.encode to use
> LinkedHashMap to avoid difference between Java 5 and 6. Tests should now pass
> irrespective of the jdk version" and was checked in by "jdonnerstag."
> I see no reason to be so strict on the types you can add to the
> PageParameters object, especially since the toRequestParameters() method
> already contains logic to convert the values to strings for types which it
> supports and it has the getInt() and getAsInteger() methods. Can we please
> back this out?
> I could perhaps see adding logic to check that it is indeed a type that is
> supported by the get*() methods, however.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2163) Make Palette's "Choices" Model More Generics Friendly
[ https://issues.apache.org/jira/browse/WICKET-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-2163: - Attachment: WICKET-2163.patch Here's a patch that changes the choices model type to: IModel> > Make Palette's "Choices" Model More Generics Friendly > - > > Key: WICKET-2163 > URL: https://issues.apache.org/jira/browse/WICKET-2163 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4-RC2 >Reporter: James Carman > Attachments: WICKET-2163.patch > > > The Palette class suffers from the same issues as ListView and > DropDownChoice. It should be fixed similarly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2163) Make Palette's "Choices" Model More Generics Friendly
Make Palette's "Choices" Model More Generics Friendly - Key: WICKET-2163 URL: https://issues.apache.org/jira/browse/WICKET-2163 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4-RC2 Reporter: James Carman The Palette class suffers from the same issues as ListView and DropDownChoice. It should be fixed similarly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2162) REGRESSION: PageParameters.put() No Longer Accepts Integers as Values
[
https://issues.apache.org/jira/browse/WICKET-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated WICKET-2162:
-
Description:
In 1.4-rc1 (and before) it was possible to do this:
PageParameters params = new PageParameters();
params.put("myint", 12345);
In 1.4-rc2, it is not. This code change happened in revision 735338 which has
the log message "changed IndexSharedResourceCodingStrategy.encode to use
LinkedHashMap to avoid difference between Java 5 and 6. Tests should now pass
irrespective of the jdk version" and was checked in by "jdonnerstag."
I see no reason to be so strict on the types you can add to the PageParameters
object, especially since ValueMap already contains logic to check which types
it supports (PageParameters overrides that for some reason) and it has the
getInt() and getAsInteger() methods. Can we please back this out?
was:
In 1.4-rc1 (and before) it was possible to do this:
PageParameters params = new PageParameters();
params.put("myint", 12345);
In 1.4-rc2, it is not. This code changed happened in revision 735338 which has
the log message "changed IndexSharedResourceCodingStrategy.encode to use
LinkedHashMap to avoid difference between Java 5 and 6. Tests should now pass
irrespective of the jdk version" which was checked in by "jdonnerstag."
I see no reason to be so strict on the types you can add to the PageParameters
object, especially since ValueMap already contains logic to check which types
it supports (PageParameters overrides that for some reason) and it has the
getInt() and getAsInteger() methods. Can we please back this out?
> REGRESSION: PageParameters.put() No Longer Accepts Integers as Values
> -
>
> Key: WICKET-2162
> URL: https://issues.apache.org/jira/browse/WICKET-2162
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
>Reporter: James Carman
>
> In 1.4-rc1 (and before) it was possible to do this:
> PageParameters params = new PageParameters();
> params.put("myint", 12345);
> In 1.4-rc2, it is not. This code change happened in revision 735338 which
> has the log message "changed IndexSharedResourceCodingStrategy.encode to use
> LinkedHashMap to avoid difference between Java 5 and 6. Tests should now pass
> irrespective of the jdk version" and was checked in by "jdonnerstag."
> I see no reason to be so strict on the types you can add to the
> PageParameters object, especially since ValueMap already contains logic to
> check which types it supports (PageParameters overrides that for some reason)
> and it has the getInt() and getAsInteger() methods. Can we please back this
> out?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2162) REGRESSION: PageParameters.put() No Longer Accepts Integers as Values
REGRESSION: PageParameters.put() No Longer Accepts Integers as Values
-
Key: WICKET-2162
URL: https://issues.apache.org/jira/browse/WICKET-2162
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4-RC2
Reporter: James Carman
In 1.4-rc1 (and before) it was possible to do this:
PageParameters params = new PageParameters();
params.put("myint", 12345);
In 1.4-rc2, it is not. This code changed happened in revision 735338 which has
the log message "changed IndexSharedResourceCodingStrategy.encode to use
LinkedHashMap to avoid difference between Java 5 and 6. Tests should now pass
irrespective of the jdk version" which was checked in by "jdonnerstag."
I see no reason to be so strict on the types you can add to the PageParameters
object, especially since ValueMap already contains logic to check which types
it supports (PageParameters overrides that for some reason) and it has the
getInt() and getAsInteger() methods. Can we please back this out?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2137) Synchronize generics between ListView and DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679233#action_12679233 ] James Carman commented on WICKET-2137: -- That sounds like a better approach. Good idea! > Synchronize generics between ListView and DropDownChoice > > > Key: WICKET-2137 > URL: https://issues.apache.org/jira/browse/WICKET-2137 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-RC3 > Environment: 1.4-SNAPSHOT as of 2009-01-28 >Reporter: Brill Pappin > Attachments: TestGenerics.java > > > DropDownChoice has a generics definition of List in its > constructor. > This causes trouble with existing models that may be used in a DropDownChoice > and is not consistant with ListView which uses >. > Change DropDownChoice to match the other list type components so that their > models can be used across components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2137) Remove ? extends from constructor of DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679225#action_12679225 ] James Carman commented on WICKET-2137: -- Brill, if I buy you a Pepsi, will you close this JIRA? :) > Remove ? extends from constructor of DropDownChoice > --- > > Key: WICKET-2137 > URL: https://issues.apache.org/jira/browse/WICKET-2137 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-RC3 > Environment: 1.4-SNAPSHOT as of 2009-01-28 >Reporter: Brill Pappin > Attachments: TestGenerics.java > > > DropDownChoice has a generics definition of List in its > constructor. > This causes trouble with existing models that may be used in a DropDownChoice > and is not consistant with ListView which uses >. > Change DropDownChoice to match the other list type components so that their > models can be used across components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2137) Remove ? extends from constructor of DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679020#action_12679020 ] James Carman commented on WICKET-2137: -- Brill, I am for the wildcard (and my "extended wildcard") API for both ListView and DDC. It allows the most flexibility for the calling code. The calling code does not need to contain all of those wildcards at all. I don't know about the usecase of needing to remove stuff from the DDC or ListView's model. It doesn't seem that common to me. I suppose folks could do it, but as Johannes Schneider pointed out, they could simply cast it to do so (since they know the actual type). > Remove ? extends from constructor of DropDownChoice > --- > > Key: WICKET-2137 > URL: https://issues.apache.org/jira/browse/WICKET-2137 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-RC3 > Environment: 1.4-SNAPSHOT as of 2009-01-28 >Reporter: Brill Pappin > Attachments: TestGenerics.java > > > DropDownChoice has a generics definition of List in its > constructor. > This causes trouble with existing models that may be used in a DropDownChoice > and is not consistant with ListView which uses >. > Change DropDownChoice to match the other list type components so that their > models can be used across components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2137) Remove ? extends from constructor of DropDownChoice
[
https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678932#action_12678932
]
James Carman commented on WICKET-2137:
--
Brill, a List can have just as many types of things in it as List:
List serializables = Arrays.asList("Hello", new
Date(), 1, 0.0f, 0.0, true);
List withWildcard = serializables;
This compiles. However, you can't add things to the withWildcard list, because
you don't know what that wildcard *is*.
> Remove ? extends from constructor of DropDownChoice
> ---
>
> Key: WICKET-2137
> URL: https://issues.apache.org/jira/browse/WICKET-2137
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.4-RC3
> Environment: 1.4-SNAPSHOT as of 2009-01-28
>Reporter: Brill Pappin
> Attachments: TestGenerics.java
>
>
> DropDownChoice has a generics definition of List in its
> constructor.
> This causes trouble with existing models that may be used in a DropDownChoice
> and is not consistant with ListView which uses >.
> Change DropDownChoice to match the other list type components so that their
> models can be used across components.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-2137) Remove ? extends from constructor of DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678929#action_12678929 ] jwcarman edited comment on WICKET-2137 at 3/4/09 1:32 PM: -- So, the API for the IModel versions of the constructor(s) needs to be "widened" even farther. The parameters should be of type: IModel> You don't have to declare your models with wildcards in them at all with this approach. You can have an IModel> variable and you can pass it in for this parameter type. That will allow what Oliver is talking about. ListView should be changed to match. was (Author: jwcarman): So, the API for the IModel versions of the constructor(s) needs to be "widened" even farther. The parameters should be of type: IModel> That will allow what Oliver is talking about. ListView should be changed to match. > Remove ? extends from constructor of DropDownChoice > --- > > Key: WICKET-2137 > URL: https://issues.apache.org/jira/browse/WICKET-2137 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-RC3 > Environment: 1.4-SNAPSHOT as of 2009-01-28 >Reporter: Brill Pappin > Attachments: TestGenerics.java > > > DropDownChoice has a generics definition of List in its > constructor. > This causes trouble with existing models that may be used in a DropDownChoice > and is not consistant with ListView which uses >. > Change DropDownChoice to match the other list type components so that their > models can be used across components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2137) Remove ? extends from constructor of DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678929#action_12678929 ] James Carman commented on WICKET-2137: -- So, the API for the IModel versions of the constructor(s) needs to be "widened" even farther. The parameters should be of type: IModel> That will allow what Oliver is talking about. ListView should be changed to match. > Remove ? extends from constructor of DropDownChoice > --- > > Key: WICKET-2137 > URL: https://issues.apache.org/jira/browse/WICKET-2137 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-RC3 > Environment: 1.4-SNAPSHOT as of 2009-01-28 >Reporter: Brill Pappin > Attachments: TestGenerics.java > > > DropDownChoice has a generics definition of List in its > constructor. > This causes trouble with existing models that may be used in a DropDownChoice > and is not consistant with ListView which uses >. > Change DropDownChoice to match the other list type components so that their > models can be used across components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2137) Remove ? extends from constructor of DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678087#action_12678087 ] James Carman commented on WICKET-2137: -- We don't want to go the other way and allow List in ListView? If it makes it more flexible, then I don't see why we don't do it. I'd be -0.99 to changing DropDownChoice to be less flexible. > Remove ? extends from constructor of DropDownChoice > --- > > Key: WICKET-2137 > URL: https://issues.apache.org/jira/browse/WICKET-2137 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-RC3 > Environment: 1.4-SNAPSHOT as of 2009-01-28 >Reporter: Brill Pappin > > DropDownChoice has a generics definition of List in its > constructor. > This causes trouble with existing models that may be used in a DropDownChoice > and is not consistant with ListView which uses >. > Change DropDownChoice to match the other list type components so that their > models can be used across components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1561) Quickstart Build Failure: "No mojo descriptors found in plugin"
[ https://issues.apache.org/jira/browse/WICKET-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669375#action_12669375 ] James Carman commented on WICKET-1561: -- This issue is also almost a year old. So, some other plugin/feature may have changed, too. If the build works from a clean local repository (with maven 2.0.9), then I'm good with closing this issue. > Quickstart Build Failure: "No mojo descriptors found in plugin" > --- > > Key: WICKET-1561 > URL: https://issues.apache.org/jira/browse/WICKET-1561 > Project: Wicket > Issue Type: Bug > Components: wicket-quickstart >Affects Versions: 1.4-M1 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman >Assignee: Igor Vaynberg > Attachments: archetype-patch.patch > > > The artifact type should be changed to "maven-archetype" to fix this issue > (patch attached). See: > http://jira.codehaus.org/browse/MPLUGIN-102 > Here's my build output: > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Wicket Quickstart Archetype > [INFO]task-segment: [install] > [INFO] > > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin. > ' > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008 > [INFO] Final Memory: 9M/18M > [INFO] > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1950) JavaScriptEvent Enumeration
JavaScriptEvent Enumeration --- Key: WICKET-1950 URL: https://issues.apache.org/jira/browse/WICKET-1950 Project: Wicket Issue Type: Improvement Components: wicket Reporter: James Carman We should add an enum for JavaScript event types (onclick, onmouseover, onmouseout, etc.). Any code that takes a String for the event name (like behavior constructors) should either be rewritten/overridden to take the enum instead/also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1936) Client-Side Image Map
[ https://issues.apache.org/jira/browse/WICKET-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649608#action_12649608 ] James Carman commented on WICKET-1936: -- I need to fix that patch. The coordinates and type parameters to the Area class are reversed. Either the callers need to change how they're calling it or the parameters need to be switched. > Client-Side Image Map > - > > Key: WICKET-1936 > URL: https://issues.apache.org/jira/browse/WICKET-1936 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.5, 1.4-RC1 >Reporter: James Carman > Attachments: ClientSideImageMap.patch > > > The existing ImageMap implementation does not allow you to "attach" it to any > Image component. Also, it only works with Link objects (and thus not > AjaxLinks or ExternalLinks). The new client-side image map implementation > attaches itself to any existing image and supports any AbstractLink object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-1456) ImageMap blocks Image functionality
[ https://issues.apache.org/jira/browse/WICKET-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648143#action_12648143 ] jwcarman edited comment on WICKET-1456 at 11/17/08 3:35 AM: You might want to check out my ClientSideImageMap implementation. I've linked the JIRA for it to this issue. was (Author: jwcarman): You might want to check out my ClientSideImageMap implementation. > ImageMap blocks Image functionality > --- > > Key: WICKET-1456 > URL: https://issues.apache.org/jira/browse/WICKET-1456 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.2 >Reporter: Martijn Vos > Fix For: 1.5-M1 > > Attachments: wicket-1456.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > ImageMap is applied to an img tag, which means you can't apply an Image to > that tag anymore. Since ImageMap does not supply the functionality of Image, > this means it's impossible to treat an imagemap's image like a Wicket image > (including dynamic rendering). And because ImageMap is final (why?), it's > also not possible to extend it and add that functionality. > I see three possible fixes: > 1: The easiest and ugliest fix: make ImageMap not final, and have the user > figure it out. > 2: Add Image functionality to ImageMap. This duplicates functionality (since > ImageMap can't inherit directly from Image), and might give problems in the > future when new functionality is added to Image. > 3: Consider the current ImageMap broken, and replace it with a different > approach: apply ImageMap to a tag, use a regular image for the > part, and add to Image a method to link it to an ImageMap. I prefer the third > solution, although it will break compatibility with existing ImageMaps. > Perhaps a new DynamicImageMap could be added? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1936) Client-Side Image Map
[ https://issues.apache.org/jira/browse/WICKET-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1936: - Attachment: ClientSideImageMap.patch Here's the implementation. I'll create test cases and attach a full patch later. I just wanted to get the discussion rolling on the implementation. > Client-Side Image Map > - > > Key: WICKET-1936 > URL: https://issues.apache.org/jira/browse/WICKET-1936 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.5, 1.4-RC1 >Reporter: James Carman > Attachments: ClientSideImageMap.patch > > > The existing ImageMap implementation does not allow you to "attach" it to any > Image component. Also, it only works with Link objects (and thus not > AjaxLinks or ExternalLinks). The new client-side image map implementation > attaches itself to any existing image and supports any AbstractLink object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1936) Client-Side Image Map
Client-Side Image Map - Key: WICKET-1936 URL: https://issues.apache.org/jira/browse/WICKET-1936 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC1, 1.3.5 Reporter: James Carman The existing ImageMap implementation does not allow you to "attach" it to any Image component. Also, it only works with Link objects (and thus not AjaxLinks or ExternalLinks). The new client-side image map implementation attaches itself to any existing image and supports any AbstractLink object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1830) Include Component Path in Generated Markup
[ https://issues.apache.org/jira/browse/WICKET-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630707#action_12630707 ] James Carman commented on WICKET-1830: -- As I mentioned in the email thread, I'd like to try to take a stab at this one. I'll try to submit a patch soon. > Include Component Path in Generated Markup > -- > > Key: WICKET-1830 > URL: https://issues.apache.org/jira/browse/WICKET-1830 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: James Carman >Priority: Minor > > For unit testing purposes, it would be nice to know the exact ids of the > components on your wicket pages. Perhaps the generated markup could contain > a wicket:path attribute? > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1830) Include Component Path in Generated Markup
Include Component Path in Generated Markup -- Key: WICKET-1830 URL: https://issues.apache.org/jira/browse/WICKET-1830 Project: Wicket Issue Type: Improvement Components: wicket Reporter: James Carman Priority: Minor For unit testing purposes, it would be nice to know the exact ids of the components on your wicket pages. Perhaps the generated markup could contain a wicket:path attribute? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-767) Generify IModel
[
https://issues.apache.org/jira/browse/WICKET-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604676#action_12604676
]
James Carman commented on WICKET-767:
-
Isn't this already done? I'm pretty sure the consensus is that we at least
need to generify IModel and it's already done. So, are we good to
resolve/close this?
> Generify IModel
> ---
>
> Key: WICKET-767
> URL: https://issues.apache.org/jira/browse/WICKET-767
> Project: Wicket
> Issue Type: Wish
>Reporter: Willis Boyce
> Fix For: 1.4-M3
>
>
> I find myself writing custom IModel implementations that depend on the
> underlying object being some specific type. It would be nice if I could get
> some type safety using generics, e.g.
> class MyCustomModel implements IModel
> {
> MyCustomObject getObject(Component component) { ... }
> ...
> }
> I imagine that this has already been suggested, but I couldn't find a JIRA
> issue about it in the road map.
> I don't think that the core Wicket code would change too much, except in
> cases where the code actually cared what was in the model. Elsewhere it can
> just use IModel.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1699) NPE in RequestLogger
[ https://issues.apache.org/jira/browse/WICKET-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604672#action_12604672 ] James Carman commented on WICKET-1699: -- In case anyone's interested, it looks like this was fixed in revision 661205. > NPE in RequestLogger > > > Key: WICKET-1699 > URL: https://issues.apache.org/jira/browse/WICKET-1699 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-M2 >Reporter: Craig McIlwee > Fix For: 1.4-M3 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > RequestLogger throws an NPE at line 200 because the field 'active' is never > assigned a value when the class is instantiated. In older versions (I am > migrating from 1.3.3) this field was just a native int so the value would > default to 0, but sometime between 1.3.3 and 1.4m2 it has changed to an > AtomicInteger and never assigned a value via new AtomicInteger() or new > AtomicInteger(someInt). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1312) Generic inter-component event mechanism
[ https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604674#action_12604674 ] James Carman commented on WICKET-1312: -- Are we going to introduce this stuff in 1.4? I thought 1.4 was all about generification? > Generic inter-component event mechanism > --- > > Key: WICKET-1312 > URL: https://issues.apache.org/jira/browse/WICKET-1312 > Project: Wicket > Issue Type: New Feature > Components: wicket-extensions >Affects Versions: 1.3.0-final >Reporter: Timo Rantalaiho > Fix For: 1.4-M3 > > Attachments: event-handler-with-testcase.zip, > Generic_EventBroadcaster.patch, > Generic_EventBroadcaster_glued_in_Component.patch > > > The attached patch provides a generic mechanism for transmitting > inter-component events within a page. This has grown primarily from the need > to repaint all relevant ajax components after an event, but can be used also > in non-ajax environments such as after normal form submits. > The basic idea is to fire an IVisitor on the page of the component sending an > event, giving as an argument an event-specific listener interface that must > be implemented by the components willing to receive the events. They can then > do whatever they need such as add themselves to the AjaxRequestTarget that > can be supplied in the event. > Sometimes the basic Wicket mechanisms such as sharing a model are not enough; > particularly repainting all relevant components in Ajax events gets tedious > if the components are far away from each other in a complex DOM tree. > The benefits of this approach are > - loose coupling between the sending and receiving end > - however, because of strong static typing it's easy enough to find with an > IDE from where the events are broadcasted and where they are received > - good testability (EventBroadcaster can be mocked on the sending end, and > event handlers tested directly on the receiving end, possibly with mock > events) > - no need the keep references to Component instances or their paths (which > could have been problematic on repeaters) > (This is not a real observer or listener pattern implementation because the > components cannot register and unregister themselves dynamically, but > "registering" is handled statically on a class basis by implementing the > relevant event receiver interface.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1699) NPE in RequestLogger
[ https://issues.apache.org/jira/browse/WICKET-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604671#action_12604671 ] James Carman commented on WICKET-1699: -- Looks like Igor already fixed this one. Can someone please resolve/close it? > NPE in RequestLogger > > > Key: WICKET-1699 > URL: https://issues.apache.org/jira/browse/WICKET-1699 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-M2 >Reporter: Craig McIlwee > Fix For: 1.4-M3 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > RequestLogger throws an NPE at line 200 because the field 'active' is never > assigned a value when the class is instantiated. In older versions (I am > migrating from 1.3.3) this field was just a native int so the value would > default to 0, but sometime between 1.3.3 and 1.4m2 it has changed to an > AtomicInteger and never assigned a value via new AtomicInteger() or new > AtomicInteger(someInt). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1696) CaptchaImageResource - should take an IModel instead of String for captcha-text
[ https://issues.apache.org/jira/browse/WICKET-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604666#action_12604666 ] James Carman commented on WICKET-1696: -- Should this be moved to m3, since m2 is already out the door? > CaptchaImageResource - should take an IModel instead of String for > captcha-text > --- > > Key: WICKET-1696 > URL: https://issues.apache.org/jira/browse/WICKET-1696 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Reporter: Stefan Simik > Fix For: 1.4-M2 > > Original Estimate: 0.33h > Remaining Estimate: 0.33h > > CaptchaImageResource - should take an IModel instead of String for > captcha-text -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597766#action_12597766 ] James Carman commented on WICKET-1358: -- Any chance this could make it into one of the 1.4-m* releases or do we think this definitely needs to wait for 1.5? > Make Application Class More Bean-ish > > > Key: WICKET-1358 > URL: https://issues.apache.org/jira/browse/WICKET-1358 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.1 >Reporter: James Carman >Assignee: Johan Compagner > Fix For: 1.5-M1 > > Attachments: WICKET-1358.patch > > > The Application class has getters for properties like applicationSettings and > securitySettings. Couldn't we make those properties writable also? I > realize that the internal implementation might have to change a bit. > Currently, the Settings class implements all of those interfaces and it uses > a single instance of Settings by default. The reason that I want this is so > that I can set up my Application object in Spring and access it via > wicket-spring. The current implementation of Application doesn't facilitate > the "set up" part very well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596798#action_12596798 ] James Carman commented on WICKET-1428: -- Peter, I'm not a big fan of the "wicket:up" string, since it's too verbose. But, I agree we should pick something that means "go up one level" and just use that. You didn't like the idea of using two colons "::"? Colons are already used in Wicket, so it might kind of stick with the "theme" better. I'm glad you did some of the legwork on this (I had no idea where to look). It seems like an easy fix. We'd just need to unit test the heck out of it so that we don't break stuff (and nobody else breaks it in the future). > AutoLinkResolver and Parent-Relative (../) Links > > > Key: WICKET-1428 > URL: https://issues.apache.org/jira/browse/WICKET-1428 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.2 >Reporter: James Carman > Fix For: 1.5-M1 > > Attachments: wicket-1428-use-wicket-up.patch, WICKET-1428.patch, > wicket-link-outside-of-package.zip > > > Suppose I have a package structure like this: > com.mycompany.myproject > --- module1 > --- page > - Page1.html > --- module2 > --- page > - Page2.html > If I want to autolink from Page1.html to Page2.html, it would look like: > > Click Here! > > This is not working, however. The AutoLinkResolver spits out a warning > message: > "WARN - AutoLinkResolver - Did not find corresponding java class: > .module2.page.Page2" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595277#action_12595277 ] James Carman commented on WICKET-271: - I don't mind helping, but I'm definitely not the best-qualified Javascript person. Would someone be willing to help point me in the right direction? > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595268#action_12595268 ] jwcarman edited comment on WICKET-271 at 5/8/08 7:39 AM: - If you don't want to globally enable it, perhaps you can add it in as a behavior (AjaxBackButtonSupportBehavior)? This could be added to your page? was (Author: jwcarman): If you don't want to globally enable it, perhaps you can add it in as a behavior (AjaxBackButtonSupportBehavior)? > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595268#action_12595268 ] James Carman commented on WICKET-271: - If you don't want to globally enable it, perhaps you can add it in as a behavior (AjaxBackButtonSupportBehavior)? > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595259#action_12595259 ] James Carman commented on WICKET-271: - Or, perhaps this: http://developer.yahoo.com/yui/history/ > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595258#action_12595258 ] James Carman commented on WICKET-271: - Has anyone looked into RSH for this? http://code.google.com/p/reallysimplehistory/ It's BSD-licensed, so it's ASF license compatible. > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1584) FragmentColumn
[ https://issues.apache.org/jira/browse/WICKET-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1584: - Attachment: WICKET-1584.patch > FragmentColumn > -- > > Key: WICKET-1584 > URL: https://issues.apache.org/jira/browse/WICKET-1584 > Project: Wicket > Issue Type: New Feature > Components: wicket-extensions >Affects Versions: 1.4-M1 >Reporter: James Carman >Priority: Minor > Attachments: WICKET-1584.patch > > > An abstract column superclass which allows subclasses to provide a Fragment > which displays the contents of the cell. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1584) FragmentColumn
FragmentColumn -- Key: WICKET-1584 URL: https://issues.apache.org/jira/browse/WICKET-1584 Project: Wicket Issue Type: New Feature Components: wicket-extensions Affects Versions: 1.4-M1 Reporter: James Carman Priority: Minor Attachments: WICKET-1584.patch An abstract column superclass which allows subclasses to provide a Fragment which displays the contents of the cell. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593962#action_12593962 ] James Carman commented on WICKET-1428: -- Could we use "..." (three dots) or ",," (two commas) or "::" (two colons)? We just need to trick the browser into not interpreting the "go up" part of the links. > AutoLinkResolver and Parent-Relative (../) Links > > > Key: WICKET-1428 > URL: https://issues.apache.org/jira/browse/WICKET-1428 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.2 >Reporter: James Carman > Fix For: 1.5-M1 > > Attachments: WICKET-1428.patch, wicket-link-outside-of-package.zip > > > Suppose I have a package structure like this: > com.mycompany.myproject > --- module1 > --- page > - Page1.html > --- module2 > --- page > - Page2.html > If I want to autolink from Page1.html to Page2.html, it would look like: > > Click Here! > > This is not working, however. The AutoLinkResolver spits out a warning > message: > "WARN - AutoLinkResolver - Did not find corresponding java class: > .module2.page.Page2" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1561) Quickstart Build Failure: "No mojo descriptors found in plugin"
[ https://issues.apache.org/jira/browse/WICKET-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591702#action_12591702 ] James Carman commented on WICKET-1561: -- In the maven bug report, I showed how locking it down to 2.3 made it work. But, the way you're supposed to do it going forward it to use maven-archetype. What version of Maven are you using? > Quickstart Build Failure: "No mojo descriptors found in plugin" > --- > > Key: WICKET-1561 > URL: https://issues.apache.org/jira/browse/WICKET-1561 > Project: Wicket > Issue Type: Bug > Components: wicket-quickstart >Affects Versions: 1.4-M1 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-patch.patch > > > The artifact type should be changed to "maven-archetype" to fix this issue > (patch attached). See: > http://jira.codehaus.org/browse/MPLUGIN-102 > Here's my build output: > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Wicket Quickstart Archetype > [INFO]task-segment: [install] > [INFO] > > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin. > ' > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008 > [INFO] Final Memory: 9M/18M > [INFO] > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1561) Quickstart Build Failure: "No mojo descriptors found in plugin"
[ https://issues.apache.org/jira/browse/WICKET-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591632#action_12591632 ] James Carman commented on WICKET-1561: -- Well, the other way to fix this is to "lock down" the maven-plugin-plugin version. Do you have that locked down somewhere or are you building from a clean "trunk"? I just checked out the trunk and tried a clean build and it failed (with the error message as I described). > Quickstart Build Failure: "No mojo descriptors found in plugin" > --- > > Key: WICKET-1561 > URL: https://issues.apache.org/jira/browse/WICKET-1561 > Project: Wicket > Issue Type: Bug > Components: wicket-quickstart >Affects Versions: 1.4-M1 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-patch.patch > > > The artifact type should be changed to "maven-archetype" to fix this issue > (patch attached). See: > http://jira.codehaus.org/browse/MPLUGIN-102 > Here's my build output: > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Wicket Quickstart Archetype > [INFO]task-segment: [install] > [INFO] > > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin. > ' > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008 > [INFO] Final Memory: 9M/18M > [INFO] > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1561) Quickstart Build Failure: "No mojo descriptors found in plugin"
[
https://issues.apache.org/jira/browse/WICKET-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated WICKET-1561:
-
Description:
The artifact type should be changed to "maven-archetype" to fix this issue
(patch attached). See:
http://jira.codehaus.org/browse/MPLUGIN-102
Here's my build output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Wicket Quickstart Archetype
[INFO]task-segment: [install]
[INFO]
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 0 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error extracting plugin descriptor: 'No mojo descriptors found in plugin.
'
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008
[INFO] Final Memory: 9M/18M
[INFO]
was:
The artifact type should be changed to "maven-archetype" to fix this issue
(patch attached). See:
http://jira.codehaus.org/browse/MPLUGIN-102
Here's my build output:
{noformat}
[INFO] Scanning for projects...
[INFO]
[INFO] Building Wicket Quickstart Archetype
[INFO]task-segment: [install]
[INFO]
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 0 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error extracting plugin descriptor: 'No mojo descriptors found in plugin.
'
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008
[INFO] Final Memory: 9M/18M
[INFO]
{noformat}
> Quickstart Build Failure: "No mojo descriptors found in plugin"
> ---
>
> Key: WICKET-1561
> URL: https://issues.apache.org/jira/browse/WICKET-1561
> Project: Wicket
> Issue Type: Bug
> Components: wicket-quickstart
>Affects Versions: 1.4-M1
> Environment: Maven version: 2.0.8
> Java version: 1.5.0_14
> OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows"
>Reporter: James Carman
> Attachments: archetype-patch.patch
>
>
> The artifact type should be changed to "maven-archetype" to fix this issue
> (patch attached). See:
> http://jira.codehaus.org/browse/MPLUGIN-102
> Here's my build output:
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Wicket Quickstart Archetype
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [plugin:descriptor]
> [INFO] Using 2 extractors.
> [INFO] Applying extractor for language: java
> [INFO] Extractor for language: java found 0 mojo descriptors.
> [INFO] Applying extractor for language: bsh
> [INFO] Extractor for language: bsh found 0 mojo descriptors.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in
> plugin.
> '
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008
> [INFO] Final Memory: 9M/18M
> [INFO]
> -
[jira] Updated: (WICKET-1561) Quickstart Build Failure: "No mojo descriptors found in plugin"
[
https://issues.apache.org/jira/browse/WICKET-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated WICKET-1561:
-
Description:
The artifact type should be changed to "maven-archetype" to fix this issue
(patch attached). See:
http://jira.codehaus.org/browse/MPLUGIN-102
Here's my build output:
{noformat}
[INFO] Scanning for projects...
[INFO]
[INFO] Building Wicket Quickstart Archetype
[INFO]task-segment: [install]
[INFO]
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 0 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error extracting plugin descriptor: 'No mojo descriptors found in plugin.
'
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008
[INFO] Final Memory: 9M/18M
[INFO]
{noformat}
was:
The artifact type should be changed to "maven-archetype" to fix this issue
(patch attached). See:
http://jira.codehaus.org/browse/MPLUGIN-102
Here's my build output:
{panel}
[INFO] Scanning for projects...
[INFO]
[INFO] Building Wicket Quickstart Archetype
[INFO]task-segment: [install]
[INFO]
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 0 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error extracting plugin descriptor: 'No mojo descriptors found in plugin.
'
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008
[INFO] Final Memory: 9M/18M
[INFO]
{panel}
> Quickstart Build Failure: "No mojo descriptors found in plugin"
> ---
>
> Key: WICKET-1561
> URL: https://issues.apache.org/jira/browse/WICKET-1561
> Project: Wicket
> Issue Type: Bug
> Components: wicket-quickstart
>Affects Versions: 1.4-M1
> Environment: Maven version: 2.0.8
> Java version: 1.5.0_14
> OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows"
>Reporter: James Carman
> Attachments: archetype-patch.patch
>
>
> The artifact type should be changed to "maven-archetype" to fix this issue
> (patch attached). See:
> http://jira.codehaus.org/browse/MPLUGIN-102
> Here's my build output:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Wicket Quickstart Archetype
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [plugin:descriptor]
> [INFO] Using 2 extractors.
> [INFO] Applying extractor for language: java
> [INFO] Extractor for language: java found 0 mojo descriptors.
> [INFO] Applying extractor for language: bsh
> [INFO] Extractor for language: bsh found 0 mojo descriptors.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in
> plugin.
> '
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008
> [INFO] Final Memory: 9M/18M
> [INFO]
> --
[jira] Updated: (WICKET-1561) Quickstart Build Failure: "No mojo descriptors found in plugin"
[
https://issues.apache.org/jira/browse/WICKET-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated WICKET-1561:
-
Description:
The artifact type should be changed to "maven-archetype" to fix this issue
(patch attached). See:
http://jira.codehaus.org/browse/MPLUGIN-102
Here's my build output:
{panel}
[INFO] Scanning for projects...
[INFO]
[INFO] Building Wicket Quickstart Archetype
[INFO]task-segment: [install]
[INFO]
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 0 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error extracting plugin descriptor: 'No mojo descriptors found in plugin.
'
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008
[INFO] Final Memory: 9M/18M
[INFO]
{panel}
was:
The artifact type should be changed to "maven-archetype" to fix this issue
(patch attached). See:
http://jira.codehaus.org/browse/MPLUGIN-102
Here's my build output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Wicket Quickstart Archetype
[INFO]task-segment: [install]
[INFO]
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 0 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error extracting plugin descriptor: 'No mojo descriptors found in plugin.
'
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008
[INFO] Final Memory: 9M/18M
[INFO]
> Quickstart Build Failure: "No mojo descriptors found in plugin"
> ---
>
> Key: WICKET-1561
> URL: https://issues.apache.org/jira/browse/WICKET-1561
> Project: Wicket
> Issue Type: Bug
> Components: wicket-quickstart
>Affects Versions: 1.4-M1
> Environment: Maven version: 2.0.8
> Java version: 1.5.0_14
> OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows"
>Reporter: James Carman
> Attachments: archetype-patch.patch
>
>
> The artifact type should be changed to "maven-archetype" to fix this issue
> (patch attached). See:
> http://jira.codehaus.org/browse/MPLUGIN-102
> Here's my build output:
> {panel}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Wicket Quickstart Archetype
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [plugin:descriptor]
> [INFO] Using 2 extractors.
> [INFO] Applying extractor for language: java
> [INFO] Extractor for language: java found 0 mojo descriptors.
> [INFO] Applying extractor for language: bsh
> [INFO] Extractor for language: bsh found 0 mojo descriptors.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in
> plugin.
> '
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008
> [INFO] Final Memory: 9M/18M
> [INFO]
> --
[jira] Updated: (WICKET-1561) Quickstart Build Failure: "No mojo descriptors found in plugin"
[ https://issues.apache.org/jira/browse/WICKET-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1561: - Description: The artifact type should be changed to "maven-archetype" to fix this issue (patch attached). See: http://jira.codehaus.org/browse/MPLUGIN-102 Here's my build output: [INFO] Scanning for projects... [INFO] [INFO] Building Wicket Quickstart Archetype [INFO]task-segment: [install] [INFO] [INFO] [plugin:descriptor] [INFO] Using 2 extractors. [INFO] Applying extractor for language: java [INFO] Extractor for language: java found 0 mojo descriptors. [INFO] Applying extractor for language: bsh [INFO] Extractor for language: bsh found 0 mojo descriptors. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in plugin. ' [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008 [INFO] Final Memory: 9M/18M [INFO] was: The artifact type should be changed to "maven-archetype" to fix this issue (patch attached). See: http://jira.codehaus.org/browse/MPLUGIN-102 > Quickstart Build Failure: "No mojo descriptors found in plugin" > --- > > Key: WICKET-1561 > URL: https://issues.apache.org/jira/browse/WICKET-1561 > Project: Wicket > Issue Type: Bug > Components: wicket-quickstart >Affects Versions: 1.4-M1 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-patch.patch > > > The artifact type should be changed to "maven-archetype" to fix this issue > (patch attached). See: > http://jira.codehaus.org/browse/MPLUGIN-102 > Here's my build output: > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Wicket Quickstart Archetype > [INFO]task-segment: [install] > [INFO] > > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin. > ' > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008 > [INFO] Final Memory: 9M/18M > [INFO] > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1561) Quickstart Build Failure: "No mojo descriptors found in plugin"
[ https://issues.apache.org/jira/browse/WICKET-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1561: - Attachment: archetype-patch.patch > Quickstart Build Failure: "No mojo descriptors found in plugin" > --- > > Key: WICKET-1561 > URL: https://issues.apache.org/jira/browse/WICKET-1561 > Project: Wicket > Issue Type: Bug > Components: wicket-quickstart >Affects Versions: 1.4-M1 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-patch.patch > > > The artifact type should be changed to "maven-archetype" to fix this issue > (patch attached). See: > http://jira.codehaus.org/browse/MPLUGIN-102 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
