We Keep Coding

Use log4j on a deployed war

I've made a trivial RESTful service on a JBoss server that just says "hello" when it receives any request. This part works and it is already deployed.
To go further with my project I need to log. The other applications on the server use log4j configured by a log4j.xml placed on a specific folder on the server.
For an offline project I'm used to have a runnable main method that in this case I would use to execute DOMConfigurator.configure(filepath) (where filepath is the log4j.xml) and I will be expecting to log with those settings.
However, since this is a deployed service (and since I'm not skilled enough to figure it myself) how would I so such a thing?
The question in my opinion could be interpreted in two ways:
How do I run some code "for sure" when I deploy something (in similar way to a main method) ? Do i need something like spring-boot?
How do I setup log4j on a deployed service on JBoss?
(I don't know if one question excludes the other...)
Thanks for the help!

1) If you want to run some code "for sure" you can create #PostConstruct method in one of your beans. Both Spring and EJB support it.
2)As for log4J configuration it should be enough to put it in classpath and add corresponding dependencies, no explicit configuration of path should be needed.

Jersey 2.5: How can a resource access external classes instances

I have embedded Jetty container inside my main server and I also use Jersey 2.5 for handling REST resources.
everything seems to work well and now I would like to pass my server's context class into each of my REST resources.
I'm having hard time understanding how to do that...
If someone can provide full code example - it could be awesome!
Many thanks

What exactly do you mean when you say you have a Jetty container inside your "main server"? Are you programmatically executing Jetty within the application? Also, when you say "context" are you referring to the ServletContext?

persisting database connection parameters in java webapps

Java webapps provide a convenient way to make them run: It’s suficcient to drop the jar file into tomcat‘s webapps folder or upload it using the tomcat manager. If the jar file is named foo123.jar, the web application is soon accessible under http://<host>:8080/foo123/. However, in the majority of cases, there is a problem with the configuration: It’s a good practice to store data in a database, but where can I store the database connection parameters? Usually you have to adapt some server.xml or web.xml or other configuration file to put it there, but this hinders making use of the automatic deployment for such an application.
A “simple to use” web application should request its required configuration on the first run, like a “setup” screen, and then keep it in some place where it survives a restart of the servlet container. Of course, for database connection parameters, storing them in the database is not an option.
Following the specs, the servlet container has to provide a directory that a web application has write access to. It can be determined using:
File tempDir =
(File) session.getServletContext().getAttribute("javax.servlet.context.tempdir");
The content of this directory is bound to the ‘servlet context lifecycle’, if I got it right this means it is empty after a server restart. If that is true, it cannot be used for my purpose.
Does anybody know some kind of best practice for that? I don’t want to reinvent the wheel.
In lack of a better solution, I would implement it this way: As I said, if you make use of the easy deployment means described above, the context path is derived from the jar file name. So I could imagine to make use of this for the database connection as well. In simple terms: If the web application foo123 finds a MySQL connection on localhost:3306 (the MySQL default port) and can connect to it with username foo123 and password foo123 and has permissions to access a schema called foo123 it always uses that on restart.
What do you think of that?

You could just use a context.xml file. That will let you store the config files on a server-by-server basis and that means that you'll never have to put that information in the code itself.
This example seems to sum it up rather nicely.

Spring 3.0 not finding the applicationcontext.xml

I'm working on web application that uses a database storage system and I chose to keep the dataAccess-applicationcontext seperate from the rest. However when I run the following line of code it says it does not exist.
ApplicationContext ac = new ClassPathXmlApplicationContext("dataAccess-applicationContext.xml", UsageDataDAO.class);
I have even moved the xml file to the same directory only to get the same error as posted below.
nested exception is java.io.FileNotFoundException: class path resource [com/foobar/bar/foo/dataAccess-applicationContext.xml] cannot be opened because it does not exist
Any Idea what is going on here?

This is hard to debug without all of the details, but it has to be one of two issues.
First, the file really isn't in your classpath. This is a web application, so you should consider how your particular servlet container works when you're checking the classpath. For example, in a servlet environment, WEB-INF is not in the classpath, but WEB-INF/classes is.
Second, the file is in your classpath, but you're referring to it incorrectly. Based on the information that you provided already, I don't think this is the case, but this possibility can be expanded on later.
Regardless, why are you trying to load a file manually? You should reference the configs in your web.xml. If you provide more details about how you're running your web application, then we can help you with this part. In the meantime, this example might be enough information. It illustrates how to configure the root spring container that's shared by all of the Servlets and Filters in the container (configuring a specific Servlet requires a slightly different approach):
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/config1.xml, /WEB-INF/config2.xml</param-value>
</context-param>

please edit your file name with underscore dataAccess_applicationContext.xml instead dataAccess-applicationContext.xml. And try again.

Try with the classpath*: prefix . "classpath*:dataAccess-application-context.xml" if it is in the root classpath else use "classpath*:/folderName/dataAccess-application-context.xml"

Your 2nd parameter to:
ApplicationContext ac =
new ClassPathXmlApplicationContext("dataAccess-applicationContext.xml",
UsageDataDAO.class);
Includes UsageDataDAO.class. According to the spring javadoc for this class, this is requesting the context search start in com/foobar/bar/foo/.
Instead put dataAccess-applicationContext.xml in WEB-INF/classes and try:
ApplicationContext ac =
new ClassPathXmlApplicationContext("dataAccess-applicationContext.xml");
UsageDataDAO myDao = (UsageDataDAO) ac.getBean("MyDaoBeanName");

understanding jboss framework - URL

I am trying to figure out what the following url does.
http://server/abc/testmodule/runtest.do?action=edit&id=123
I am new to jboss/jsp but I am very familiar with .net.
When I see this url, I expect to see the physical folder called "abc" and subfolder called "testmodule" and a physical file "runtest". am i wrong? what does runtest.do? is "runtest" class and "do" is a method within it?

It could be anything--URLs can map to arbitrary resources. It might be a Struts action, it might be a servlet, it might be a Spring controller, etc.
You'd need to check your web.xml file and/or any framework configuration files, or provide more information.
(Also, JBoss isn't a framework, it's a Java EE container :)

The /abc entry is the name of the context in which the application is running. If it's a web app, deployed in a WAR file, that would be the name of the WAR that's deployed (abc.war).
The .do extension suggests a Struts or JSF action mapping.
There are two parameters passed in the GET: action, with value edit, and id, with value 123. Looks like a REST-ful API to me.