Well my skin which has several filters (some of which are quite complex when it comes to options) is now broken too. See below for my comments (I'll possibly reply to other comments too).
Note that I don't have any errors in the log. I also already have a no-args constructor. I also have getters and setters but I don't known if they're all used. Is this required? For example do I have to use a getter every time I refer to a variable in the class? That seems silly to me and would make the code even uglier yet looking at it I think I do do that at least in the one filter I am testing (the others I know don't work but I am pretty sure I also use setters and getters).
Chris, ensure that the filter has both a default, no args constructor and both getter and setter methods. The change made since v23.1 is that we now make a clone of the filter for each execution thread. For the cloning to work, there needs to be a no-args constructor and getter and setter methods corresponding to the JavaBeans spec.
Well as I said my ReflectionFilter does have getters and setters and a no args constructor and it's not working correctly (it does filter images but it's really weird and definitely wrong). Now I can upload it here or in a different post if you wan though I warn you it's kind of big and it does refer to another filter or maybe two that are much more complicated (well one is much more complicated) and I don't think you'd want to look at them anyway.
The cloning is done to ensure that filters that contain state won't bug things when executed over multiple threads. Prior to v23 we used one single filter instance and synchronized the filter call, but this doesn't scale well when users have multiple CPU cores. v23 removed the synchronization and gained performance, but broke XBorderFilter (that contains state). v23.1 solved this by cloning filters for each execution thread.
Would you please implement a feature that this will work on single threads?
Because as you can see it's not only Chris's filter that is broken; I have several that are broken and I imagine there are others that are also broken. I find it very annoying and all the more since I also just updated my subscription
when now it seems useless and pointless to even have the option of updating jAlbum; it's as if I spent the money for no reason.
Additionally I already do have getters/setters and no arg constructor and unless I'm doing something wrong (and I wasn't
doing anything wrong before!) I don't see what else I'm supposed to do. Frustratingly you don't seem to have the documentation updated as Chris pointed out. That's not good.
The only side effect of this change I can imagine now (apart from filters needing to follow the JavaBean spec with regards to no-args constructor and getter/setter methods) is that no state is kept BETWEEN each filter() invocation (a new clone is used every time)
I'm too tired to tell right now but this might actually affect one of my filters... Which is also annoying.
So to recap:
- Would you please implement a feature that allows the old style to work?
- What do I do if I already have what you say is needed and it still does not work? Something seems off again unless I have missed something. Do you want me to upload the filter source code here or in another thread?
- I'm really upset that I just spent the money to renew my subscription only for it to be that my filters no longer work due to (one can assume) no longer allowing single thread execution (and almost immediately making the marking of synchronization pointless). That's very annoying as I don't have a lot of money to begin with and last year when I returned it was only for the filters I wrote!
- Why wasn't this in the changelog? Or did I miss it? I don't think I did but I did see the synchronization keyword (or whatever it is called in Java) needed to be done and I did that. But this change wasn't added to changelog which means that filters silently stopped working on newer versions of jAlbum. Not really a good thing.
If I seem annoyed it's because I am both annoyed and frustrated. I don't mean the above to be aggressive and if it sounds like it is I apologise but I do have a lot going on and I am rather annoyed that I spent money for something that appears to be a waste of not only money but time fixing code that isn't actually broken (or wasn't broken).