I'm using the trinidad gem to host my jruby application.
However, any requests for .woff or .ttf font files are met with 400 Bad Request.
When I was jar-ing up my project with warbler and dumping the jar file in a regular Tomcat instance, I was able to add the MIME type definitions for those extensions in the web.xml.
However, I do not know how to do this for the instance of Tomcat that the trinidad gem uses, and the documentation doesn't appear to list it. It does mention specifying a web.xml file to use as a default for the web applications, but that appears to be the one that's placed in the WEB-INF folder and the server doesn't start when I put in Tomcat's conf/web.xml file for it.
I've also tried adding the following lines to config/initializers/mime_types.rb:
Mime::Type.register "application/x-font-woff", :woff
Mime::Type.register "application/octet-stream", :ttf
but this doesn't appear to affect the public folder (and I'd be surprised if it did...).
Where can I find how to do this?
Related
I am trying to do a log4j migration for a legacy application. I made the changes to the configuration files and tested it locally with Tomcat, where the logs were displayed correctly. However when I deploy on WAS, the logging stops.
I checked a lot of pages about the necessary dependencies and the possible problems, but now I feel I'm stuck. Here is what I already tried:
Added the log4j jars manually to the lib/ext directory in WAS (together with commons-logging, I read an article where it helped, although all these jar-s were already present in the ear)
Double checked, that the configuration file is on the classpath and that it's syntax is correct
Added logj42-web dependency
Added the necessary filters in web.xml (Spring version is 3.8, so also the config listener with the config name context-param)
Checked classloader in WAS - it's parent first
Am I missing something?
Any ideas are appreciated. Thank you in advance!
WAS includes its own commons-logging API (that does not utilize Log4j), so bringing your own logger requires a bit of extra class-loader-related config. Typically, that would go something like this:
Put your commons-logging and log4j jars, along with your logging properties files, in some directory (not WAS_HOME/lib/ext) readable by the user running the server.
Create a shared library on the server, with that directory as its class path, and select the "use an isolated class loader" option. Associate that shared library with your application or web module.
Ideally, that should be it. Isolated shared libraries search themselves before delegating to the server's loaders, so your application will "see" the commons-logging/log4j classes in the shared library instead of in the server, and likewise, it should pick up the configuration files from that directory instead of the ones found in the server.
You can also accomplish this same basic thing by leaving all the logging stuff in your WAR or EAR and setting its class loader to parent-last (which causes the class loader to search locally before delegating to the server-level loaders), but that is a bit riskier configuration - if your application includes APIs that are also provided by the server, parent-last class loading increases the possibility of ClassCastExceptions or LinkageErrors.
In my project I use Maven to package a web application to a WAR which is later deployed to Jetty using a custom Maven plugin on CentOS. The custom plugin is used by every project that deployes to a production environment. There is now a requirement that all static content (like web site text, properties) is packed outside of the WAR so that it can be changed in production without requiring a new release cycle. I am unsure how to achieve this externalization.
The Jetty server has the directory structure described in Jetty quick start guide. Currently, the web application already offers some .properties files which can be altered externally, and these reside in the resources/ directory. These files are moved here by the custom Maven plugin. The WAR resides in the webapp/ folder. One option for my problem is to use <packagingExcludes> of maven-war-plugin to not include e.g. *.xhtml and *.properties in the WAR. Later, I can use the custom Maven plugin to move excluded files to resources/ directory. But, I have a feeling this is not the correct way to externalize static content... Shouldn't xhtml files live in webapp/ folder while the only the properties file live in resources/ folder?
I have also researched the option of deploying the WAR as exploded, but I am unsure of the implications of such. Clearly, the changes in the exploded WAR files will be overwritten in the next deploy, but the idea is to do static changes both in development and production. Also, I am not sure how to achieve WAR "explosion", is it something that Jetty does for your WAR if configured in jetty.xml or do I have to extract the WAR before deploying?
Lastly, how do people serve static content in Jetty which can be altered in production? Do both the WAR and static files live side by side
The Jetty resources folder should not be used for application files. A J2EE web application (war) should be self-contained -- and in Jetty, reside only on the /webapps folder -- and its only binding to the container (Jetty servlet engine) is via the web.xml deployment descriptor.
Since property files may be read from the classpath and the Jetty resources folder is part of the system classpath, a property file there could be read by the web application class loader. Note that there are other ways to read property files as well and the Jetty resources folder should not be used for application properties. Also, the application may not be portable as other application servers have different forms of webapp classloader isolation.
If the below architecture approach does not work for you, then your only approach would be to expand (explode the war) in the /webapps folder and hope for the best when files are edited.
Tackling this from a different angle,
- if your web application depends on .properties and .xhtml files in order to function properly, then these files are probably not 'content'. The fact that there is a business process that requires them to to be updated ad hoc does not make them content.
- 'content' is something like text, images, and videos that is added, edited and removed by an administrative user. The application does not depend on it for correct execution, it merely reads and passes it on the browser.
Suggestions:
I would suggest that you deploy your application every time there is a change to the .xhtml or .properties files change. If the editors of these files are power business users, you might think of a git push-pull tool for them and a continuous build hook, so that when they make changes and push them to the git repository, the application gets tagged with a newer version and gets built and deployed. If there is a problem (tag not closed in xhtml), then it would be easy to roll back to the last tag.
Alternately, if the changes are minor (such as text descriptions), then modify the application to read them from an arbitrary external file (outside the webapp) -- a location that is provided to the webapp on startup. You can then package a 'default' version of the file in the webapp, but the code would attempt to look in the specified external location first.
I discovered that you can add HTML tags to properties and later use <h:outputFormat> to fetch these properties with parameters. Also, you can do pretty neat stuff with property files as described in MessageFormat API.
My solution was to keep the .xhtml files inside the WAR, but use simple HTML snippets properties from the default resource bundle which is based on a .properties file. These properties were included in the .xhtml using <h:outputFormat>and <h:outputText>. This allows the user to add simple styling like bold and underline to the snippets.
The properties file are copied to the Jetty resource folder using the custom Maven plugin, so I have kept the .properties files in the WAR. For some reason the Jetty resource folder has precedence over the packed .properties files, so this works out fine. Also, as Akber pointed out, I will have the default versions of the properties available if for some reason the WAR was moved to some other application server where the resource folder is not available.
Of course, with this approach the code can break if malformed HTML is placed inside the snippet properties, as pointed out by Akber, but it works for our application as it is very small. I may never have done this if this was a much larger application, but then I might have gone for a database based solution for adding static text (like Joomla/Drupal/Wordpress).
I develop a web app:
frontend javascript
transport json
backend Java EE
JBoss AS 6.1
All static html and js files are in an exploded .war directory which itself is in an exploded .ear directory.
Normally everything works fine! Today I changed a html file and copied it to the .war directory.
When the browser loaded the file it was the old one. So I started wireshark and saw in wireshark the get request and the returned OLD file, even when I changed the filename in the .war directory.
So there is some caching in jboss. I started Googling and found some posts about the tmp and work folders.
I looked in my "...\server\default\work..." folders, but everything was empty.
In "...\server\default\tmp" I found some files but no one seems to be related to my cached page.
As this is a tomcat-in-jboss issue, you have to go to the tomcat area in jboss.
In my case ..\server\default\deploy\jbossweb.sar. In this directory you should find a file called context.xml.
Now stop jboss.
In the context tag there are 2 attributes - cookies and crossContext. Now just add the attribute cachingAllowed="false" and start jboss again:
<Context cookies="true" crossContext="true" cachingAllowed="false">
If you need only one time solution, just create fresh ear with fixed HTML file, undeploy the old one and deploy the new one.
I have a jboss seam 2.2.2 project and it is my first time using internationalization with this framework. I have already set the default locale and using the global messages_XX.properties is already working.
Well, this project is growing fast and for better organization and for ease of maintance I would like to have the messages better organized in various properties files for specific pages.
Seam documentation on internationalization mention this and in a specific paragraph it says:
If you want to define a message just for a particular page, you can
specify it in a resource bundle with the same name as the JSF view id,
with the leading / and trailing file extension removed. So we could
put our message in welcome/hello_en.properties if we only needed to
display the message on /welcome/hello.jsp
This paragraph can be found at: http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/i18n.html#d0e14166
The docs mention pages with .jsp extension but in my case I am using facelets and what I have is a .xhtml file so for my home.xhtml page I have created a home_pt_BR.properties file being pt_BR the default locale for my app and I have placed messages for this specific page in this .properties file.
Actually this approach did not work for me.
I have also tryed to register the page in faces-config.xml and also in pages.xml but again this does not seem to work.
So, how do I configure Seam to support multiple bundle files for my application?
You could add the bundle files to components.xml
For example:
<core:resource-loader>
<core:bundle-names>
<value>messages</value>
<value>strings</value>
</core:bundle-names>
</core:resource-loader>
What is the best practice to make changes in beans.xml file in production environment?
Lets imagine Hello World application with one Interface and 2 Implementations. After creating jar and running JVM how can we change implementation in beans.xml without opening jar and reassembling it afterwards?
Is it any trick that permits having beans.xml outside the jar, but without knowing the full file-system path?
On top of suggestion made by OrangeDog, I would suggest considering leaving the beans.xml inside your deployed application AND using the PropertyOverrideConfigurer mechanism.
Configure an override configurer to point to some fixed path outside of the application, something like /opt/configuration/something/override.properties would be ideal. If you can't use an absolute path, you can always try to play with file:../../.. style of paths. Then you can list only the changed values within the override.properties file.
Don't have the XML in a JAR. Your application should be deployed in at least a WAR, which the app server will probably "explode". The folder WEB-INF/classes will be added to the classpath. You can make changes to the exploded XML here and the app server should detect this and reload the app.
Edit:
If you are using plain Java SE, you can use a system property to pass the location of the XML file. System.getProperty("property") in code and -Dproperty=value on the command line.