JDeveloper 10.1.3.x
I've recently learned that a library that is not exported will not be included on the classpath when deployed to the embedded OC4J container because it will have no library entry in the application-oc4j-app.xml file.
I have also demonstrated to myself that libraries that are not exported in projects that my project depends on are included in the application-oc4j-app.xml file.
Unexported libraries in my project do not get included. Unexported libraries in my project dependencies do get included.
Is that a bug or a feature, and can I change that behavior such that unexported libraries in my project dependencies also do not get included?
Thanks,
Steve
Unexported libraries should not get included in the application-oc4j-app.xml file. It looks like there is a bug, or some inexplicable behavior in JDeveloper.
IMHO, given a choice between Eclipse or <insert another IDE here>, and JDeveloper, it is wise to choose Eclipse.
One of the inexplicable behaviors that I referred to earlier, was the issue with JDeveloper compiling all projects in the application's directory, even if they were not part of the current workspace file (jws file). In other words, JDeveloper will consider a JPR file for inclusion in the workspace, even if the JWS file states otherwise (i.e. is does not appear visually in the JDeveloper workspace).
To date I have not found a way to specify different classpaths for build vs run time, but with help from a colleague, a solution to my specific situation was stumbled upon. Even though the connector is not a JDev project, the dependent project can reference the log4j jar file that is packaged and loaded with it. That effectively mimics the behavior at runtime, for both standalone as well as embedded oc4j container deployment, in which the web application and associated application code link to the log4j instance loaded by the 3rd party JCA connector's classloader. I did not think this would work assuming that a log4j library loaded by two different classloaders would still appear to be two distinct instances of the library with respect to log4j's static initializers. (That is what I am presuming motivates log4j to throw an exception if it finds another instance of itself in the classloader hierarchy.) Apparently this is not the case, at least for the embedded scenario. I do not have to test this for the standalone container since the Maven build knows not to include a copy of the log4j library jar in the application EAR file via the "provided" scope specification in the build file. The embedded OC4J container now loads the JCA connector, the associated log4 library instance, deploys the application, and allows both to use the log4j classes from the same log4j library file. Not entirely sure of how the connector and web applications classloaders interact, but it works now.
Related
I have added spring-web.4.0.jar in classpath. It contains the class - org.springframework.web.context.WebApplicationContext. but when I try to run it in eclipse it shows me an error : org/springframework/web/context/WebApplicationContext.
How to resolve this error?
Choosing "Clean..." from the server contextual menu helped me get rid of this problem.
Try clean and rebuild your eclipse project, because sometimes eclipse gets out of date.
Alternatively, if this doesn't help, you need to verify that the runtime path indeed points to the correct jar, and that the jar does indeed contain the WebApplicationContext.class and is readable.
To see the runtime path, use the debug view (Window - Views- Debug), right click to view properties.
Find the jar and open it with a normal zip viewer to see if the file reads correctly.
The root cause of this problem can be almost literally anything, but here are a few weird things to check:
Maven dependencies with test or provided scope that should be normal scope
Spring XML files have schema versions that don't match framework version (3.0 or 4.0)
Spring XML references "https://" instead of "http://" or vice-versa (depends on version)
web.xml file containing ${} references not compatible with chosen web server
Conflicting version of very core libraries such as Jackson, Servlet API, spring-*
Misconfigured or missing or incompatible loggers: slf4j, log4j, jcl
Mixing of old and new: jdk version, spring version, dependency versions, IDE, server
Maven dependencies not showing up in Deployment Assembly (this one went away with upgrades)
Stale or locked jarfiles... may require a reboot, tomcat "Clean..." not enough
Missing required -D or environment variables
My application ended up with several of these all wrong one after another.
The exception is misleading. Setting a debugger breakpoint on the exception sometimes helps.
Why there's a difference in Default Source Lookup Path between GWT and java launch configurations?
In multi-module projects instead of containing projects, the Default folder contains the class folders of those projects!
It causes "Source not found" errors when the debugger steps into a dependency project.
I know I can add projects manually. Just want to know why this difference is needed.
The only project in the list is the associated with the .launch.
GWT needs '.java' source files of dependencies to be able to compile (translate to js) while the Java launcher needs only '.class' compiled files.
I suppose you know GWT has a different way to manage dependencies (through modules within the same project), which is good for some advanced GWT practices like loading a module's js lazily (this feature doesn't work with "foreign" libs/projects).
So this could also be an answer for why eclipse GWT doesn't suppose you will have more projects (but more modules instead)
Finally if you really have an independent GWT lib that you're maintaining this is an issue as you said.
I have a GWT webapp split into two Maven projects where one is a dependency to the other. Each time I change something in the dependency and I'm running webapp in hosted mode I have to rebuild the subproject and restart hosted mode for changes to apply. It takes a lot of time so I'd like to ask you if there is any way to make GWT using "live" version of the dependency?
There are 2 cases:
for server-side code, assuming you use the DevMode's embedded server, rebuilding the app and then refreshing the server should be enough
for client-side code, AFAICT, you have to use the source and output directories of the dependency module rather than the JAR containing them (GWT will load the source from the classpath, but apparently it'll only see the modified sources if it comes from a folder rather than a JAR; at least that's what I found in my tests). This goes against The Maven Way™ but the only solution so far is to use a special profile that will import the sources of the dependency project as sources of the project you're running. You can see examples of that in my archetypes.
There's actually a bug opened for the gwt-maven-plugin, MGWT-332, to do that automatically when running a reactor build. I also mused about what's really needed, for the forthcoming official gwt-maven-plugin (rewritten from scratch, independent from the CodeHaus Mojo plugin).
If your dependency does not come from a reactor build, then you're out on your own: you chose to make it totally distinct, so that's how it'll behave: you'll have to release it (even a snapshot) each time you make a change to it, and use the new version in your app (which means re-launching the DevMode).
This can be circumvented by running DevMode on your own, without the help of the gwt-maven-plugin. You're left on your own managing the classpath though (using the Google Plugin for Eclipse, I suppose you could simply edit the launch configuration to add the source folders of your dependency project to the classpath, before the classpath provided by Maven, that would reference the JAR).
Remove the dependent other application jar file from the primary application lib folder under webapp.
Eclipse should then resolve the dependency using the other project in the workspace if you have added it to your primary application classpath.
As GWT build takes ages, we invested some money in a JRebel license. We have two separate Eclipse projects for our back-end and our GWT front-end. JRebel reloads the classes automatically and I never need to restart my local server while writing code. It proved to be a wonderful time saver. Definitely worth the investment.
I'm trying to build portlets for websphere in Eclipse Juno. Everything works so far, building and running the WAR files on WPS7 is ok.
But in my JSP editor I get a lot of warnings:
Can not find the tag library descriptor for "/WEB-INF/tld/portal.tld"
In my JSP file I'm using the usual taglib line:
<%#taglib uri="http://java.sun.com/portlet" prefix="portlet"%>
Now I wonder if I have to bring the actual JAR file that defines this tag into my eclipse or if there is something else that I missed.
The reason you are getting this error message has nothing to do with the taglib declaration you had quoted. The latter refers to the standard Portlet tag library (JSR-168), whereas the former has to do with WebSphere Portal's proprietary tags, needed to use WebSphere Portal-specific facilities.
I am guessing that portal.tld is referred-to by your web.xml.
When developing portlets under RAD, IBM's RAD plugins ensure that this TLD file is known to the JSP compiler, by virtue of attaching the WebSphere Portal runtime - in its entirety - to the Dynamic Web Project's classpath.
Under Eclipse Juno, this isn't done for you. You will have to find the JAR file that contains it (which might vary from one WebSphere Portal release to another) and add it to your compile-time classpath.
Having said that, you may want to consider why you need that web.xml declaration in the first place. With Portal 7.0, most of IBM's tag libraries can be referred to by their URI's, rather than having to specifically mention the TLD file.
I'm using a Portal 8 installation but the structure should be similar.
I found a jar containing portal.tld at [Portal Install root]\Portal Server\base\wp.engine.tags\shared\app\wp.engine.tags.jar
Though as a more complete solution you might want to include the whole base folder into your classpath. The server runtime RAD adds to my portlet project include lots of jars from that folder as part of the basic setup. It also includes many jars from [WAS Install root]\App Server\plugins. Since you're just using Eclipse instead of RAD (which would help manage the Portal server jars) you'll probably want to create a user library to manage all these jars.
In RAD/Eclipse, assuming you have the Portal 8 Stubs and Developer Tools installed, you can go to Project->Project Properties -> Java Build Path, to the Libraries tab, Go to Add Library -> Server Runtime , and you should see "Websphere Portal 8" or whichever version you have installed ... once that library is added your URI problems should be resolved.This essentially adds every jar file in the entire portal installation to the build path. If you do not have the stubs and development tools installed, or if you are using another IDE, you will need to add the jar files manually to the build path ....
I'm using STS, and with a Web (WTP); Maven; Groovy stack.
By default, it appears that the Groovy classpath entries weren't marked to be exported, and I was issued with the following warning:
Classpath entry GROOVY_DSL_SUPPORT will not be exported or published.
Runtime ClassNotFoundExceptions may result. Classpath entry
GROOVY_SUPPORT will not be exported or published. Runtime
ClassNotFoundExceptions may result.
So, I added the libraries from Project Properties -> Deployment Assembly -> Add...
However, now I get the following error:
Invalid classpath publish/export dependency
/Users/martypitt/springsource/2.8.1.RELEASE/sts-2.8.1.RELEASE/plugins/org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE/lib/antlr-2.7.7.jar.
The project contains another dependency with the same archive name.
I worked around by excluding antlr manually from my pom.xml. However, this seems counter-intuitive, and leaves me concerned about issues later when I deploy to a server outside of STS.
Is there a more appropriate way to resolve this issue?
You do not need to export the DSL support container. It provides editing support for some built in Groovy AST transforms. There is nothing in the classpath container required for compilation or runtime.
Looks like your project is groovy project. Go to eclipse and install groovy addon - from software site - http://dist.springsource.org/snapshot/GRECLIPSE/e4.6/
After this restart eclipse and you should have these in path/eclipse to work with.
Detailed instructions # https://github.com/groovy/groovy-eclipse/wiki
Make sure you have the proxy configured properly - if any.