Hi, I have added a patch for this task.
About the changes: -------------------- AppValidator - Nothing much here, Just added CheckDescriptorLocation to validation CheckDescriptorLocation -Looks in the base-dir of an EjbModule for any descriptor. If present, logs a warning CheckDescriptorLocationTest -Uses Archives.java to create a Jar with a descriptor placed in root. Tests for the warning to be issued. CheckDescriptorLocationTestFileDeletionHelper - I'd like you to look at this one.. I wasn't able to delete the jar file created in the above test. After DeloloymentLoader.load(jarFile) was executed in the test, it looks like the jar is held by something . Even a delete in @AfterClass method in CheckDescriptorLocationTest didn't delete the file. deleteOnExit() didn't seem to delete too. But when I placed the deletion separately in a new file (CheckDescriptorLocationTestFileDeleteHelper) and ran this, then the file got deleted. Archives - Copied and pasted (from http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/src/test/java/org/apache/xbean/finder/archive/Archives.java http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/src/test/java/org/apache/xbean/finder/archive/Archives.java ) into openejb-core util package and modified to pass the jar-filename-prefix as a method-parameter. Not feeling so good about a copy-paste. Anyway that could be avoided ? This kinda finishes the first list of changes In some cases where something was totally descriptor driven, like ( examples/simple-stateless-with-descriptor) if ejb-jar.xml was misplaced in the root, then ConfigurationFactory.getDeclaredApps() would return a list of size 0, nothing was considered for deployment.. Hence no AppModule was created. The validation as in above (CheckDescriptorLocation) doesn't help here. So added a log statement in ConfigurationFactory. Finally a similar case while misplacing the descriptor in examples/simple-mdb-with-descriptor. But the flow now went on to throw a NoModulesFoundException. Thought of adding a detailed exception message in this case, so that might help the user. Something like ( http://www.grepcode.com/file/repo1.maven.org/maven2/org.mockito/mockito-all/1.8.5/org/mockito/exceptions/Reporter.java http://www.grepcode.com/file/repo1.maven.org/maven2/org.mockito/mockito-all/1.8.5/org/mockito/exceptions/Reporter.java ). I really liked such detailed messages in Mockito. The changes in OpenEJBContainer.java Exceptions.java and StringUtilities are for this. I'm not sure if an exception message can be so elaborate or if it is consistent with this project's coding conventions. In any case, feel free to tell me / change it. Please review, Thanks, Vishwa -- View this message in context: http://openejb.979440.n4.nabble.com/Patch-for-OpenEJB-1570-Look-for-Misplaced-descriptor-and-warn-tp3706787p3706787.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
