I am developing a standalone java application which is later packaged as a jar and will be deployed into an Enterprise application(EAR).
I am accessing database several times in my application using JDBC, in this application can I use any of the data access design patterns like Abstract DAO? or should I not consider including data access layer or any such layers in a stand alone java application?
Of-course you can do whatever you can do with a web application. Moreover, the abstract DAO pattern is not specific to a particular set of applications.
There are couple of ways of doing this.
You can create the DAO code as a jar and include it in the class path of other proejcts which are deployed as EAR.
Yes having a data access layer to consolidate your JDBC code instead of having it scattered throughout the application is beneficial. Also should consider using a db connection pool. An example is Apache DBCP. Just because it is a stand-alone app does not negate the benefit IMO.
If I were to it, I would :
Create a dedicated library dao.jar (packaged as a jar) that would contain the DAO code
Create a standalone (runable) application app.jar (runnable jar) that relies on this library
Make my ear app.ear use the dedicated library (dao.jar) NOT the application
If there is some business logic, you can create an additional library that contains it business.jar that relies on dao.jar and make app.jar and app.ear rely on it too.
One jar should have only one major responsability or layer.
dao.jar can use any useful design principle or design pattern to access its data.
Related
I have a Spring Boot REST application with JPA entities and Repository classes (and related services) that works very well. Now I would like to reuse these classes for other purposes, like weekly CRON jobs and similar one-time processes which will be run from the command line.
What would be the best way to do this? The challenge is that the persistence context properties are set in application.properties, and the persistence context isn't initialized unless the Application class is initialized.
I can break out all of these classes into a separate project, and use a different way to define the persistence context there, but this becomes more of a maintenance headache if anything changes with the entities or DAO methods.
What I would really like is to have a way, from the command line, to tell Spring Boot to run another class instead of the main Application (and have the persistence context properly initialized). Any way to do this?
(Note I asked a similar question which got no response: Possible to use Spring Boot repositories from another main class?)
[Edit] is it possible to do this by creating a #component that implements the CommandLineRunner? I just want it to run a simple one-time process and not the full REST application.
There are a number of ways you could do this.
You can have multiple Main classes, and then select which application yuo want to start select main class, however if you don't know how ComponetScan works you will end up loading both applications if you are not careful.
Another way is to use Profiles, you can set the profile when you start your spring app, and then have your web profile that will start Tomcat, and a command line profile that will not .
In the project I'm working on we have choosen to have the data-layer as a completly separate module (same gradle project), which has it's own Spring Context. The data-layer spring context is then used as the parent context for other applications, as a reusable component. It is a somewhat cleaner separations of concerns, were the shared code is clearly marked, instead of having multiple applications inside the same code mudule.
I am trying to develop a java software based on OSGi (Apache Felix), which different module (which may contain more than one jar file) could be developed by different developers from different companies.
the question is: i am wondering how should i provide database connection to these modules. if i share the same user credential between modules, they may accidentally or intentionally use each other tables or data which should be avoid because of information privacy. or if i force each module to have its own connection with its own user credential then there will be many connections.
note: i am using mariadb as backend.
i know this problem is not a OSGi specific problem. i am wondering if anyone has faced such problem and has proven solution for this scenario (i only describe my development environment).
any idea,
thanks
First of all, your issue of multi-tenancy isn't something any system (beeing it OSGi or not) is made for. Therefore you need to take care of this yourself. Most OSGi applications still use datasources if you want to connect to a db, via JPA for example. Usually those datasources are registered as OSGi services.
Coming back to your multi-tenancy issue, you should make sure for each you have another datasource and just use that datasource in your application. For example make sure each tenant has it's own configuration and therefore receives his own Datasource as configured in your configuration. This way you can make sure each tenant is separate to each other.
OSGi cannot achieve the level of security you need for this scenario. An OSGi Framework is intended to represent a single logical application. If bundles exist in the same JVM and OSGi Framework, then it is very hard to prevent data leaks, especially against determined attacker.
You need to isolate processes at the very least, and run those processes as separate user IDs.
I'm creating an application that relies heavily on dynamic creation/management of various resources like jms queues, webservice endpoints, jdbc connections... I have a background in java EE and am currently working on a jboss 7 server however I'm finding it increasingly difficult to control these things programmatically. The hardest thing to control seem to be the webservices. I need to be able to generate WSDLs (and XSDs) on the fly, manage the endpoints, soap handlers etc and the system simply does not seem to be set up to do that.
Other application servers don't seem to really offer any groundbreaking solutions so I'm wondering whether perhaps java EE is not the best solution to this particular problem?
Is there an application server that allows you to do just that? Is there another technology that does? Should I just roll a custom solution that integrates all the separate modules (e.g. a jms server, a web server etc...)?
UPDATE
To clarify, most java EE stuff is accomplished through a mixture of annotations and XML configuration. This however assumes that you have a POJO and/or a jar/war/... per resource.
Suppose I have a #WebServiceProvider bean which can be reused for multiple input/output combinations (for example because it dynamically redirects the content). I need to be able to deploy a new "instance" of the provider on the fly. This means I do not want to duplicate the code and redeploy it, I just want to take that one existing bean on the classpath and deploy it multiple times with different configuration settings. This also means I need to manage the WSDL dynamically. The end result should be a webservice that works pretty much like a standard webservice on the application server with the necessary integrated security, soap handlers,...
I imagine that at some point in the application server code, there must be a class "WebserviceManager" which has a method like "createWebservice(...)" that is actually used by the deployment module whenever it discovers a webservice annotation. I want access to that method and similar methods for creating jdbc connections, jms queues,...
You can use OSGi for these kind of scenarios. It is perfect for hot deployment of varios modules.
Consider the following example.
There is a server application that has three layers. The service layer that is exposed to the clients, the database layer that is used for persistence and the business layer that calculates something.
The application serves three different types of data. Users, Payments and Worktimes.
How should I package my application?
Package by layer:
foo.bar.service
UserService.class
PaymentsService.class
WorktimeService.class
foo.bar.persistence
UserPersistenceService.class
PaymentPersistenceService.class
WorktimePersistenceService.class
foo.bar.business
PaymentCalculator.class
Or package by type:
foo.bar.user
UserService.class
UserPersistenceService.class
foo.bar.payment
PaymentService.class
PaymentsPersistenceService.class
PaymentCalculator.class
foo.bar.worktime
WorktimeService.class
WorktimePersistenceService.class
I guess the first example could become confusing if the application grows and more and more logic is implemented. However, it appears to be easier to find the right place when the task is to "extend the persistent service layer to do something fancy".
The second example can be easier extended without flooding packages with millions of classes.
Is there any best practice to choose between them? Or do you guys have any other idea of a package structure.
As far as I am concerned I would package by layer AND type :
foo.bar.service.user.UserService
foo.bar.persistence.user.UserPersistence
And so on
For most of my projects I use maven and some multi modules :
Domain Model (Model Objects)
Persistence
Service
Applications
With this way, you could get different jars (or not if you have got only a simple project) and it is easier to retrieve the good place to extend/modify the existing sources.
What is more important for your application?
Do you deploy the layers/types to different machines (or might want to do so in the future)?
Do different people work on different layers/types?
If so use layers/types to seperate packages.
If your application is a little larger, you probably want to use both, resulting in packages like
foo.bar.<layer>.<type>
or
foo.bar.<type>.<layer>
Usually there is a model package in which you put the types (Users, Payments and Worktimes in your example).
Next to the model package there are layer packages like presentation and service (I normally nest data access layers within the service package to encourage these layers to only be used from service implementations but that's up to you).
If the project is a bit bigger I split out the service layer into a separate module. If it is bigger still (or the domain model is large and complex) I also move the model package into a separate module, resulting in a three-module project: model, service and presentation.
If there are also multiple presentation channels (e.g. web application, REST service and dekstop client app) these can also be split out into separate modules.
I'm working on a project that have several webapps (WARs) built with Maven and deployed in a Java EE.
These WARs share several common business JARS (like one containing domain objects which are loaded from hibernate) and other framework JARs like Spring and Hibernate.
They use Spring MVC, and the Application Context loads Hibernate. As each WAR has its own Classpath in the servlet container, the Hibernate cache (EHcache) is not shared.
What I'd like is to share the cache and also the hibernate session factory bean (as well as other common beans) betweeen the different WARs. I think this is possible by repackaging those WARs inside an EAR and then I'd have to make a spring configuration XML using those commons beans and in the WAR's Spring XML use something like SingletonBeanFactoryLocator from what I've read.
What I'm asking here is if there is a simple way to do this, minimizing changes to the WARs' POMs
Note: I'm familiar with WARs, tomcat and servlets, but not so much with EARs.
Thanks in advance.
Hmmm... Most Java EE containers use isolated classloaders for WARs, even in an EAR (even if the Java EE spec does not mandate class loading isolation among modules of a single EAR) so I wouldn't expect to much from an EAR packaging, especially if you want your application to remain portable (i.e. if you don't want to rely on any app server specific behavior).
Now, if really it makes sense to share your session factory and your 2nd level cache between several applications, maybe consider merging them in a single WAR. That would be the easiest way IMO. But I'd be tempted to ask why are they separate then? When applications are separate, they have most of time separate governance and I don't know if deploying them together would be a good idea in such case.
And if merging the WARs is not an option, please tell us which container you are using.
Have you considered making use of a coherent clustered L2 cache? If you're using multiple app servers you might see more benefit then as they would all be sharing the same coherent cache
Using a shared parent application context in a multi-war spring application
http://blog.springsource.org/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/