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

Similar Messages

  • Precompile JSPS problem

              When jsps are precompiled using weblogic server and during deployment it is giving
              java.lang.NullPointerException .
              I am precompiling jsps in this way (in web.xml)
              <context-param>
              <param-name>weblogic.jsp.precompile</param-name>
              <param-value>true</param-value>
              </context-param>
              I am deploying an ear in which i have an war.
              Please let me know if u have some info
              SubbaRao
              

              Hi Subba Rao,
              This problem will be resolved after installing rolling patch 2.
              So, Please install RP2.
              regards
              Sanjeev
              "SubbaRao Mandavilli" <[email protected]> wrote:
              >
              >When jsps are precompiled using weblogic server and during deployment
              >it is giving
              >java.lang.NullPointerException .
              >
              >I am precompiling jsps in this way (in web.xml)
              ><context-param>
              > <param-name>weblogic.jsp.precompile</param-name>
              > <param-value>true</param-value>
              > </context-param>
              >
              >I am deploying an ear in which i have an war.
              >
              >Please let me know if u have some info
              >
              >SubbaRao
              >
              

  • 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 Unexpected Signal : 11  JVM_IsInterface

              Hi,
              We have an weblogic 7.0 SP0 application running on solaris 7. As part of it startup
              in precompiles jsps - sometimes at different points weblogic crashes
              when we don't precompile the jsp's we never get this problem
              has any body seem it got a work around
              the message is
              Unexpected Signal : 11 occurred at PC=0xfe15b1c8
              Function name=JVM_IsInterface
              Library=/usr/j2sdk1_3_1_03/jre/lib/sparc/server/libjvm.so
              Current Java thread:
              Dynamic libraries:
              0x10000      /usr/j2sdk1_3_1_03/bin/../bin/sparc/native_threads/java
              0xff360000      /usr/lib/libthread.so.1
              0xff3a0000      /usr/lib/libdl.so.1
              0xff280000      /usr/lib/libc.so.1
              0xff270000      /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
              0xfe000000      /usr/j2sdk1_3_1_03/jre/lib/sparc/server/libjvm.so
              0xff210000      /usr/lib/libCrun.so.1
              0xff1f0000      /usr/lib/libsocket.so.1
              0xff100000      /usr/lib/libnsl.so.1
              0xff1c0000      /usr/lib/libm.so.1
              0xff240000      /usr/lib/libw.so.1
              0xff0e0000      /usr/lib/libmp.so.2
              0xff0a0000      /usr/j2sdk1_3_1_03/jre/lib/sparc/native_threads/libhpi.so
              0xff070000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libverify.so
              0xff030000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libjava.so
              0xfe7d0000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libzip.so
              0xfe650000      /usr/lib/nss_files.so.1
              0xfe540000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libnet.so
              0xfdee0000      /usr/lib/nss_nis.so.1
              0xfdec0000      /apps/wls70/weblogic/server/lib/solaris/libmuxer.so
              0xfdd50000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libioser12.so
              Local Time = Thu Sep 4 17:40:55 2003
              Elapsed Time = 288
              # HotSpot Virtual Machine Error : 11
              # Error ID : 4F530E43505002BD 01
              # Please report this error at
              # http://java.sun.com/cgi-bin/bugreport.cgi
              # Java VM: Java HotSpot(TM) Server VM (1.3.1_03-b03 mixed mode)
              Many thanks
              Malcolm Bridgeford
              

              See Sun's bug parade:
              http://developer.java.sun.com/developer/bugParade/bugs/4458653.html
              They fixed something in 1.3.1_04 that was causing errors similar to yours so you
              should probably try moving up to the _04 release.
              Also there are some know problems with older JVMs when JSPs get REALLY big through
              many custom tags, includes, etc. Breaks some internal 64K limit.. Might be related
              to that.
              -Greg
              Co-author of new advanced WebLogic book, "Mastering BEA WebLogic Server" http://www.amazon.com/exec/obidos/ASIN/047128128X
              "Malcolm Bridgeford" <[email protected]> wrote:
              >
              >Hi,
              >We have an weblogic 7.0 SP0 application running on solaris 7. As part
              >of it startup
              >in precompiles jsps - sometimes at different points weblogic crashes
              >
              >when we don't precompile the jsp's we never get this problem
              >
              >has any body seem it got a work around
              >
              >the message is
              >
              >Unexpected Signal : 11 occurred at PC=0xfe15b1c8
              >Function name=JVM_IsInterface
              >Library=/usr/j2sdk1_3_1_03/jre/lib/sparc/server/libjvm.so
              >
              >Current Java thread:
              >
              >Dynamic libraries:
              >0x10000      /usr/j2sdk1_3_1_03/bin/../bin/sparc/native_threads/java
              >0xff360000      /usr/lib/libthread.so.1
              >0xff3a0000      /usr/lib/libdl.so.1
              >0xff280000      /usr/lib/libc.so.1
              >0xff270000      /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
              >0xfe000000      /usr/j2sdk1_3_1_03/jre/lib/sparc/server/libjvm.so
              >0xff210000      /usr/lib/libCrun.so.1
              >0xff1f0000      /usr/lib/libsocket.so.1
              >0xff100000      /usr/lib/libnsl.so.1
              >0xff1c0000      /usr/lib/libm.so.1
              >0xff240000      /usr/lib/libw.so.1
              >0xff0e0000      /usr/lib/libmp.so.2
              >0xff0a0000      /usr/j2sdk1_3_1_03/jre/lib/sparc/native_threads/libhpi.so
              >0xff070000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libverify.so
              >0xff030000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libjava.so
              >0xfe7d0000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libzip.so
              >0xfe650000      /usr/lib/nss_files.so.1
              >0xfe540000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libnet.so
              >0xfdee0000      /usr/lib/nss_nis.so.1
              >0xfdec0000      /apps/wls70/weblogic/server/lib/solaris/libmuxer.so
              >0xfdd50000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libioser12.so
              >
              >Local Time = Thu Sep 4 17:40:55 2003
              >Elapsed Time = 288
              >#
              ># HotSpot Virtual Machine Error : 11
              ># Error ID : 4F530E43505002BD 01
              ># Please report this error at
              ># http://java.sun.com/cgi-bin/bugreport.cgi
              >#
              ># Java VM: Java HotSpot(TM) Server VM (1.3.1_03-b03 mixed mode)
              >#
              >
              >Many thanks
              >Malcolm Bridgeford
              >
              >
              >
              

  • 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

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

  • Precompile JSP for Application?

    Hi,
    i had been done the Examples in the NWDS(Help) and have some problems with them.
    It isnt possible for me to deploy the war package to my mi without precompiled JSPs.
    If i deploy them without precompiled JSPs i will get an exception like this:
    Error: 500
    Location: /TEST/initial.jsp
    Internal Servlet Error:
    javax.servlet.ServletException: sun/tools/javac/Main
    I use MI 25 SP16 and NWDS Version 2.0.16.
    Has anybody some ideas?
    Thanx
    Message was edited by: Tony Hennersdorf

    Hi,
    Doublecheck whether the environment variable JAVA_HOME is set, if not set it. Also check if path to jdk bin directory is added to the PATH variable of the user with which the j2ee engine is running.
    Also check for javac.exe in winnt\System32 or any winnt subdirectories (if engine is running on Windows) if it is present remove it.
    If all of above does not help, try changing the property of servlet_jsp service ExternalCompiler to the exact location of the javac executable on the system where the j2ee engine is running.
    I hope this helps.
    Myriana

  • Using precompiled JSPs on Sun ONE 6.1 SP5

    I"m using precompiled JSPs on Sun ONE 6.1 SP5. I have created a virtual server which has one web application deployed as the default web application located at <server-instance>/webapps/myapp. So in the server.xml it appears as :
    <webapp uri="/" path="<server-instnce/webapps/myapp"
    I have precompiled the JSPs using the jspc tool and created the directory containing the class files and have put them under WEB-INF/classes directory. I also generated the web.xml file with mappings for all jsps.
    My problem is that in my web.xml I have specified the <welcome-file> as index.jsp which used to reside under the <server-instance>/webapps/myapp directory. but now since i'm using precompiled versions i have physically removed that file. And now when i point my browser to the app's URL in the browser, i get the app's directory structure and only when i explicitly point my browser to https://<ip>:port/index.jsp then only the index.jsp page is invoked. I'm confused with this behavior. Do I need to change my docsroot directory to point to where the jsp class files are stored? I dont know what else can be going wrong...
    Any help appreciated :D
    Thanks

    Okkay i'll make my question easier.. if i'm using precompiled JSPs i.e. all compiled JSP files (.class files) including index.jsp is in the WEB-INF/classes directory then what is our docroot property supposed to be. Since if I give the document root as <server-instance>/webapps/myapp then it doesnt show the index.jsp that its supposed to when i point my browser to https://<host>:port. Only when I do https://<host>:port/index.jsp the index.jsp servlet is called and the index.jsp page is rendered.... I removed all the jsps physically from my apps folder but when I put only index.jsp there then it does work properly.... so any thoughts on this anyone...

  • Are There Compatability Problems Wtih Adobe Photoshop CS2 On The Windows Portion of iMac?

    I understand that there are compatability problems with CS2 and lower vesions of the creative suite in relation to Leoapard OSX. Are there any compatability problems with CS2 for Windows if I install it on the Windows (using XP) partition of an iMac that uses the Leopard OSX?
    Please advise. Thanks.

    If its not running in Leopard you should be fine.
    don't confuse running PowerPC software in Rosetta (PPC emulation) with running CS2 in XP which is native. It like apples and oranges. there is nothing in common.

  • Re: [iPlanet-JATO] sp3 jsp compiler problem

    Weiguo,
    First, Matt is correct, the regular expression tool is perfect for general text
    substitution situations, and as a completely independent tool its use is not
    restricted to migration situations (or file types for that matter).
    Second, I sympathize with the unfortunate trouble you are experiencing due to
    Jasper's (perhaps more strict) compilation, but in what way did the iMT
    automated translation contribute to these inconsistencies that you cited?
    1. Changed the case of the tag attribute to be the same as what's
    defined in tld.
    example: changed OnClick to onClick
    The iMT does not generate any OnClick or onClick clauses per se. In a
    translation situation, the only way "OnClick" would have been introduced was if
    it had been part of the pre-existing project's "extraHTML" (which was written
    by the original customer and just passed through unchanged by the iMT) or if it
    was added manually by the post-migration developer.
    2. Removed attributes which are not defined in tld.
    example: escape attribute only defined in three tags
    but in some pages, it's used although it's not defined as an
    attribute
    of certain tags. The jasper compiler doesn't like it.Can you give soem examples? Is there a definite pattern? Again, this might be
    similar to the OnClick situation described above?
    3. In an end tag, there can't be any space.
    example: </content > doesn't work. </content> works.
    Again, the content tag would never have been generated by the iMT. There was no
    equivalent in the NetDynamics world, so any content tags in your code must have
    been introduced by your developers manually. Its a shame that jasper is so
    particular, but the iMT could not help you out here even if we wanted to. The
    constants that are used by the iMT are defined in
    com.iplanet.moko.jsp.convert.JspConversionConstants. From what I can see, the
    only situation of a closing tag with any space in it is
    public static final String CLOSE_EMPTY_ELEMENT = " />";
    But that should not cause the type of problem you are referring to.
    Mike
    ----- Original Message -----
    From: Matthew Stevens
    Sent: Thursday, September 06, 2001 10:16 AM
    Subject: RE: [iPlanet-JATO] sp3 jsp compiler problem
    Weiguo,
    Others will chime in for sure...I would highly recommend the Regex Tool from
    the iMT 1.1.1 for tackling this type of problem. Mike, Todd and myself have
    posted to the group (even recently) on directions and advantages of creating
    your own RULES (rules file) in XML for arbitary batch processing of source.
    matt
    -----Original Message-----
    From: weiguo.wang@b...
    [mailto:<a href="/group/SunONE-JATO/post?protectID=125056020108194190033029175101192165174144234026000079108238073194105057099246073154180137239239223019162">weiguo.wang@b...</a>]
    Sent: Thursday, September 06, 2001 12:25 PM
    Subject: [iPlanet-JATO] sp3 jsp compiler problem
    Matt/Mike/Todd,
    We are trying to migrate to sp3 right now, but have had a lot of
    issues with the new jasper compiler.
    The following workaround has been employed to solve the issues:
    1. Changed the case of the tag attribute to be the same as what's
    defined in tld.
    example: changed OnClick to onClick
    2. Removed attributes which are not defined in tld.
    example: escape attribute only defined in three tags
    but in some pages, it's used although it's not defined as an
    attribute
    of certain tags. The jasper compiler doesn't like it.
    3. In an end tag, there can't be any space.
    example: </content > doesn't work. </content> works.
    As I see it, we have two options to go about solving this problem:
    1. Write a script which will iterate through all the jsp files and
    call jspc on them. Fix the errors manually when jspc fails. Jspc will
    flag the line number where an error occurs.
    2. Write a utility which scans the jsp files and fix the errors when
    they are encountered. We should define what's an error and how to
    correct it. It's best if we combine this with solution 1 since we
    might miss an error condition.
    Actually, there might be another option, which is seeking help from
    you guys since you have better understanding of JATO and iAS. Can you
    do anything to help us?
    We would be happy to hear your thoughts.
    At last, I would like to suggest modifying the moko tool so that
    these rules are enforced and the generated JSPs work with the new
    compiler. This is for the benefit of any new migration projects.
    Thanks a lot.
    Weiguo
    [email protected]
    Choose from 1000s of job listings!
    [email protected]
    [Non-text portions of this message have been removed]

    Thanks a lot Matt and Mike for your prompt replies.
    I agree completely that iMT doesn't introduce the inconsistencies.
    About the three cases I mentioned, the third one happens only in
    manually created JSPs. So it has nothing to do with iMT. The first
    two are mainly due to the existing HTML code, as you rightly pointed
    out.
    The reason I made the suggestion is since we know that case 1 and 2
    won't pass the japser compiler in sp3, we have to do something about
    it. The best place to do this, in my mind, is iMT. Of course, there
    might be some twists that make it impossible or difficult to do this
    kind of case manipulation or attribute discard.
    Weiguo
    --- In iPlanet-JATO@y..., "Mike Frisino" <Michael.Frisino@S...> wrote:
    Weiguo,
    First, Matt is correct, the regular expression tool is perfect for general text substitution situations, and as a completely independent
    tool its use is not restricted to migration situations (or file types
    for that matter).
    >
    Second, I sympathize with the unfortunate trouble you are experiencing due to Jasper's (perhaps more strict) compilation, but
    in what way did the iMT automated translation contribute to these
    inconsistencies that you cited?
    >
    1. Changed the case of the tag attribute to be the same as what's
    defined in tld.
    example: changed OnClick to onClick
    The iMT does not generate any OnClick or onClick clauses per se. In a translation situation, the only way "OnClick" would have been
    introduced was if it had been part of the pre-existing
    project's "extraHTML" (which was written by the original customer and
    just passed through unchanged by the iMT) or if it was added manually
    by the post-migration developer.
    >
    2. Removed attributes which are not defined in tld.
    example: escape attribute only defined in three tags
    but in some pages, it's used although it's not defined as an
    attribute
    of certain tags. The jasper compiler doesn't like it.Can you give soem examples? Is there a definite pattern? Again, this might be similar to the OnClick situation described above?
    >
    >
    3. In an end tag, there can't be any space.
    example: </content > doesn't work. </content> works.
    Again, the content tag would never have been generated by the iMT. There was no equivalent in the NetDynamics world, so any content tags
    in your code must have been introduced by your developers manually.
    Its a shame that jasper is so particular, but the iMT could not help
    you out here even if we wanted to. The constants that are used by the
    iMT are defined in
    com.iplanet.moko.jsp.convert.JspConversionConstants. From what I can
    see, the only situation of a closing tag with any space in it is
    public static final String CLOSE_EMPTY_ELEMENT = " />";
    But that should not cause the type of problem you are referring to.
    Mike
    ----- Original Message -----
    From: Matthew Stevens
    Sent: Thursday, September 06, 2001 10:16 AM
    Subject: RE: [iPlanet-JATO] sp3 jsp compiler problem
    Weiguo,
    Others will chime in for sure...I would highly recommend the Regex Tool from
    the iMT 1.1.1 for tackling this type of problem. Mike, Todd and myself have
    posted to the group (even recently) on directions and advantages of creating
    your own RULES (rules file) in XML for arbitary batch processing of source.
    >
    matt
    -----Original Message-----
    From: weiguo.wang@b...
    [mailto:<a href="/group/SunONE-JATO/post?protectID=125056020108194190033029175101192165174048139046">weiguo.wang@b...</a>]
    Sent: Thursday, September 06, 2001 12:25 PM
    Subject: [iPlanet-JATO] sp3 jsp compiler problem
    Matt/Mike/Todd,
    We are trying to migrate to sp3 right now, but have had a lot of
    issues with the new jasper compiler.
    The following workaround has been employed to solve the issues:
    1. Changed the case of the tag attribute to be the same as
    what's
    defined in tld.
    example: changed OnClick to onClick
    2. Removed attributes which are not defined in tld.
    example: escape attribute only defined in three tags
    but in some pages, it's used although it's not defined as an
    attribute
    of certain tags. The jasper compiler doesn't like it.
    3. In an end tag, there can't be any space.
    example: </content > doesn't work. </content> works.
    As I see it, we have two options to go about solving this problem:
    >>
    1. Write a script which will iterate through all the jsp files and
    call jspc on them. Fix the errors manually when jspc fails. Jspc will
    flag the line number where an error occurs.
    2. Write a utility which scans the jsp files and fix the errors when
    they are encountered. We should define what's an error and how to
    correct it. It's best if we combine this with solution 1 since we
    might miss an error condition.
    Actually, there might be another option, which is seeking help from
    you guys since you have better understanding of JATO and iAS. Can you
    do anything to help us?
    We would be happy to hear your thoughts.
    At last, I would like to suggest modifying the moko tool so that
    these rules are enforced and the generated JSPs work with the new
    compiler. This is for the benefit of any new migration projects.
    Thanks a lot.
    Weiguo
    [email protected]
    Choose from 1000s of job listings!
    [email protected]
    Service.
    >
    >
    >
    [Non-text portions of this message have been removed]

  • HT5085 I would like to upload my music library from my PC to the Cloud through iTunes Match.  I also will be purchasing a Mac in the near future and would like to download some of that music from iCloud to my Mac.  Will I have compatability problems?

    I would like to upload my music library from my PC to the Cloud through iTunes Match.  I also will be purchasing a Mac in the near future and would like to download some of that music from iCloud to my Mac.  Will I have compatability problems?

    You should have no problems. To add a second computer or device to iTunes Match, see:
    http://support.apple.com/kb/ht4913
    Regards.

  • 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

  • I've been using Elements 10 on my windows 7 machine editing RAW/NEF picture files taken with a Nikon D40X camera with no problems. I upgraded my camera to a Nikon DX7100 and can no longer load my RAW/NEF into elements 10. Is there a compatability problem

    I've been using Elements 10 on my windows 7 machine editing RAW/NEF picture files taken with a Nikon D40X camera with no problems. I upgraded my camera to a Nikon DX7100 and can no longer load my RAW/NEF into elements 10. Is there a compatability problem with my new camera? Will upgrading elements to a newqer version solve the problem?

    NEF's for the D7100 should work with the latest version PSE13
    You can download here and try free for 30 days:
    https://www.adobe.com/cfusion/tdrc/index.cfm?product=photoshop_elements&loc=us&PID=2159997 #

Maybe you are looking for