My laptop just got upgraded to windows 10 from windows 7, and a piece of code stopped working. A large application using velocity templates which used to work on windows 7 just fine now cannot find the template files.
The templates are kept at the path WebContent\WEB-INF\config\templates under the project directory. An EngineInitializer class is used to load them. The code for the class is as follows:
private static Logger logger = Logger.getLogger(EngineInitializer.class);
private static String RELATIVE_PATH_FOR_TEMPLATES = "/WEB-INF/config/templates";
if(logger.isDebugEnabled())
logger.debug("About to initialize the Velocity Engine");
Properties p = new Properties();
String absolutePath=new File(Thread.currentThread().getContextClassLoader().getResource("").getFile()).getParentFile().getParentFile().getPath();//this goes to webapps directory
//configure the velocity logger to use the default logging
p.put(RuntimeConstants.RUNTIME_LOG_LOGSYSTEM_CLASS,"org.apache.velocity.runtime.log.Log4JLogChute");
p.put("runtime.log.logsystem.log4j.logger", "defaultLog");
p.put("file.resource.loader.path", absolutePath + RELATIVE_PATH_FOR_TEMPLATES);
p.put("file.resource.loader.cache", "true");
p.put("file.resource.loader.modificationCheckInterval", "-1");
p.put("parser.pool.size", "30");
Velocity.init(p);
if(logger.isInfoEnabled())
logger.info("The velocity engine is now initialized..");
The following lines in the applicationBeans.xml file initializes the engine:
<!-- initialize the velocity engine before the listener thread starts -->
<bean id="engineInitializer" class="com.file.myprogram.template.processor.EngineInitializer"
init-method="initializeEngine" />
At the beginning, the log is getting printed. Inside the individual classes, the templates are called using Velocity.getTemplate() method. This is now returning a org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'MediationZone.vm' error. Nothing other than the underlying OS has been changed. This code runs fine on an RHEL server as a web app. Code has been downloaded from subversion and run on the windows 10 laptop using eclipse v4.9.
What is going wrong here?
I had the same issue and nothing worked (file:/ prefix variants, C: or c:).
Finally I tried it with some relative path (like used in the production environment) and voilà, it worked.
Figured out current run dir using System.getProperty("user.dir"):
vel.getTemplate( "foo/bar/some.vm", UTF_8.name() )
Related
I am following this fundamentals of JEE tutorial which provides instruction to create a minimal EJB deployment.
I have gone through the steps in the tutorials but made changes to the following command line invocations
>set CLASSPATH=.;E:\wildfly-10.1.0\wildfly-10.1.0.Final\bin\client\jboss-client.jar; (Changed from the long list in the tutorial)
>jar -cvf SimpleSessionApp.ear beans*.java (Changed file extention to .ear from .ejb3)
copy SimpleSessionApp.ear E:\wildfly-10.1.0\wildfly-10.1.0.Final\standalone\deployments (Copied to the wildfly deployment directory)
I started the server and I did not get any errors. However, I did not get set of standard names the server log outputs when a bean is deployed.
I ran the client application using the following command as in tutorial
>java -D java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory -D java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces -D java.naming.provider.url=localhost client.SimpleSessionClient Now is the time for all good men
I get the following error as the output
Error: Could not find or load main class java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
I know the tutorial caters for an older version of Java and JBoss. However, I modified the old references to point to the newer environment as mentioned above. So I assume versioning is not a issue here? BTW I'm just starting to learn EJB. Any insights would be great.
My Environment
Java 1.8.0.212
Wildfly 10.1.0.Final
Notepad
You should look at the reference documentation https://docs.wildfly.org/17/Developer_Guide.html#JNDI_Remote_Reference as it seems your are passing wrong configuration parameters.
final Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
env.put(Context.PROVIDER_URL, "http-remoting://localhost:8080");
// the property below is required ONLY if there is no ejb client configuration loaded (such as a
// jboss-ejb-client.properties in the class path) and the context will be used to lookup EJBs
env.put("jboss.naming.client.ejb.context", true);
InitialContext remoteContext = new InitialContext(env);
RemoteCalculator ejb = (RemoteCalculator) remoteContext.lookup("wildfly-http-remoting-ejb/CalculatorBean!"
+ RemoteCalculator.class.getName());
We're running a Spring application within a docker container. Our application can take SVG files and transform them into PDF format to be embedded within a PDF.
The application works correctly on osx and transcodes as expected. However when run from inside a docker container, which has a different file system, the transcoder gets stuck and thrashes the cpu in some bizarre recursive file searching loop.
java.lang.Thread.State: RUNNABLE
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
at java.io.File.isFile(File.java:882)
at org.apache.commons.io.filefilter.FileFileFilter.accept(FileFileFilter.java:59)
at org.apache.commons.io.filefilter.AndFileFilter.accept(AndFileFilter.java:122)
at org.apache.commons.io.filefilter.AndFileFilter.accept(AndFileFilter.java:122)
at org.apache.commons.io.filefilter.OrFileFilter.accept(OrFileFilter.java:118)
at java.io.File.listFiles(File.java:1291)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:357)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:364
Here's a look at the stack trace of a thread that ran the PDFTranscoder. Walk is called recursively for a while and then eventually getBooleanAttributes0 is called and everything blocks.
After some further research, we found out we could take a closer look at what is happening with the strace command and saw that the system is essentially spamming the following in an endless loop.
stat("/./sys/devices/pci0000:00/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/PNP0103:00/subsystem/devices/pcspkr/input/input1/subsystem/input0/subsystem/input0/uniq", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0 <0.000224>
We seem to be getting blocked or hanging in the stat call. But we've delved so deep into system calls now that it's proving hard to debug. Does anyone have any ideas?
I was getting the same error. After trying many things to fix it, I came to the conclusion that it's an issue with your having fonts available to you on Mac OS X, while your (headless) Docker container OS has no fonts. The transcoder is not failing gracefully while searching for fonts all over the place. I solved it by forcing the transcoder to use the default fonts (and to not automatically look for other fonts) like this:
...
PDFTranscoder transcoder = new PDFTranscoder();
transcoder.addTranscodingHint(PDFTranscoder.KEY_AUTO_FONTS, false);
...
transcoder.transcode(transcoderInput, transcoderOutput);
...
Note this has the downside, of course, of falling back to its known fonts when it encounters one outside of the 14 fonts. I tried things to fix that but so far no luck.
I hope this helps someone.
I had the same issues and solved it in my case. This thread helped a lot. Now I'd like to put all the parts together - maybe also for other people who come accross this.
The reason for this is the directory in which you start your Java application. I recognized that this problem occurs under the following circumstances:
The Java application was started in the filesystem root.
Auto scanning for fonts is enabled in Apache FOP.
I found a similar post in Infinite scan for fonts in Apache FOP on CentOS. The explanation of Fyodor Sherstobitov sounds plausible.
Apache FOP uses the working directory of your Java application to scan for fonts. In this case this is the filesystem root. Therefore the whole filesystem will be scanned.
The following code is copied from PDFDocumentGraphics2DConfigurator. It shows that new File(".").getAbsoluteFile().toURI() is used - which is the working directory resp. the directory in which the Java application was started.
/**
* Creates the {#link FontInfo} instance for the given configuration.
* #param cfg the configuration
* #param useComplexScriptFeatures true if complex script features enabled
* #return the font collection
* #throws FOPException if an error occurs while setting up the fonts
*/
public static FontInfo createFontInfo(Configuration cfg, boolean useComplexScriptFeatures)
throws FOPException {
FontInfo fontInfo = new FontInfo();
final boolean strict = false;
if (cfg != null) {
URI thisUri = new File(".").getAbsoluteFile().toURI();
InternalResourceResolver resourceResolver
= ResourceResolverFactory.createDefaultInternalResourceResolver(thisUri);
//TODO The following could be optimized by retaining the FontManager somewhere
FontManager fontManager = new FontManager(resourceResolver, FontDetectorFactory.createDefault(),
FontCacheManagerFactory.createDefault());
//TODO Make use of fontBaseURL, font substitution and referencing configuration
//Requires a change to the expected configuration layout
DefaultFontConfig.DefaultFontConfigParser parser
= new DefaultFontConfig.DefaultFontConfigParser();
DefaultFontConfig fontInfoConfig = parser.parse(cfg, strict);
DefaultFontConfigurator fontInfoConfigurator
= new DefaultFontConfigurator(fontManager, null, strict);
List<EmbedFontInfo> fontInfoList = fontInfoConfigurator.configure(fontInfoConfig);
fontManager.saveCache();
FontSetup.setup(fontInfo, fontInfoList, resourceResolver, useComplexScriptFeatures);
} else {
FontSetup.setup(fontInfo, useComplexScriptFeatures);
}
return fontInfo;
}
You can solve this in two ways:
Disable auto scanning for fonts in Apache FOP as Bob Schultz mentioned. If you do that, you will have to configure the fonts for Apache FOP manually.
Don't start the Java application in the filesystem root as snyman mentioned. In this case you can continue using the auto scanning for fonts.
Disable Auto Scanning
This is a snippet of the code, which configures Apache FOP with a config file. If you don't enable the auto scan in that file, you don't have to disable it programatically.
// Load configuration for manually configuring fonts
DefaultConfigurationBuilder cfgBuilder = new DefaultConfigurationBuilder();
Configuration cfg = cfgBuilder.build(ResourceUtil.getResourceStream("path/to/config"));
PDFTranscoder transcoder = new PDFTranscoder();
transcoder.configure(cfg);
// Disable auto scanning for fonts programatically - not necessary if you
// don't enable auto scan in your config file
// transcoder.addTranscodingHint(PDFTranscoder.KEY_AUTO_FONTS, false);
Start the Application in a Separate Folder
By specifying the WORKDIR everything happens in this folder. The auto scan runs there and finishes fast and smooth.
FROM openjdk:8-jre-alpine
WORKDIR /app
ARG JAR_FILE=target/myapp-0.0.1-SNAPSHOT.jar
COPY ${JAR_FILE} app.jar
...
ENTRYPOINT ["java","-jar","app.jar"]
I had the same issue.
Solved it by setting the WORKDIR variable in the DockerFile.
I set it to my deployment dir, where I copy the spring jar file. Ie:
WORKDIR ${DEPLOYMENT_DIR}
using latest batik libraries in pom
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>batik-all</artifactId>
<version>1.9.1</version>
</dependency>
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>fop</artifactId>
<version>2.2</version>
</dependency>
I had the same problem on my project. I solve it with the downgrade of batik to 1.7 version.
I hope this will work for you.
Try adding the parameter '-Duser.dir=/%CATALINA_HOME/' to your CATALINA_OPTS. I encountered the same issue on my centos server.
I want to write logging-messages to a defined file into the tomcat's log-folder, using eclipse, maven, tinylog.
Problem: There is no webapp.log as soon as I run the app in tomcat.
In eclipse everything works fine.
What I did:
add Maven-dependency tinylog-1.2.jar
set configuration-parameter in Run Configuration (Main-Tab) so the tinylog-properties can be found for the build-process:
name: -Dtinylog.configuration
value: C:\Program
Files\Tomcat\apache-tomcat-9.0.0.M13\webapps\folder\subfolder\tinylog.properties
in Java-Class:
import org.pmw.tinylog.Logger;
...
Logger.info(message);
tinylog.properties looks like:
tinylog.writer = file
tinylog.writer.filename = webapp.log
tinylog.writer.buffered = true
tinylog.writer.append = true
tinylog.level = info
I also tried different file-references but none of them worked:
tinylog.writer.file = C:\Program Files\Tomcat\apache-tomcat-9.0.0.M13\logs\webapp.log
tinylog.writer.file= "C:\Program Files\Tomcat\apache-tomcat-9.0.0.M13\logs\webapp.log"
Does anybody know how to write the logs into the named path-file?
Thanks for any valuable hint.
I propose to use the tinylog-jul artifact instead of the usual tinylog artifact. tinylog-jul provides the tinylog API, but uses the Tomcat logging back end. So, you don't need to configure tinylog. All log entries will be automatically output as you are used to with other logging APIs on Tomcat.
I am trying to log all my slow queries in a separate file. Until now I have to following Tomcat context configuration:
<Resource name="jdbc/paymentDB" auth="Container" type="org.apache.tomcat.jdbc.pool.DataSource"
driverClassName="...oracle..."
...
jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.QueryTimeoutInterceptor(queryTimeout=2);org.apache.tomcat.jdbc.pool.interceptor.SlowQueryReport(threshold=1000,maxQueries=200)"
</Context>
This works as long as I do not set another kind logger and it prints to the console. One thing that I believe should be added is that I run this test in IntelliJ Idea using default IDE configuration.
The next thing I wanted to do was to log into a separate file. So I opened logging.properties and did the following changes:
handlers = ..., 5slowqueries.org.apache.juli.FileHandler, ...
.handlers =..., 5slowqueries.org.apache.juli.FileHandler, ...
5slowqueries.org.apache.juli.FileHandler.level = ALL
5slowqueries.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5slowqueries.org.apache.juli.FileHandler.prefix = slow-queries.
org.apache.tomcat.jdbc.pool.interceptor.SlowQueryReport.level = ALL
org.apache.tomcat.jdbc.pool.interceptor.SlowQueryReport.handlers = 5slowqueries.org.apache.juli.FileHandler
The problem is that executing the same slow queries and have been printed earlier in console, this time, using this configuration, no slow-queries.* file is created. (I ran this from IntelliJ Idea)
I can't figure out how to make this work. Maybe it has something to do with IDE? I have noticed that IDEA has a Logs category in Run/Debug Configurations, I tried to play with these options too but didn't have any luck.
I found the problem. It was the IDE. When IDEA starts the server it prints something like this in the console:
Using CATALINA_BASE: "C:\Users\..."
Using CATALINA_HOME: "C:\..."
another few variables
The logs are created, by default, if not changed, in CATALINA_BASE/logs.
I have an application named HelloWorld installed, yet not deployed. Its state is Installed, like such:
When I'm trying to deploy it on target server, say AdminServer, it results in creating a new application named helloworld.war which is deployed on AdminServer whereas the original HelloWorld app remains in Installed state. App helloworld.war is the one that is in state Active... Snapshot:
Here's the code I use to deploy the already installed app:
File warFilePath = new File("c:/helloworld.war"); // war file path on AdminServer machine
Target adminServerTarget = deployManager.getTarget("AdminServer");
WebLogicTargetModuleID targetModuleID = deployManager.createTargetModuleID(
"HelloWorld", ModuleType.WAR, adminServerTarget);
WebLogicTargetModuleID[] targetModuleIDs = new WebLogicTargetModuleID[1];
targetModuleIDs[0] = targetModuleID;
ProgressObject redeployProcessObject =
deployManager.redeploy(targetModuleIDs, warFilePath, null /*no deployment plan*/ );
There are two surprising facts, though.
First, when running this code on WebLogic versions 9.x to 10.3.3 it works great.
Second, when running this code from WLST prompt, with jython it also works great even on version 10.3.4 (I can attach the exact commands although they're the same as java except for syntactic adoptions)...
My question is, how do I make it work also on 10.3.4?
I should have thought that no one would answer this question... :)
Anyway, I found a solution. I should have used deploy instead of redeploy, with a DeploymentOptions of which name is the existing application name (HelloWorld):
ProgressObject redeployProcessObject = null;
try {
final DeploymentOptions options = new DeploymentOptions();
options.setName(applicationName);
redeployProcessObject = deployManager.deploy(
targetModuleIDs, warFilePath, null /*no deployment plan*/, options);
} catch (TargetException e) {
final String message =
String.format("Deployment of application %s on target %s failed: %s",
applicationName, allTargets, e.getMessage());
_log.error(message, e);
}
According to the docs, redeploy only replaces the current application files and plan with an updated version. Whereas deploy distributes the files (from the AdminServer) to the target(s) and starts the application.
Also, after digging deep in WebLogic's jython scripts and jars I found out that this is exactly what's done when invoking redeploy in the WLST.