Moving from JSF to Wicket I continue my habits of having all JPA operations in a EJB facade use the container's transaction management. I use and know wicket-cdi for injection, which works fine.
Unfortunately, if I inject an EJB in a wicket page, the serialization checks of wicket complain that it is not serializable. This is true for EJB, I suppose since they are proxied.
My thinking is blocked at this point. How can I use jpa with container managed transactions with wicket? All examples I goggled are just reading data or are using Spring, what I do not want to do.
Thank You
Dieter
I repeated the question in the wicket-users mailing list and it was an interesting thread with 3 solutions.
One of them is my idea of encapsulating the EJB in a LoadableDetachableModel and realize the load by a JNDI lookup of the bean. See http://mail-archives.apache.org/mod_mbox/wicket-users/201210.mbox/%3C5072F013.9040702%40tremel-computer.de%3E
A little more generic solution I posted in my blog, sorry only in german language.
Related
I have read the spring guide with kotlin and its says data class for JPA is not recommended
but i am quite confused after seeing some tutorials and video using data class for JPA
did spring find a way to deal with data class in new versions?
We have developed several services with Spring and Kotlin and used data classes as e.g. entities. This works fine and leads to a lot less boilerplate. You do, however, need to configure your project with these build options/dependencies to avoid Spring interoperability issues:
https://kotlinlang.org/docs/all-open-plugin.html
You can use Kotlin for Spring Data entities. This is true for all Spring Data modules including JPA where Spring Data is not the one doing the mapping, but your JPA implementation does.
The problem is that all the libraries involved are developed with mainly Java in mind and Kotlin isn't developed with Hibernate or Spring Data in mind. Therefore problems are bound to occur.
For example Kotlin does generate a lot of stuff that isn't visible for normal users, like special constructors. But this is visible for reflection so in the past we had situations where the developer only sees a single constructor, but Spring Data saw multiple constructors and couldn't decide which one to use.
So you may use Kotlin, but especially when the next Kotlin version comes a long you might experience some extra pain.
I've been trying to find a clear answer to this question for a while but haven't had any luck. I need to know why Struts is tightly coupled? which component of struts makes it tightly coupled.
As this great Mkyong article discusses, what makes Struts tightly coupled is not the presence of something but rather the absence of something. Struts is basically a web UI framework, and it can be compared to Spring MVC. However, unlike Spring, Struts has no out-of-the-box support for dependency injection. As a result, this means that when using Struts your entire code may have to be changed if a given depenency changes. Another way of saying this is that the components you use in Struts are tightly coupled to the framework.
There are two ways of looking at this question:
Struts 1 itself is tightly-coupled, and
Struts 1 is tightly-coupled to the servlet spec
Issue #1
Eliminating this is trivial; use a supported version of Spring, and you have all the DI you need at the application level, e.g., you can inject your services, wire things with AOP, etc.
At the framework level you don't have the same flexibility. You cannot arbitrarily replace Struts 1 framework components. That's why custom request processors and action base classes are the first approach when framework-level functionality is needed–there's nowhere else to put it.
Issue 2
Eliminating issue #2 is less trivial: Struts artifacts all reference servlet spec artifacts, like the HTTP request and response. If you want to abstract that away, e.g., for easier testing, or business logic reuse, you must do so manually.
An example would be to marshal request parameters (e.g., form values) into a domain object or a simple map, and pass that to your domain logic.
Struts 1 was written before DI/IoC was what the cool kids were doing, before strict layer isolation was common, etc. It was written early. It carried that baggage on through the years because backwards compatibility is a thing.
You could argue that the coupling to the servlet spec is good or bad: it's really a matter of where the isolation between business logic and the web app occurs, who is responsible for it, and how do you want to test it.
Unit-testing a Struts 1 action is kind of a PITA. If all it does is handle the web-app-to-business-logic marshalling it's argiable they don't need to be unit tested: the business logic does, but the Struts 1 layer could be tested via an integration test at the web app level. (I'd argue that even makes sense, and I feel much the same way about Struts 2 action testing–but S2 actions are so easy to test (barring heavy interceptor interaction and a few other less-common things) that the differentiation is less important.
Is there a tool that can generate an apache isis application from JPA classes? Or do I have to rewrite everything with ISIS annotation?
Currently Apache Isis works with JDO, not JPA, so your larger piece of work is to change the JPA annotations. Under the covers we use DataNucleus, which does support JPA, so alternatively you could provide a contribution to enable JPA (this is on our roadmap anyway).
There is no need to add any Isis annotations, but I do anticipate you would need to write additional code in order to expose the business functionality surrounding your core entities. Isis' support for contributed actions and subscribers (over an in-memory event bus) would be a good way to do that.
For further questions, please subscribe to the Isis users mailing list.
I have some experience with NHibernate and I'm trying to get started with Castle Nhibernate Facilities OR Castle NhibernateIntegration. I'd like to know, where I can find a demonstration project of how to configure and perform transactional control (with attributes) in a service layer (business, class library project)? There is no documentation, and I have a really difficult to find some content to getting started.
I found some samples on the web but only with pieces of code and not the demonstration project... I would like to download something to study. I'm not finding to a complete solution, just the configuration and transactional control in business classes (class library).
Sorry for this kind of thread here, but I do know how to start.
Thank you!
If you want to see an full example of Castle Windsor integrating with nHibernate then I would check out Sharp Architecture
Sharp is an attempt at a 'best practice' template project and utilises a number of tech's (Castle and nHibernate included). While some of the things it does may not be to your taste it will clearly show you one of the ways that it can all fit together.
You may need to go hunting into the source repository on GitHub if you want to see what is going on at a low level as Sharp uses it's own base classes in the template project that are pre-compiled (tho its still open source so you can see what is going on if you want).
It was an invaluable help to me when I was putting my architecture together and I can honestly say that Castle and nHibernate are the way to go, so you are very much on the right track.
EDIT FOR COMMENT 1: Perhaps I am a little confused here. According to the Castle notes
Facilities are main way of extending the container. Using facilities
you can integrate container with external framework, like WCF or
NHibernate, add new capabilities to the container like event wiring,
transaction support... or to components (synchronization, startable
semantics...).
To the best of my knowledge both Castle Nhibernate Facilities and Castle NhibernateIntegration are Facilities and must be based on a container.
If you want to work without a container then you need to use some form of Singleton Factory to manage the SessionFactory. There is an example of this here.
In terms of attributes controlling Transactions then this is how Sharp does it (see here). You may get away with reusing this code and replacing NHibernateSession with your own Singleton like theirs.
You don't need to implement UnitOfWork as nHibernate is effectively doing this for you. What you really need is an architecture that allows you to manage a transaction at a single point of control (Singleton) and is available in every repository.
Can the WCF runtime be made to instantiate a service via an IoC container rather than via its usual process? (Also, given a potential clash between the container's lifestyle configuration for the type and the service's InstanceContextBehavior, would this approach be a terrible idea?)
I'm aware that I might be asking the wrong question altogether. My objective is an AOP approach via method interception facilities provided by the container (for example, method enter/exit logging, perf counting, and call throttling, all involving logic and dependencies that I do not want to insert into my service implementation). I imagine WCF provides other ways to approach this, so I would also be curious to hear other recommended approaches.
Short answer - yes it may.
Please take a look at Castle WCF intergration. It let's you use Castle Windsor for WCF, what gives you much more powerful capabilities than just injecting dependencies.
It's best to use the trunk version found here. There's not much documentation on it, but take a look at tests. They are easy to follow and will be a good sample code for you.
WCF facility let's you do exactly those kinds of thinkgs you're asking about.
Yes, heres implementations using both ObjectBuilder and Spring.NET (and more if you follow the links!):
http://www.infoq.com/news/2008/01/wcf-di
Can't comment on lifestyle and instance context behavior interaction though.
As for more WCF-specific approaches, leveraging WCFs behaviors concept (as the above example does) may also be useful. There are several different types, heres a starting point:
http://mehranikoo.net/CS/archive/2007/02/22/WCFBehaviours.aspx
Cheers,
Matt