Hi Rob, I have not tried out your attached example but can explain why that warning is generated:
-the classpath entry publish/export support that was added in WTP 2.0 now allows you to tag (using a WTP-specific classpath attribute) entries on the project classpath for publish/export (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=185176 for a detailed description) -the warning you see is generated for all classpath entries that are both missing that tag (and therefore won't be included in the published/exported structure of the module) AND do not match a set of classpath containers declared via an extention as entries that should be ignored; here is the default filtered list (defined in org.eclipse.jst.j2ee): <extension point="org.eclipse.jst.j2ee.classpathdep"> <filteredClasspathContainer containerID="org.eclipse.jst.j2ee.internal.module.container"/> <filteredClasspathContainer containerID="org.eclipse.jst.j2ee.internal.web.container"/> <filteredClasspathContainer containerID="org.eclipse.jst.server.core.container"/> <filteredClasspathContainer containerID="org.eclipse.jdt.launching.JRE_CONTAINER"/> </extension> -I'm not completely clear on the mechanism by which your custom server adapter is exposing the code exposed by these classpath containers at runtime but it looks like this is only working for one of the classpath containers (are these classes already available on the server runtime classpath or do they needed to be added to the assembled WAR?). If your server adapter is going to handle packaging these classes or they are available at runtime and you want to suppress that warning, you can utilize the "filteredClasspathContainer" element of the "org.eclipse.jst.j233.classpathdep" extension point, otherwise, you could leverage the classpath entry publish/export support (see to get the JAR(s) resolved that those cp containers packaged inside the WEB-INF/lib of the published WAR. -Rob -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Stryker Sent: Thursday, August 23, 2007 10:10 AM To: General discussion of project-wide or architectural issues. Subject: [wtp-dev] Server Adapter Use Case Question Hi All: I've been having a bit of trouble with a simple use-case, and I wanted to know if this was a valid use case or if it's not actually a use-case. My issue is that the following works 100% for generic adapters, but not for the example adapter I'm including. When you create a dynamic web project, depending on the runtime used, different jars may be added to the project's classpath. My use case is very simple. Create a dynamic web project with some server adapter (in this case, the attached stripped-down server adapter), and then add only 1 class file inside that new project, a JUnit test file, which attempts to merely access classes contributed by the facets. The goal is to see if the junit test case will be able to access these classes at runtime. I am confronted with ClassNotFoundExceptions upon doing this. Also, in the problems view, is the following message: Classpath entry example.app.server.classpath.genericInitializer/Example Server Runtime/jst.java/5.0 will not be exported or published. Runtime ClassNotFoundExceptions may result. Step by step reproduction: 1) untar the attached project 2) Open a blank workspace. Import the attached project into the workspace. 3) Run the attached project as an eclipse plugin. 4) Create a new server of type Example (RS) -> Example Server Type 5) Create a dynamic web project targeting the Example Server Runtime 6) Note the classpath containers added to the project 7) Note the warnings in the Problems View 8) Create a JUnit Test *inside* this dynamic web project with the following method: public void testShouldNotFail() { Start1.class.getName(); Start.class.getName(); } 9a) Before running, verify that the classpath container "Example entries for jst.java" includes a jar "jst.java.jar" which has one class in it, Start1.class 9b) Before running, verify that the classpath container "Example entries for jst.web" includes a jar "jst.web.jar" which has one class in it, Start.class 10) right-click on the junit test file, and run it as a junit test. Result: The first line will not fail. Start1.getClass().getName() will resolve successfully. The second line *will* fail. Start.getClass().getName() will not resolve successfully. This seems very odd, because both were added to the classpath in the same fashion as far as I can tell by looking at my stripped down server adapter example. (in example.app.server.core.classpath.ProjectRuntimeClasspathProvider in the method getClasspathEntries(IProjectFacetVersion) Also, both classpath containers receive the warning in the problems view, so it seems odd that one of the classes would resolve and the other would not. I realize this is most likely an error in the enclosed adapter, but I'm completely unsure what one would need to do to make this junit test work properly, to ensure that these jars are exported to the junit's launch. - Rob Stryker Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
