dev@jsftemplating.java.net

Re: JSFTemplating: Re: getting back into jsft - question on testing code changes to glassfish

From: Ken Paulsen <Ken.Paulsen_at_Sun.COM>
Date: Thu, 07 Jun 2007 21:08:08 -0700

Hi Mike,

I tend to use google to find just about everything. :)  Using google this time, I found the relevant place in the documentation w/i 1 or 2 minutes:

    https://glassfish.dev.java.net/javaee5/docs/ADG/beaqi.html#indexterm-193

Unfortunately, it doesn't look like the docs have much information.  They just state its purpose w/o examples.  The same google search also brought up:

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6553104

This is a bug that was fixed... however, it DOES have a Windows example of how to specify the path.  You can see that Anissa was successful in using fully qualified Windows paths in this attribute -- note she *did* have to use ';' characters to separate paths as I suggested that you may have to.  Anyway, you can compare this to what you tried.

FYI, here's the magic google search I used:

    "extra-class-path" sun-web.xml glassfish

Good luck!

Ken

Michael Phoenix wrote:
OK, I copied the files from jbi to docroot WEB-INF/lib and it worked. so the problem does appear to be the way I was entering the path names for the classloader extra-classpath in sun-web.xml. I've been researching the docs to see if I can find the "right" way to enter windows paths in sun-web.xml. I'm afraid I haven't had much luck. Either there isn't any documentation on setting up su-web.xml in the Sun AppServer docs or it's very well hidden. Google doesn't pull up much of use, either. Is there a better way to search the application server documentation rather than looking in the index?

On 6/6/07, Ken Paulsen <Ken.Paulsen@sun.com> wrote:

Hi Mike,

You might want to give up on the admin-gui and use one of the checked in samples in JSFTemplating.  In fact, Jason checked in a new one today and Imre modified it... Fred has been updating the editor sample, and has been running the woodstock sample.  Several people are running the demo app.

Anyway... I went to the javaserverfaces web site I mentioned below... I clicked on downloads, then nightly and found the GlassFish updater.  I think this link will take you right there:

https://javaserverfaces.dev.java.net/servlets/ProjectDocumentList?folderID=1703&expandFolder=1703&folderID=1504

The "SchemaType" is not the class that it can't find.  That class couldn't find a class and isn't telling you which one.  The new version of JSF supposedly will give you a better error message.


Good luck!

Ken

Michael Phoenix wrote:
This is getting very frustrating, setting up an environment to test and learn JSF seems to be virtually impossible. I tried changing the ":" used for seperators in the sun-web.xml to ";" and that didn't help. If I remove the gentered stuff , do I remove the whole folder or just the subfolders. I am undeploying an redeploying docroot each time I make changes. What is the class loader extra calsspath from sunweb.xml actually being parsed by? Is it sent directly to Windows for parsing?
I couldn't find any "glassfish updater" on the jsf site. The class it's not finding appears to be org/apache/xmlbeans/SchemaType. I assume that's in the xmlbeans.jar, but I don't know how to find out for sure.

Mike

On 6/6/07, Ken Paulsen <Ken.Paulsen@sun.com > wrote:

Hi Mike,

I assume there is no return in the middle of the extra-class-path as shown below.  I am not familiar with what is valid for windows... but I wonder how well this is parsed with ':' characters in the "c:" and used as the separator between paths.  Perhaps you need ';'?  Perhaps you need a relative path?

What class is it not finding?  Can you determine that?  If you use the latest version of JSF, Ryan said it would give you a better error message.  You can visit http://javaserverfaces.dev.java.net  I think you can download a GlassFish updater from there to get the most recent version of JSF.  Anyway, if you can see what class it's not finding, you can search to find the jar that it is looking for... then figure out why it's not working.  Optionally, you should be able to move the .jar files its looking for into your WEB-INF/lib directory instead of doing the sun-web.xml stuff.

If all that fails, perhaps it's a different issue and we need to re-examine the stack trace to see what the problem is.

I hope this helps!

Ken


Michael Phoenix wrote:
Double checked the paths and they are good. Here's the contents of sun-web.xml miinus the comments:
<!DOCTYPE sun-web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Sun ONE Application Server 7.0 Servlet 2.3//EN' ' http://www.sun.com/software/sunone/appserver/dtds/sun-web-app_2_3-0.dtd' >

<sun-web-app>
 <security-role-mapping>
    <role-name>admin</role-name>
    <principal-name>admin</principal-name>
    <group-name>asadmin</group-name>
 </security-role-mapping>

 <session-config>
     <session-manager>
     <manager-properties>
         <property name="sessionFilename" value="" />
     </manager-properties>
     </session-manager>
 </session-config>

 <locale-charset-info>
    <parameter-encoding default-charset="UTF-8" />
 </locale-charset-info>
 
<class-loader extra-class-path="C:/workspace/publish/glassfish/jbi/lib/jbi- admin-common.jar:C:/workspace/publish/glassfish/jbi/lib/jbi.jar:C:/workspace/publish/glassfish/jbi/lib/xbean.jar" />

</sun-web-app>


On 6/5/07, Ken Paulsen <Ken.Paulsen@sun.com> wrote:

Email your sun-web.xml file.  Also check your paths to those .jar files to ensure those jar files exist where you are specifying that they exist.

Ken


Michael Phoenix wrote:
Ok, I made the change to sun-web.xml as you suggested and undeployed/redeployed the docroot and I still get the same results and same messages in the server log.

On 6/5/07, Ken Paulsen <Ken.Paulsen@sun.com> wrote:

Your java version should be fine.  You only need to worry about the sun-web.xml classloader change that I mentioned.  Also, after you do this, you will either need to undeploy / redeploy.  Or you will need to stop the server, and delete the contents of the <glassfish install root>/domains/domain1/generated/* directory.  It caches the configuration information which you are changing, so in order to see changes to the web.xml or sun-web.xml files, you need to delete the contents of this directory or redeploy.

Good luck!

Ken


Michael Phoenix wrote:


On 6/4/07, Ken Paulsen <Ken.Paulsen@sun.com> wrote:



>     Also can you do: java -version
>
>
> jjava version "1.6.0_01"
> Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
> Java HotSpot(TM) Client VM (build 1.6.0_01-b06 , mixed mode, sharing)
>
>     And also make sure the <glassfish-root>\config\asenv.conf file
>     points to
>     the same version of Java?
>
>
> It doesn't look like it. Here's the entry I think we are looking for :
> set AS_JAVA=C:\Program Files\Java\jdk1.5.0_06\jre/..
> Looks like some changes are needed here.  I'm not sure how to change
> my jre version in the system and that notation for the config file
> looks like nothing I've seen before.
You should be able to point it to your Java 6 directory: c:\java6\

If you compile some things w/ Java 6 then try to run with Java 5, it
could cause problems.
>
Getting back to what we talked about on the phone my javac -version is 1.5.0_06. So do I need to make any changes here? I would assume that there is enough backwards compatibility in the jre to handle code from the previous version's compiler. Should I just change the sun.web.xml configuration as you and Ryan have suggested or is there something that needs to be done about my java version as well?