A deployable Grails war-File contains groovy files as well as a groovy.jar.
Is there a groovy agent running when the application is deployed?
Is it possible to make dynamic modifications for the application via Groovy at runtime?
if yes, how can this be prevented?
Edit:
After the grails application war is deployed on let's say on Tomcat: Is there some kind of Groovy Shell/Process/Agent running where someone who has access to the system can connect to? And if this is possible can he make dynamic modifications to the application without touching any files on the file system?
You can use the Console plugin which provides a web-based version of the Groovy Console/Grails Console. Like the Swing-based app it has a ctx variable in scope to give you access to all of the app's Spring beans, and it will run arbitrary Groovy code in the context of your running web app, can access GORM, etc.
Obviously this is dangerous, so be sure to guard it with a security plugin
I wrote a blog post a while back about using a similar web-based console (which I've since merged into the plugin) to fix a bug in a running server: http://burtbeckwith.com/blog/?p=155
By default Grails apps do not ship with a console that will let you execute arbitrary Groovy code at runtime.
Related
I'm trying to use an Updatesite.nsf to deploy jar to a test server. I can see it in this case the jdbc driver plugin at the server console using the http osgi ss command. But when I use it I get a java.lang.ClassNotFoundException com.mysql.jdbc.driver. What I'm missing or doing wrong. Thank you
The immediate answer is that the code that's calling Class.forName will need to have the MySQL driver in its classloader one way or another, which an XPage or in-NSF Java won't have by default.
To expand on it a bit:
If you're trying to call it from an XPage or Java code in an NSF, it would have to be part of an XPages Library from another plugin, which in turn depends on and re-exports the driver plugin.
If you're trying to call it from another plugin, that other plugin should have a Require-Bundle or Import-Package entry to bring it in.
The class will be available to NSFs by default if you plunk it in jvm/lib/ext, though that admittedly gives up the niceties of OSGi-based deployment.
The reason it works for the XPages JDBC support is that the wrapped plugins created by the wizard in Designer include a special extension point to provide the driver class to the ExtLib code that wants it, but they don't make it automatically available to XPages apps themselves.
My company has a Web Application that uses the JAXB provider in the JDK
The application runs great in Tomcat.
We have a customer that want to to use WebLogic
The application fails when trying to create a JAXBContext.
This page https://docs.oracle.com/cd/E24329_01/web.1211/e24964/data_types.htm#WSGET347
documents how to configure a WebLogic application to not use MOXy for JAXB
When I use the "Global" solution, modifying the startup script to prepend modules/databinding.override.jar to the classpath, my Web App works fine
This is a rather large hammer as the customer has existing apps on an existing server and we are targeting that server.
When I try the Application level solution, no luck.
Any pointers as to where I going wrong?
Eclipse Workbench
I want to package a Groovy CLI application in a form that's easy to distribute, similar to what Java does with JARs. I haven't been able to find anything that seems to be able to do this. I've found a couple of things like this that are intended for one-off scripts, but nothing that can compile an entire Groovy application made up of a lot of separate Groovy files and resource data.
I don't necessarily need to have the Groovy standalone executable be a part of it (though that would be nice), and this is not a library intended to be used by other JVM languages. All I want is a simply packaged version of my application.
EDIT:
Based on the couple of responses I got, I don't think I was being clear enough on my goal. What I'm looking for is basically a archive format that Groovy can support. The goal here is to make this easier to distribute. Right now, the best way is to ZIP it up, have the user unzip it, and then modify a batch/shell file to start it. I was hoping to find a way to make this more like an executable JAR file, where the user just has to run a single file.
I know that Groovy compiles down to JVM-compatible byte-code, but I'm not trying to get this to run as Java code. I'm doing some dynamic addition of Groovy classes at runtime based on the user's configuration and Java won't be able to handle that. As I said in the original post, having the Groovy executable is included in the archive is kind of a nice-to-have. However, I do actually need Groovy to be executable that runs, not Java.
The Gradle Cookbook shows how to make a "fat jar" from a groovy project: http://wiki.gradle.org/display/GRADLE/Cookbook#Cookbook-Creatingafatjar
This bundles up all the dependencies, including groovy. The resulting jar file can be run on the command line like:
java -jar myapp.jar
I've had a lot of success using a combination of the eclipse Fat Jar plugin and Yet Another Java Service Wrapper.
Essentially this becomes a 'Java' problem not a groovy problem. Fat Jar is painless to use. It might take you a couple of tries to get your single jar right, but once all the dependencies are flattened into a single jar you are now off an running it at the command line with
java -jar application.jar
I then wrap these jars as a service. I often develop standalone groovy based services that perform some task. I set it up as a service on Windows server using Yet Another Java Service and schedule it using various techniques to interact with Windows services.
Currently I am busy with a brand new XPages project. I use Java and Managed Beans to access the data.
Till now I don't have to use Lotusscript ;-)
One of the last things is to create a scheduled agent to perform some backend stuff. There is already some logic in Java classes, who are in a directory in the WEB-INF directory.
I son't want rewrite these Java logic to Lotusscript, but reuse.
Is is possible to access these Java classes, from a (scheduled) Java agent??
Assuming that the WEB-INF directory that you are talking about is inside the NSF the answer is going to be NO.
Java Agents in Lotus Domino are self contained and can't see that part of the NSF. You could package those particular classes into a jar file and then attach the jar to the java agent or just copy the classes directly to the java agent. Either way you will have to maintain two sets of code.
Maybe another option for you. I'll post on Monday sample code how to use Eclipse jobs on Domino triggered from XPages. These jobs can run on behalf of the current user. The Eclipse jobs framework also allows scheduling them.
Both XPages and your Eclipse jobs run in the http process and you can access the jobs from your XPages. In other words jobs can use the same code in the WEB-INF directory.
Teaser: http://www.youtube.com/watch?v=uYgCfp1Bw8Q
Update: Posted the sample here http://www.openntf.org/Internal/home.nsf/blogEntry.xsp?permaLink=NHEF-8SJB2R
Yes, if the WEB-INF/classes is on the classpath when the java agent executes. The other way to do it would be to put the classes in there own jar, and distribute the jar with the webapp and the java agent code.
I want to know how to integrate a Java web application with OpenCms contents. Is it possible to integrate a Java application with OpenCms?
Yes, it's possible. For example you can integrate SpringMVC or Struts into OpenCms, or other tools like JForum, an open source java forum, which also supports single-sign-on (SSO).
You can find information here & a small sample OpenCms+Spring integration project:
http://www.opencms-wiki.org/wiki/Integration_HOWTOs
Since OpenCms is open source and based on Java EE standards, you are pretty free.
What I have done successfully is to create a jstl tag library to connect JSPs in OpenCms to a business backend.
In my case it was done through a SOAP web-service.
Another advantage of this was that I could test and develop my code in Eclipse, without a dependency on OpenCms.
Deploying to production would then mean to deploy a jar file to the OpenCms webapp.
Yet another advantage: Since we put some of the view-logic into the OpenCms-hosted JSPs, they were versioned by OpenCms.
We have integrated SprigMVC into an existing OpenCMS installation. Here is a description of how we went about that: http://blog.shinetech.com/2013/04/09/integrating-springmvc-with-opencms/