[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-tabpanelfocusedCommentId=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] [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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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] 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-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] 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] 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-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] 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 IProviderIExceptionMapper 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] 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: (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] Commented: (WICKET-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 IProviderIExceptionMapper 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] 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] 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] 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: (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: - 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] Commented: (WICKET-3256) Use a Provider for IExceptionMapper
[ https://issues.apache.org/jira/browse/WICKET-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 thead wicket:id=topToolbars
[
https://issues.apache.org/jira/browse/WICKET-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:
wicket:panel
span wicket:id=topToolbars
span wicket:id=toolbar/span
/span
tr wicket:id=rows
td wicket:id=cells
span wicket:id=cell[cell]/span
/td
/tr
span wicket:id=bottomToolbars
span wicket:id=toolbar/span
/span
/wicket:panel
In 1.4.6, my page fails to render. In 1.4.5, it works fine.
DataTable generates two thead wicket:id=topToolbars
---
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 thead 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}
table class=dataview cellspacing=0
tr class=navigation
{html}
When you look at
http://www.wicket-library.com/wicket-examples/repeater/?wicket:bookmarkablePage=:org.apache.wicket.examples.repeater.DataTablePage
it shows:
{html}
table class=dataview cellspacing=0
thead
tr class=navigation
{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] Created: (WICKET-2817) ChoiceGroup's Constructor should take IModel? extends CollectionT
ChoiceGroup's Constructor should take IModel? extends CollectionT - 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] Updated: (WICKET-2817) ChoiceGroup's Constructor Should Accept IModel? extends CollectionT
[ 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? extends CollectionT (was: ChoiceGroup's Constructor should take IModel? extends CollectionT) ChoiceGroup's Constructor Should Accept IModel? extends CollectionT --- 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] Commented: (WICKET-2817) ChoiceGroup's Constructor Should Accept IModel? extends CollectionT
[ https://issues.apache.org/jira/browse/WICKET-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852860#action_12852860 ] James Carman commented on WICKET-2817: -- Thanks again! ChoiceGroup's Constructor Should Accept IModel? extends CollectionT --- 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-2821) More IModel? extends Collection Fixes
[ 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? extends Collection Fixes (was: More IModel? extends Collection? extends T Fixes) More IModel? extends Collection 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 Priority: Minor Fix For: 1.5-M1 I searched the code for all occurrences of IModelCollection and replaced all that I thought could be replaced with IModel? extends Collection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2821) More IModel? extends Collection? extends T Fixes
More IModel? extends Collection? extends T 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 IModelCollection and replaced all that I thought could be replaced with IModel? extends Collection. -- 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? extends Collection Fixes
[ 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? extends Collection 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 Priority: Minor Fix For: 1.5-M1 Attachments: WICKET-2821.patch I searched the code for all occurrences of IModelCollection and replaced all that I thought could be replaced with IModel? extends Collection. -- 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? extends CollectionT
ListMultipleChoice's Constructors Should Accept IModel? extends CollectionT --- 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 IModelCollectionT for the model of the ListMultipleChoice. Thus, you can't pass in an IModelSetT. The constructors should be modified to take IModel? extends CollectionT 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? extends CollectionT
[ 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? extends CollectionT to IModelCollectionT. I couldn't monkey with the generics declaration on the class to say that it takes IModel? extends CollectionT because the class definition doesn't accept wildcards. I think this is okay, though. ListMultipleChoice's Constructors Should Accept IModel? extends CollectionT --- 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 IModelCollectionT for the model of the ListMultipleChoice. Thus, you can't pass in an IModelSetT. The constructors should be modified to take IModel? extends CollectionT 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? extends CollectionT
[ 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? extends CollectionT --- 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 IModelCollectionT for the model of the ListMultipleChoice. Thus, you can't pass in an IModelSetT. The constructors should be modified to take IModel? extends CollectionT 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-2803) ListMultipleChoice's Constructors Should Accept IModel? extends CollectionT
[ https://issues.apache.org/jira/browse/WICKET-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12849988#action_12849988 ] James Carman commented on WICKET-2803: -- Thank you, sir! ListMultipleChoice's Constructors Should Accept IModel? extends CollectionT --- 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 IModelCollectionT for the model of the ListMultipleChoice. Thus, you can't pass in an IModelSetT. The constructors should be modified to take IModel? extends CollectionT 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-tabpanelfocusedCommentId=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-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] 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? extends Collection? extends T 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] 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-tabpanelfocusedCommentId=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? extends T in its constructor. This causes trouble with existing models that may be used in a DropDownChoice and is not consistant with ListView which uses ListT. 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) Synchronize generics between ListView and DropDownChoice
[ https://issues.apache.org/jira/browse/WICKET-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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? extends T in its constructor. This causes trouble with existing models that may be used in a DropDownChoice and is not consistant with ListView which uses ListT. 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? extends T 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 IModelList? extends T and ListView only allows a model of type IModelListT. The most flexible approach for these situations (for the client code) is to allow IModel? extends List? extends T. 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] 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-tabpanelfocusedCommentId=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? extends List? extends T You don't have to declare your models with wildcards in them at all with this approach. You can have an IModelListInteger 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? extends List? extends T 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? extends T in its constructor. This causes trouble with existing models that may be used in a DropDownChoice and is not consistant with ListView which uses ListT. 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-tabpanelfocusedCommentId=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? extends T in its constructor. This causes trouble with existing models that may be used in a DropDownChoice and is not consistant with ListView which uses ListT. 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-tabpanelfocusedCommentId=12678087#action_12678087 ] James Carman commented on WICKET-2137: -- We don't want to go the other way and allow List? extends T 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? extends T in its constructor. This causes trouble with existing models that may be used in a DropDownChoice and is not consistant with ListView which uses ListT. 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 map tag, use a regular image for the img 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] 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] 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-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? div wicket:path=some:path:to:this:div -- 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-tabpanelfocusedCommentId=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? div wicket:path=some:path:to:this:div -- 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 IModelString instead of String for captcha-text
[ https://issues.apache.org/jira/browse/WICKET-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 IModelString 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 IModelString 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-1699) NPE in RequestLogger
[ https://issues.apache.org/jira/browse/WICKET-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1699) NPE in RequestLogger
[ https://issues.apache.org/jira/browse/WICKET-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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-tabpanelfocusedCommentId=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] Commented: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] Commented: (WICKET-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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] 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] 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] 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.
[jira] Created: (WICKET-1561) Quickstart Build Failure: No mojo descriptors found in plugin
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.
[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:
-
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]
{panel}
--
This
[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:
[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]
--
This message is
[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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588539#action_12588539 ] James Carman commented on WICKET-1428: -- Anchor as in a tags, not (necessarily) anchors on a page. So, I guess I tested it with hyperlinks would be a better way to say it. The original description shows the use case I used to test it. 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 Assignee: Igor Vaynberg Fix For: 1.3.3 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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588716#action_12588716 ] James Carman commented on WICKET-1428: -- I don't see a problem with URLs like: resources/markup.level1.level2.level3.page.TestPage/../../../../base.js The ../ when dealing with a class name (such as we have here) means to go up to the parent package to look for the package-relative resource. Correct? To me, it's just a matter of making the resource handling logic understand resource URLs with this ../ stuff in it. Again, I'm no expert on the internals of Wicket like you folks. This is just my view from the outside. 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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588735#action_12588735 ] James Carman commented on WICKET-1428: -- Ooh! Yuck! I didn't realize the browser would be that smart when it saw a weird URL like that. Would it help if we spit out something like this instead? resources/markup/level1/level2/level3/page/../../../../base.js So, if the browser wanted to be smart about it, it would send up (if I counted correctly): resources/markup/base.js 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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588808#action_12588808 ] James Carman commented on WICKET-1428: -- Oh, but then it won't know how to go up the class hierarchy to look for the resource with respect to the parent class. Darn it! 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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588811#action_12588811 ] James Carman commented on WICKET-1428: -- Could you use a URL parameter to specify the path? resources/markup.level1.level2.level3.page.TestPage?path=/../../../../base.js 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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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] Issue Comment Edited: (WICKET-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588811#action_12588811 ] jwcarman edited comment on WICKET-1428 at 4/14/08 3:01 PM: --- Could you use a URL parameter to specify the path? resources/markup.level1.level2.level3.page.TestPage?path=/../../../../base.js Also, I've never really liked the fact that we have the classname in the URL. Could we use something to replace the scope of the resource URL with some constant (and it would be remembered for subsequent invocations)? Basically, we'd have a bidi-map that goes from some generated string - class name or something? was (Author: jwcarman): Could you use a URL parameter to specify the path? resources/markup.level1.level2.level3.page.TestPage?path=/../../../../base.js 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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588382#action_12588382 ] James Carman commented on WICKET-1428: -- Was this broken in 1.3.2? Or, is this now broken because of my patch? 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 Assignee: Igor Vaynberg Fix For: 1.3.3 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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588461#action_12588461 ] James Carman commented on WICKET-1428: -- I tested it for regular anchor 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 Assignee: Igor Vaynberg Fix For: 1.3.3 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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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-1373) cache created proxy classes
[ https://issues.apache.org/jira/browse/WICKET-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586001#action_12586001 ] James Carman commented on WICKET-1373: -- Commons Proxy does this automatically. So, if we change it to use Proxy, then you get this for free. cache created proxy classes --- Key: WICKET-1373 URL: https://issues.apache.org/jira/browse/WICKET-1373 Project: Wicket Issue Type: Sub-task Reporter: Igor Vaynberg Assignee: Johan Compagner Fix For: 1.4-M1 we can cache the created proxy class and simply give each instance a new handler... -igor On Tue, Feb 26, 2008 at 10:26 AM, James Carman [EMAIL PROTECTED] wrote: Have you tried this out using load testing? You are creating a new class every time you create a model. Have you run out of permgen space? -- 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 Does Not Resolve Relative Links Correctly
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579219#action_12579219 ] James Carman commented on WICKET-1428: -- Ok, you're right, the Javadocs specifically say the href URL must be relative to the package containing the associated page. However, one might argue that ../../blah/blah is indeed a relative URL. Either way, I've attached the patch. I don't care if you treat it as a bug or an enhancement request. It'd be nice if this worked properly. Thanks. AutoLinkResolver Does Not Resolve Relative Links Correctly -- 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 Attachments: WICKET-1428.patch 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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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] Updated: (WICKET-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1428: - Summary: AutoLinkResolver and Parent-Relative (../) Links (was: AutoLinkResolver Does Not Resolve Relative Links Correctly) 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 Attachments: WICKET-1428.patch 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: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link 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-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576779#action_12576779 ] James Carman commented on WICKET-1358: -- Hey, no worries. This is your baby. I'm just an admirer! :) I'm really diggin' this Wicket stuff! Thanks for considering the patch. 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 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] Updated: (WICKET-1404) DefaultFocusBehavior
[ https://issues.apache.org/jira/browse/WICKET-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1404: - Attachment: WICKET-1404.patch Here's a patch that implements the behavior. I haven't the foggiest idea of how to test this thing, so I'll leave that up to you gurus. Also, you'll probably need to add a @since tag once you decide when this goes in (if it does). DefaultFocusBehavior 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 a behavior which gives a component the focus when the page loads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1348) Please Change Scope of Spring Dependencies in pom.xml File
[ https://issues.apache.org/jira/browse/WICKET-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved WICKET-1348. -- Resolution: Won't Fix Please Change Scope of Spring Dependencies in pom.xml File -- Key: WICKET-1348 URL: https://issues.apache.org/jira/browse/WICKET-1348 Project: Wicket Issue Type: Improvement Components: wicket-spring Reporter: James Carman Priority: Minor The Spring dependencies need to be marked as provided or whatever so that they're not picked up transitively. Projects using the wicket-spring library might want to use a different version of Spring and this can bring about some pretty nasty classpath errors to track down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1348) Please Change Scope of Spring Dependencies in pom.xml File
[ https://issues.apache.org/jira/browse/WICKET-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman closed WICKET-1348. Please Change Scope of Spring Dependencies in pom.xml File -- Key: WICKET-1348 URL: https://issues.apache.org/jira/browse/WICKET-1348 Project: Wicket Issue Type: Improvement Components: wicket-spring Reporter: James Carman Priority: Minor The Spring dependencies need to be marked as provided or whatever so that they're not picked up transitively. Projects using the wicket-spring library might want to use a different version of Spring and this can bring about some pretty nasty classpath errors to track down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1392) Force Serialization of Session Resources in Development Mode
Force Serialization of Session Resources in Development Mode Key: WICKET-1392 URL: https://issues.apache.org/jira/browse/WICKET-1392 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.1 Reporter: James Carman In development mode, it would be nice if the session storage mechanism automatically forced serialization of session resources so that the NotSerializableExceptions can be found early. Perhaps just make a serialized copy of the object when it comes in? A recommended solution would be to change the WebApplication.newSessionStore() method to return a serializing version of HttpSessionStore if we're in development mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1327) CompoundModel backed by cglib proxies
[ https://issues.apache.org/jira/browse/WICKET-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572615#action_12572615 ] James Carman commented on WICKET-1327: -- Would you be willing to implement this using Apache Commons Proxy? It would take all of the proxying logic (CGLIB stuff) out of your code and it would also allow you (or the user) to switch proxying technologies altogether. Let me know if you want an example. CompoundModel backed by cglib proxies - Key: WICKET-1327 URL: https://issues.apache.org/jira/browse/WICKET-1327 Project: Wicket Issue Type: New Feature Components: wicket Reporter: Scott Swank Priority: Minor Fix For: 1.4-M1 Attachments: matej_and_johan_great_work_in_thailand.jar, Model.zip This is a simple model that lets cglib handle building the propertyExpression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1358: - Attachment: WICKET-1358.patch Here's what I have in mind. So far, I've only implemented ApplicationSettings, DebugSettings, and ExceptionSettings, but you'll get the idea of what I'm wanting to do. I don't want to the rest if you guys don't like the idea in the first place (it takes a bit of time to do this). If you like the idea, let me know and I'll finish it up and attach a patch. Thanks. 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 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] Updated: (WICKET-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1358: - Attachment: WICKET-1358.patch Here's the full patch. All test cases pass with this. I had to modify the existing test case for application settings so that it tested against the new Default* flavors of the different interfaces. I hope you guys like it. I think it makes it a bit cleaner (and it allows me to do what I want ;). 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 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] Updated: (WICKET-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1358: - Attachment: (was: WICKET-1358.patch) 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 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-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570538#action_12570538 ] James Carman commented on WICKET-1358: -- Wait, you guys can't all go on vacation at the same time! What happens if there's some freak accident!?!? Who's going to maintain Wicket!?!?! ;) Have fun! This will be waiting when you get back. No rush. 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 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] Created: (WICKET-1358) Make Application Class More Bean-ish
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 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.
