Binding...finally getting it together (well maybe)
It's been a while now but I might have hacked a solution for binding. We have an application which we developed using NetBeans. We have been through various binding solutions but once JSR-295 code was released by Scott Violet a couple of JavaOne's ago, we decided to use it. Looking back this decision may have been even more premature than we expected but I don't regret it.
JSR-295 has, at least on some level, been usable since it was available. In my opinion the initial release was as good (and as bad) at most anything else we tried.
In the one project I have in mind at the moment we had a couple of wrinkles. This is a Swing application that utilizes web services. We really do like NetBeans for many reasons including the ability to visually design Swing apps. Having just returned from I think what was my seventh JavaOne (I was not at the first one and missed quite a few years along the way), I am not unaware that there are some excellent developers who perfect their UI's by banging out code. That went out a long time ago for me but to each his own.
The idea was to take advantage of NetBeans to both design the UI and "wire it up" to the data. In this case our data just so happens to be web services stuff. NetBeans and JAX-WS 2.1 pair up very nicely but when it comes to binding (via JSR-295), there have been some significant issues.
Over the past year or so the issues we have bumped into and reported (not that we are alone) include the following:
- beans generated by JAX-WS using NetBeans do include property change notification which is a problem if you're doing binding
- Boolean vs. boolean is not handled consistently
- null values can be a problem with binding
- null dates can be a problem with web services
To my knowledge most all of these have been fixed with the exception of the property change notification issue when generating client-side web services with NetBeans and JAX-WS. The real problem, in my opinion, is related to the fact that at least three groups at Sun are involved with making this work together. These include NetBeans, JSR-295 (beans binding), and JAX-WS (JAXB2). Sometimes when an issue is the responsibility of more than one, it's difficult for anyone to take ownership.
While I have no idea how the process actually works, the NetBeans folks continually impress me with how quickly they can and do get a wide variety of Java technology into their IDE. Once it gets there, it generally cannot get any easier. I have also been very impressed with the web services as implemented by the JAX-WS Glassfish people.
JSR-295 (as well as JSR-296) have been kicked around a bit at Sun. Scott Violet was the lead on JSR-295 but he left before it was complete. Shannon Hickey took over the lead what has to be over a year ago (has it really been that long?). Scott and Shannon have both done an excellent job especially when you consider quite a few others have built their own binding logic, are very willing to offer their opinions on how it should be done, and they don't necessarily agree. Don't get me wrong I realize this is a natural part of the process but when you couple these issues with the resources JavaFX have apparently consumed at Sun, one can see why these JSR's are not quite mature.
Back to the point at hand, currently if you generate client web services using JAX-WS with NetBeans, you cannot (easily) bind the beans to your UI components. There is something called the property-listener-injector that seems like it might address this issue but it does not work for me. I may well be missing something but here's my (current) understanding. If you add the property-listener-injector to your build file, you will end up with beans which have setters that fire vetoable changes. I think the idea behind a vetoable change is that the listener can request that the change be rolled back. Now if you're used to coding EE stuff where you're dealing with databases directly, this makes a great deal of sense. Actually it also makes sense at the client which ultimately talks to the back end but I don't think that's how JSR-295 works.
It seems to me that JSR-295 is looking for a property change event and it is smart about it. Apparently if a change notification event is fired and JSR-295 sees that the data has not really changed, it ignores it (what else could it do). The problem is that the property-listener-injector generates code that first fires the vetoable change (as opposed to the property change which is needed) and then it makes the change. Therefore it would not work even if it were the correct event.
To test this I modified the property-listener-injector code and from my tests, it all works as I describe above. Getting this code to compile at all is a bit harder than it should be. There is at least one class file (Kind.java) which was deleted from the CVS repository, documentation is scarce, and it's not neatly "packaged" with the dependencies in the jaxb2-commons. You can get the whole thing to build with maven as intended but if you're lazy and like the code-completion comfort of an IDE, it takes effort I did not make the time for. I found myself moving from the IDE to maven at the command line and back.
I'll get some code posted shortly. In the meantime I am wondering what if anything others have to say.
You can find the modified plugin, source code, and NetBeans example use here.
It's been a while now but I might have hacked a solution for binding. We have an application which we developed using NetBeans. We have been through various binding solutions but once JSR-295 code was released by Scott Violet a couple of JavaOne's ago, we decided to use it. Looking back this decision may have been even more premature than we expected but I don't regret it.
JSR-295 has, at least on some level, been usable since it was available. In my opinion the initial release was as good (and as bad) at most anything else we tried.
In the one project I have in mind at the moment we had a couple of wrinkles. This is a Swing application that utilizes web services. We really do like NetBeans for many reasons including the ability to visually design Swing apps. Having just returned from I think what was my seventh JavaOne (I was not at the first one and missed quite a few years along the way), I am not unaware that there are some excellent developers who perfect their UI's by banging out code. That went out a long time ago for me but to each his own.
The idea was to take advantage of NetBeans to both design the UI and "wire it up" to the data. In this case our data just so happens to be web services stuff. NetBeans and JAX-WS 2.1 pair up very nicely but when it comes to binding (via JSR-295), there have been some significant issues.
Over the past year or so the issues we have bumped into and reported (not that we are alone) include the following:
- beans generated by JAX-WS using NetBeans do include property change notification which is a problem if you're doing binding
- Boolean vs. boolean is not handled consistently
- null values can be a problem with binding
- null dates can be a problem with web services
To my knowledge most all of these have been fixed with the exception of the property change notification issue when generating client-side web services with NetBeans and JAX-WS. The real problem, in my opinion, is related to the fact that at least three groups at Sun are involved with making this work together. These include NetBeans, JSR-295 (beans binding), and JAX-WS (JAXB2). Sometimes when an issue is the responsibility of more than one, it's difficult for anyone to take ownership.
While I have no idea how the process actually works, the NetBeans folks continually impress me with how quickly they can and do get a wide variety of Java technology into their IDE. Once it gets there, it generally cannot get any easier. I have also been very impressed with the web services as implemented by the JAX-WS Glassfish people.
JSR-295 (as well as JSR-296) have been kicked around a bit at Sun. Scott Violet was the lead on JSR-295 but he left before it was complete. Shannon Hickey took over the lead what has to be over a year ago (has it really been that long?). Scott and Shannon have both done an excellent job especially when you consider quite a few others have built their own binding logic, are very willing to offer their opinions on how it should be done, and they don't necessarily agree. Don't get me wrong I realize this is a natural part of the process but when you couple these issues with the resources JavaFX have apparently consumed at Sun, one can see why these JSR's are not quite mature.
Back to the point at hand, currently if you generate client web services using JAX-WS with NetBeans, you cannot (easily) bind the beans to your UI components. There is something called the property-listener-injector that seems like it might address this issue but it does not work for me. I may well be missing something but here's my (current) understanding. If you add the property-listener-injector to your build file, you will end up with beans which have setters that fire vetoable changes. I think the idea behind a vetoable change is that the listener can request that the change be rolled back. Now if you're used to coding EE stuff where you're dealing with databases directly, this makes a great deal of sense. Actually it also makes sense at the client which ultimately talks to the back end but I don't think that's how JSR-295 works.
It seems to me that JSR-295 is looking for a property change event and it is smart about it. Apparently if a change notification event is fired and JSR-295 sees that the data has not really changed, it ignores it (what else could it do). The problem is that the property-listener-injector generates code that first fires the vetoable change (as opposed to the property change which is needed) and then it makes the change. Therefore it would not work even if it were the correct event.
To test this I modified the property-listener-injector code and from my tests, it all works as I describe above. Getting this code to compile at all is a bit harder than it should be. There is at least one class file (Kind.java) which was deleted from the CVS repository, documentation is scarce, and it's not neatly "packaged" with the dependencies in the jaxb2-commons. You can get the whole thing to build with maven as intended but if you're lazy and like the code-completion comfort of an IDE, it takes effort I did not make the time for. I found myself moving from the IDE to maven at the command line and back.
I'll get some code posted shortly. In the meantime I am wondering what if anything others have to say.
You can find the modified plugin, source code, and NetBeans example use here.
Comments