I guess everyone of you already know content loading mechanism used on the Twitter site. When you scroll down at the bottom of current page another content is loaded immediatelly without you clicking on any UI element. It’s a very nice idea for AJAX powered listings and you’d probably take advantage of it on your own site too. I came to the same conclusion also but it seems there is no single jQuery plugin enveloping this kind of mechanism. Searching Google you could find several articles describing how to implement similar funcionality with jQuery but you wouldn’t find any jQuery plugin ready to use. So I decided to make one for this purpose – it’s called TriggerOnView plugin.
English
Spellchecking provided by IntelliJ Idea is very handy for those who are not confident in written English (such as me for example
).
But for non-English speaking developers it’s common to use (at least) two languages simultaneously – English for writing Javadoc, method and variable names and their native language (Czech, Polish …) for strings in UI layer. Setuping Ideas’ spellchecker to validate string in multiple languages is more than handy. This article will guide you through setuping your native dictionary.
Testing transactional aspect of your application is not easy as we usually use Springs’ transaction rollback on tear down testing approach. Though there are solutions to test aspect oriented logic it’s not without a price. More than that – we very much got used relying on easy-to-use Spring @Transaction annotation so that we don’t usually take an effort to do it. There is a few standard Spring rules for rollbacking transaction in relation to method resolution:
- transaction is automatically rollbacked only on unchecked exeption (RuntimeException)
- rollback will also occur for exception types specified in rollback-for attribute of the annotation or XML element
- rollback will not occur for exception types specified in no-rollback-for attribute of the annotation or XML element
- transaction demarcation will aplly only to the external calls of the bean method (consider use-case when external logic calls a public method on your bean, that is not annotated with @Transactionaidl and this method will call in its body another public method of the same class that has @Transaction annotation – in such case Spring will not start and manage transaction)
But there is yet another one – your @Transactional annotation must be resolved by Spring bean post processing logic in the first place. Usually it is, but when using CgLib based proxies (proxy-target-class) there is a catch which will cause omitting @Transactional annotation on your method declaration.
In the last post I described the basic principles I found behind the scenes of GroovyScript refresh. Now imagine that you want to create your own long living Groovy instances with auto-refresh behaviour when source code changes. You can use out-of-the-box Spring support – but there are some limitations I stated in the previous article.
In this post I am going to present an alternative solution that addresses some of the painful issues I noticed. As I stated before, key is to wrap the reference to Groovy instance into an another object managed by the Java class loader and that is exactly the main point of the solution presented.
The first thing one should undestand before he tries to integrate scripting support into his application / framework are class loading issues. One of the main reasons (next to the ability to easily switch from Java) why we have chosen Groovy as our primary scripting language is very good support for live refresh of Groovy classes when source file has changed. But what does Groovy exactly do when it „refreshes“ its loaded classes to conform to a newly modified source file? What about existing instances referencing to this class? Is it even possible in JVM to change class structure in runtime? Yes JavaRebel can do this, but it needs special setup and debug mode for hotswap. And how does all this fit into the existing Spring support? From the documentation it seems, that it all just magically works! Dozens of questions ran in my mind when I started to strive for Groovy integration in our product. Those questions gets answered in this article.
I had a discussion with Jira recently, whether we could be still looking forward to iBatis 3. It has been long time since iBatis 3 Whiteboard was seriously touched and I haven’t found any other clue when or whether there is going to be iBatis 3. There is very small activity for 3.x version in Jira, though there were some commits into iBatis 3 core. As I am going to have a speech in University Hradec Králové on iBatis, I have decided to ask directly its authors about this issue.
I’ve run into interesting and very strange problem. I was writing transactional
Spring test that opens transaction at the beginning of it, and rollbacks at the end. First part of my test performed bunch of INSERT and UPDATE SQL commands and after that I was checking persisted changes by loading data back from the database. Suddenly my tests started to fail. And I was searching for the reason …
If you use Maven 2 and Teamcity integration server, you might want to perform releases on server. Although it’s not so complicated, some things must fit one into another and you might spend a lot of time till you find out how to configure pom.xml and build configuration. For those of you, who need to setup it, this article could come quite handy.
English translation
Tímto příspěvkem bych chtěl poděkovat pánům ze Sun Microsystems za uspořádání tohoto školení. Přestože mým oborem jsou výhradně server side aplikace, rád jsem si rozšířil obzory v oblasti desktopu. Z tohoto důvodu se z mé strany pravděpodobně nedočkají významné kontribuce, a proto se snažím jim námahu vrátit alespoň touto reklamou na jejich edukační program.
Common introduction to AJAX in Stripes
Stripes framework offers basic but sufficient support for AJAX that is covered with article at official web site. Article recommends using commonly known PrototypeJS AJAX client side library. On the server side, request is processed by Stripes themselves by standard population and execution as any other http request (that means that data from client to server are sent as a standard URL encoded parameters). What you get is correctly populated and validated action bean – and until now you haven’t even recognize, that request is made by JavaScript on the client side not even you have to care of it. You can access session, exchange cookies and so on.


