This week's book giveaway is in the Open Source Projects forum.
We're giving away four copies of Spark in Action and have Jean-Georges Perrin on-line!
See this thread for details.
Win a copy of Spark in Action this week in the Open Source Projects forum!

kato Kwong

+ Follow
since Sep 23, 2011
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by kato Kwong

Having read the intro on the link provided, I see that there is a notion of learning how to write a cross browser library.

What is the use of this given that there are many already out there that are quite good? I believe you have written several books about them yourselves.

For anyone interested, turns out this is a bug in the manifest header of the org.apache.servicemix.bundles.ehcache bundle.

The DynamicImport-Packages = * is not a valid OSGi header, it should be: DynamicImport-Package = *

A small but significant difference.

This has been tested by manually adjusting the header whilst waiting for a fixed version.


I am using ehcache 2.5.1 to cache my objects. I've deployed on ServiceMix 4.3.

I am using the ServiceMix bundle version of Ehcache, which has the headers set as follows

I have made sure that my bundle exports the offending package:

And yet I still get the runtime error:

What am I missing?

Thanks for your reply Gunnar, very interesting.

Particularly when you say:

one may consider OSGi being an even higher-level of abstraction for applications (but could use Spring Integration internally)

I always thought that OSGi would be used to define application modules that would be fine grained “chunks” and combine them to form the coarse grained “chunk”. This coarse grained "chunk" can then be integrated with other coarse grained “chunks” using SI, for example. The reason for this is OSGi offers a way to integrate the chunks as though a normal java method call were being made, i.e. there is no overhead for calling an external module and we can make them as fine grained as we like.

But maybe this is the wrong way round…or maybe it could be used in both ways…or maybe I have confused the purpose of OSGi...

Maybe I’ll just have to read the book!

7 years ago
Mate, I love your brazen attack on Camel code quality. Poor old Camel.

I would like to point out you have not backed this up with any of the somehow you would like from a Spring Integration critic...
7 years ago
Thanks Gunnar.

I've read a reply you made in another post: spring integration vs ESB and you say:

Thus, you can use Spring Integration easily as a library within (existing) applications. This means Spring Integration is also very suitable for intra-application integration and not just for business-to-business (B2B) or application-to-application integration (EAI).

Is it thus the intention to make integration patterns more accessible from within applications?

Does the book discuss the trade offs involved in using integration patterns in this manner, e.g. overheads involved in any transformations?

And what are your thoughts on the use of spring integration vs spring dependency injection vs OSGi in making applications more modular?

I mean, with Spring we have a great way to decouple components of an application. With OSGi we have a way to formalise this decoupling at a physical level. So why do we need to complicate matters further by using integration patterns within the application?

I'm just trying to understand the bigger picture

7 years ago

I am wondering what is the mission of the Spring integration project.

Is it to provide a DSL for integration patterns that follows the Spring way?
Or is it to provide a microcontainer for integration?
Or is it just an alternative to other frameworks like Camel?
Something else?

I have little experience of integration and I get confused about when I might use integration patterns (other than when coupling existing and legacy applications).

Does the book discuss reasons to use Spring integration rather than the Spring integration features themselves?

7 years ago

I am trying to understand managed transactions and how they are related to XA.

My understanding is that XA resources, such as data sources, allow 2 phase commit where multiple data sources are involved in the same transaction. This must be managed with a JTA transaction manager.

But where only a single data source is involved, there is no need for XA data sources.

Is there still a need for a JTA transaction manager?

Is a non-JTA transaction manager still able to manage transactions as they are propagated through the application?

I am using JBoss 5 with Spring 3: this means Spring transaction annotations and Spring JtaTransactionManager.

Any help appreciated,


I am using MyBatis 3.1.1, mybatis-ehcache 1.0.0, mybatis-spring 1.1.0 with Spring 3.0.6 and Ehcache 2.0 for caching. I would also like to use Terracotta for a distributed cache at some future date.

I am forced to deploy my application in a container that is itself an application. Unfortunately, it uses Ehcache itself. This would not be a problem except the classloader of this container application is used by my application to find . And of course it does not find my version but the container version which then cannot find my application ehcache.xml.

I have tried moving my config file to the container classpath and that seems to work. I have also tried to remove the container Ehcache JAR, which also works. Unfortunately, neither is an option moving forward.

So I am wondering what I can do. Is there a way to configure MyBatis to use a specific version of Ehcache? Alternatively, I could configure my ehcaches through MyBatis, but I am worried I won't have access to the full range of Ehcache properties, especially the terracotta element. Here is my ehcache.xml

Could I write my own class that wraps org.mybatis.caches.ehcache.EhcacheCache and somehow loads the correct Ehcache library or at least config file?

Or should I cut my losses and try to use a different caching solution?

Any ideas appreciated.

8 years ago
Not sure about catalina.out, but if you define loggers in your application, using log4j for example, then you can set up a RollingFileAppender which has a max file size and it will create new files when the limit is reached. In this case no output from your application goes into catalina.out, so you probably don't need to rotate it.
8 years ago
Hi Kirk,

Thanks, that excerpt is quite interesting – may have to buy the book

But I just have a few follow up points that perhaps you can help me with.

I’m using JPA and so my entities contain JPA annotations. Then my DAO implementations simply use the entity manager. So do you think this separation is still valid?

If so and I create different module JARs, can we put them in packages of the same name? I believe this is not allowed in OSGi because the packages will shadow each other, is this right?

In keeping with the domain driven approach, I have entity repositories that often use DAO interfaces, but are a domain concept – not a software one. My business logic involves the use of repositories to retrieve entities, update and save them. Would these become the service layer in a new module that encapsulated the data access logic?

Hi Kirk,

Having a look around your website I see you discuss the granularity of modules and I guess this is discussed in the book.

I'm keen on domain driven design, where domain objects reside in the same packages as the factories and repositories that create and store them.

This means the application data access layer is not as a whole in a single explicit package.

Do you think that this is wrong and that domain entities should be separated from domain repositories (and DAOs), even to the extent of shifting them into separate modules?


Thanks for the links Kirk.

Talking about the relative maturity of OSGi and application server vendor OSGi support, there is also the OSGi readiness of 3rd party frameworks to consider.

Being aware of the different class loading paradigm so as to avoid coding pitfalls in my own code is one thing. Another is using 3rd party frameworks such as Hibernate.

Is there any virtue in the OSGi specification being mature if container and framework support is not? I guess this is an evolution...

As you say, by making my code more modular I may resolve some of my issues, but at least I can be satisfied that I will have written a better application
Hi Kirk,

Your book sounds interesting.

I just happen to have started using OSGi by trying to deploy an existing application that is designed for web application servers and am having a lot of trouble with dependencies and class loaders.

Reading some of your introduction, it seems as though some of my problems are because my application is not designed in a modular fashion: I guess I need to pay more attention to the physical design.

But if the theory is valid and useful right now, it seems to me as though the tools and containers I am using are not very robust, some may say flaky (I am using Karaf/ServiceMix 4.4).

What are your thoughts on this, are the tools mature enough for modular JAVA? Or should we wait for java 8 or maybe 9 to avoid the early adopter struggle?

I would say that if we are just talking about IoC and dependency injection, then OSGi will not replace spring.

This is because OSGi and Spring offer two different things. OSGi is a specification for defining how modules interact. Spring IoC is more generic, it can be applied at any level. Spring DM, AFAIK, was an attempt to define a module specific version of the IoC that adhered to the OSGi standard and yet was a simple extension of the core spring IoC.

I would think that Spring IoC should be used to develop modules, which would be deployed in an OSGi container. Whether Spring or Blueprint is then used to define OSGi services and clients, i.e. how the modules interact, is another matter.

This is of course assuming that the definition of a module will not narrow to any size component of code. In this case, as stated earlier, by using OSGi we would be using a heavyweight tool where a lightweight one would be sufficient.
8 years ago