Precompile jsps via ant

I have a development project that has been setup to use JDeveloper 10.1.3.5.0 to create and EAR for deployment. The EAR is comprised of three sub applications - appData, appEjb, appWeb. Each subapplication has its own resource to deploy in JDeveloper. The appWeb has an additional resource defined in JDeveloper to deploy the EAR.
I am attempting to move the build process out of JDeveloper and into ant in order to integrate the application with an automated build management framework.
I have been successful in creating an ant build.xml to pull the code from source control, compile the three subapplications, jar the appData, and jar the appEjb. The issue I am having is precompiling the jsp files in the appWeb.
The JDeveloper resource for appWeb.deploy precompiles all the jsps and packages the jsp class files along with all the other appWeb content as part of the appWeb.war.
I thought JDeveloper was utilizing an internal J2EE standalone OC4J. I created a classpath and taskdef as follows
<path id="ojspc.classpath">
<fileset dir="jdevstudio">
<include name="**/*.jar"/>
</fileset>
<pathelement location="${env.JAVA_HOME}/lib/tools.jar" />
<pathelement location="${outDir}/appData"/>
<pathelement location="${outDir}/appWeb"/>
<pathelement location="${outDir}/appEjb"/>
</path>
<taskdef name="ojspc" classpathref="ojspc.classpath" classname="org.apache.tools.ant.taskdefs.optional.jsp.OjspC" />
My original attempts had a much more constrained classpath definition (using the classpath found in the manifest file within j2ee\home\ojspc.jar); however, ant is unable to find the OjspC class and thus I expanded the classpath to include all jar files.
After reading through blogs, forums, and documentation, I am unable to figure out how to define a task within ant to precompile the jsps in my project which mirrors the work being done via the JDeveloper deploy resource. Does anyone know the actual class to use for precompiling the jsps?
Any help is greatly apprciated,
/dclink

GR wrote:
          > Is there any ant task for precompiling jsp provided by weblogic 8.1.2?
          > (Ant's wljspc doesnt work with 8.1.2).
          Have you tired a regular java task that calls the class weblogic.jspc?
          A little more direct but I imagine it would work
          ~Ryan
          

Similar Messages

  • Precompiling JSPs using ant

    Hi
    Does anyone know a documented way to precompile a JSP using an ant script. I've tried a lot, but didn't find a satisfying solution. The best solution I've found was calling OJSPC from commandline via ants "java" task, but even this solution does not work in JDeveloper 9.0.4 anymore.
    If anyone can give me a hint, I'd be really happy.
    Thanks

    Anybody ?

  • Tomcat5 and precompiling JSPs with Ant

    Hi I'm trying to precompile my JSPs in ANT and I'm using Tomcat5. Below is my taskdef:
    <target name="jsp" depends="build">
        <!--
             The Ant JSPC task doesn't work with Tomcat 5.0
             so in the meantime we need to define our own task.
          -->
        <taskdef name="jspc50" classname="org.apache.jasper.JspC">
            <classpath id="jspc50.classpath">
                <fileset dir="${tomcat.home}">
                    <include name="*.jar"/>
                </fileset>
            </classpath>
        </taskdef>
        <jspc50 outputDir="${classes}"
                uriroot="${src}"
                package="jsp"
                validateXml="false">
            <include name="**/*.jsp" />
            <exclude name="**/includes/**/*.jsp" />
        </jspc50>
        <javac srcdir="${classes}"
               destdir="${classes}"
               debug="true"
               optimize="false"
               includes="**/*.java"
               source="1.4">
        </javac>
    </target>Now, this actually works but if I use an absolute include directive in my JSPs like:
    <%@ include file="/includes/header.jsp" %>Then I get the "/include/header.jsp" not found. However, if I change to
    <jsp:include page="/includes/header.jsp" />It works fine. Now, I want to use an absolute path and I also want to use the include directive. Has anybody seen this problem and know a solution?
    Thanks,
    Mike

    Hi All,
    Pls. help
    I have deployed my application on Sun Appln server 9.0. When I try to lauch the application it gives following error.
    [#|2007-11-06T17:31:16.451+0530|SEVERE|sun-appserver-pe9.0|javax.enterprise.system.container.web|_Th
    readID=13;_ThreadName=httpWorkerThread-8080-0;_RequestID=076de172-4f31-4f76-888d-a19cc736c3ee;|Stand
    ardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception
    java.lang.NoClassDefFoundError: javax/servlet/jsp/tagext/TagExtraInfo
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
    at com.sun.appserv.server.util.ASURLClassLoader.loadClass(ASURLClassLoader.java:100)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
    at com.sun.enterprise.util.ConnectorClassLoader.loadClass(ConnectorClassLoader.java:176)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1405)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1292)
    at org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryInfoImpl.java:478)
    at org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.java:298)
    at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:176)
    at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:445)
    at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:513)
    at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1579)
    at org.apache.jasper.compiler.Parser.parse(Parser.java:151)
    at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:212)
    at org.apache.jasper.compiler.ParserController.parse(ParserController.java:129)
    at org.apache.jasper.compiler.Parser.processIncludeDirective(Parser.java:360)
    at org.apache.jasper.compiler.Parser.parseIncludeDirective(Parser.java:397)
    at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:505)
    at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1579)
    at org.apache.jasper.compiler.Parser.parse(Parser.java:151)
    at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:212)
    at org.apache.jasper.compiler.ParserController.parse(ParserController.java:113)
    at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:224)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:526)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:507)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:495)
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:530)
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:412)
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:318)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.jav
    a:397)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
    ava:303)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
    at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
    ava:216)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
    at com.fdu.mdsgui.web.filter.LocaleFilter.doFilter(LocaleFilter.java:58)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
    ava:216)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
    at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:188)
    at com.fdu.mdsgui.web.filter.MDSSecurityFilter.doFilter(MDSSecurityFilter.java:57)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
    ava:216)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:276)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
    at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:24
    0)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
    at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
    at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
    at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
    at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:239)
    at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:6
    67)
    at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.ja
    va:574)
    at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
    at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
    at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
    at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
    at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
    |#]

  • Error in precompiling JSPs using OJSPC

    Hi,
    I am precompiling JSPs in war file using ojspc as specified below.
         ojspc -output myapp.war app.war
    However I am getting following error:
    Detected archive, now processing contents of app.war...
    Setting up temp area...
    Expanding archive in temp area...
    WARNING: IGNORED file: /WEB-INF/lib/jsf-impl.jar
    WARNING: IGNORED file: /WEB-INF/lib/jsf-ri.jar
    Parse error in AddNewAttachment.jsp:
    oracle.jsp.parse.JspParseException: /AddNewAttachment.jsp: Line # 48,
    actionListener="#{addAttachmentBackingBean.cancel}"/>
    Error: A String literal value, "#{addAttachmentBackingBean.cancel}", has been pr
    ovided for attribute actionListener which has an associated deferred method with
    void signature
    Removing temp area...
    Can anbody help me to solve this problem?
    Thanks.
    Regards,
    Umesh

    Hi,
    If I create a method via the binding editor in JDev it creates a managed bean method with a void return type as default.
    eg.
        public void cmdlink_actionListener(ActionEvent actionEvent) {
            // Add event code here...
        }could it have anything to do with the two OJSPC warnings? jsf-impl.jar should be included in your war file. I haven't seen this warning when OJSPC is compiling.
    Brenden

  • Precompiling JSPs Outside Weblogic Home Directory

    Using Weblogic Server 9.2. Was able to precompile JSPs in a war file with weblogic.appc at the command line with only the weblogic.jar inside the Weblogic installation directory in my classpath. I then translated this into an Ant task, and because the script may need to run on a box that does not have Weblogic installed, copied weblogic.jar to my build area and included that one in my classpath. It immediately began throwing NoClassDefFound exceptions. Discovered the "Class-Path" list of additional jars in the MANIFEST inside weblogic.jar, searched these jars and found all of the missing classes--except for the last one. The missing class is org/apache/bcelx/classfile/ClassParser, and the error I'm getting is "WARNING: unable to get an input stream for jar:file:D:\APPS\Java\jdk1.5.0_13\jre\lib\rt.jar!" followed by java.lang.NoClassDefFoundError. The error occurs in javelin.java.JavaClassFile.getParseTree() at line 178. There is a BCEL Apache project, but they have no mention of BCELX on their website. Anyone know where I can find this class, or source code for javelin.java.JavaClassFile?
    Edited by willhandley at 06/06/2008 10:25 AM

    I tried the wlappc target:
    <target name="_precompile-jsp">
         <taskdef name="wlappc" classname="weblogic.ant.taskdefs.j2ee.Appc" classpathref="class.path" />
         <echo message="Precompiling JSPs in ${appfile}"/>
              <wlappc source="${appfile}" debug="true" verbosejavac="true" verbose="true" runtimeflags="-J-ms1024m -J-mx2048m"/>
    </target>
    But I keep getting:
    [java] [wlappc] java.lang.OutOfMemoryError: Java heap space
    We've got quite a lot of jsps in our application. It seems the memory options are being ignored and it seems other people have experienced the same problem with the memory options being ignored when using wlappc and have switched to weblogic.appc.
    When I switch to weblogic.appc I don't get the out of memory issue, though of course I'm still getting the initial stack trace reported. Any other ideas?

  • Re: Precompiling JSP with admin/managed servers

    Thanks, but I'm not doing any copying.
              The admin/managed-server communication copies things to the managed server,
              which then always recompiles the pages when hit.
              -Greg
              Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              "Robert Coonrad" <[email protected]> wrote in message
              news:[email protected]...
              >
              > check out post 8366...i found that i was not preserving
              > the lastmodified date on my jsps and this was causing
              > unnecessary re-compilation.
              >
              > hope it helps...
              > bobc
              >
              > "Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote:
              > >I believe I have exhausted all permutations of EARing/notEARing,
              > >WARing/notWARing, placing precompiled jsp class files in WEB-INF/classes,
              > >placing them in a static location and setting workingDir to that
              location,
              > >combinations of the above.
              > >
              > >No matter what, the managed server re-compiles pages the first time they
              > >are
              > >hit. Non admin/managed-server I have no problems.
              > >
              > >Can anyone from BEA comment on this problem? Or give me a workaround
              > >for
              > >getting a cluster working with precompiled jsps?
              > >
              > >-Greg
              > >
              > >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              > >news:[email protected]...
              > >> Grrr... The JSP engine is extremely frustrating! I've spent many hours
              > >> fighting the "staleness" checker in WL. I've been through all of the
              > >> newsgroup messages pertaining to pre-compiling, etc., and I've gotten
              > >> pre-compilation working on single-server deployments, but admin/managed
              > >> server deployments have me beat.
              > >>
              > >> WL6.1, SP1, Solaris
              > >>
              > >> I've done the pageCheckSeconds=-1 and the workingDir is set to a fixed
              > >> place. The fixed place contains pre-compiled versions of all jsps
              > >made on
              > >> that machine using jspc not 20 minutes earlier using the JSP files
              > >in the
              > >> exploded EAR file used by the admin server as the model for managed
              > >> servers.. The managed servers are on the same machine.
              > >>
              > >> When the admin server gives an application to a managed server, the
              > >managed
              > >> server creates a temporary directory containing all of the webapp
              > >> components, etc. The file timestamps on these files is the set by
              > >the
              > >> copying process to the time of the managed server boot (why?!?!????!?),
              > >so
              > >> the staleness check always thinks they are new and could care less
              > >what
              > >> precompiled jsps I have in my workingDir, the WEB-INF/classes
              directory,
              > >or
              > >> anywhere else. The pageCheckSeconds=-1 seems to be completely ignored
              > >in
              > >> this scenario.
              > >>
              > >> If I tell the managed server to precompile everything on boot (about
              > >45
              > >> minutes for this app) it will create versions of the classes that match
              > >th
              > >e
              > >> new JSP file timestamps, but this does not even survive a reboot of
              > >the
              > >> managed server because it AGAIN creates a new temp version of
              everything
              > >on
              > >> the next reboot with new timestamps.
              > >>
              > >> If I wait for the managed server to boot and find the directory like
              > >> .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically
              > >copy
              > >> (via cp -pr to retain timestamps) all of the original webapp components
              > >on
              > >> top of the temp versions, the staleness checker is happy and the
              > >> pre-compiled versions work fine.
              > >>
              > >> There HAS to be a way to package pre-compiled versions of the JSPs
              > >in the
              > >> "model" application in the admin server and keep from having to
              precompile
              > >> the JSPs on every managed server every time managed server is booted..
              > >>
              > >> It would help if we had a way to bypass the staleness checking
              > >completely..
              > >> Or you guys should make the timestamps on the files copied by the
              > >> admin/managed deployment process match properly so the staleness
              checker
              > >> doesn't think the JSP is different.
              > >>
              > >> It would also help if the engineer who wrote this could explain the
              > >rules
              > >> being implemented by the staleness checker. So far all the messages
              > >in
              > >the
              > >> newsgroup have amounted to point solutions for problems without a good
              > >> understanding of what the engine is checking for and/or doing under
              > >the
              > >> covers. Looking at the generated .java files for the JSP pages helps,
              > >but
              > >> it is not good enough...
              > >>
              > >> Anyone out there have a working admin/managed server JSP application?
              > >> -Greg
              > >>
              > >> -----------------------------------------------------------
              > >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              > >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              > >>
              > >>
              > >>
              > >
              > >
              >
              

    The admin/managed-server communication copies things to the managed server, which then always recompiles the pages when hit.
              This is a known issue and is fixed. The timestamps of the compiled classes was not being preserved when extracted from the war file used to distribute to the managed servers. This will be available in WLS6.1 Service Pack 3 - and there is a temporary patch available for SP2. Please ask your friendly BEA support person for it (you can refer to CR058946)
              I'd give you the patch myself, but they like to keep track of these things...
              Regards,
              Alex
              "Girish" <[email protected]> wrote in message news:[email protected]...
              >
              > "Aditya Kiran Gavvala" <[email protected]> wrote:
              > >Greg,
              > >
              > >I have been following your posts, because our application deployment
              > >ran
              > >into exact same problem you ran into. I had spent a full two days
              > >researching into the problem. And I figured the solution. Hope this
              > >helps.
              > >
              > >Here are my discoveries:
              > >
              > >The following applies only to the following environment:
              > >OS: Linux (perhaps for Win/Unix/Solaris etc)
              > >WLS 6.0 SP2 ( no rolling patches): I found Rolling Patch2 (RP2) not useful
              > >for this problem.
              > >Clustered environment with Admin/Managed servers
              > >
              > >- When you compile JSP using weblogic.jspc compiler it puts the JSP file
              > >timestamp into the compiled class. You can see it in the generated java
              > >file
              > >(you need to supply -keepgenerated switch to jspc)
              > >
              > >- When a request is made to a JSP page after the application is deployed,
              > >it
              > >seems to be retrieving this timestamp from the compiled class file and
              > >comparing it with the JSP file timestamp. If they dont match a compile
              > >command gets run by the server. Thereby you see a compile happening at
              > >run
              > >time.
              > >
              > >- If you have exploded directory deployment, when you start the managed
              > >servers they create a ".war" file (under some temp dir) with all the
              > >JSP
              > >source files going into the file. You can notice this by looking into
              > >the
              > >server log file. Therefore all JSP source files get a brand new timestamp
              > >in
              > >the archive (a timestamp later than what was put class files by
              > >weblogic.jspc). So, the server at run time sees that the timestamp in
              > >the
              > >class file is older than the JSP source file and runs a recompile. So
              > >DONT
              > >DO EXPLODED directory deployment if your environment is as described
              > >in this
              > >post.
              > >
              > >- If you have ".war" file deployment, you will not have a problem. At
              > >the
              > >start up time managed server still creates "".war" file under a temp
              > >directory however it seems to be copying the content of the your ".war"
              > >file. So, the timestamps of JSP remain the same as they were before.
              > >SO NO
              > >RE-COMPILATION.
              > >
              > >- Another important thing to remember is to make sure you specify the
              > >workingDir in the weblogic.xml file. That is where the precompiled class
              > >files should reside. This should be any directory the server uses as
              > >scratch
              > >pad to compile classes or find (pre)compiled classes. This is not a
              > >directory inside your .war file is what I am trying to get at.
              > >
              > >Hope this helps,
              > >Aditya
              > >
              > >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              > >news:[email protected]...
              > >> Thanks, but I'm not doing any copying.
              > >>
              > >> The admin/managed-server communication copies things to the managed
              > >server,
              > >> which then always recompiles the pages when hit.
              > >>
              > >> -Greg
              > >>
              > >> -----------------------------------------------------------
              > >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              > >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              > >>
              > >> "Robert Coonrad" <[email protected]> wrote in message
              > >> news:[email protected]...
              > >> >
              > >> > check out post 8366...i found that i was not preserving
              > >> > the lastmodified date on my jsps and this was causing
              > >> > unnecessary re-compilation.
              > >> >
              > >> > hope it helps...
              > >> > bobc
              > >> >
              > >> > "Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote:
              > >> > >I believe I have exhausted all permutations of EARing/notEARing,
              > >> > >WARing/notWARing, placing precompiled jsp class files in
              > >WEB-INF/classes,
              > >> > >placing them in a static location and setting workingDir to that
              > >> location,
              > >> > >combinations of the above.
              > >> > >
              > >> > >No matter what, the managed server re-compiles pages the first time
              > >they
              > >> > >are
              > >> > >hit. Non admin/managed-server I have no problems.
              > >> > >
              > >> > >Can anyone from BEA comment on this problem? Or give me a workaround
              > >> > >for
              > >> > >getting a cluster working with precompiled jsps?
              > >> > >
              > >> > >-Greg
              > >> > >
              > >> > >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              > >> > >news:[email protected]...
              > >> > >> Grrr... The JSP engine is extremely frustrating! I've spent many
              > >hours
              > >> > >> fighting the "staleness" checker in WL. I've been through all
              > >of the
              > >> > >> newsgroup messages pertaining to pre-compiling, etc., and I've
              > >gotten
              > >> > >> pre-compilation working on single-server deployments, but
              > >admin/managed
              > >> > >> server deployments have me beat.
              > >> > >>
              > >> > >> WL6.1, SP1, Solaris
              > >> > >>
              > >> > >> I've done the pageCheckSeconds=-1 and the workingDir is set to
              > >a
              > >fixed
              > >> > >> place. The fixed place contains pre-compiled versions of all
              > >jsps
              > >> > >made on
              > >> > >> that machine using jspc not 20 minutes earlier using the JSP files
              > >> > >in the
              > >> > >> exploded EAR file used by the admin server as the model for managed
              > >> > >> servers.. The managed servers are on the same machine.
              > >> > >>
              > >> > >> When the admin server gives an application to a managed server,
              > >the
              > >> > >managed
              > >> > >> server creates a temporary directory containing all of the webapp
              > >> > >> components, etc. The file timestamps on these files is the set
              > >by
              > >> > >the
              > >> > >> copying process to the time of the managed server boot
              > >(why?!?!????!?),
              > >> > >so
              > >> > >> the staleness check always thinks they are new and could care
              > >less
              > >> > >what
              > >> > >> precompiled jsps I have in my workingDir, the WEB-INF/classes
              > >> directory,
              > >> > >or
              > >> > >> anywhere else. The pageCheckSeconds=-1 seems to be completely
              > >ignored
              > >> > >in
              > >> > >> this scenario.
              > >> > >>
              > >> > >> If I tell the managed server to precompile everything on boot
              > >(about
              > >> > >45
              > >> > >> minutes for this app) it will create versions of the classes that
              > >match
              > >> > >th
              > >> > >e
              > >> > >> new JSP file timestamps, but this does not even survive a reboot
              > >of
              > >> > >the
              > >> > >> managed server because it AGAIN creates a new temp version of
              > >> everything
              > >> > >on
              > >> > >> the next reboot with new timestamps.
              > >> > >>
              > >> > >> If I wait for the managed server to boot and find the directory
              > >like
              > >> > >> .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically
              > >> > >copy
              > >> > >> (via cp -pr to retain timestamps) all of the original webapp
              > >components
              > >> > >on
              > >> > >> top of the temp versions, the staleness checker is happy and the
              > >> > >> pre-compiled versions work fine.
              > >> > >>
              > >> > >> There HAS to be a way to package pre-compiled versions of the
              > >JSPs
              > >> > >in the
              > >> > >> "model" application in the admin server and keep from having to
              > >> precompile
              > >> > >> the JSPs on every managed server every time managed server is
              > >booted..
              > >> > >>
              > >> > >> It would help if we had a way to bypass the staleness checking
              > >> > >completely..
              > >> > >> Or you guys should make the timestamps on the files copied by
              > >the
              > >> > >> admin/managed deployment process match properly so the staleness
              > >> checker
              > >> > >> doesn't think the JSP is different.
              > >> > >>
              > >> > >> It would also help if the engineer who wrote this could explain
              > >the
              > >> > >rules
              > >> > >> being implemented by the staleness checker. So far all the messages
              > >> > >in
              > >> > >the
              > >> > >> newsgroup have amounted to point solutions for problems without
              > >a
              > >good
              > >> > >> understanding of what the engine is checking for and/or doing
              > >under
              > >> > >the
              > >> > >> covers. Looking at the generated .java files for the JSP pages
              > >helps,
              > >> > >but
              > >> > >> it is not good enough...
              > >> > >>
              > >> > >> Anyone out there have a working admin/managed server JSP application?
              > >> > >> -Greg
              > >> > >>
              > >> > >> -----------------------------------------------------------
              > >> > >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              > >> > >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              > >> > >>
              > >> > >>
              > >> > >>
              > >> > >
              > >> > >
              > >> >
              > >>
              > >>
              > >
              > >
              >
              [att1.html]
              

  • Precompiling JSP with admin/managed servers

    Grrr... The JSP engine is extremely frustrating! I've spent many hours
              fighting the "staleness" checker in WL. I've been through all of the
              newsgroup messages pertaining to pre-compiling, etc., and I've gotten
              pre-compilation working on single-server deployments, but admin/managed
              server deployments have me beat.
              WL6.1, SP1, Solaris
              I've done the pageCheckSeconds=-1 and the workingDir is set to a fixed
              place. The fixed place contains pre-compiled versions of all jsps made on
              that machine using jspc not 20 minutes earlier using the JSP files in the
              exploded EAR file used by the admin server as the model for managed
              servers.. The managed servers are on the same machine.
              When the admin server gives an application to a managed server, the managed
              server creates a temporary directory containing all of the webapp
              components, etc. The file timestamps on these files is the set by the
              copying process to the time of the managed server boot (why?!?!????!?), so
              the staleness check always thinks they are new and could care less what
              precompiled jsps I have in my workingDir, the WEB-INF/classes directory, or
              anywhere else. The pageCheckSeconds=-1 seems to be completely ignored in
              this scenario.
              If I tell the managed server to precompile everything on boot (about 45
              minutes for this app) it will create versions of the classes that match the
              new JSP file timestamps, but this does not even survive a reboot of the
              managed server because it AGAIN creates a new temp version of everything on
              the next reboot with new timestamps.
              If I wait for the managed server to boot and find the directory like
              .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically copy
              (via cp -pr to retain timestamps) all of the original webapp components on
              top of the temp versions, the staleness checker is happy and the
              pre-compiled versions work fine.
              There HAS to be a way to package pre-compiled versions of the JSPs in the
              "model" application in the admin server and keep from having to precompile
              the JSPs on every managed server every time managed server is booted..
              It would help if we had a way to bypass the staleness checking completely..
              Or you guys should make the timestamps on the files copied by the
              admin/managed deployment process match properly so the staleness checker
              doesn't think the JSP is different.
              It would also help if the engineer who wrote this could explain the rules
              being implemented by the staleness checker. So far all the messages in the
              newsgroup have amounted to point solutions for problems without a good
              understanding of what the engine is checking for and/or doing under the
              covers. Looking at the generated .java files for the JSP pages helps, but
              it is not good enough...
              Anyone out there have a working admin/managed server JSP application?
              -Greg
              Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              

              check out post 8366...i found that i was not preserving
              the lastmodified date on my jsps and this was causing
              unnecessary re-compilation.
              hope it helps...
              bobc
              "Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote:
              >I believe I have exhausted all permutations of EARing/notEARing,
              >WARing/notWARing, placing precompiled jsp class files in WEB-INF/classes,
              >placing them in a static location and setting workingDir to that location,
              >combinations of the above.
              >
              >No matter what, the managed server re-compiles pages the first time they
              >are
              >hit. Non admin/managed-server I have no problems.
              >
              >Can anyone from BEA comment on this problem? Or give me a workaround
              >for
              >getting a cluster working with precompiled jsps?
              >
              >-Greg
              >
              >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              >news:[email protected]...
              >> Grrr... The JSP engine is extremely frustrating! I've spent many hours
              >> fighting the "staleness" checker in WL. I've been through all of the
              >> newsgroup messages pertaining to pre-compiling, etc., and I've gotten
              >> pre-compilation working on single-server deployments, but admin/managed
              >> server deployments have me beat.
              >>
              >> WL6.1, SP1, Solaris
              >>
              >> I've done the pageCheckSeconds=-1 and the workingDir is set to a fixed
              >> place. The fixed place contains pre-compiled versions of all jsps
              >made on
              >> that machine using jspc not 20 minutes earlier using the JSP files
              >in the
              >> exploded EAR file used by the admin server as the model for managed
              >> servers.. The managed servers are on the same machine.
              >>
              >> When the admin server gives an application to a managed server, the
              >managed
              >> server creates a temporary directory containing all of the webapp
              >> components, etc. The file timestamps on these files is the set by
              >the
              >> copying process to the time of the managed server boot (why?!?!????!?),
              >so
              >> the staleness check always thinks they are new and could care less
              >what
              >> precompiled jsps I have in my workingDir, the WEB-INF/classes directory,
              >or
              >> anywhere else. The pageCheckSeconds=-1 seems to be completely ignored
              >in
              >> this scenario.
              >>
              >> If I tell the managed server to precompile everything on boot (about
              >45
              >> minutes for this app) it will create versions of the classes that match
              >th
              >e
              >> new JSP file timestamps, but this does not even survive a reboot of
              >the
              >> managed server because it AGAIN creates a new temp version of everything
              >on
              >> the next reboot with new timestamps.
              >>
              >> If I wait for the managed server to boot and find the directory like
              >> .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically
              >copy
              >> (via cp -pr to retain timestamps) all of the original webapp components
              >on
              >> top of the temp versions, the staleness checker is happy and the
              >> pre-compiled versions work fine.
              >>
              >> There HAS to be a way to package pre-compiled versions of the JSPs
              >in the
              >> "model" application in the admin server and keep from having to precompile
              >> the JSPs on every managed server every time managed server is booted..
              >>
              >> It would help if we had a way to bypass the staleness checking
              >completely..
              >> Or you guys should make the timestamps on the files copied by the
              >> admin/managed deployment process match properly so the staleness checker
              >> doesn't think the JSP is different.
              >>
              >> It would also help if the engineer who wrote this could explain the
              >rules
              >> being implemented by the staleness checker. So far all the messages
              >in
              >the
              >> newsgroup have amounted to point solutions for problems without a good
              >> understanding of what the engine is checking for and/or doing under
              >the
              >> covers. Looking at the generated .java files for the JSP pages helps,
              >but
              >> it is not good enough...
              >>
              >> Anyone out there have a working admin/managed server JSP application?
              >> -Greg
              >>
              >> -----------------------------------------------------------
              >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              >>
              >>
              >>
              >
              >
              

  • Tomcat 4.0 Precompile JSP - Help!

    I wish to create an Ant script to precompile my JSP as the project I'm working on is being reworked so objects are changing and JSP needs to be updated accordingly. At the moment we have to navigate the site to find any effects of changing an object - so we may not get a page compilation error for some time.
    Can anyone point me in the right direction to find help on compiling my JSP. I don't even know where to start. I cannot find anything on the Jakarta site ... Help!!!

    I've never tried it, but Ant does have an optional task called JspC to precompile JSP pages...
    http://jakarta.apache.org/ant/manual/OptionalTasks/jspc.html

  • Precompile JSPs before deployment

    Does anyone have a working sample of precompiled JSPs distributed inside an EAR for deployment on an Oracle 10g app server?
    I'm almost convinced it's impossible. Please prove me wrong.

    I am glad to know that ojspc is indeed getting better.
    Right, some ant file types can be helpful to provide list of files as argument to java command. Nice try!
    For a while, I was down the road of using the batch mode against the ear but that is a
    mess because it puts all the output in a "_pages" folder under the html root. I couldn't find
    a way to change that behavior.This was changed in the next release 10.1.3, where the generated classes are put into a jar inside WEB-INF/lib/. The only way to get around it in 10.1.2 is to extract the ear/war file so that you will get a hold on the generated classes. Then you can put them in WEB-INF/lib or WEB-INF/classes and re-wrap the ear/war file.
    It takes 8 minutes to compile 173 JSPs. I have an AMD 2200+ with 1GB RAM. You can use the "-verbose" option to feel how long each group of files got compiled. Does your jsp files have different encodings? Currently if a jsp file with each encoding is encountered, the java compiler used by ojspc will be recreated, which takes quite some time. Looking ahead, we are preparing to speed up the compile process by reusing the java compiler.
    I'm not sure why ojspc can't do the directory recursion by itself.I will see if directory recursion should be implemented. Other options are also considered, like a deploy time option to compile all jsp artifacts. Do you think that would be a better option?
    There also seems to be a bug in batch mode if ojspc is run from the Same directory as specified in the appRoot parameter.Can you give a bit more detail so that I can reproduce it? Thanks.
    Try it out. Overall, it wasn't a very intuitive experience. Thanks for your feedback. I believe your experience will be getting better with each release.

  • Can we precompile JSPs to avoid Weblogic Recompile JSPs

    We'll prevent Weblogic 10.3 to Recompile JSPs when deployment and running. So we precompile JSPs when build by weblogic.jspc and added staments below in weblogic.xml, but we failed, weblogic will recompile JSPs as before. Anybody can help me?
    <jsp-param>
    <param-name>precompile</param-name>
    <param-value>false</param-value>
    </jsp-param>
    <jsp-param>
    <param-name>pageCheckSeconds</param-name>
    <param-value>-1</param-value>
    </jsp-param>
    Comman in ANT build file is below:
    <java classname="weblogic.jspc" fork="yes" classpath="${esc2.classpath}">
                   <arg line="-webapp ${esc.buildwardir} -compileAll -compiler javac -d ${esc.buildwardir.classes} -k"/>
                   <arg line="-J-mx256m"/>
              </java>

    Hi,
    If the classes are still being recompiled then you are running different WLS versions - make sure you are compiling your classes using the same release & version as the one to which you are deploying
    You can have a look at the below URL for further information
    http://download-llnw.oracle.com/docs/cd/E13222_01/wls/docs81/jsp/reference.html

  • Cannot access precompiled JSP

    My application contains several JSP working correctly, but after I choose to precompile my JSP files (putting the compiled classes in classpath). The server return a 404 indicating cannot find the JSP pages.
    It seems like the
    RequestDispatcher dispatcher=request.getRequestDispatcher("xxx.jsp");
    can no longer find the JSP page anymore. What should I put there instead? Moreover, I will still use JSP for faster development and debugging purposes, can I write it so that the same code runs for both raw JSP pages and precompiled JSP?
    Any suggestion will be appreciated!

    Thanks for your info on the creation of web.xml fragment, it really helps. I am using Ant to precompile the JSP to deploy on Jetty.
    But, the webxml and webinc attribute just does not output any file as specified. However, when I tried it with the task like this:
    <java classname="org.apache.jasper.JspC" fork="true" failonerror="true">
    <arg line="-l -d ${web}/WEB-INF/work -webinc ${web}/jspc.xml -webapp ${web}"/>
    it seems to create the webinc, however, the JSPC just doesn't work as it says
    org.xml.sax.SAXException: Internal Error: File /javax/servlet/resources/web-app_2_3.dtd not found
    Now both ways seems unworkable, do you or anyone have any idea?

  • Precompiled JSP not taken in account by Weblogic 10.3.1

    Hi
    My JSPs are properly precompiled in my ear, and well taken in account by weblogic when I work with my local environment. But if I upload my ear on the Unix server, they're not taken in account anymore. Weblogic compiles them in real time, that causes a display time really long for each page.
    The precompiled JSP are present in the folder WEB-INF/classes/jsp_servlet/_jsp , inside the file app-web.war, itself included in the ear.
    Once the ear is deployed on the server, I find my precompiled JSP at 2 places :
    - <domain>/servers/<server>/tmp/_WL_user/<ear_name>/rdi76c/war/WEB-INF/lib/_wl_cls_gen.jar
    then in jsp_servlet/_jsp
    - <domain>/servers/<server>/tmp/_WL_user/<ear_name>/m8l8j8/app-web.war
    then in WEB-INF\classes\jsp_servlet\_jsp\
    At the execution time, Weblogic should be able to find the precompiled JSP at that 2 places. However, it recompiles the JSPs and places them here :
    - <domain>/servers/<server>/tmp/_WL_user/<ear_name>/rdi76c/jsp_servlet/_jsp
    I have already checked the dates. The dates written in the generated .java files match the system dates of the corresponding JSP files. It could have been an explanation, but it's not.
    Do you have any idea ?

    but encounter version mismatching error... It indicated that it only support 10.3.0... It's hard to tell based on your description, but I am going to guess that you are not selecting the right version of WLS runtime in the new runtime wizard. WLS 10.3.1 is also known as WLS 11gR1. Make sure that you look for it in Oracle rather than BEA category.
    - Konstantin

  • Problem creating JMS Error Destination via Ant in WLS 8.1

    We've got several JMS queues in our application. We create the server via Ant (using the wlconfig task).
    All is well, the queues have been working fine, until we try to add an error destination queue (after several attempts to handle the message, it'll be sent to the error queue for later troubleshooting).
    Here's an example of what we've got now:
    <create type="JMSQueue" name="batchQueue" property="jmsqueue">
        <set attribute="JNDIName" value="net.nike.cdm.batchQueue"/>
        <set attribute="RedeliveryLimit" value="5"/>
    </create>We create another queue to handle the errors, and then add an attribute to the first to point to the second:
    <create type="JMSQueue" name="batchErrorQueue" property="batchErrorQueue">
        <set attribute="JNDIName" value="net.nike.cdm.batchErrorQueue"/>
        <set attribute="RedeliveryLimit" value="5"/>
    </create>
    <create type="JMSQueue" name="batchQueue" property="jmsqueue">
        <set attribute="JNDIName" value="net.nike.cdm.batchQueue"/>
        <set attribute="RedeliveryLimit" value="5"/>
        <set attribute="ErrorDestination" value="${batchErrorQueue}"/>
    </create>This seems logical, because if we do this same exact operation via the console, the config.xml goes from this:
    <JMSQueue JNDIName="net.nike.cdm.batchQueue"
                Name="batchQueue" RedeliveryLimit="5"/>to this:
    <JMSQueue ErrorDestination="batchErrorQueue"
                JNDIName="net.nike.cdm.batchQueue"
                Name="batchQueue" RedeliveryLimit="5"/>
    <JMSQueue JNDIName="net.nike.cdm.batchErrorQueue" Name="batchErrorQueue"/>The error we get when trying to do this via Ant is:
    [wlconfig] A destination and its ErrorDestination must both be on the same JMS server. (The problematic destination is "batchQueue" on JMS server "cdmdomain"). Also, an ErrorDestination can not be null if the ExpirationPolicy for a destination is "redirect" and a destination can not specify itself as its ErrorDestination.Flipping on -verbose in Ant, the actual exception is:
    [wlconfig] SET -mbean cdmdomain:Name=batchQueue,Type=JMSQueue -property ErrorDestination cdmdomain:Name=batchErrorQueue,Type=JMSQue
    [wlconfig] A destination and its ErrorDestination must both be on the same JMS server. (The problematic destination is "batchQueue"
    s its ErrorDestination.
          [if] Error in class net.sf.antcontrib.logic.IfTask
    BUILD FAILED
    file:C:/viewstore/CDM_R6.5_Development/B2B_CDM/dev/build.xml:1399: Error invoking MBean command: java.lang.NullPointerException
           at weblogic.ant.taskdefs.management.WLConfig.handleException(WLConfig.java:567)
           at weblogic.ant.taskdefs.management.WLConfig.invokeCommand(WLConfig.java:381)
           at weblogic.ant.taskdefs.management.WLConfig.invokeSetCommand(WLConfig.java:235)
           at weblogic.ant.taskdefs.management.WLConfig.invokeCreateCommand(WLConfig.java:163)
           at weblogic.ant.taskdefs.management.WLConfig.executeCommands(WLConfig.java:106)
           at weblogic.ant.taskdefs.management.WLConfig.invokeCreateCommand(WLConfig.java:167)
           at weblogic.ant.taskdefs.management.WLConfig.executeCommands(WLConfig.java:106)
           at weblogic.ant.taskdefs.management.WLConfig.execute(WLConfig.java:89)
           at org.apache.tools.ant.Task.perform(Task.java:341)
           at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:117)
           at org.apache.tools.ant.Task.perform(Task.java:341)
           at net.sf.antcontrib.logic.IfTask.execute(Unknown Source)
           at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
           at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
           at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
           at java.lang.reflect.Method.invoke(Method.java:324)
           at org.apache.tools.ant.TaskAdapter.execute(TaskAdapter.java:147)
           at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:193)
           at org.apache.tools.ant.Task.perform(Task.java:341)
           at org.apache.tools.ant.Target.execute(Target.java:309)
           at org.apache.tools.ant.Target.performTasks(Target.java:336)
           at org.apache.tools.ant.Project.executeTarget(Project.java:1339)
           at org.apache.tools.ant.Project.executeTargets(Project.java:1255)
           at org.apache.tools.ant.Main.runBuild(Main.java:609)
           at org.apache.tools.ant.Main.start(Main.java:196)
           at org.apache.tools.ant.Main.main(Main.java:235)So, my question is, what are we doing wrong? What IS the syntax to set an error destination for a JMS queue via Ant for WLS 8.1?
    Any help would be greatly appreciated
    Thanks,
    Douglas Bullard

    I get exactly the same problem - was a resolution to this issue found?
    Thanks,
    Richard Marriott
    [email protected]

  • Precompiled JSP Compatibility Problem

    I am a developer in the Cross Applications Unlimited group. We are experiencing a problem with precompiled jsps in a ADF web application that we have developed. Any help that you can provide with this problem would be much appreciated. Neither Oracle forums nor the internet have yielded any leads to us so far. Here are the specifics of our problem.
    In our application, we precompile our JSPs when the EAR is built. The application was initially developed in JDeveloper 10.1.3.2 and worked without problems when deployed to OAS 10.1.3.2. However, our application server MTR recently shifted to OAS 10.1.3.3. We migrated our workspace and projects to JDeveloper 10.1.3.3 and rebuilt our EAR file in JDeveloper 10.1.3.3. We are getting "500 Internal Server Errors" when this new ear file is deployed to OAS 10.1.3.3. The error does not always manifest when running the application. We can login and navigate to JSPs linked directly from our navigation menu (our first level pages). However, in these first level pages are buttons that navigate to second level pages. The error is being seen whenever we try to access one of these second level pages. Everything else about the application works fine. When we don't precompile our JSPs and deploy, the application works fine.
    This is the error we find reported in our application logs...
    EWCoreViewController: Servlet error
    javax.faces.el.PropertyNotFoundException: Error testing property 'inputValue' in bean of type null
    at com.sun.faces.el.PropertyResolverImpl.isReadOnly(PropertyResolverImpl.java:274)
    at oracle.adfinternal.view.faces.model.FacesPropertyResolver.isReadOnly(FacesPropertyResolver.java:124)
    at com.sun.faces.el.impl.ArraySuffix.isReadOnly(ArraySuffix.java:236)
    at com.sun.faces.el.impl.ComplexValue.isReadOnly(ComplexValue.java:209)
    at com.sun.faces.el.ValueBindingImpl.isReadOnly(ValueBindingImpl.java:266)
    Enabling enhanced java logging yields these logs...
    <record>
    <date>2008-04-09T11:27:25</date>
    <millis>1207762045495</millis>
    <sequence>258943</sequence>
    <logger>com.sun.faces.application.ViewHandlerImpl</logger>
    <level>FINE</level>
    <class>com.sun.faces.application.ViewHandlerImpl</class>
    <method>renderView</method>
    <thread>14</thread>
    <message>Found no URL patterns mapping to FacesServlet </message>
    </record>
    <record>
    <date>2008-04-09T11:27:25</date>
    <millis>1207762045495</millis>
    <sequence>258944</sequence>
    <logger>com.sun.faces.taglib.jsf_core.ViewTag</logger>
    <level>FINE</level>
    <class>com.sun.faces.taglib.jsf_core.ViewTag</class>
    <method>doStartTag</method>
    <thread>14</thread>
    <message>Can't leverage base class</message>
    <exception>
    <message>java.lang.IllegalStateException</message>
    <frame>
    <class>com.sun.faces.taglib.jsf_core.ViewTag</class>
    <method>getComponentType</method>
    <line>253</line>
    </frame>
    Any information anyone can provide would be greatly appreciated.
    Thanks

    Hi Ian,
    Add this jar file to classpath...use either web interface or directly edit jvm12.conf to modify classpath..
    Raj

  • Spark Classes and Skins not being included when running FlexUnit task via Ant

    I have a series of unit tests that run on a spark component. This spark component has a custom skin defined for it, and that is working beautifully.
    Inside that component is a spark list... By default, after digging into the list code, spark lists should use a default skin called "BorderContainerSkin". When I run the application that uses this component directly (whether compiled via FlashBuilder or via Ant/Hudson), the component itself runs and looks exactly like I would expect. When I run my unit tests in the browser (via Run As Web Application command on my TestRunner), the unit tests all perform as expected.
    However, when I run the FlexUnit tests via Ant (either through windows non-headless, or linux headless), an exception is thrown with the following error:
    Error: Skin for FromToList132.FromToListSkin133.VGroup134.fromList cannot be found.
        at spark.components.supportClasses::SkinnableComponent/attachSkin()[E:\dev\4.x\frameworks\pr ojects\spark\src\spark\components\supportClasses\SkinnableComponent.as:632]
        at spark.components.supportClasses::SkinnableComponent/validateSkinChange()[E:\dev\4.x\frame works\projects\spark\src\spark\components\supportClasses\SkinnableComponent.as:405]
        at spark.components.supportClasses::SkinnableComponent/commitProperties()[E:\dev\4.x\framewo rks\projects\spark\src\spark\components\supportClasses\SkinnableComponent.as:419]
        at spark.components.supportClasses::ListBase/commitProperties()[E:\dev\4.x\frameworks\projec ts\spark\src\spark\components\supportClasses\ListBase.as:785]
        at spark.components::List/commitProperties()[E:\dev\4.x\frameworks\projects\spark\src\spark\ components\List.as:907]
        at mx.core::UIComponent/validateProperties()[E:\dev\4.x\frameworks\projects\framework\src\mx \core\UIComponent.as:7933]
        at mx.managers::LayoutManager/validateProperties()[E:\dev\4.x\frameworks\projects\framework\ src\mx\managers\LayoutManager.as:572]
        at mx.managers::LayoutManager/doPhasedInstantiation()[E:\dev\4.x\frameworks\projects\framewo rk\src\mx\managers\LayoutManager.as:730]
        at mx.managers::LayoutManager/doPhasedInstantiationCallback()[E:\dev\4.x\frameworks\projects \framework\src\mx\managers\LayoutManager.as:1072]
    (Note: fromList is the id of the spark list used in the FromToList component.)
    The issue is that the "BorderContainerSkin" class isn't ever getting imported along the way. I did several things that worked to "fix" the problem, but they are all hacky and don't explain the root problem:
    1- If I explicitly import that skin into my test file, then everything works great.
    2- If I add the <includes> directive into my mxmlc task in the Ant file, and again specifically call out that skin class, then again it will work.
    However, how would I know what skins from the spark library are going to get included and which aren't? How would I know that a default skin isn't included or where to find it or even what it is?
    It seems like either I'm missing something in my Ant file or there is a serious bug here with the FlexUnit task. Can anyone shed light on if this is a known issue, any permanent fixes (that don't involve keeping track of a long list of strings of class references), or anything that I might be missing?
    Thank you for any help!

    Guessing the ant tasks aren't forcing the include of the spark skins libraries... which is a little silly. I would assume the compiler would take care of this but it is something we can investigate...
    Not 100% sure as to why, but this is what it sounds like.
    Mike

Maybe you are looking for