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?

Similar Messages

  • Can't Trash Files Outside of Home Directory

    Hello
    I have a problem I can't seem to trash files/directories outside of my home directory even if I have rwx!... not sure when it started.  Here's an example of my issue.
    [jamie@simula vhosts]$ groups
    wheel video audio optical storage camera jamie sshusers www-data
    [jamie@simula vhosts]$ pwd
    /srv/http/vhosts
    [jamie@simula vhosts]$ ls -al
    total 12
    drwxrwxr-x 3 root www-data 4096 Aug 19 15:13 .
    drwxr-xr-x 3 root root 4096 Jun 4 20:03 ..
    drwxr-xr-x 5 jamie www-data 4096 Aug 4 21:58 doc.demurgatroid.net
    [jamie@simula vhosts]$ mkdir testdir
    [jamie@simula vhosts]$ ls -al
    total 16
    drwxrwxr-x 4 root www-data 4096 Aug 19 15:14 .
    drwxr-xr-x 3 root root 4096 Jun 4 20:03 ..
    drwxr-xr-x 5 jamie www-data 4096 Aug 4 21:58 doc.demurgatroid.net
    drwxr-xr-x 2 jamie jamie 4096 Aug 19 15:14 testdir
    [jamie@simula vhosts]$ gvfs-trash testdir
    Error trashing file: Unable to find or create trash directory
    But in my home directory (on the same partition mind you) I can trash a file (so it's obviously finding it this time)
    [jamie@simula testdir1]$ pwd
    /home/jamie/testdir1
    [jamie@simula testdir1]$ ls -al
    total 8
    drwxr-xr-x 2 jamie jamie 4096 Aug 19 15:16 .
    drwxr-xr-x 65 jamie jamie 4096 Aug 19 15:16 ..
    [jamie@simula testdir1]$ mkdir testdir2
    [jamie@simula testdir1]$ ls -al
    total 12
    drwxr-xr-x 3 jamie jamie 4096 Aug 19 15:16 .
    drwxr-xr-x 65 jamie jamie 4096 Aug 19 15:16 ..
    drwxr-xr-x 2 jamie jamie 4096 Aug 19 15:16 testdir2
    [jamie@simula testdir1]$ gvfs-trash testdir2/
    [jamie@simula testdir1]$ ls -al
    total 8
    drwxr-xr-x 2 jamie jamie 4096 Aug 19 15:16 .
    drwxr-xr-x 65 jamie jamie 4096 Aug 19 15:16 ..
    ...and it shows up in the trash as expected!  What is preventing me from being able to trash files from other locations?  I've tested from various locations in my filesystem and it seems only inside /home/jamie can I trash anything.  I haven't been able to find out much about the error (like where it's attempting to find/create a trash and why there) besides the obvious, li  Here's some more info
    * Using Gamin instead of FAM, didn't make any difference to my issue
    * Here's my partitions if it matters
    [jamie@simula vhosts]$ df -h
    Filesystem Size Used Avail Use% Mounted on
    udev 10M 260K 9.8M 3% /dev
    /dev/disk/by-uuid/7cf22373-9d30-4bbd-b178-9702efd1cd1f
    76G 3.6G 68G 5% /
    shm 1.9G 104K 1.9G 1% /dev/shm
    /dev/sda1 958M 15M 895M 2% /boot
    /dev/sda5 19G 1.3G 17G 7% /var
    /dev/sda6 197G 111G 77G 60% /home
    tmpfs 32M 0 32M 0% /home/jamie/ramdisk
    Thank you!
    Last edited by gojamiegirl (2010-08-19 23:16:29)

    I first noticed this doing html work in /srv/http/, I gave my user rwx and being able to delete files on the command line I assumed I'd also be able to right-click and 'Move to Trash' in Nautilus, nope.
    --> If I 'Move to Trash' from within my home directory it goes to ~/.local/share/Trash/
    --> If I 'Move to Trash' from anywhere else (even with permission) it fails because there is no .Trash-??? directory in that partition.
    It works if I manually create it.
    [jamie@simula ~]$ ls -al /home/jamie/.local/share/Trash/
    total 64
    drwx------ 5 jamie jamie 4096 May 28 16:23 .
    drwx------ 14 jamie jamie 4096 Jul 14 22:32 ..
    drwx------ 2 jamie jamie 4096 Aug 19 21:52 expunged
    drwx------ 2 jamie jamie 24576 Aug 19 21:52 files
    drwx------ 2 jamie jamie 24576 Aug 19 21:52 info
    [jamie@simula ~]$ ls /.Trash*
    ls: cannot access /.Trash*: No such file or directory
    [jamie@simula ~]$ gvfs-trash /testdir1/testdir2/
    Error trashing file: Unable to find or create trash directory
    [jamie@simula ~]$ sudo mkdir /.Trash-1000
    [jamie@simula ~]$ sudo chown jamie:jamie /.Trash-1000
    [jamie@simula ~]$ gvfs-trash /testdir1/testdir2/
    [jamie@simula ~]$ ls -al /.Trash-1000/files/
    total 12
    drwx------ 3 jamie jamie 4096 Aug 19 22:03 .
    drwxr-xr-x 4 jamie jamie 4096 Aug 19 22:03 ..
    drwxr-xr-x 2 jamie jamie 4096 Aug 19 21:57 testdir2
    This is solved
    Last edited by gojamiegirl (2010-08-20 05:24:05)

  • Precompiling JSPs using weblogic.jspc

    Hello,
    My question has more to do with getting the Weblogic precompiler to understand <%@ include file="myFilejsp" %> directives.
    Test scenario:
    In our application, we have used a common JSP page say 'commonJSP' as a header and have included 'commonJSP' in all our other JSP pages.
    Suppose my commonJSP is like this:
    <%
    String hello= "Hello";
    %>
    and suppose my index.jsp is like this
    <%@ include file="commonJSP" %>
    <%
    System.out.println(hello);
    %>
    Now when I serve index.jsp to clients it compiles correctly because the commonJSP is included in the source before compiling.
    HOWEVER, when precompiling the JSPs in my web application using the <java weblogic.jspc ..> tag in my ant build file, I am getting errors on compiling index.jsp that 'hello' cannot be resolved.
    When using the WebLogic JSP compiler, is there any way to tell the compiler to not treat JSP pages as individual 'servlet' classes but look at the 'big picture'?

    Anybody ?

  • Weblogic.ejbc wants weblogic.home sysproperty in ant - why

    I found that I had to add the following 'sysproperty' line to an ant target which
    runs weblogic.ejbc:
    <target name="ejbjar" depends="jar">
    <mkdir dir="${java.class.dir}/${package.dir}/tmp"/>
    <java classname="weblogic.ejbc" fork="true" failonerror="true">
    <sysproperty key="weblogic.home" value="c:/bea70/weblogic700/server"/>
    <classpath>
    <path refid="classpathWL"/>
    </classpath>
    <arg line="${java.class.dir}/${archive}.jar ${java.class.dir}/ejb-${archive}.jar"/>
    </java>
    </target>
    If the line is not there I get an error:
    [java] ERROR: Error from ejbc: error in finding weblogic.Home
    If the line is there and points to an invalid weblogic.home directory the error is:
    [java] ERROR: Error from ejbc: Installation file c:\temp\lib\persistence\persistence.install
    does not exist. Could not initialize EJB container managed persistence.
    However the file contains only one line:
    WebLogic_CMP_RDBMS.xml.
    Question: is there a way to specify this value directly to weblogic.ejbc without
    the look-up to the file? In my case I would like to do a build on a machine where
    weblogic is not installed (but of course weblogic.jar is available). It is trivial
    to add the file to the FS somewhere but why bother?

    here is my Ant target looks like...
    <property name="classpath" value="${lib.ext.dir}/j2ee12.jar;${lib.ext.dir}/weblogic.jar;${lib.ext.dir}/log4j-1.2.9.jar;${lib.ext.dir}/struts.jar;${dest.dir}/${ant.project.name}.jar"/>
    <target name="testjar">
    <javac srcdir="${src.dir}" destdir="${ejbc.dir}" classpath="${classpath}"/>
    <ejbjar srcdir="${dest.dir}" descriptordir="${desc.dir}" basejarname="test" classpath="${classpath}">
    <weblogic destdir="${lib.dir}" classpath="${classpath}" oldCMP="false"/>
    <include name="**/ejb-jar.xml" />
    <exclude name="**/weblogic*.xml" />
    <dtd publicid="-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" location="${lib.dir}/dtd/ejb20-jar.dtd"/>
    <dtd publicid="-//BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB//EN" location="${lib.dir}/dtd/weblogic-ejb-jar.dtd"/>
    </ejbjar>
    </target>
    I a not sure where to specify <sysproperty....>
    Please revert back if u know the answer.

  • Disabling indexing except home directory

    The indexing of spotlight takes so long, so I wanted to enable the indexing path only to the home directory. I edited the _rules.plist as below and ran the command.
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dt
    d">
    <plist version="1.0">
    <dict>
    <key>EXCLUDE</key>
    <array>/</array>
    <key>INCLUDE</key>
    <array>~/</array>
    <key>NOTE</key>
    <string>Specify paths to include or exclude, preceeding rules which target user-homes with ~/</strin
    g>
    </dict>
    </plist>
    % mdutil -i off /pathtovolume
    % mdutil -E /pathtovolume
    % mdutil -i on /pathtovolume
    The result was, excluding for every path under root path didn't seem to work. My assumption is that the path is not crawled recursively.
    My question is,
    1. Is there a way to write path to be crawled recursively?
    2. If there aren't a way to crawl recursively, do I have to write every path to exclude for doing such thing?
    PowerBook G4   Mac OS X (10.4.4)  

    Hi, K. O. Welcome to the Discussions.
    By default, Spotlight does not index much outside your Home directory, unless you have multiple users defined on your Mac, in which case it also indexes their Home directories and the other locations documented in "Mac OS X 10.4: Where does Spotlight search?".
    Since most of the data on your PowerBook (unless you also have external drives connected) resides in your Home directory, there's little you can do about this other than exclude (via Privacy) subdirectories of your Home directory that you do not want to search with Spotlight.
    Good luck!
    Dr. Smoke
    Author: Troubleshooting Mac® OS X

  • Error while deploying war file with jsp precompile option in weblogic 7.0

              Hi
              I am trying to precompile jsp file which is there in a war.Main jsp file code
              includes one more jsp which is there in other folder under defaultweb directory.
              While deploying the war i am getting the following error.Can any bosy help me
              in this regard
              <Nov 23, 2002 5:01:28 PM IST> <Error> <HTTP> <101045> <[ServletContext(id=464413
              3,name=ArkinTestWeb,context-path=/ArkinTestWeb-3)] translation of /Admin/account
              _access.jsp failed: weblogic.utils.ParsingException: nested TokenStreamException
              : antlr.TokenStreamException: Could not include ./../includes/sessionStatusPage.
              jsp>
              <Nov 23, 2002 5:01:28 PM IST> <Error> <Deployer> <149201> <The Slave Deployer
              fa
              iled to complete the deployment task with id 1 for the application ArkinTestWeb.
              weblogic.management.ApplicationException: Prepare failed. Task Id = 5
              Module Name: ArkinTestWeb, Error: Could not load ArkinTestWeb: weblogic.utils.Ne
              stedException: ArkinTestWeb:ArkinTestWeb Failure while Precompiling JSPs: weblog
              ic.utils.ParsingException: nested TokenStreamException: antlr.TokenStreamExcepti
              on: Could not include ./../includes/sessionStatusPage.jsp - with nested exceptio
              n:
              [weblogic.utils.ParsingException: nested TokenStreamException: antlr.TokenStream
              Exception: Could not include ./../includes/sessionStatusPage.jsp]
              at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
              er.java:657)
              at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
              er.java:548)
              at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(Sla
              veDeployer.java:1026)
              at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDep
              loyer.java:700)
              at weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHan
              dler.java:24)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
              >
              Regards
              Anand Mohan
              

    Hi,
    1] Remove following from server.xml
    <Context path="/SEA" docBase="SEA" debug="0"/>
    2] Paste SEA.WAR (test WAR file) into /webapps of TOMCAT
    3] Start Tomcat Server - This will create SEA folder under webapps
    4] Stop server.
    5] Add following to server.xml
    <Context path="/SEA" docBase="SEA" debug="0"/>
    6] Start Tomcat Server
    7] Access the URL.
    This will work. Somehow Tomcat does not extract war file contents which are mentioned in server.xml.
    I have Apache Tomcat 4.0.3 and faced this problem. The above solution works for it.
    Regards,
    Sandesh
    hi.
    I have put my SEA.WAR (test WAR file) into /webapps of
    TOMCAT.
    I checked the server.xml and put:
         <Context path="/SEA" docBase="SEA" debug="0"/>
    I restarted TOMCAT and tried to execute the file:
         http://localhost:8080/SEA/index.jsp
    But I got error message:
    Apache Tomcat/4.0.3 - HTTP Status 404 -
    /SEA/index.jsp
    What was happenning?
    Anyone can help me?
    Thank you.

  • Error while precompiling the JSP using weblogic 7.0

    Hi
    I am trying to precompile jsp file which is there in a war.Main jsp file code includes one more jsp which is there in other folder under defaultweb directory.
    While deploying the war i am getting the following error.Can any bosy help me in this regard
    <Nov 23, 2002 5:01:28 PM IST> <Error> <HTTP> <101045> <[ServletContext(id=464413
    3,name=ArkinTestWeb,context-path=/ArkinTestWeb-3)] translation of /Admin/account
    _access.jsp failed: weblogic.utils.ParsingException: nested TokenStreamException
    : antlr.TokenStreamException: Could not include ./../includes/sessionStatusPage.
    jsp>
    <Nov 23, 2002 5:01:28 PM IST> <Error> <Deployer> <149201> <The Slave Deployer fa
    iled to complete the deployment task with id 1 for the application ArkinTestWeb.
    weblogic.management.ApplicationException: Prepare failed. Task Id = 5
    Module Name: ArkinTestWeb, Error: Could not load ArkinTestWeb: weblogic.utils.Ne
    stedException: ArkinTestWeb:ArkinTestWeb Failure while Precompiling JSPs: weblog
    ic.utils.ParsingException: nested TokenStreamException: antlr.TokenStreamExcepti
    on: Could not include ./../includes/sessionStatusPage.jsp - with nested exceptio
    n:
    [weblogic.utils.ParsingException: nested TokenStreamException: antlr.TokenStream
    Exception: Could not include ./../includes/sessionStatusPage.jsp]
    at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:657)
    at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:548)
    at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(Sla
    veDeployer.java:1026)
    at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDep
    loyer.java:700)
    at weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHan
    dler.java:24)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
    >
    Regards
    Anand Mohan

    Hi
    All jsp pages are under one web application only.Can you help more on this.
    Regards
    Anand

  • Precompile JSP's in Weblogic 5.1/SP6

              Hello,
              How do you get the precomplilation of JSP's to work in 5.1? I have
              seen some emails on this mailing list about how to precompile the
              JSP's in 6.0 but I would like to know how to do it in 5.1. looking
              at the documentation here: http://www.weblogic.com/docs51/classdocs/API_jsp.html#register
              In the weblogic properties file we have them set as follows:
              weblogic.httpd.documentRoot=htdocs/
              # WEBLOGIC JSP PROPERTIES
              # Sets up automatic page compilation for JSP. Adjust init argsfor
              # directory locations and uncomment to use.
              weblogic.httpd.register.*.jsp=weblogic.servlet.JSPServlet
              weblogic.httpd.initArgs.*.jsp=\
              pageCheckSeconds=1,\
              keepgenerated=true,\
              compileCommand=d:/jdk1.2.2/bin/javac.exe,\
              workingDir=D:/Mediaprise/mpsite/WebLogicServer,\
              verbose=true
              that should be picking up any JSP's underneath the document root
              folder (htdocs, in this case) and precompile them to the working
              dir. now we have JSP's in the htdocs folder and a whole stucture
              of JSP's underneath the htdocs folder in a folder called JSP with
              it's own file and directory structure. The weblogic.log file shows
              that the above properties are being set correctly on startup but
              no precompilation seems to be happening to the working dir. any
              ideas on how to make this work in 5.1??
              I am working on Weblogic 5.1 with SP6.
              Thanks,
              Gagan
              

    In WebLogic 6.0 register each jsp in the web.xml with a <servlet-name>, <jsp-file>
              and <load-on-startup>. For example:
              <web-app>
              <servlet>
              <servlet-name></servlet-name>
              <jsp-file></jsp-file>
              <load-on-startup></load-on-startup>
              </servlet>
              <servlet-mapping>
              <servlet-name></servlet-name>
              <url-pattern></url-pattern>
              </servlet-mapping>
              </web-app>
              The optional value of load-on-startup element must be a positive integer indicating
              the order in which the servlet should be loaded.
              In WebLogic 6.1 set the precompile parameter in weblogic.xml.
              <jsp-descriptor>
              <jsp-param>
              <param-name>
              precompile
              </param-name>
              <param-value>
              true
              </param-value>
              </jsp-param>
              </jsp-descriptor>
              Vaibhav wrote:
              > This solution is with web.xml, if I am
              > using weblogic.properties only and no web.xml, How do I specify precompile=true ?
              

  • Precompiling JSPs changes directory name

    I am using the weblogic.appc compiler to precompile JSPs and I noticed that if my source folder name contains a hyphen, eg. my-test, after precompilation the class files are stored under \WEB-INF\classes\jsp_servlet\_my_45_test\ directory.
              The "-" in the name is substituted by its ASCII value. Is there a way to stop this from happening other than choosing a different name for the source folder?
              Thanks

    cranestar wrote:
    Oracle db versesion : 11g
    Apex version: 4.1.0.00.32
    I have created a file browse object on a page. After filling several text boxes and selecting a file the page writes a row into a table
    in the database.
    When a file is selected with the file browse the name looks like:
    C:\OracleApex\PDM-BOM comparison app\datafiles\B-15680-49_D_SAP.CSV
    However in the database the name appears as:
    F1531709975/B-15680-49_D_SAP.CSV
    What happened to the directory name? This causes problems because I need to use the directory and file name in a utl_file
    utility.<tt>F1531709975</tt> is produced to provide a unique file identifier in the <tt>apex_application_files</tt> view, and is the session state value of the file browse control that uploaded the file. The actual filename is available in the <tt>filename</tt> column.
    As has been noted in many previous threads on this topic: For security/privacy reasons recent versions of browsers by default do not send local file path information from File Browse items to the server, nor expose the file path in the control's JavaScript methods. Firefox, Safari and Chrome only provide the filename. IE6 & IE7 still yield the path in Windows format. IE8+ and Opera have adopted an irritating approach of replacing the path with a wholly imaginary "C:\fakepath\"&mdash;and this monstrosity has sadly had to be enshrined in the HTML5 spec...
    Changing IE's security config setting "Include local directory path when uploading files" enables the path to be exposed in IE, but unless you're working in an intranet environment where: IE is the only browser used; it's possible to make remote changes to this setting on every desktop; and this won't break/expose anything else, then trying to achieve this is pointless.
    For more information see:
    http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018980.html
    http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx
    http://developers.whatwg.org/number-state.html#file-upload-state

  • Re: Precompile JSP's in Weblogic 5.1/SP6

              http://www.weblogic.com/docs51/classdocs/webappguide.html
              Search for pre-compile on this page.
              Mike
              "Gagan Bhalla" <[email protected]> wrote:
              >
              >Hello,
              >How do you get the precomplilation of JSP's to work in
              >5.1? I have
              >seen some emails on this mailing list about how to precompile
              >the
              >JSP's in 6.0 but I would like to know how to do it in
              >5.1. looking
              >at the documentation here: http://www.weblogic.com/docs51/classdocs/API_jsp.html#register
              >
              >In the weblogic properties file we have them set as follows:
              >
              >weblogic.httpd.documentRoot=htdocs/
              ># # # # # # # # # # # # # # # # # # # # # # # # # # #
              ># # # # #
              ># #
              ># WEBLOGIC JSP PROPERTIES
              ># ------------------------------------------------
              ># Sets up automatic page compilation for JSP. Adjust init
              >argsfor
              ># directory locations and uncomment to use.
              >weblogic.httpd.register.*.jsp=weblogic.servlet.JSPServlet
              >weblogic.httpd.initArgs.*.jsp=\
              > pageCheckSeconds=1,\
              > keepgenerated=true,\
              > compileCommand=d:/jdk1.2.2/bin/javac.exe,\
              > workingDir=D:/Mediaprise/mpsite/WebLogicServer,\
              > verbose=true
              >
              >that should be picking up any JSP's underneath the document
              >root
              >folder (htdocs, in this case) and precompile them to the
              >working
              >dir. now we have JSP's in the htdocs folder and a whole
              >stucture
              >of JSP's underneath the htdocs folder in a folder called
              >JSP with
              >it's own file and directory structure. The weblogic.log
              >file shows
              >that the above properties are being set correctly on startup
              >but
              >no precompilation seems to be happening to the working
              >dir. any
              >ideas on how to make this work in 5.1??
              >I am working on Weblogic 5.1 with SP6.
              >Thanks,
              >Gagan
              

    In WebLogic 6.0 register each jsp in the web.xml with a <servlet-name>, <jsp-file>
              and <load-on-startup>. For example:
              <web-app>
              <servlet>
              <servlet-name></servlet-name>
              <jsp-file></jsp-file>
              <load-on-startup></load-on-startup>
              </servlet>
              <servlet-mapping>
              <servlet-name></servlet-name>
              <url-pattern></url-pattern>
              </servlet-mapping>
              </web-app>
              The optional value of load-on-startup element must be a positive integer indicating
              the order in which the servlet should be loaded.
              In WebLogic 6.1 set the precompile parameter in weblogic.xml.
              <jsp-descriptor>
              <jsp-param>
              <param-name>
              precompile
              </param-name>
              <param-value>
              true
              </param-value>
              </jsp-param>
              </jsp-descriptor>
              Vaibhav wrote:
              > This solution is with web.xml, if I am
              > using weblogic.properties only and no web.xml, How do I specify precompile=true ?
              

  • 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

  • Which is weblogic serevr home directory

    Hi All
    i installed weblogic 10.3 in my system.
    i am deploying ADF jdev10.1.3 application on weblogic server.
    while installing ADF runtime libraries it is asking for weblogic server home directory.
    i gave F:\bea .(which is Bea home directory)
    but the wizard is saying that is not a "weblogic server home directory".
    Can you help me which path we can call weblogic server home directory.

    The [JDev 10.1.3 Guide for Forms/4GL Programmers|http://download.oracle.com/docs/cd/B32110_01/web.1013/b25947/toc.htm] says here that WLS v8.1 SP1 and 9.0 are supported, not 10.3.
    This isn't to say it isn't technically possible to install a JDev 10.1.3 app on WLS, however the ADF Runtime Libraries feature in JDev 10.1.3 may not know how to identify previous versions of WLS.
    Hope this helps.
    CM.

  • 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

  • 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
              >>
              >>
              >>
              >
              >
              

Maybe you are looking for

  • Not able to display the output of O_store_rec object

    Hi Can any resolved my question. while compiling this pl/sql block i am getting error ora-6531 :reference to uninitialised collection. Declare O_error_message RTK_ERRORS.RTK_TEXT%TYPE; O_store_rec STORE_SQL.STORE_REC; I_message RIB_XSTOREDESC_REC; I_

  • Limiting notifications to only one mail account

    i have one inbox, in it i have mobileme and gmail, but i only want to see dock notifications for the mobileme account, whats the best way? thank you Max

  • Listing files on FMS server @ client

    Hi Everybody! I want to show list of FLV files placed on FMS server. do u guys have any sample code for that. Looking forward for reply! thanks.

  • Getting an error on my mac

    Hi guys! I just got my first mac.It's not new. This is macbook pro 15 So i get an error sometimes.I don't understand why.Sometimes it's very often. I copied details.Please help me Interval Since Last Panic Report:  47007 sec Panics Since Last Report:

  • Photoshop elements 9 screen flickers

    Hello, I have photoshop elements 9 on a desktop computer. Lately when working with photos, the window in editor shifts and jumps around. I have an intel i3 and 6gb ram I have a graphics cards (Nividia gt240). The photos that I work with have an avera