I forgot the codez...

In an application we work with threads, but for ease of usage, we may not want to pass around the same objects all the time. It helps in our method signature, signifying the objects we perfrom our function on, but sometimes, it feels rather unnecessary. For example, let's assume we have a request-id which we recieve, and want to pass to all outgoing requests. Or we want to prevent a certain query being performed multiple times by caching the result. These are request-scoped data items. Since every request runs in it's own thread, we can use threadlocals. In spring, we can do a bit better, by using a ThreadLocalTargetSource https://dzone.com/articles/an-alternative-approach-to-threadlocal-using-sprin-1 This allows us to get a thread-instance per request, which can be injected into our services without any knowledge of caching occuring. In essence, we create some sort of thread-tied global object. This is, of course, something which can be easily abused, and can lead...

So we have a bean of type FunkyClass and we want to override it. How? Well, we have the @Ordered annotation, which allows us to define the order when there are multiple beans of the same type. However, what happens when we only want one? Spring does not automatically take the highest order. To override a bean, you can use the @Primary annotation :)

So, I'm on a small project which has some multi-tenancy. Simply put; user A can see the bananas on his trees, and user B can see the bananas on his own trees... but they can't see each others. But it's restfull, so ideally, you'd call something like /tree/{tree-id}/bananas And since we know who's executing the call (since it's authenticated), we can verify that it's user A calling us, and then check which trees he can see. If he's trying to be sneaky, and does a restcall with a treeId of B, a security violation should occur. Okay, so how do we do that? Well, the application has a controller for that, and we'd want to secure it there. So, assume we have the following code: public List<Banana> getBananasOfTree(String tree) Since it's supposed to be annotated, we'd use something like this: @RequestMapping("/tree/{tree-id}/bananas") @Secured // or some other requirement  public List<Banana> getBananasOfTree(@Pat...

So I had a discussion about stateless session beans and them containing state. Coming from spring, I expected stateless to mean no state what so ever. This is because the default scope for beans in spring is Singleton. This allows beans to be shared (and wired) on application startup, ensuring that no real bean pool management is necessary. The container decides to use separate beans for injection, or all the same, since there is no real 'pool' to speak of. Compare this to EJB, which has a stateless session bean. This compares with a stateful session bean. A stateful session bean contains the state through the entire session. A stateless session bean does not. However, a stateless session bean can contain state. Stateless session beans are request scoped , meaning that any state they have they can access within the request. This, of course, comes from EJB's Stateful and Stateless EJB's of old, where it was made that way. Spring made sure that stateless = no ...

Javascript fatigue (or: why it sucks to learn) Organizing code - by strategy, by component, etc. Configuration building in spring Complete java based config in spring Ungit...?

For testing, I wanted the option to have the applicaitoncontext be modifyable. Normally, I'd use the Spring4UnitRunner for testcases in combination with a @ConfigurationContext(...) However, in this case,  I wanted to modify the applicationcontext, or more precisely, I wanted to override a property, with a different value for each test. (overriding the properties for the entire test with a property-file should be easy, using @TestPropertySource) Injecting the applicationcontext didn't work, as we receive a GenericApplicationContext, which cannot be refreshed. So, we create our own applicationcontext, update the properties, and refresh the context:     private ApplicationContext createApplicationContextWithProperties(String applicationContextXmlLocation, Map<String, Object> propertiesMap) {         ClassPathXmlApplicationContext overridenApplicationContext = new ClassPathXmlApplicationContext(applicationContextXmlLoca...

Spring has a nice @Conditional annotation, to have the option to have beans be available in the context depending a specific condition (Of course, this can also be realized by using @Configuration objects, but that's a different post). Ideally, we'd have the option to have a condition evaluate to true or false depending on a property. Sadly, Spring does not support that out of the box. Googling and looking around gives a partial solution, but the complete one here, so we won't forget: /** * Components annotated with ConditionalOnProperty will be registered in the spring context depending on the value of a * property defined in the propertiesBeanName properties Bean. */ @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Conditional(OnPropertyCondition.class) public @interface ConditionalOnProperty { /** * The name of the property. If not found, it will evaluate to false. */ String value(); /** * if the p...

Sometimes we want to use both spring-ws and spring-mvc in one application. However, these are two different stacks. To use them combined is a bit of a hassle, and... lest I forget, this post. The following needs to be set in the applicationcontext: <!-- To nicely support webservices from httprequests, we use the WebServiceMessageReceiverHandlerAdapter (which needs a messagefactory) --> <!-- Because we declare this, the dispatcherservlet automatically uses it... instead of the normal mvc adapter! --> <!-- To ensure that the normal mvc adapter is also loaded, we need to define it (the SimpleControllerHandlerAdapter) as well. --> <!-- Requires a message factory so we declare one --> <bean class="org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter">   <property name="messageFactory" ref="messageFactory" /> </bean> <bean id="messageFactory" class="org.springframework.ws....

In spring you can use the @Transactional annotation to marcate public methods as transactions. Any exception thrown in such an exception causes a rollback... Any exception? No, spring only does so on runtime exceptions. Checked exceptions are allowed and do not result in a rollback. And even then, you can allow some transactions to rollback, or not, with the proper properties for the transactions. For examle, @Transactional(rollbackFor="MyCheckedException.class") will rollback for a specific checked exception, and similarly, you can use @Transactional(noRollbackFor="MyUncheckedException.class") for unchecked exceptions. Of course, you might want to make it a little simpler on yourself. This article on stackoverflow shows us a different way: we can use our own transaction handler by overriding spring's. Let's have a sample interface which defines whether an exception should perform a rollback: interface ConfigurableRollback shouldRollbackOnE...

Oracle can run in a cluster, also called Oracle RAC (real application cluster - what's in a name that they need to call it a REAL cluster...). This means that at any time a machine in the cluster can be removed from the cluster, and hence all connections to it dropped. This, of course, does not give high availability... which is one of the reasons we actually have a cluster in the first place. Oracle, in all its wisdom, considered this an let the client-side oracle driver detect this and throw an exception, which then needs to be caught and handled, and by handling it the action can be redone. Of course, this means having a transaction being rolled back (because really, we're talking oracle and that means enterprisey), and we would want to redo that transaction. To make this easy, the spring-data jdbc extensions has a rac failover interceptor which does this for you. It wires itself to all transactional annotated methods, and retries a number of times. Of course, we ca...