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.
Related
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.
I'm writing an application that manages something like Drupal's nodes. I'm planning on using the app in various content management systems / applications (Concrete5, Wordpress, custom Zend & Yii applications, etc...).
Since I'm using it in so many different places, I have to package an ORM with the app (ie I can't use Conrete5's or Yii's ORM, etc...). I love Doctrine 2, but am concerned that this is too 'big' of an orm to be packaged with my app.
It get's messy, for example, if I'm incorporating this app with a Zend application which is running Doctrine 2. I don't want two 'instances' of Doctrine running in the same app. Is this a warranted concern?
Question: Is Doctrine 2 too 'big' for this project? If so, what would be a good alternative ORM?
If you are going to use your application as an extension for other CMSes and/or frameworks,you should definitley use an ORM for the following reasons which comes to my mind:
1.CMS database installations are different.some use mysql some use oracle ,etc and you will have to create your own adapters or
2.Use CMS's native database abstraction layers.So you will have to rerwite your own model for every cms plugin you are gonna make.
3.Doctrine can do many big jobs but using doctrine is rather easy.doctrine is not resources intensive.
4.using more than one instance of doctrine will not be a problem as far as i know.
5.however doctrine2 requires minimum installation of PHP 5.3 and some shared servers might have older versions of php which this problem will be resolved while time passes and 5.2 becomes obsolete.
However in some CMSes more than one connection will made for your extension to work.(one for the CMS'S native database queries and one for your doctrine query.)
Way 1: work with different ORM's via adapters
(+) better integration with frameworks
(-) a lot of work to implement adapters
(-) loss of flexibility (limited by your adapters interface)
Way 2 (my choice): Use PDO with FETCH_CLASS, it's comfortable enough (you can fetch data to instances of your classes). Most of modern ORM's on PHP works through PDO, so integration must be easy.
Also about Doctrine 2 & Yii -- I tested this combination, works fine.
We are developing a web application using Spring MVC, Spring and Hibernate.
We need to add efficient free text search capabilities to our applications. For this we are thinking of using either Hibernate Search (it uses Lucene under the hood) or directly lucene.
What is the best option for us as we are already using hibernate in our application? What are the pros and cons of one over the other?
Thanks.
You said it yourself - you'll be using Lucene one way or the other.
The raw Lucene API isn't very easy to use. It's much more low-level than Hibernate Search. if you're already using Hibernate, then it's a no-brainer - use Hibernate Search to implement your text search functionality.
disclaimer: I'm one of the developers of Hibernate Search.
The goal of the project is not to compete with Lucene nor Solr, but to facilitate as much as possible integration with Hibernate applications, to avoid having to maintain the two worlds in sync and duplicate all mapping and CRUD operations.
While we provide some common helpers and a nice encapsulation, Hibernate Search can also hand you over a direct reference to the Lucene API, so in case you find yourself needing to use the "raw" Lucene API you will never be stuck. Also for writing to the index Hibernate Search provides a common pattern which will solve most of known requirements, but in case you have very non-standard requirements you can get full control of the written Documents.
Solr is a good alternative, but as it is a separate server you have to interact with it via REST APIs which is quite different, with it's pros and cons. Having a second service to manage is not always wanted, and of course the remote invocations will never be as efficient as direct references to Lucene and to all it's internal filters and caches.
Not all functionality of Lucene can be exposed via a remote API, and if you need to do some "low level" operation, if this is not implemented in Solr you won't be able to do it (without patching Solr). Still Solr is very cute, especially when you want to share the index with other non-Java applications, and so we might add a Solr backend for Hibernate Search to eventually keep a Solr server in synch (especially if there's interest for it, and possibly some help).
Finally, the Lucene API is really hard core stuff. We spend a lot of effort to make the best use of it to provide top performance while exposing a stable API to people using Hibernate Search, basically until now all releases have been backwards compatible to provide a "drop-in" performance boost to use latest greatest tricks from Lucene - which actually changes API quite often; these changes are always exciting, but be prepared to maintain that in your application if you don't use a proper abstraction.
The other way of using Lucene is to get the middlman API which is known as SOLR. SOLR will connect to Lucene and perfom HTTP calls for search. Please note that you will need to build and Parse the XML what Solr consumes. All the functionality of Lucene is exponse via SOLR and should be really helpful.
I want to develop my own website administration.
Here is my problem, I want to use these technologies :
* search : LUCENE/SOLR
* users' permission : ACEGI (SPRING SECURITY)
* taxonomy (I do not not if there is technologies for this)
So I do not have experience in these technologies. I would like to know if somebody understand my situation in order to help me...I think there is a logical coherence between theses elements but I do not why...Do I need to develop these functionalities as if they were totally independant ?
I've had some success in building web sites using Grails. Grails is the Java-world equivalent to the Rails framework, and is built on top of Spring, Hibernate, and Groovy. It also interfaces smoothly with existing Java code, because it runs in the same virtual machine and is, basically, Java. In addition, Grails has a rich collection of plugins, including ones for search and authentication/security. I am not sure what taxonomy you're referring to, but that may be something you can model using Grails Domain classes.
Both GWT and Wicket are stateful, java object oriented based. GWT is completely client based with features like javascript optimization, CSS optimization, and I'm pretty new to Apache Wicket.
The more I read about Wicket the more similar it feels to GWT.
So I guess the question is - What are the differences between GWT and Wicket? Or am I comparing apples to oranges?
I have been using both GWT (1.x and 2.x) and Wicket (1.4, 1.5) on a large project for several years now, and both frameworks have their advantages and drawbacks. Both of them are cool and nice, if they are used for what they have been designed for. But you can take the best of both by mixing them together easily.
Wicket is really nice and powerful for CRUD websites, with a good separation between the page design (HTML) and the Java code. As long as you do not need powerful client capabilities it's doing it's job very nicely, at the prize of being a bit code-verbose: but that's the prize to pay to be strongly typed: there's no "magic"; refactoring and componentization works like a charm. For large projects it can be easily decoupled and is well designed to work with large teams: people can focus on providing a nice set of core components, other on the presentation layer, etc... The only drawback is for complex behavior on client side, you still need to master Javascript and it can easily become rather complex to mix Wicket and Javascript yourself.
GWT is nice when you really need rich behavior capabilities on your client (GMail-like application). The main problem with GWT is that it look too nice on paper (the "everything in java" paradigm), but it does not fulfill it's promises. It does not scale well: GWT is nice for small modules providing a small set of functionalities, not for large applications. Code/compile/debug cycle is rather long, and when module size grows too large it becomes a burden. Also it does not support well large teams working concurrently on the same module.
To summarize, I would suggest people having to choose:
Use GWT sparingly when it's really needed, keeping module size small, and never try to build a whole big application entirely with it;
Use wicket for the rest (Wicket really rocks!).
To mix both together, use the powerful component capabilities of Wicket to modularize GWT code in a "wicket way" (GWT modules becoming a special kind of Wicket components), and again, keep GWT small.
It is pretty much apples to oranges.
This wiki entry summarizes some of the similarities and differences, and the start of a strategy for using them together, which I think is an interesting idea.
Wicket is primarily a server-side technology with some built-in Ajax support and hooks for wiring in more Ajax. It does not translate Java to JavaScript like GWT. It maintains state server-side where GWT maintains state on the client.
Both are component-based and to me have something of the feeling of Swing development (though Wicket doesn't seem to feel like Swing to at least one other respondent).
Now with GWT 2, what are the advantages over wicket and likewise?
It's been 6 years since this thread was active and GWT has mostly stagnated.
Wicket seems to be much more actively developed and supported.
Anyone have newer opinions about Wicket or other options?
Wicket is server based framework.. It is much more similar to JSf than GWT. GWT is conceptually similar to Swing, I am ex-swing developer, it is very easy to migrate from swing to gwt. But I cant say same things for Wicket or JSF..
Wicket is server framework. It allow to create html which you needed. It is possible separation of roles in project. (Web design->html/css->java).
If you consider to use GWT for you project, web designer probably not needed.
GWT generate javascript. Most logic can be executed on browser side. GWT better for scalable application.