Greetings,
We have been using our reusable "user-management" module which was written using Spring/Hibernate(using Doman-Model Pattern).We have used that module in several project integrating with Wicket,JSP and ZK frameworks.
Now I am going to develop an application using GWT.I am completely new to GWT and I noticed that the domain objects should go inside "xxx.xxxx.client" package.
But I want to use our reusable module (jar) and the domain model is in completely different package.
How can I use my domain-model object from this external library in GWT?
How about service interfaces? Do I have to write proxies for them too?
thanks in advance
For your domain-model object to be used on the client side (ie: to be translated in javascript), you need to provide the sources to GWT during compile time. You also need to tell GWT in a module which package name you need to compile. See how to organize projects in GWT.
About the GWT service interfaces, I'd suggest you to integrate GWT with Spring. There is a nice tutorial about how integrating GWT with Spring. The RPC calls of GWT could be then be routed to your existing services.
Hope it helps.
Related
I have created a Java webservice in Eclipse which provides a REST API and an Android project (in Android Studio) which consumes said API. The problem I am facing right now is that I want to use the same model/domain classes in both the Java webservice and the Android application (the webservice uses Maven whereas the Android application uses Gradle).
At the moment I am manually mirroring any changes I make to the model classes in both the Java webservice and the Android project. This is however very tedious and obviously not a good solution.
My questions is how I can solve this issue. I thought about creating a Maven module containing the model classes and importing them in the Java webservice and the Android project. However I am uncertain if this a solution which will work.
Are there any better (and maybe obvious) solutions I am not seeing? Thanks in advance for any help!
Edit: Is it actually smart to share the whole model classes? I clearly don't want to use all the attributes from the webservice in the Android project (e.g. passwords will never be stored in the Android project but have to be stored in the webservice).
You could create a library for your model, and share it between the provider (REST API) and the consumer (your Android app). That could be done with a multi-module maven project, where you can have a module for your model layer and another module for your REST API layer that uses the previous model artifact.
Doing so, you could install the model library in your local repository (or deploy it in whatever centralized repository you may need) and use it from your Android application.
But I would advice you against sharing the model that way, because you would be tight-coupling your consumer and provider at the model level. That would make it harder to evolve them independently.
I would like to develop a "database based" java desktop application in the following way:
Develop the Data Access Layer (DAL) using JPA (POJOs generated by Netbeans 7.4)
Develop the Business Layer (BL) (my own classes, controllers, etc.)
Develop the Presentation Layer (PL): Graphical User Interfaces (Panels, Frames, Dialogs)
Making the (PL) communicate with the (BL)
I developed the (DAL + BL) in a single Netbeans project (ProjectDBL.jar).
I developed the PL in a separate Netbeans project (ProjectGUI)
I am importing ProjectDBL.jar into ProjectGUI as a compiled library.
I didn't add the EclipseLink libraries to ProjectGUI since they were added in the ProjectDBL.jar.
I didn't add the database driver library to ProjectGUI for the same reasons.
I would like to fully separate between my DAL+BL and my PL. Further database modification (MySQL->SQLServer for example) should not impact all what was done in the PL.
The problem i am facing is a kind of exception raising when i want to invoke any method in the ProjectDBL.jar:
Exception in thread "main" java.lang.NoClassDefFoundError: javax/persistence/EntityNotFoundException
It seems as if the Persistence Unit must not be instantiated by an external jar...
A compiled library doesn't include all the libraries it uses. Otherwize, every jar file would be 50MBs large, and you would end up with commonly used libraries being present several times in your classpath.
You neet to add every library you use, directly or indirectly, to the classpath.
Consider using an Enterprise Application archetype for this.
Your DAL and BL would be contained in the EJB project, and the PL would be in the web project.
This specific case is exactly what this archetype is for, and will ensure that you're including the necessary libraries in each module, not just the compiled classes stripped of their dependancies.
As an aside, when using JPA, if your DAL/BL is encapsulated in EJB classes, you also get Container Managed Transactions, so it's a good idea to segregate classes as you have anyway, because you can take better advantage of JEE's extensive built-in plumbing.
I have a Java EE based REST api application. It has a layered architecture like the following:
Resources (Jax-rs resources)
Object Validation
Object Mapper
Service Layer
Repository Layer
JPA Entities
Everything is wired using Spring dependency injection.
I need to design this core application in such a way that it allows other external developers to write extensions/plugins and override or extends any minor or major functionality in the core. Think of it like Wordpress CMS in Java EE if that helps. How would you design a plugin system around the current architecture?
One obvious way that I can think of is override or add new functionality to the proper resource (with validation, objectmapper), service, repository and entity and create a jar + xml out of it. But I want to make sure that the plugin developer has to write the absolutely minimum amount of code to get the new functionality working, while reusing mush of the core code.
Assume, you want to create a wordpress blog post extension that lets you create blog posts with few extra fields that don't exist in core yet. What would be the simplest and cleanest way to go about designing the current Java EE app, so its easy for the plugin/extension developers? Any patterns that could be useful like strategy or template method pattern?
Are there any open source Java CMS that follow the model using Spring/JPA and standard technologies?
I think you mean to extend the functionality, rather than override the core. Typical architecture examples define concerns which can be overridden (separate from core) and make provisions. Eclipse framework achieves this using a combination of plugin-extensions & extension-points mechanism. This is taken further using OSGI bundling.
Another alternative is to breakdown the application into smaller independent modules/services. All you need to do is host these modules over an ESB/Application Integrator (like Mule/Spring Integration) and allow users to configure their version of routing/transformation. Extension would mean creation of new transformers which get added to the message flow.
I am developing a Spring (Java framework for server-side web-development)web application, which will respond to another client-side Java application(which uses socket communication) by a JSON object. At the same time, I'm working on both server-side and client-side Java applications.
The problem is that I have a bunch of files(say, a Json variable interfaces) that are being used at both projects. For now, I have duplicate copies of that interface, in different packages in the two projects. But this causes inconsistency, because I have to update the both files whenever I need to make a change in the interface.
Does anyone have a neat solution for this?
Thanks
You should treat your shared code at the package level and not the file level.
You should create a package of interface definitions that are used by both the client and server side of your architecture and whenever that package changes, both sides will have to change accordingly.
EDIT:
I wasn't explicit about it but zellus' suggestion about importing the common code as a jar is a good one.
You might create a separate project for your common JSON code. Using subversion, svn:externals allow a neat integration on the source level. Importing the common code as jar file is another approach.
If you're using maven, you could create a local maven project containing all the classes you might need in different projects and add this dependency to your pom.xml which requires these classes.
I'm currently using Java & Spring (MVC) to create a webapp, and I'm considering moving to Grails. I'd appreciate feedback/insight on the following:
I have multiple application contexts in the current Java/Spring webapp that I load through the web.xml ContextLoaderListener; is it possible to have multiple application contexts in Grails? If, yes, how?
This webapp extensively uses a CXF restful web service and the current Java/Spring webapp uses the bundled CXF HTTP client. Can I continue to use the (Java) CXF HTTP Client in Grails?
I implemented Spring Security using a custom implementation of UserDetails and UserDetailsService, can I re-use these implementations in Grails "as is" or must I re-implement them?
There is an instance where I've relied on Spring's jdbc template (rather than the available ORM) and an additional data source I defined in app context, can I re-use this in Grails?
I plan on using Maven as the project management tool; are there any issues of using Maven with Grails where there is a combination of groovy and java?
Edit:
I'm considering moving to Grails to make the development of the web component of the webapp "faster," a la Ruby-on-Rails. Also, I'm considering Grails rather than say Ruby-on-Rails, because I want to continue to use the JVM and I've dabbled with Grails in the past and it was fairly easy to pick-up and use.
Probably. Grails uses a sub-class of Spring's ContextLoaderListener class which it configures in the web.xml file. I can answer more precisely if you let me know how you do it with Spring MVC.
Yes. You might even be interested in the CXF plugin, although I can't vouch for it:
http://grails.org/plugin/cxf
You should be able to use them as-is. However, you might want to check whether this is easily done with the Spring Security plugin. I believe it is, but you'll be able to get a definitive answer from Burt Beckwith, the author of the plugin.
Yes. You can also get hold of the Hibernate session factory to do raw Hibernate stuff. GORM can also work with multiple data sources:
http://grails.org/plugin/datasources
Another Burt Beckwith one :)
It depends on what you mean by "a combination of Groovy and Java". You can build Grails projects with Maven, but the integration isn't entirely smooth. If you have Java and Groovy in your Grails project, then that's taken care of automatically.
In response to Bozho, I use standard Grails services + GORM and wouldn't do it any other way. Note that if you use Java for services and the domain model, you won't have automatic reloading of services. You also lose the benefits of expressiveness and conciseness that Groovy bring.
If you want, you can use static types in Grails services to make it easier for your IDE to provide code completion. It can also give you hints on properties and methods it doesn't recognise (which would corresponding to Java compilation errors). That said, even if you use static types, Groovy can't do type checks at compilation time. You'll only find out about them at runtime.
You can do all these things in grails. It supports all existing Java classes and spring configurations (grails is built ontop of spring mvc)
However, I really wouldn't recommend moving the whole application to grails. You can perhaps move only the web layer, if you have web developers that are not java experts.
The service layer, the data access, etc, better remain pure Java. That is, only your web controllers - the components that gather the user input, handle http requests and sessions, should use grails. The rest - the stateless service classes and your domain model would better be Java. That's my opinion, but I have already some experience with grails, and static typing in the service layer will save you much trouble.
2) Yes you can use CXF as is. There is a nice layer on top of CXF called GroovyWS. I have only used it for consuming SOAP services, but maybe it has something for REST as well. It's really easy to use.
For consuming REST services I have used HTTP Builder
4) Yes. You can continue to use e.g. spring config for configuring the datasource, or any other way you do it today. Multiple datasources is no problem.
5) I have recently tried using Grails (1.2.1) with Maven. It works, but there has been some issues with both Maven and Grails trying to do dependency management. The documentation is maybe the worst part. I haven't tried upgrading to 1.3 yet because of some major Maven-related JIRAs, but 1.3.2 is right around the corner, and those issues have now been resolved :) There will also be a 1.3.2 maven archetype. Looking forward to that. "Deployment and resolution of plugins from Maven repositories" is one of the new features of Grails 1.3, so things are probably better. Roadmap for 1.3.2 says release today, but there are 8 issues left at time speaking, so my guess would be tomorrow, the Grails releases are usually on time. If you can wait for that, you will probably save yourself some trouble.
If you are looking for rapid application development but aren't otherwise particularly enthused about groovy, you should look into spring-roo. It offers the same kind of RAD functionality, but builds a completely standard java + ORM + spring-mvc app (which has no actual dependencies (runtime or compile) on roo). It's definitely not as mature as grails, but you may find that it better suits your existing experience with statically typed java code and existing ORM, etc. I've only done a couple of small pet projects in roo, but I've been very impressed so far, particularly with how easy it is to customize the generated code and move back and forth between written and generated code. The initial tutorial is very rapid and quite revealing.