Updating the .bat file in Wildfly 10 Final not working? - java

Hi all I am new to jboss/wildfly world I am working on a java application which supports both tomcat and wildfly where I have a piece of code which changes the file content dynamically(from java code)...when I execute the following code in tomcat,it updates the file and restarts automatically...but when I tried the same code with wildfly I don't see any updates in file content.
NOTE : I am deploying the .WAR file from admin console (the file is in .WAR).
I tried restarting the wildfly server no changes same old file content.
Here is my piece of java code,
Path nioPath = Paths.get(XYZScript.getPath());
List<String> aLines = new ArrayList<>();
aLines.add("Content 1");
aLines.add("Content 2");
try {
Files.write(nioPath, aLines, ENCODING, StandardOpenOption.TRUNCATE_EXISTING, StandardOpenOption.WRITE);
} catch (IOException e) {
I found some links which says we need to redeploy the .WAR or use Overlay
But it should be programmatic the user will change files dynamically

During deployment JBoss / Wildfly unpacks the deployment under $JBOSS_HOME/standalone/tmp/vfs/deployment. It is used as a virtual file system (vfs). But it also gets deleted on undeployment.
In your case you will have to modify the war under $JBOSS_HOME/standalone/deployments and trigger a redeployment by using marker files like <war-name>.war.dodeploy. See here for more information on marker files.

Related

Cannot access file using relative path in local test when developing Google App Engine applications

I am trying to write and deploy a simple web-app at Google Cloud Platform. I installed gcloud and the corresponding libraries/plugins on Eclipse in my Mac. I use the following code to try to open a file specified in a HttpServeletRequest:
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
resp.setContentType("text/html");
resp.getWriter().println("<p>DEBUG: In Create2.</p>");
// get the file info
// to get the value of each input, always use the name and then
// req.getParameter(name);
String fileName = req.getParameter("file");
// create the file
File file = new File(fileName);
resp.getWriter().println("<p>"+file.getAbsolutePath()+"</p>");
if (file.exists()) {
...
}
else {
...
}
I put a test.txt file under project/src/main/webapp directory, run this project as an app engine and submit "test.txt" to servelet. But
In my local machine (localhost:8080), file.exists() always fails and the absolute path printed is
Applications/Eclipse/Contents/MacOS/test.txt
On the contrary, after I deploy the project to Google App Engine, everything works just fine and the absolute path printed is
/base/data/home/apps/XXXX/20170425t133741.400812218449586767/test.txt
I read a couple discussion threads all saying the file access in GAE/Google Cloud Platform is relative path. But why would my eclipse interpret it as an absolutely path when trying to open the file? Is there a fix on this issue so that I can always use relativ path both locally and on google cloud?
Thank you very much.
If you could set the working directory of the local App Engine dev server correctly, you wouldn't have problems using relative paths locally. Unfortunately, as of now, the Cloud Tools for Eclipse plugin doesn't support changing the working directory. Here is what you can do as a workaround:
Run the local dev server and check the server log in the Console view to see the actual web application root the server should use as a working directory. You'll see a log message like this:
WARNING: Your working directory, (<...your current, out-of-sync local server working directory...>) is not equal to your
web application root (<...your workspace...>.metadata/.plugins/org.eclipse.wst.server.core/tmp0/<...your Eclipse project name...>)
Open the Servers view. Stop the server.
Double-click on the server. Click Open launch configuration on the Overview page that pops up.
Select the Arguments tab.
Enter -Duser.dir=<...the directory of the web application root from the server log...> in the VM arguments: box. Click OK. (The Working directory section below doesn't work unfortunately.)
From now on, you won't see the WARNING message, and the server will use the directory you provided as a working directory.
UPDATE: This has been fixed in recent CT4E versions, which automatically set the working directory properly (unless you run multiple projects in a single local server). Update to the latest CT4E if you encounter this issue.

Tesseract OCR not working in Web Project

I'm trying to use Tesseract OCR in a web application. The code runs fine when I run it as a JAVA application. But as soon as I put the same code in my web application, it doesn't work anymore. If put the function in the servlet, tomcat doesnt start at all. If I call it from a separate class by creating an object, On debugging I find that the object does not get created at all. I have included all the jars necessary.
Code in servlet
OCRFullTrial ot = new OCRFullTrial();
ot.imgOCR();
Inside other class
public void imgOCR(){
File imageFile = new File("D:\\OCRTesting\\0.jpg");
try {
ITesseract instance = new Tesseract(); //
System.out.println("1");
} catch (Exception e) {
System.err.println(e.getMessage());
}
Just some pointers I think you should check, in case if you are using Tess4j in Web Based Project:
1) Put all your jars in WEB-INF > lib folder.
2) The *.dll files that are provided along Tess4j must be in system32 folder (Windows). I don't know for other OS.
3) Set the instance path using instance.setDataPath() method. It must point to folder containing tessdata folder.
4) Set the language using instance.setLanguage() incase your tessdata has multiple languages training data in them.
Crosscheck above steps and try running again. Hope it works

java crash on HKDFBytesGenerator androidpay

When I run the script locally
HKDFBytesGenerator hkdfBytesGenerator = new HKDFBytesGenerator(new SHA256Digest());
works great and creates the generator, when I upload WAR file (exported from eclipse IDE) and deploy to my dev server the application simply crashes when I get to that line.
Tried surrounding with try/catch - but its like no error is thrown and the output is the path of the package (the app does not get to the next line)
"org.bouncycastle.crypto.generators.HKDFBytesGenerator"
Any ideas how to resolve/whats the issue?
The jars are same in my local and remote env.

Why getClass().getProtectionDomain().getCodeSource().getLocation().getPath() doesn't work in final product after compiled?

Ok, Here is my Web project. I built it in eClipse with the following structure:
workspace3\MyProject\war\images\uploaded
workspace3\MyProject\war\WEB-INF\classes
Ok, I want to store the uploaded images into workspace3\MyProject\war\images\unloaded, so here is the code at service side & it works fine in Eclipse
String absolutePath = getClass().getProtectionDomain().getCodeSource().getLocation().getPath();
absolutePath=absolutePath.replace("WEB-INF/classes/", "images/uploaded");
File file = File.createTempFile("upload-", "."+extName, new File(absolutePath));
Ok, now I compiled my project & put it into VPS with Tomcat server and it has the following structure
tomcat7\webapps\ROOT\images\uploaded
tomcat7\webapps\ROOT\WEB-INF\classes
However, somehow when run the website via internet, it couldn't find the images\uploaded location.
Did i do anything wrong here?
Why getClass().getProtectionDomain().getCodeSource().getLocation().getPath() doesn't work in final product after compiled?
You should rather use ServletContext#getRealPath(...) to determine the file system path of your web application:
String absolutePath = request.getServletContext().getRealPath("/images/uploaded");
// File uploaded to this directory will be accessible via
// `http://<yourserver>/<web-app>/images/uploaded/`
But be careful! The servlet specification does not guarantee, that getRealPath will return a path to a writable directory. And it may return null in case the virtual path cannot be translated to a real path!
If you want to be sure, that the destination is a writable directory, and you just want to upload files into a temporary directory for processing, consider using the web application's private temp directory:
File tempDir = (File)request.getServletContext().getAttribute(ServletContext.TEMPDIR);
// Files uploaded to that directory will NOT be automatically published to WWW.
Note that this directory is temporary only and may not survive a server restart! So it is not thought for durable persistance.
The most sensible and durable solution is to write the file into a database, or any other repository (e.g. JCR like Jackrabbit), or into a file directory that is NOT controlled by your web server (and is specified from outside, e.g. via system property or in web.xml).

Loading a jrxml file under Tomcat

I have a web app that uses JasperReports to power data export to Excel, PDF & CSV. It's a grails app using the DynamicJasperReports plugin and it uses a jrxml file as the template for the report.
This was working but has broken following some changes to our tomcat configuration. It still works locally in grails development mode.
FastReportBuilder drb = new FastReportBuilder()
drb.setTemplateFile("resources/reportTemplate.jrxml")
DynamicReport report = reportBuilder.call(drb)
JRDataSource ds = new JRMapCollectionDataSource(data)
JasperPrint jp = DynamicJasperHelper.generateJasperPrint(report, new ClassicLayoutManager(), ds)
ReportWriter reportWriter = ReportWriterFactory.getInstance().getReportWriter(jp, format, [:])
reportWriter.writeTo(response)
It throws this error:
java.lang.NullPointerException
at ar.com.fdvs.dj.core.DynamicJasperHelper.generateJasperDesign(DynamicJasperHelper.java:151)
at ar.com.fdvs.dj.core.DynamicJasperHelper.generateJasperReport(DynamicJasperHelper.java:448)
at ar.com.fdvs.dj.core.DynamicJasperHelper.generateJasperPrint(DynamicJasperHelper.java:234)
at ar.com.fdvs.dj.core.DynamicJasperHelper.generateJasperPrint(DynamicJasperHelper.java:187)
at com.giivpro.services.analytics.JasperReportsService.runReport(JasperReportsService.groovy:30)
I eventually realized this was not due to upgrading to tomcat7 as I originally thought but instead was due to changes in how the app was being deployed, made around the same time.
All the jar file dependencies of the app are now copied to /var/lib/tomcat/lib rather than being deployed inside the war file. Which means that the line in DynamicJasperHelper
URL url = DynamicJasperHelper.class.getClassLoader().getResource(dr.getTemplateFileName());
now failed due to security restrictions on the ClassLoader. The jars in /var/lib/tomcat/lib get loaded by a separate ClassLoader and are not able to load resources from specific WAR files.

Categories

Resources