I have a core java application which is using Quartz 2.2.1 with JDBC job store. All the jobs are scheduled in the same.
I am building another Spring based application using Appfuse, maven and Quartz.
I want to reschedule the jobs running in the former application from the spring application.
While doing that I am getting class not found exception as I have not added the job classes in the class path.If I am adding them I am able to update the jobs.
Is there any way to manage the jobs from Spring application without adding the job classes in the class path.
I do not want to update the quartz database using jdbc or hibernate.
Yes, that is a known limitation of the Quartz remote API. It becomes very painful if you have to communicate with or manage multiple Quartz scheduler versions remotely. It becomes even more painful when the management application uses the Quartz API internally (which seems to be your case).
If you take a look at the QuartzDesk project that I founded, you will find out that it very elegantly solves the problem by exposing a JAX-WS SOAP interface through which you can communicate with and manage external Quartz scheduler instances. It hides all Quartz scheduler API complexities and Quartz differences behind a simple Quartz-like API.
The JAX-WS interface is described here and there is also the relevant WSDL file available for download.
Related
Java Spring Boot MVC and CLI API in the same project
I have implemented a web app using Spring Boot MVC and I now I need to add an API whose functions can be called from a cronjob.
I would like to use Entity and Repository classes implemented in my Web app. I was thinking about creating a new main class which implements
CommandLineRunner interface and then create separate JARS for Web and CLI applications and run them independently. Is this a good approach?
Do you have any suggestion about the architecture?
Thanks
Concur with comment from #jb-nizet - cron is really just another client of your application, and using a (bash,etc.) script wrapping curl, httpie, or wget to call the controller is a good solution.
Advantages include:
can be called remotely
doesn't add complexity to the application
application boundary/interface remains the same
doesn't add a new application (except a relatively trivial script)
not tied to cron - could be almost any other application
Considerations:
authentication (if needed) and the management of credentials in the script/cron
if all methods/actions needed for cron are new and different to existing functions in the web app, do they make sense to be encoded in the webapp?
We have a variety of batch jobs that are currently set up with spring, quart, hibernate and talk to the webspere connection pooler. We deploy them to the EAR that is most closely related to them in subject matter.
But we are starting to think it might be a bad idea to link the batch jobs so closely with the GUI and web services. And it seems like a waste to have them in websphere merely to take advantage of the j2ee container.
Is there a way to run these jobs from outside the app server but still have all the comfort of the j2ee connection pooler? Or is there some other better way to organize? What is "best practice" for organizing your batch jobs in java?
I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.
If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.
It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.
I'm using a set of APIs developed internally by my company to communicate with some common central services in the organization. The APIs can be configured dynamically by runtime configuration to use several transport protocols as needed by the system.
The collection of internal APIs are coupled to the IBM WebService thinclient.jar to configure and call all the necessary web services. I got the standalone prototype working smoothly, but need to integrate the functionality into several other services that are being developed in Grails.
This is where things fell apart. In the code that I've written, we just call a factory method and use that to get a client session and then proceed with our business logic. Simple. Using the debugger and digging into the API getClient() call, I can see that this gets a generic transport configuration and then binds it to a SOAP transport configuration. From here, the path differs whether it is the pure standalone Java service or the service running in the Grails app.
In the pure Java standalone, this then is bound to a
com.ibm.ws.webservice.engine.client.Service where the
initService() method is called and things work as expected.
In the Grails app, with the same Java code included, the same place
in the code calls to
com.springsource.loaded.ri.ReflectiveIntercepter and then after a
lot of back and forth in the spring-loaded API, it finally throws a
java.lang.reflect.InvocationTargetException.
Does any one have any tips or ideas on how to get the reflection in Grails to behave the same as in the straight Java?
I've tried a lot of variations to get to this point and I'm nearing the end of my rope. Ideally, it would be easiest to manage the Grails service that manages our business logic and the Java code that talks to these internal systems together, so I would prefer to get everything (Grails and my Java service code) working together. I briefly tried building a standalone JAR of my service code and all it's dependencies, but had chained dependency conflicts when trying to use that in Grails. My final option will be to stand my Java service up separately from the business logic in the Grails service and just make the calls from the Grails service to the Java service. This is less than ideal.
It's easy when you stumble into the answer... ;-)
The Grails service runs as expected if I set the run configuration in IDEA to use -noreloading option.
grails -noreloading run-app
This stops Grails/IDEA from leaving in the hooks to reload classes on the fly.
Are there any thoughts on whether this is a bug in Grails or the SpringSource Loader classes?
Has anyone worked or has any experience with executing spring batch jobs from web UI. Currently I have written few jobs for data-copy from CSV to DB table, it runs fine from command prompt and in a JUnit test. But now these jobs have to be executed through web, JSF is being used as the front controller framework. Any suggestions about the best practices in this case would be very helpful.
Thanks!
Spring Batch Admin is a deployable web frontend for your Spring Batch jobs. If all you want is a simple UI instead of a shell script for Administrators, take this approach:
http://static.springsource.org/spring-batch-admin/getting-started.html
If you're looking for a way to integrate the job trigger mechanism with your existing application, look at this implementation using Spring's JobLauncher which can be invoked from Controller/Servlet:
http://docs.spring.io/spring-batch/trunk/reference/html/configureJob.html#runningJobsFromWebContainer