I'm relatively new with SI (I say "relatively" because I did some work with SI version 0.6 to 1, but I had to stop then and I'm now on it again in 4.2.5) and for now I'm writing some prototypes for POCs. In one of then I configured a channel backed by a jdbcChannelMessageStore which I wanted to customize in a simple way. To change the column MESSAGE_BYTES from bytea to text.
So I changed the schema-postgresql.sql to include that change and hope that I could only rewrite the jdbc statement for the INSERT. However, even if the statement itself is easily changeable, setting the parameters is not, since it is buried inside a lambda inside the jdbcTemplate.update itself inside the addMessageToGroup method. So the only solution would be to override the entire addMessageToGroup method, which seems not a good solution at all, since it contains more logic than the simple jdbc insert.
So what ended up doing was what I commented on my code as // very big hack. I overriden the DefaultLobHandler to actually not use the lob at all but a setString(...) instead.
So, I have a question and a suggestion:
Is there a way customize the JdbcChannelMessageStore to have our own schema structure and/or our own statements, without using things like this "big hack"?
If there is no better way, can I suggest to at least put the prepared statement fields setters on it's own protected (or public) method, instead of a lambda inside the jdbcUpdate?
Thanks in advance.
We should probably make it easier to override that logic, perhaps by delegating to an overridable method.
Contributions are always welcome :).
In JSF sources I found the logic of defining character encoding via facelets.Encoding attribute, which can be available in FacesContext.getAttributes()
See FaceletViewHandlingStrategy#getResponseEncoding method for details. How can I define this attribute for instance of FacesContext? I tried to define it via context-param in web.xml, but it's not working. And also I didn't find any reference about it in JSF documentation.
The main reason why I want do this, it is overriding of javax.faces.request.charset value. I don't want define a special filter for my application the order to define not UTF-8 encoding. Because my application contains a lot of WAR packages inside of big EAR.
Does anyone have a link to a concise summary of what makes a portlet "JSR-286 compliant" vs being only "JSR-168 compliant". I've got a copy of the spec and that's anything but concise so linking the spec is not a useful answer. I've searched the web for an hour now and I've found nothing that is clear (aside from the spec, which of course requires that you read the previous spec too, and then weed out the "new features" from the "required compliance".
Particularly I've found that there's quite a bit of confusion out there on the necessity of web.xml, which appears to come from people using Liferay and not realizing that Liferay is dropping in a web.xml for them.
Do JSR-286 portlets require a web.xml file in their WAR files?
What I'd really like is something that contains one or more of the following lists:
Things you have to do to a JSR-168 to make it become JSR-286 compliant
Things you must not do, that would cause an otherwise JSR-286 compliant portlet to be considered only JSR-168.
You can leave "use the portlet-app_2_0.xsd" off the list, as I consider that part obvious.
I'm open to the answer that both lists are empty aside from the DTD/xsd for portlet.xml, and the difference is only in what the portal supports, but please back that assertion up with a link or other reference.
The reason I care is I see posts about Vaadin portlets in Liferay that imply that some features are not available for JSR-168 portlets... It may also be that some logic in Liferay switches based on which version of portlet.xml it sees, but I haven't confirmed that either so that would be interesting information too, but not the answer to my question.
According to this doc, but it's also mentioned in jsr286:
The JSR 286 spec(Portlet 2.0) does not break binary compatibility with JSR168(Portlet 1.0). This means that all portlets written against the Portlet 1.0 specification can run unchanged. The only exceptions to this rule are:
renderResponse.setContentType is no longer required before calling getWriter or getOutputstream. In JSR168, calling getWriter or getOutputstream without previously setting the content type resulted in an IllegalStateException.
getProtocol for included servlets / JSPs returns ‘HTTP/1.1’, In JSR168, it returned null.
So as long as your jsr168 portlet doesn't depend on the value returned by getProtocol() you're safe (ie every jsr168 portlet is a jsr286 portlet).
The posts you see seem to be logical as jsr286 is a newer spec and there are some features that make jsr268 portlet not a jsr168 portlet.
Ok, Since I've not found anything new that distinguishes a 2.0 portlet from a 1.0 portlet (aside from using additional services and ) I'll begin the lists for my answer here.
Must Do:
Conform to the 2.0 XSD for portlet.xml (xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd")
Must Not Do:
Rely on getWriter throwing an exception if renderResponse.setContentType has not been called yet. (Seems unlikely anyway)
Rely on getProtocol() returning null
The upshot is, if you simply convert your portlet.xml, you are now "286 compliant" unless you relied on the two items in the second list for your program flow. I can't find anything else, but if someone finds another item for these lists, please edit.
I am looking for a refreshable groovy classloader,I want to let groovy file change on fly,I know
GroovyScriptEngine do the thing,but if I have AClass.groovy and BClass.groovy, and I write in AClass:
Class pageClass = ClassUtils.forName("BClass", this.getClass().getClassLoader());
and auto reloading BClass is not work when BClass.groovy is not work.
I think the best solution is need a refreshable ClassLoader,but I can not find the exisiting implemention.
And I am not using spring-groovy and grails,I want a independent implemention.
Thanks
Not exactly what you want I'm sure but if you want to do something ONLY with Groovy (no Spring or Grails) that allows you to change stuff and not have to restart your application, you might look at doing some initial work with Groovlets -> http://groovy.codehaus.org/Groovlets
This is only for servlet container work and probably won't be extremely useful as your application gets large but it would allow you to initially change things frequently and simply refresh with a call to the Groovlet.
If you did consider using Spring, scripted beans are 'refreshable' and you can implement that yourself using Java's dynamic language support but I'd suggest simply letting Spring do it for you.
Background
I'm going to develop a new web-application with java. It's not very big or very complex and I have enough time until it'll "officially" start.
I have some JSF/Facelets development background (about half a year). And I also have some expirience with JSP+JSTL.
In self-educational purpose (and also in order to find the best solution) I want to prototype the new project with one of action-based frameworks. Actually, I will choose between Spring MVC and Stripes.
Problem
In order to get correct impression about action-based frameworks (in comparison with JSF) I want to be sure that I use them correctly (in a bigger or a lesser extent).
So, here I list some most-frequent tasks (at least for me) and describe how I solve them with JSF. I want to know how they should be solved with action-based framework (or separately with Spring MVC and Stripes if there is any difference for concrete task).
Rendering content: I can apply ready-to-use component from standard jsf libraries (core and html) or from 3rd-party libs (like RichFaces). I can combine simple components and I can easily create my own components which are based on standard components.
Rendering data (primitive or reference types) in the correct format: Each component allow to specify a converter for transforming data in both ways (to render and to send to the server). Converter is, as usual, a simple class with 2 small methods.
Site navigation: I specify a set of navigation-cases in faces-config.xml. Then I specify action-attribute of a link (or a button) which should match one or more of navigation cases. The best match is choosen by JSF.
Implementing flow (multiform wizards for example): I'm using JSF 1.2 so I use Apache Orchestra for the flow (conversation) scope.
Form processing: I have a pretty standard java-bean (backing bean in JSF terms) with some scope. I 'map' form fields on this bean properties. If everything goes well (no exceptions and validation is passed) then all these properties are set with values from the form fields. Then I can call one method (specified in button's action attribute) to execute some logic and return string which should much one of my navigation cases to go to the next screen.
Forms validation: I can create custom validator (or choose from existing) and add it to almost each component. 3rd-party libraries have sets of custom ajax-validators. Standard validators work only after page is submitted. Actually, I don't like how validation in JSF works. Too much magic there. Many standard components (or maybe all of them) have predefined validation and it's impossible to disable it (Maybe not always, but I met many problems with it).
Ajax support: many 3rd-party libraries (MyFaces, IceFaces, OpenFaces, AnotherPrefixFaces...) have strong ajax support and it works pretty well. Until you meet a problem. Too much magic there as well. It's very difficult to make it work if it doesn't work but you've done right as it's described in the manual.
User-friendly URLs: people say that there are some libraries for that exist. And it can be done with filters as well. But I've never tried. It seems too complex for the first look.
Thanks in advance for explaning how these items (or some of them) can be done with action-based framework.
I'll do my best to answer regarding Stripes. I've used Struts and JSF in the past, but not recently, so at best I have vague notions and feelings about them.
We are intimately familiar w/ Stripes, use it for most everything now, and really enjoy it. It is easy to jump into, supports many of the complicated scenarios, but you are also free to work OUTSIDE of it, which is really important when you want to build your own ajax widgets or talk to another system or something.
If you go the stripes route, I definitely recommend buying or download the book. It is a one stop shop for everything you need for Stripes, and is practically the only documentation for Stripersist (really nice feature, but NO web docs).
Rendering content: I can apply ready-to-use component from standard jsf libraries (core and html) or from 3rd-party libs (like RichFaces). I can combine simple components and I can easily create my own components which are based on standard components.
This is similar. Core, Html, Fmt, etc. as well as any custom tags you find, inc. display:tag, pack tag, and create your own. However, obviously you do not deal at the component level now, you deal with a tag that determines what is on the page / sent to or from the server.
Rendering data (primitive or reference types) in the correct format: Each component allow to specify a converter for transforming data in both ways (to render and to send to the server). Converter is, as usual, a simple class with 2 small methods.
Stripes has many built in converters, and it is easy to create custom converters for your more complex data types. Stripes supports very complex data structures to be mapped with little hassle. Combined with Stripersist, for example, I can put my model object directly on the ActionBean, put a few of the fields on the form, and Stripersist will hydrate the model from the db (based on its PK) and update that with the fields I put on the form - all before releasing control to me on the ActionBean.
Site navigation: I specify a set of navigation-cases in faces-config.xml. Then I specify action-attribute of a link (or a button) which should match one or more of navigation cases. The best match is choosen by JSF.
Navigation in stripes is based on what you name the ActionBeans, initially. There is no xml. Additionally, pretty urls are an annotation at the ActionBean level in Stripes 1.5, so you can do things like #UrlBinding("/{$event}/{model}") where /view/5 would take you to the "view" event handler for your Model object with the ID/PK of 5.
Implementing flow (multiform wizards for example): I'm using JSF 1.2 so I use Apache Orchestra for the flow (conversation) scope.
While I only am vaguely familiar with the concept of conversation scope, Stripes has Wizard Form functionality, but I haven't used it and am unable to really expand on that. I think it is a similar idea though.
Form processing: I have a pretty standard java-bean (backing bean in JSF terms) with some scope. I 'map' form fields on this bean properties. If everything goes well (no exceptions and validation is passed) then all these properties are set with values from the form fields. Then I can call one method (specified in button's action attribute) to execute some logic and return string which should much one of my navigation cases to go to the next screen.
Not drastically different. Instead of components on your [action] bean, you now have Java or custom types. ActionBeans are created per request and thrown away, unless you do something like put it in session, or wizard, or whatever. This is nice, because all the instance variables get mapped to the data from the form, you use it, then throw it away, and don't have to deal with any synchronization issues like struts did. After you do your thing with the data, Stripes lets you send a ForwardResolution (OK status), Redirect, or Streaming (JSON, file, etc). The Redirect-after-POST pattern is implemented nicely with the idea of flash scope (3/4 down the page).
Forms validation: I can create custom validator (or choose from existing) and add it to almost each component. 3rd-party libraries have sets of custom ajax-validators. Standard validators work only after page is submitted. Actually, I don't like how validation in JSF works. Too much magic there. Many standard components (or maybe all of them) have predefined validation and it's impossible to disable it (Maybe not always, but I met many problems with it).
Stripes allows validation in annotations on the instance variables on the ActionBean. They allow some defaults, required, maxlength, etc. or you can always create your own. The default is easy to add and flexible, while there is always the ability to make something completely customized.
Ajax support: many 3rd-party libraries (MyFaces, IceFaces, OpenFaces, AnotherPrefixFaces...) have strong ajax support and it works pretty well. Until you meet a problem. Too much magic there as well. It's very difficult to make it work if it doesn't work but you've done right as it's described in the manual.
This was my big problem with the JSF way of doing things. Even if you did get the widget right, you're still stuck with THAT widget. With Stripes, you can use whatever latest and greatest Jquery has to offer, and as long as you send the right GET or POST to the server, stripes knows what to do with it and can easily send JSON back. I think component frameworks fit a niche a few years ago much better when AJAX was hard, but JQ makes it so easy now.
User-friendly URLs: people say that there are some libraries for that exist. And it can be done with filters as well. But I've never tried. It seems too complex for the first look.
#UrlBinding, it's as easy as that.
My answer is not the one you want to hear: Don't switch from Component Framework to action framework
I switched the other way around after many years of action framework development and I'm never going back.
Of the 8 use cases you mentioned, only one comes to mind where Action frameworks are obviously better, and that is URL design / friendly URLs. It can be done in component frameworks as well, but much easier in Action Frameworks (especially in Stripes where you just annotate your ActionBean with the url).
I would advise you to try wicket, it is very easy to learn (much easier than JSF) and it let's you re-use many existing components as well.