it doesn’t matter how often a user’s role changes as I only index the roles _required to read an entry_.

I think I am going to stay with my builder-wrapper approach for the time being. Extending your class is hard because if I want to add a new public method signature, I’ll need to override every single public method that returns a “this” reference to return the narrower type.

For example, if I want to add a setCssMedia() method (which as far as I can tell is something that ResourceMount does not currently support), my class will look like this:

public class CssResourceMount extends ResourceMount
{
…
public CssResourceMount setCssMedia(String media)
{
…
}
}

But now if I try to use this new class like this:

new CssResourceMount()
.setPath(…)
.setCssMedia(…)

I’ll get this compilation error:

cannot find symbol
symbol : method setCssMedia(java.lang.String)
location: class org.wicketstuff.mergedresources.ResourceMount

Because setPath() is returning ResourceMount, not CssResourceMount. I’d have to override and redefine setPath() (and every other public method that returns a “this” reference) to have the CssResourceMount return signature.

So yes, I can subclass and override existing methods, but I can’t subclass to effect the public API without a lot of extra work.

Anyway, I like what I see otherwise in 3.0. Don’t let me hold you up. I’ll add JIRA issues later this week for the CSS media and CSS/JS detection enhancements.

Give me a couple days to test this out; I’ll let you know later this week if I run into any problems that would need to be considered before the 3.0 release.

@Matt I’ve just committed changes to ResourceMount inspired by your ResourceMountBuilder. Actually, I don’t really see the main benefit of using yet another builder around a builder API. It’s best to simply extend ResourceMount if you want to change it’s default behaviour. There are lots of protected methods you may override in order to change the defaults. Additionally, you may use ResourceMount#clone() to reuse configuration of a single ResourceMount for multiple mounts. However, I’ve added a new constructor (ResourceMount(boolean)) and a new method (ResourceMount#build(WebApplication)). Please have a look and tell me what you think. It’s the last change to get any suggestions into version 3.0. Lastly, I’ve used your ResourceBuilderTest as ResourceMount test. The only thing it doesn’t support like your ResourceBuilder is detection of JS and CSS files being added to the same merged resource. If you’d like to see this feature in 3.1, please crate a JIRA issue.

Cheers, Stefan

@Matt looks interesting, especially the test case. I’ll have a closer look next week.

I’ll release versions 2.1 and 3.0 on Monday.

Have a nice weekend!

Cheers, Stefan

I would appreciate a 3.0 release when you have the chance. I’ve only been using merged-resource on small projects, but it has held up well. I am not, however, using the annotation features, as those didn’t seem to fit my coding style.

On a related note, I wrapped your code with a simple helper class of my own that has been working well for my purposes:

http://opensource.55minutes.com/svn/java/trunk/fiftyfive-wicket/src/main/java/fiftyfive/wicket/resource/MergedResourceBuilder.java

I also figured out how to unit test the merged-resources functionality:

http://opensource.55minutes.com/svn/java/trunk/fiftyfive-wicket/src/test/java/fiftyfive/wicket/resource/MergedResourceBuilderTest.java

Thought you might be curious…

8:14:25,909 INFO [STDOUT] 2010-01-29 18:14:25,909 ERROR [org.apache.wicket.util.lang.Objects] – Error serializing object class com.foo.txbu.directory.markup.html.pages.LoginPage [object=[Page class = com.foo.txbu.directory.markup.html.pages.LoginPage, id = 5, version = 0]]
org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: Unable to serialize class: org.wicketstuff.mergedresources.ResourceSpec
Field hierarchy is:
5 [class=com.foo.txbu.directory.markup.html.pages.LoginPage, path=5]
private java.lang.Object org.apache.wicket.MarkupContainer.children [class=[Ljava.lang.Object;]
protected org.apache.wicket.util.collections.MiniMap org.apache.wicket.markup.html.link.BookmarkablePageLink.parameters[5] [class=com.foo.txbu.directory.markup.html.pages.BasePage$11, path=5:linkLogo]
private java.lang.Object org.apache.wicket.MarkupContainer.children [class=org.apache.wicket.markup.html.image.Image, path=5:linkLogo:logo]
private final org.apache.wicket.markup.html.image.resource.LocalizedImageResource org.apache.wicket.markup.html.image.Image.localizedImageResource [class=org.apache.wicket.markup.html.image.resource.LocalizedImageResource]
private org.apache.wicket.Resource org.apache.wicket.markup.html.image.resource.LocalizedImageResource.resource [class=org.wicketstuff.mergedresources.resources.CachedResource]
private final org.wicketstuff.mergedresources.resources.MergedResourceStream org.wicketstuff.mergedresources.resources.MergedResource._mergedResourceStream [class=org.wicketstuff.mergedresources.resources.MergedResourceStream]
private final org.wicketstuff.mergedresources.ResourceSpec[] org.wicketstuff.mergedresources.resources.MergedResourceStream._specs [class=[Lorg.wicketstuff.mergedresources.ResourceSpec;]
private final org.wicketstuff.mergedresources.ResourceSpec[] org.wicketstuff.mergedresources.resources.MergedResourceStream._specs[0] [class=org.wicketstuff.mergedresources.ResourceSpec] <—– field that is not serializable

Any ideas?

well, actually I planned to release 3.0 for a while. The only problem is that I’m still using 2.x (as I’m currently stuck on Wicket 1.3).

However, if you think 3.0 works and is ready for prime time, I would release it. Therefore, my idea would be that you keep developing and testing with 3.0-SNAPSHOT, but as soon as your project is ready for production, I will create a release.

If you’re interested in helping with open issues (currently, there aren’t any though), see http://wicketstuff.org/jira/browse/WMR

Cheers, Stefan