I have two projects in eclipse - a Java project (let's call it Project A) and a Dynamic Web Project (Project B). Both projects use log4j and both have their own configuration files(as it is now, Project A uses a log4j.properties file and Project B a log4j.xml file). I require Project A to call code from Project B, so in Project A's build path, Project B is added as a required project. This seems to confuse log4j, as it loads it's configuration from Project B's log4j.xml file instead of Project A's log4j.properties. To combat this, I added the line "-Dlog4j.configuration=log4j.properties" in my launch configuration, which seems to work. Indeed, the formatting of the logger output is now as described in Project A's log4j.properties.
Both projects also use spring for database connections. The problem I am faced with now is that all logging output from spring seems to be missing. If I remove Project B from Project A's build path the problem goes away and I see the log output from Spring in the console. Is there something inherently wrong with my approach here? If not, any suggestions to make Spring's log output appear in the console while keeping Project B in Project A's build path?
Sorry for the long winded explanation. Any suggestions would be very appreciated.
It sounds like you have have the log4j config file for Project B in the classpath. In both projects, make sure the config file is not in the classpath and use the -Dlog4j.configuration technique instead.
Usually, for things like this I try not to have multiple log4j files. If both projects have standalone Java main()s, then you may want to consider having a 'common' project for both projects that contains common configuration files like log4j.
Related
Using Java8, Eclipse Mars 4.5
I have a simple Maven project with a pom and a single java file, in a folder. I do the File -> Import -> Existing Maven Project -> Point to my folder. Eclipse does its thing sucessfully creates the project (no errors). But with somewhat of a complex folder structure that I am able to edit (with some difficulty). My project file structure is:
Project
/classes
/pkg
/.class
/src
/pkg
/.java
I originally see my java file (but not in the /src), I see all my dependent jars. After some doing (open/new etc) I am able finally compile my java class- I see all the generated class files.
But I am unable to run it. I do have my main class specified in the eclipse run configuration.
I don't have the Run As enabled.
I try run java application, get error:
Could not find or load main class 'myclass' (I do have the main method)
If I try Maven build (M2 the red icon), initially I got 'no goal specified' error, added <defaultGoal>install</defaultGoal> to the pom. I do get BUILD SUCCESS
But still no run? What am I missing.
I went the maven project route to simplify, but
Thanks
This problem was finally solved by conforming (submitting) to the default file structure of the eclipse/maven project- <classpathentry kind="src" output="target/classes" path="src/main/java">. I re-created the file structure (as this) put/copied my .java and .classes in those directories - it ran fine finally.
I could see this problem when I opened the .classpath file - it had the original /classes and /src directory and not he one I had edited in eclipse (as I indicated in my Question). Even though I was actually successfully compiling into my /classes.
I would certainly not expect this behavior, there is clear edit option for /src and /classes and it should take effect- but maybe not.
Another observation to add- when I look at my run configuration - I see the correct class but eclipse does not show the location. So one would never know.
So long story short it finally worked after much frustration and effort and loss of a couple of days (And I just had exactly one java file to compile and run - wondering how much pain would be if I had a few more).
I am not a regular eclipse user (any longer) so some of it would be getting used to etc - but some of these quarks need to be taken care of (It is the No1 tool)
I am working on two projects in Eclipse.
Project A depends on some jar files that come with the project, and those jar files have been added to the “Libraries” tab in Project A's “Java Build Path” property in Eclipse.
Project B depends on Project A, as well as directly using some classes in some of those jar files in Project A's build path.
I had assumed that adding Project A to Project B's Java Build Class would also add the jars already in Project A's build path, but that appears not to be the case.
Do I have to manually add those jars to Project B's build class, or am I overlooking a setting? If so, why is that a useful standard behaviour?
You have to manually add the jars to project B's classpath.
Adding a project dependency means project A depends on the compiled output of project B. Project B's output (its compiled .class files) doesn't contain the .jar files it depends on.
Why is this? I don't know the rationale of the eclipse authors, but my guess is that they want to keep the classpath as simple and verbose as possible. Things can get confusing if you have multiple versions of the same library on the classpath.
In vanilla java you can provide directory names for the classpath. When loading a class, the JVM will search these directories in order. Eclipse encourages a stricter approach where each jar is specified manually. Note that you can add multiple jars at once, so it's trivial to add all of project B's jars to project A's classpath.
The structure is as follows:
Actually deployed module is EAR.
EAR contains WAR module, and WAR module contains another JAR module.
In this last JAR, there are some generated classes and their parent folder is also used as source folder. Its path is "target/generated-sources/java".
The problem that is killing me, is that the deployed application throws ClassNotFoundException on server start, and the classes in question are the generated ones.
Now the trick:
if I explicitly change the Deployment Assembly in WAR project in Eclipse not to contain JAR project as "project", but as an archive from the JAR's project "target" folder, JBoss sees the generated classes and starts.
This solution however works only until next eclipse maven project update, so manual edit of deployment assembly is not really a solution.
Any ideas how to deploy or reorganise packages correctly?
OK, seems I have found the solution.
I looked through the build-path of the mentioned JAR file and saw that the entry Output folder pointed to target/test-classes.
After changing this entry to target/classes the application deploys and starts without any missing generated classes.
This is what worked for me:
Expand the 'target' folder of your maven project inside Eclipse (Project Explorer View);
Refresh it (F5);
Right click on your project on 'Servers' tab, then select "Full Publish";
Start your JBoss.
I had to enforce the JBoss Tool "Full Publish" to get an updated version of my target folder by Refreshing it manually on eclipse.
I don't know why but sometimes the Publishing from maven projects (even Full Publishes) do not copy classes from the target Project as it is in the file system. Maybe it's using some outdated memory info or some cache...
Anyway, this is what works for me.
After an update to Eclipse 4.15 and JBoss tools I got this problem too.
My solution: project -> properties -> Java Build Path --> Source
There my Output folder from my source was linked to project/target/classes, I changed this to project/target/project-projectversion/WEB-INF/classes
When I looked into the standalone JBoss folder I saw the folder structure of my source, but the classes where missing, when I changed the output folder the classes pop up and everything worked like before.
I am pretty sure the update made the problems.
I am working in an ActiveJDBC project that requires an instrumentation step before the build in order to do the entity mapping. I did this by adding a script that generates an activejdbc.properties at the classpath.
The build part is fine and the file is being properly generated in the workspace. However, when I publish the project the file is being packed in the WAR file (all the other classes are fine though).
It is a simple dynamic web project, no changes in the build or classpath besides the instrumentation step. I am using:
- OS X Mavericks.
- Eclipse Juno.
- Maven 3.
- JBoss AS 7.
- JRE 1.6.
I used the following tutorial: http://javalite.io/eclipseIntegration
Can you guys give me a hint on whats going on? There is no error or warning in console...
I think you mean activejdbc_models.properties file. This file will be produced by instrumentation process and will be placed at the root of your classpath, usually target/classes. Please see if it is there. If it is there, it will be placed at the root of your war file: war_root/WEB-INF/classes. Unpack your war file and see if it is there. If not, something is wring in how you create a war file.
I went through the whole process again and, after a lot of attempts, I changed the configuration in the instrumentation builder to refresh resources recursively upon completion and it started working. Its on Proj Properties >> Builders >> Edit (on instrumentation builder) >> Refresh tab.
It seems to be working now, but I'll try to map more entities to check if its really ok.
I have a Maven project in SVN with trunk\Config\TestProjConfig folder having all the XML configuration files and all Java code is in trunk\JavaSource\TestProj. When I check out to my local Eclipse there are 2 projects created one for TestProjConfig and one for TestProj.
How do I test this project? Do I have to edit the build path to make a connection between the two projects? Do I have to write a main class which accesses the AppContext file to invoke the Spring injections?
Note:I have the m2eclipse plugin in Eclipse.
I don't understand why you separated XML configuration from Java sources. It could be a good practice only if you want to reuse your conf in other project, but in this case, I'm not sure that's suitable.
Solution 1
Move all your xml config into JavaSource\TestProj\src\main\resources
If you really don't have to share your configuration or don't have any legacy / corporate / mysterious reason, you should not separate them.
Solution 2
If you REALLY want to separate them, put them in a zip with an assembly, and add a dependency from TestProj to TestProjConfig.
Here an example : Maven - Depend on assembled zip