Page 1 of 1

Strange behaviour when deploying application as JAR instead of .class files

Posted: 18 May 2017, 10:24
by oneofmillions
Hello there,

I'm somewhat new to PrimeFaces (using it for about 1 year now) and first I would like to thank the PrimeFaces team for the gift of a free version. Also thanks to the community helping here.

I'm having strange problems with an application that I develop and that uses the PrimeFaces p:fileUpload component in advanced mode.
When running the application in my development environment, deployed as a bunch of .class files, the p:fileUpload component works perfectly.
When I pack my .class files as .jar archive, the app behaves "strange".

There is only one difference on the production system. It's has the jar instead of the class files.
When I deploy the class files there, everything works as expected. I'm asking for Ideas.

What do I mean with strange?

- p:fileUpload does not accept EL expression in it's sizeLimit attribute (it results in an null pointer exception).
- It looks like the RegeEx in the allowed file extensions attribute is empty, altough I had explicitly set it...
- when I do press the upload button, the fileUploadListener callback is never called...


All in all it is all about the attributes. I also stepped into the primefaces classes with the debugger.

It seems like all the problems come to the surface inside the method "encodeScript" of org.primefaces.component.fileupload.FileUploadRenderer.
When calling some of the attr("attribute", a, b) methods there, it starts to trigger null pointer exceptions...

It only happens when my app is deployed as JAR... the .xhtml files that build the context of the p:fileUpload
are not part of the jar file, they are located in a seperate folder.

I'm not asking for a concrete example 'nor I'm posting any exception logs. Because the broken fileUpload component is just symptom
of another problem. I'm asking for ideas what could be different when starting an web application inside tomcat/myfaces as a JAR instead of
a bunch of .class files.

Environment:

Orcale JVM: 1.8
Apache Tomcat: 8.0.42
Apache MyFaces: 2.2.9
PrimeFaces 6.0

Ideas will be very much appreciated!

Re: Strange behaviour when deploying application as JAR instead of .class files

Posted: 31 May 2017, 04:25
by Miguel Cubells
First of all, I believe you should be deploying your application as a WAR file, with several JARs inside.
I'm not clear what do you mean by deploying as a JAR.

Secondly, there should not be any difference between deploying a packaged WAR file, or an exploded WAR file (with all the .class file as you say)

If you are packaging your application as a WAR, I bet you are missing some libraries inside, most probably related to EL expressions. (make sure el-api.jar and some el-impl.jar are included in your packaged WAR).

With full JEE servers like WildFly, these problems do not usually show up, because they already provide all the necessary libraries.

Re: Strange behaviour when deploying application as JAR instead of .class files

Posted: 31 May 2017, 22:44
by kukeltje
With an exploded war file you can upload files to a folder inside that 'war', with a non-exploded war you can't. And you should never upload to a folder inside the exploded war. Search stackoverflow on why.

Re: Strange behaviour when deploying application as JAR instead of .class files

Posted: 14 Jun 2017, 17:10
by oneofmillions
Hello Miguel Cubells,

I'm sorry for replying so late. Many thanks for your suggestions and comments.

"I'm not clear what do you mean by deploying as a JAR."

It means I archived all my application .class files into one JAR file (including a version number). This has some benefits (for example you just have to replace a single file on updates, but it seems it also has some drawbacks, sometimes).

However, reading your suggestions, I'm in doubt about this practice now. I thought it would be bad practice to have a bunch of .class files... but it sounds like that it is common for Java webapps. So I probably just drop the whole JAR archiving before deploying.

Greets,
Ole