Thanks for figuring this out Anissa!
These jars should be included with the application, not in the shared
folder. While I think this should be fine for JSFTemplating jars, I am
not as confident for the other jars. This effects classloading and can
cause unexpected results (i.e. if a class from the shared library looks
for a class that needs the web app classloader, it may not be found
unless the context classloader is used).
Thanks Anissa!
Ken
Anissa Lam wrote:
> Hi Ken,
>
> I was looking at this too to see why Jim is having that ClassNotFound
> exception.
> I can reproduce what he saw.
> Looking at his project files, all the needed jars are in the same
> directory with the server's jar, ie javaee.jar, appserv-rt.jar. This
> make me think that maybe Jim is putting all the jar in the server's
> share lib directory.
>
> If i exploded dist/jsfdemo.war, put all the necessary jar under
> WEB-INF/lib, deploydir, i can run the app without any problem.
>
> However, if i did what i believe he is doing, move all the needed jar
> to <AS>/lib, restart domain, undeploy and then do deploydir again,
> deployment went fine. But when you run the app, you will get the
> ClassNotFound exception.
>
> [#|2007-02-17T11:25:48.622-0800|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;_RequestID=f8b4e3b6-aae3-4944-baa8-1699f2190f40;|WebModule[/TESTjsf]PWC1257:
> Error configuring application listener of class
> com.sun.faces.extensions.avatar.event.DynaFacesContextListener
> java.lang.ClassNotFoundException:
> com.sun.faces.extensions.avatar.event.DynaFacesContextListener
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:975)
>
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1470)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4425)
>
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:5144)
> at com.sun.enterprise.web.WebModule.start(WebModule.java:304)
>
> This is the exception he sent out in previous email.
> Anyway, looks like his app can't find the needed jars.
>
> Anissa.
>
> Ken Paulsen wrote:
>>
>> Hi Jim,
>>
>> Under your "web" directory you have:
>>
>> ./abc.jsf
>> ./WEB-INF
>> ./WEB-INF/sun-web.xml
>> ./WEB-INF/web.xml
>>
>> If you are trying to deploy this directory, you need the .jar files,
>> including a jar file w/ your handlers in it and your handler.map
>> file. See the the "app.jar" in the JSFTemplating's unmodified "demo"
>> app. You can download the demo app from the JSFTemplating web site if
>> you don't have this
>> (https://jsftemplating.dev.java.net/servlets/ProjectDocumentList?folderID=6920).
>>
>>
>> Under you "dist" directory you have a file called "jsfdemo.war", this
>> file contains:
>>
>> META-INF/
>> META-INF/MANIFEST.MF
>> WEB-INF/
>> WEB-INF/classes/
>> WEB-INF/classes/META-INF/
>> WEB-INF/classes/META-INF/jsftemplating/
>> WEB-INF/classes/META-INF/jsftemplating/Handler.map
>> WEB-INF/classes/demo/glassfish/ExampleHandlers.class
>> WEB-INF/classes/demo/
>> WEB-INF/classes/demo/glassfish/
>> WEB-INF/sun-web.xml
>> WEB-INF/web.xml
>> abc.jsf
>>
>> If you add all the missing jar files to WEB-INF/lib, this looks like
>> it should work. However, I recommend you move the
>> WEB-INF/classes/META-INF/* files to META-INF/*. I tested by moving
>> your classes/* to the demo application and your handler worked fine.
>>
>> Here are the files in the WEB-INF/lib directory that you need (so you
>> can double check):
>>
>> app.jar
>> dataprovider.jar
>> dojo-0.4.1-ajax.jar
>> jsftemplating.jar
>> jsftemplating-dynafaces-0.1.jar
>> json.jar
>> prototype-1.5.0.jar
>> webui-jsf.jar
>> webui-jsf-suntheme.jar
>>
>> This is assumes you are using the recently released Woodstock
>> components (https://woodstock.dev.java.net). If you don't have some
>> of these jar files, you can get them from the demo.war web
>> application on the JSFTemplating site (link above).
>>
>> I hope this helps!
>>
>> Ken
>>
>>
>> Jim Jiang wrote:
>>> Hi Ken,
>>>
>>> Please find jar file for whole nb project from the attachment.
>>> You can find the generate war file under dist directory.
>>> I tidy the src, now it will not generate the jar file under
>>> WEB-INF\lib, but play the same the effect.
>>> the files in libraries is not included.
>>>
>>> Thanks,
>>> Jim
>>>
>>> Ken Paulsen wrote:
>>>
>>>>
>>>> Here the expected app structure:
>>>>
>>>> / <--- docroot where your .jsf / .jsp / images / .css / .js and
>>>> other files go
>>>> /WEB-INF <--- where your web.xml / faces-config.xml files go
>>>> /WEB-INF/lib <-- Where your .jar files go
>>>> /WEB-INF/classes <--- if you don't .jar up your classes, you can
>>>> put the classes under this directory (make sure they're in the
>>>> right subdirectory according to package)
>>>>
>>>> JSFTemplating has a feature to move files out of the docroot in to
>>>> a .jar file, but I'm going to ignore that for now.
>>>>
>>>> The .jar files in your "lib" directory that contain "handlers"
>>>> should have this structure:
>>>>
>>>> /some/package/YourFile.class
>>>> /META-INF/jsftemplating/Handler.map
>>>>
>>>> That's it. If you want to send me your files, just .jar them up and
>>>> I'll take a look.
>>>>
>>>> As for the error directory cannot be deleted error... I don't know
>>>> why this is happening. I have heard of something similar to this
>>>> happening in older version of the app server, but I don't think
>>>> newer versions have this problem. Also, I think only Windows has
>>>> this problem. I'm not sure what the cause / solution is. You might
>>>> try posting to dev_at_glassfish.dev.java.net. It's been a long time
>>>> since I've developed on windows, but I think if you have a file
>>>> open (i.e. in NetBeans), it might lock that file and prevent you
>>>> from deleting it. I'm not sure, though.
>>>>
>>>> God luck!
>>>>
>>>> Ken
>>>>
>>>>
>>>> Jim Jiang wrote:
>>>>
>>>>> Thanks, Ken,
>>>>>
>>>>> I checked the file structure and found sth:
>>>>> under WEB-INF/lib directory, there is no jar file but 2
>>>>> directories, one for class, another is META-INF/jsftemplating with
>>>>> Handler.map file
>>>>> I created a jar file which contains all files under WEB-INF/lib,
>>>>> then generated the war and deploy it. Some change happen, I can
>>>>> found my handler in the info.jsf! But abc.jsf still not works, the
>>>>> error prompts java.lang.ClassNotFoundException as below.
>>>>>
>>>>> javax.servlet.ServletException: demo.glassfish.ExampleHandlers
>>>>> javax.faces.webapp.FacesServlet.service(FacesServlet.java:256)
>>>>> com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
>>>>> *....*
>>>>>
>>>>> java.lang.ClassNotFoundException: demo.glassfish.ExampleHandlers
>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>>>>> java.security.AccessController.doPrivileged(Native Method)
>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>>>>> ....
>>>>> I found that both WEB-INF/lib and WEB-INF/classes directory have
>>>>> the same classes, but their size are different.
>>>>> I wrote a jsp to access the handler
>>>>> demo.glassfish.ExampleHandlers, it shows it is in the classpath.
>>>>> BTW, there is another problem look strange, I can not deploy jsf
>>>>> war file twice to glassfish because of following error :
>>>>> /CLI171 Command deploy failed : Deploying application in domain
>>>>> failed; Cannot deploy. Module directo
>>>>> ry is locked and cant be deleted: {1}
>>>>> /
>>>>> Looking forward to your further suggestion.
>>>>>
>>>>> Thanks,
>>>>> Jim
>>>>>
>>>>> Ken Paulsen wrote:
>>>>>
>>>>>>
>>>>>> Yes, it sounds like your directory structure is fine. Here's what
>>>>>> I'd do first to try to debug it:
>>>>>>
>>>>>> Find your GlassFish installation and goto domains/domain1/config
>>>>>> and look at the domain.xml to see where your app is deployed (it
>>>>>> might not be where you think it is). Then I'd goto that directory
>>>>>> and double check that in the WEB-INF/lib directory there is a
>>>>>> .jar file w/ a Handler.map file with the expected contents.
>>>>>>
>>>>>> Hopefully that will show you the error... b/c there isn't much
>>>>>> more to it then that! :)
>>>>>>
>>>>>> Ken
>>>>>>
>>>>>> Jim Jiang wrote:
>>>>>>
>>>>>>> I tried restart and redeploy, but they not works.
>>>>>>> How to make sure my change is in the classpath?
>>>>>>> As i said before, META-INF/jsftemplating/Handler.map is
>>>>>>> generated in the war WEB-INF/lib directory.
>>>>>>> I use Netbean jsf wizard to create project, does the war file
>>>>>>> structure it generated meet the requirement jsftemplate?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jim
>>>>>>>
>>>>>>> Ken Paulsen wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> If it's still showing "Test.getResponse" on the info.jsf page,
>>>>>>>> then one of the following must be happening:
>>>>>>>>
>>>>>>>> 1) Your changes aren't in the classpath.
>>>>>>>> 2) You haven't restarted the server (or redeployed the app)
>>>>>>>>
>>>>>>>> The container's classloader caches things in the classpath, so
>>>>>>>> redeploying or restarting the server is necessary. You can also
>>>>>>>> use the ".reload" feature, which essentially redeploys... I've
>>>>>>>> had problems w/ this feature in the past, but I think those
>>>>>>>> problems have been addressed.
>>>>>>>>
>>>>>>>> Good luck!
>>>>>>>>
>>>>>>>> Ken
>>>>>>>>
>>>>>>>>
>>>>>>>> Jim Jiang wrote:
>>>>>>>>
>>>>>>>>> Both answer is 'Yes'.
>>>>>>>>> I clean and build project , the Handler.map show the
>>>>>>>>> 'tt.getResponse' .
>>>>>>>>> The only difference between my step with the guide is that I
>>>>>>>>> copy all the needed jar to <glassfish>/lib, to reduce the war
>>>>>>>>> size for quicker deployment.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jim
>>>>>>>>>
>>>>>>>>> Anissa Lam wrote:
>>>>>>>>>
>>>>>>>>>> Hi Jim,
>>>>>>>>>> After changing the name of the method, did you 'clean and
>>>>>>>>>> build project' ?
>>>>>>>>>> When you look at the Handler.map, does it show
>>>>>>>>>> 'tt.getResponse' or 'Test.getResponse' ?
>>>>>>>>>>
>>>>>>>>>> Anissa
>>>>>>>>>>
>>>>>>>>>> Jim Jiang wrote:
>>>>>>>>>>
>>>>>>>>>>> I have a basic question about JSFTemplate.
>>>>>>>>>>> I followed the guide 'Templating for JavaServer™ Faces
>>>>>>>>>>> Technology -- NetBeans Project Tutorial' , and deploy and
>>>>>>>>>>> run the demo successfully.
>>>>>>>>>>> But when I tried to modified the demo to change handler name
>>>>>>>>>>> from Test.getResponse to * tt.*getResponse, I got below
>>>>>>>>>>> error when running abc.jsf.
>>>>>>>>>>>
>>>>>>>>>>> /javax.servlet.ServletException: Handler 'tt*.*getResponse'
>>>>>>>>>>> in event 'beforeEncode' is not declared! Ensure the
>>>>>>>>>>> '_at_Handler' annotation has been defined on the handler Java
>>>>>>>>>>> method, that it has been compiled with the annotation
>>>>>>>>>>> processing tool, and that the resulting
>>>>>>>>>>> 'META-INF/jsftemplating/Handler.map' is located in your
>>>>>>>>>>> classpath (you may need to do a clean build)./
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I only changed 2 place:
>>>>>>>>>>> One is in abc.jsf: (the bold text)
>>>>>>>>>>> <!beforeEncode
>>>>>>>>>>> * tt.*getResponse(upper(userInput="#{in}"
>>>>>>>>>>> response=>$pageSession{foo});
>>>>>>>>>>> />
>>>>>>>>>>> Another is in ExampleHandlers.java
>>>>>>>>>>> @Handler(id="*tt*.getResponse",
>>>>>>>>>>> input={
>>>>>>>>>>> @HandlerInput(name="userInput", type=String.class)
>>>>>>>>>>> },
>>>>>>>>>>> output={
>>>>>>>>>>> @HandlerOutput(name="response", type=String.class)
>>>>>>>>>>> })
>>>>>>>>>>>
>>>>>>>>>>> I make sure that the file META-INF/jsftemplating/Handler.map
>>>>>>>>>>> is generated in the war WEB-INF/lib directory.
>>>>>>>>>>> but the info.jsf always show the handler I defined, it
>>>>>>>>>>> always show Test.getReponse.
>>>>>>>>>>>
>>>>>>>>>>> Any other place need to be changed for just renaming handler?
>>>>>>>>>>> BTW, I use Netbean 5.5.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Jim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>