Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] Server Adapter Use Case Question

Hey Rob,

I'll need to take a closer look at your use case using the attachments
to know why you are seeing a difference in class visibility on JUnit
execution between the generic servers and your example adapter (Tim,
Gorkem or Larry can probably also provide some insight here). It may
make sense to open a bugzilla to track and capture further exploration
of the issue. 

On the question of publish/export enablement for those cp container:
since these expose server libraries, you don't want to mark them for
publish/export and should use the extension point to suppress the
warning.

-Rob

-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]
On Behalf Of Rob Stryker
Sent: Thursday, August 23, 2007 4:12 PM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] Server Adapter Use Case Question


Rob:
    This seems a bit paradoxical to me.  If I mark the classpath 
container as one to be published and exported, then these jars will be 
bundled in the lib folder when the module is published. This is *not* 
the desired behavior for me because these are basically server libraries

that are already there for runtime.

However, if I don't mark them as publishable / exportable, these classes

are not available when running a class in the project as a JUnit test.

This paradox is what leads me to ask whether this is a valid use case...

running a junit test class from inside the Dynamic Web Project, but not 
publishing it... Having the libs available when running one of the 
classes as a test class, but *not* bundling them as libraries.

And somehow, the generic server accomplishes this. And I'm not sure how.

- Rob Stryker

Rob Frost wrote:
> 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: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]
> 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
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>   

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-dev

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.


Back to the top