Like I said, the easiest solution is to put some of the example code I sent you in place so that it dumps out the full list of resources found on the classpath at the time of the error.
It might even be something weird and unexpected that causes the problem. For example, running my j2ee apps inside eclipse would add every WEB-INF/lib jar to my classpath twice -- once because they are in the WEB-INF/lib System classpath, and once because they are in the WebAppClassLoader jetty classpath. I had to reconfigure jetty to disable using the WebAppClassLoader. On Tue, Apr 16, 2013 at 11:47 AM, Rick Bonnett <[email protected]> wrote: > > I verified that velocity-1.6.3.jar is in my WAR file, and after deploying my > app it is sitting in the WEB-INF/lib directory as well. This was as I > expected. > > If glass fish is somehow loading a different one I don't know where it would > be coming from. I did do a search through every jar and war file on my > system. The only reference I found to other versions was one in the m2e > Eclipse plugin, which was for 1.5.something, but I don;t see how that could > be anything glass fish would use. > > > On Apr 16, 2013, at 9:59 AM, Mike Kienenberger <[email protected]> wrote: > >> My first guess would be that you have more than one velocity jar files >> in the classpath. >> I guess a second possibility is that you have no velocity jar files in >> the classpath. >> >> We have an in-house findClass.jsp (backed by a ClassPath bean) which >> we use for problems like this to identify all definitions of a class >> in the classpath. Unfortunately, I don't have permission to share >> this. >> >> But you could probably come up with something similar: >> >> >> Here's a jsp that looks like it identifies the first definition of a class. >> http://mcpaint.tistory.com/13 >> >> >> Here's how to show all resources >> http://www.mkyong.com/java/how-to-print-out-the-current-project-classpath/ >> >> You'd probably want to combine the two. >> >> >> Here's something else I came across while trying to find an example of >> what you needed. Not sure how easy it would be to integrate with your >> app. >> >> http://classpathhelper.sourceforge.net/ >> >> On Tue, Apr 16, 2013 at 8:38 AM, Rick Bonnett <[email protected]> wrote: >>> I'm trying to use SQLTemplate queries and running into a strange problem. >>> This snippet works fine if I run it in a plain Java application, but fails >>> if I then use it within a web service running under Glassfish. >>> In both cases I am using the same cayenne metadata files. I have also >>> noticed the same issue when using EJBQL queries. >>> >>> >>> ServerRuntime cayenneRuntime = new >>> ServerRuntime("cayenne-cayenne-service-template.xml"); >>> ObjectContext context = cayenneRuntime.getContext(); >>> >>> >>> SQLTemplate sql = new SQLTemplate(Accessorial.class,"SELECT * FROM >>> live.tbl_accessorials"); >>> String pgSql = "SELECT * FROM live.tbl_accessorials"; >>> sql.setTemplate(PostgresAdapter.class.getName(), pgSql); >>> Collection<Accessorial> accessorials = context.performQuery(sql); >>> >>> >>> I have tried this both with and without the Postgres specific template - >>> same result either way. Works fine in a console app, fails running under >>> the web server. >>> >>> This seems to be the relevant section of the stack trace: >>> >>> Caused by: java.lang.NoClassDefFoundError: >>> org/apache/velocity/runtime/parser/ParseException >>> at >>> org.apache.cayenne.access.jdbc.SQLTemplateAction.performAction(SQLTemplateAction.java:102) >>> at >>> org.apache.cayenne.access.DataNodeQueryAction.runQuery(DataNodeQueryAction.java:87) >>> at org.apache.cayenne.access.DataNode.performQueries(DataNode.java:280) >>> at >>> org.apache.cayenne.access.DataDomainQueryAction.runQuery(DataDomainQueryAction.java:442) >>> at >>> org.apache.cayenne.access.DataDomainQueryAction.access$000(DataDomainQueryAction.java:70) >>> at >>> org.apache.cayenne.access.DataDomainQueryAction$2.transform(DataDomainQueryAction.java:415) >>> at >>> org.apache.cayenne.access.DataDomain.runInTransaction(DataDomain.java:877) >>> at >>> org.apache.cayenne.access.DataDomainQueryAction.runQueryInTransaction(DataDomainQueryAction.java:412) >>> at >>> org.apache.cayenne.access.DataDomainQueryAction.execute(DataDomainQueryAction.java:122) >>> at >>> org.apache.cayenne.access.DataDomain.onQueryNoFilters(DataDomain.java:758) >>> at >>> org.apache.cayenne.access.DataDomain$DataDomainQueryFilterChain.onQuery(DataDomain.java:1009) >>> at org.apache.cayenne.access.DataDomain.onQuery(DataDomain.java:748) >>> at >>> org.apache.cayenne.util.ObjectContextQueryAction.runQuery(ObjectContextQueryAction.java:350) >>> at >>> org.apache.cayenne.util.ObjectContextQueryAction.executePostCache(ObjectContextQueryAction.java:106) >>> at >>> org.apache.cayenne.util.ObjectContextQueryAction.execute(ObjectContextQueryAction.java:93) >>> at org.apache.cayenne.access.DataContext.onQuery(DataContext.java:989) >>> at org.apache.cayenne.access.DataContext.performQuery(DataContext.java:978) >>> at >>> com.mesca.services.AccessorialService.allAccessorialRows(AccessorialService.java:83) >>> >>> Any ideas on what I am missing here? >>> >>> Thanks >>> Rick >>> >
