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

Similar Messages

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]

Run Admin Server with multiple Managed Servers each using different userid?

We currently run separate WebLogic domain instances for each business application in a Unix environment. Each one is created using a unix userid unique to that application and which owns all the files and is used to run the process when that particular WebLogic instance is started up. We have run this way for a while.
I am considering altering our approach to the one that is recommended, i.e. in our Production environment we would run a single Admin instance with numerous managed servers. One issue I'm stuck on is the fact that in our current environment, each application has a different unix userid that owns the files making up the WebLogic domain instance and that WebLogic instance is run under that userid.
I've investigated and experimented using WebLogic 10.3 preview and WebLogic 10.0, but I haven't been able to determine what I have to do to make each managed server's files and processes belong to a different unix userid, if that is even possible.
Is there a way, using the recommended approach, where there is a single Admin instance that has multiple managed servers whose files and processes are owned by different unique, unix userids?
If not, how would you separate access to each of the Managed Servers so that the programmers who maintain them don't have access to Managed Servers that they are not responsible for?
Thanks for any help or suggestions.....

Hi:
I played with this stuff and I found that this will work, without the Location elements:
<IfModule mod_weblogic.c>
MatchExpression /app1 WebLogicHost=server1|WebLogicPort=7003
MatchExpression /app2 WebLogicHost=server2|WebLogicPort=7003
</IfModule>
Also this will work too, with no entries inside the IfModule element:
<Location /app1 >
SetHandler weblogic-handler
WebLogicHost server1
WebLogicPort 7003
</Location>
<Location /app2 >
SetHandler weblogic-handler
WebLogicHost server2
WebLogicPort 7003
</Location>

Problem with discovering Managed Servers

Hi,
I got problem with discovering managed servers, when I restart only administration
server while managed servers are running. During restart of admin server everything
seems to be ok (the directive: Starting discovery of managed server... appears
on the screen).
However when I start admin console through http, I cannot monitor performance,
browse logs etc. I can only shutdown managed server and I can see in a server
tag that particular managed servers are running.
I'm looking forward for any clues
Michal

Sorry,
i cannot stop those managed server - in Control tab I have active only option
to start those server but they are running. In logging tab when I want to browse
the log the message that probably this server is not running appear. However in
the tab when all servers are listened there is a message that they are running
"Michal" <[email protected]> wrote:
>
Hi,
I got problem with discovering managed servers, when I restart only administration
server while managed servers are running. During restart of admin server
everything
seems to be ok (the directive: Starting discovery of managed server...
appears
on the screen).
However when I start admin console through http, I cannot monitor performance,
browse logs etc. I can only shutdown managed server and I can see in
a server
tag that particular managed servers are running.
I'm looking forward for any clues
Michal

WLS61-WinNT: Admin/Managed servers on same machine with NodeManager?

Hi,
I'm trying to set up a development environment with a Admin server
that controls at least one Managed server. I can start the Admin
server (7001) successfully, and "startNodeManager" seems to work fine
on the default port 5555. No clustering is being done. Only
DefaultWebApp is available.
I'm starting "setEnv" and "startWebLogic" from
C:\dev\bea\wlserver6.1\config\devdomain
and "startNodeManager" from
C:\dev\bea\wlserver6.1\config
I have a Machine, "devmachine", assigned to port 5555 (thus attaching
it to the NodeManager) using the default config files.
I have 2 Servers created:
"adminserver", which listens on port 7001 (no great surprise), and
"devserver", which listens on port 7011. I have also tried
"devserver" on port 5555.
DefaultWebApp has chosen both Servers.
When I go to the Console, right-click on "devserver", and select
"Start this server...", I get the "Are you sure?" page.
Clicking "Yes", I get messages on the "startNodeManager" console:
<Date><Info><Nodemanager@localhost:5555><WindowsProcessControl: online
successfully invoked on server 'devserver', pid: 488>
This sounds good, but the console browser returns:
java.lang.NoClassDefFoundError: weblogic/Server
Exception in thread "main"
<Date><Info><Nodemanager@localhost:5555><WindowsProcessControl: online
successfully invoked on server 'devserver', pid: 488>
StartNodeManager's output confirms that "weblogic.jar" is in the
classpath.
It's location is: .\lib\weblogic.jar
Clicking on the Servers branch confirms that 'devserver:7011' is not
running, and that 'adminserver:7001' is running.
I believe that I'm making some sort of simple configuration error, but
I have been unable to find any documentation that clarifies this
problem.
Has anyone gotten this Admin/Managed combination to work on 1 physical
machine? If so, am I simply not matching ports in the config.xml file
correctly? Am I missing something obvious?
Many Thanks!
Jeff

Hi,
It may not be obvious, but a clean install seemed to solve it. A
wacky config issue? The world may never know...or care. :>
Jeff
[email protected] (Jeff Murdoch) wrote in message news:<[email protected]>...
Hi,
I'm trying to set up a development environment with a Admin server
that controls at least one Managed server. I can start the Admin
server (7001) successfully, and "startNodeManager" seems to work fine
on the default port 5555. No clustering is being done. Only
DefaultWebApp is available.
I'm starting "setEnv" and "startWebLogic" from
C:\dev\bea\wlserver6.1\config\devdomain
and "startNodeManager" from
C:\dev\bea\wlserver6.1\config
I have a Machine, "devmachine", assigned to port 5555 (thus attaching
it to the NodeManager) using the default config files.
I have 2 Servers created:
"adminserver", which listens on port 7001 (no great surprise), and
"devserver", which listens on port 7011. I have also tried
"devserver" on port 5555.
DefaultWebApp has chosen both Servers.
When I go to the Console, right-click on "devserver", and select
"Start this server...", I get the "Are you sure?" page.
Clicking "Yes", I get messages on the "startNodeManager" console:
<Date><Info><Nodemanager@localhost:5555><WindowsProcessControl: online
successfully invoked on server 'devserver', pid: 488>
This sounds good, but the console browser returns:
java.lang.NoClassDefFoundError: weblogic/Server
Exception in thread "main"
<Date><Info><Nodemanager@localhost:5555><WindowsProcessControl: online
successfully invoked on server 'devserver', pid: 488>
StartNodeManager's output confirms that "weblogic.jar" is in the
classpath.
It's location is: .\lib\weblogic.jar
Clicking on the Servers branch confirms that 'devserver:7011' is not
running, and that 'adminserver:7001' is running.
I believe that I'm making some sort of simple configuration error, but
I have been unable to find any documentation that clarifies this
problem.
Has anyone gotten this Admin/Managed combination to work on 1 physical
machine? If so, am I simply not matching ports in the config.xml file
correctly? Am I missing something obvious?
Many Thanks!
Jeff

Wl60, jsp reloading, and managed servers

JSP pages don't reload on "Managed" nodes/servers in WLS6.0. Is this
          intentional or a bug? and can this behavior be modified?
          -jim


For those interested, here's the reply I got from BEA support:
          Just got some information regarding redeploying of the JSP. I got this
          from one of my colleague.
          "The only way to cause a jsp change to propagate to all the targets is
          to redeploy the whole web app. This has undesirable side effects, such
          as losing servlet session (since we have to do an undeploy/redeploy). We
          are hoping to be able to fix this soon"
          I don't know the timeframe of when this problem will be fixed. It is
          indicated that it is not fixed in 6.1 and maybe the release after 6.1
          (1Q 2002).
          Out of curiosity, how is everyone else developing with 6.0? Is everyone
          just doing their development under the Admin server? Has anyone come up
          with any other creative alternatives?
          -jim
          In article <[email protected]>, [email protected]
          says...
          > I did.
          > I would post here their answer, because I think it must disturb lots of J2EE developper
          > - especially those that have already use other J2EE servers - to have applications
          > that are in development phase to target the administration server...
          >
          > Kumar Allamraju <[email protected]> wrote:
          > >This is a known issue.
          > >I would suggest you to contact [email protected], so that they can help
          > >you with suitable workaround.
          > >
          > >--
          > >Kumar
          > >
          > >Jim Prantzalos wrote:
          > >
          > >> JSP pages don't reload on "Managed" nodes/servers in WLS6.0. Is this
          > >> intentional or a bug? and can this behavior be modified?
          > >>
          > >> -jim

Tomcat5 and precompiling JSPs with Ant

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

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

Precompile JSP with useBean

"I am trying to precompile some of my jsps. When I try to precompile the JSP that uses useBean. I got the following error: Exception in thread "main" java.lang.ExceptionInInitializerError:


          Shanna Chan <[email protected]> wrote:
          >"I am trying to precompile some of my jsps. When I try to precompile the
          >JSP that uses useBean. I got the following error: Exception in thread "main"
          >java.lang.ExceptionInInitializerError:
          I hit this problem a lot too. On investigation, it's always because I forget that
          with jspc, there are
          *two* classpaths: the one you call weblogic.jspc with, and the one you pass to javac
          with the -classpath option.
          You need your bean classes in both, as the jsp-java parser instantiates beans before
          generating (I guess
          as a validity check).

Precompiling JSPs with taglib dependency

Hi, all.
          Could someone tell me how to specify taglib for jspc ?
          Whenever I try to precompile my JSPs, the ones that have dependency upon
          taglib always fail with the following message:
          java.lang.NullPointerException at
          weblogic.servlet.jsp.JspLexer.getHomeRelativeFile(JspLexer.java:59) at
          weblogic.servlet.jsp.JspLexer.isWebLogicTagLib(JspLexer.java, Compiled
          Code) at
          weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:69) at
          weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java,
          Compiled Code)
          at
          weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java, Compiled
          Code) at
          weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java, Compiled Code)
          at
          weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:1677) at
          weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1518) at
          weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java, Compiled Code) at
          weblogic.servlet.jsp.JspLexer.parse(JspLexer.java, Compiled Code) at
          weblogic.servlet.jsp.JspParser.doit(JspParser.java, Compiled Code) at
          weblogic.servlet.jsp.JspParser.parse(JspParser.java:116) at
          weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:97) at
          weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java,
          Compiled Code) at
          weblogic.jspc.runBody(jspc.java,
          Compiled Code) at
          weblogic.utils.compiler.Tool.run(Tool.java:80) at
          weblogic.jspc.main(jspc.java:111)
          I'm using WL5.1 with SP5.
          TIA,
          Kim.


Yep, this is a known issue.
          Work is in progress.
          Kumar
          Kim Kofman wrote:
          >
          > Hi, all.
          > Could someone tell me how to specify taglib for jspc ?
          > Whenever I try to precompile my JSPs, the ones that have dependency upon
          > taglib always fail with the following message:
          > java.lang.NullPointerException at
          >
          > weblogic.servlet.jsp.JspLexer.getHomeRelativeFile(JspLexer.java:59) at
          >
          > weblogic.servlet.jsp.JspLexer.isWebLogicTagLib(JspLexer.java, Compiled
          > Code) at
          >
          > weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:69) at
          >
          > weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java,
          > Compiled Code)
          > at
          > weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java, Compiled
          > Code) at
          >
          > weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java, Compiled Code)
          > at
          >
          > weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:1677) at
          >
          > weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1518) at
          >
          > weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java, Compiled Code) at
          >
          > weblogic.servlet.jsp.JspLexer.parse(JspLexer.java, Compiled Code) at
          >
          > weblogic.servlet.jsp.JspParser.doit(JspParser.java, Compiled Code) at
          >
          > weblogic.servlet.jsp.JspParser.parse(JspParser.java:116) at
          >
          > weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:97) at
          >
          > weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java,
          > Compiled Code) at
          > weblogic.jspc.runBody(jspc.java,
          > Compiled Code) at
          >
          > weblogic.utils.compiler.Tool.run(Tool.java:80) at
          > weblogic.jspc.main(jspc.java:111)
          >
          > I'm using WL5.1 with SP5.
          >
          > TIA,
          > Kim.

Configuring the weblogic domain with multiple managed servers(SOA)

Hi
We are trying to create a domain where we have a admin server and 2 SOA manged servers under a cluster.
domain
Admin_Server
SOA_Cluster
SOA_Managed1
SOA_Managed2
I tries the default values but that puts my soa-infra into the Admin server and as far as I know that is not supposed to be the case.
Can any one tell me what are the libraries that I should be selecting for the cluster when I try configuring the domain?
Thanks

Thanks Vlad.
I found another link that might be helpful to someone who is looking for something like this
https://blogs.oracle.com/reynolds/entry/installing_an_11g_soa_cluster_2
Thanks.

Shutdown script for Weblogic admin & managed servers

Greetings,
I am new to weblogic and am using it on a new box with OID. I am in the process of writing a shutdown script to shut down all processes on the box when it is restarted, I think this is better than just pulling the plug. I have learned about and turned on t3 protocols and used WLST to tore credentials in WebLogicKey.properties & WebLogicConfig.properties file so things are working properly. What I can't find is how to shut down the managed server using WLST and am also wondering if it is better to invoke the stopManagedWebLogic.sh and the stopWebLogic.sh scripts form the shell or from the WLST tool, if indeed that is possible. If soemone has such scripts they would be willing to share that would be much appreciated.
Thank you.
Bill Wagman

"One question, Rene, I see in your scripts you are storing username/password combinations.
I have used the storeUserConfig () command to create a WebLogicConfig.properties file and a WebLogicKey.properties file to avoid that issue.
Is there a reason you have not done this?"
No, what you did with the storeUserConfig, to prevent needing to store the unencrypted username
and password in your WLST scripts is good. One thing to note is that the key files are extremely sensitive
in that they allow any user to use the configuration file to authenticate as the user stored in the configuration
file. You should store the key files in a secure location so that only the authorized users have access to them (this
is also what you do with scripts that have unencrypted username and password in them). You probably have
an environment (operating system) in which only authorized users can reach the sensitive data.

Redeploy precompiled JSPs to managed server in exploded format without incurring a JSP recompile

     How do you redeploy precompiled JSPs to a managed server in exploded format without
incurring a JSP recompile?
     Our application is deployed in Two Phase, Stage mode, Exploded Format. We regularly
update JSPs on our Production application and would like to be able to redeploy
JSPs without incurring the JSP recompile. I am able to precompile JSPs and redeploy
the JSP and compiled JSP to the managed server, but the updated page is still
recompiled.
     I've searched the BEA site, newsgroups, and web and still need some help.
     Additional information:
     - precompile in web.xml is false. we'd prefer not to precompile all the jsps
at startup to minimize Production downtimes when deploying new major releases
     - the compiled JSPs reside in ~/classes/jsp_servlet and not ~/WEB-INF/classes/jsp_servlet
     - our directory structure looks like:
          ~/app
               /META-INF
               /WEB-INF
               /classes ( compiled source )
                    /hotwire ( java class files )
                    /jsp_servlet ( compiled jsps )
          ~/deploy ( property files )
               /prod
                    /web.xml
                    /weblogic.xml
          ~/src ( java files )
               hotwire/
     I found this information on the BEA newsgroup ( http://newsgroups.bea.com/cgi-bin/dnewsweb?cmd=article&group=weblogic.developer.interest.jsp&item=582&utag=
) regarding the _isStale() method for compiled JSPs, but wasn't able to get it
to work when the file was in the exact same path ( note: compilation occurred
on a different machine than the managed view server )
     Do we have to store our compiled JSP files under /WEB-INF/classes for this feature
to work and in a WAR?
     What am I missing?
     Regards,
          Paul

Hi Mark,
Thank you for replying and logging the CR. I've read lots of your posts in researching
this issue and was hoping you'd reply.
I used the JSP Precompile Validation Utility ( http://dev2dev.bea.com/resourcelibrary/utilitiestools/adminmgmt.jsp
) and tested against WLS8.1sp2 and agree with your assessment. The JSP Time utility
indicates that the JSP and compiled class are in agreement, yet the server always
recompiled the JSP after I redeployed that particular file and class. I opened
Case Ticket #: 473459 that includes a test script, output, and lots of information.
It's currently being investigated. I'll inform the BEA Relations engineer and
add my name to the CR you opened.
Dynamic content updates without recompiles is something we'd really like to be
able to do. We are hoping to be able to do specific frequent content updates
in the afternoon as opposed to 1:00 AM :)
Thanks again,
Paul
JSP TIME TOOL:
Summary
====================
Total JSP Files: 1
Total JSP that will compile in server because of missing _staticIsStale method:....
0
Total JSP that will compile in server because of wrong weblogic version:...........
0
Total JSP that will compile in server because jsp is newer than parse date:........
0
Total JSP that will compile in server because missing class:.......................
0
REDEPLOY COMMAND:
$JAVA weblogic.Deployer -adminurl t3://localhost:7004 -user <username> -password
<password> -name phoenixApp -targets phoenixViewWebApp@wlview1 -redeploy web/jsp/customer-care/indexMain.jsp
WEB-INF/classes/jsp_servlet/_web/_jsp/_customer_45_care/__indexmain.jsp
WEBLOGIC LOG:
####<Jan 13, 2004 3:33:04 PM PST> <Info> <Deployer> <ppjsp01> <wlview1> <ExecuteThread:
'2' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149059> <Module
phoenixViewWebApp of application phoenixApp is transitioning from active to prepared
on server wlview1.>
####<Jan 13, 2004 3:33:04 PM PST> <Info> <Deployer> <ppjsp01> <wlview1> <ExecuteThread:
'2' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149060> <Module
phoenixViewWebApp of application phoenixApp successfully transitioned from active
to prepared on server wlview1.>
####<Jan 13, 2004 3:33:05 PM PST> <Info> <Deployer> <ppjsp01> <wlview1> <ExecuteThread:
'2' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149059> <Module
phoenixViewWebApp of application phoenixApp is transitioning from prepared to
active on server wlview1.>
####<Jan 13, 2004 3:33:05 PM PST> <Info> <Deployer> <ppjsp01> <wlview1> <ExecuteThread:
'2' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149060> <Module
phoenixViewWebApp of application phoenixApp successfully transitioned from prepared
to active on server wlview1.>
####<Jan 13, 2004 3:38:13 PM PST> <Info> <HTTP> <ppjsp01> <wlview1> <ExecuteThread:
'119' for queue: 'default'> <<anonymous>> <> <BEA-101295> <Recompiling JSP [ServletContext(id=31702491,name=phoenixViewWebApp,context-path=)],
resource [web/jsp/customer-care/indexMain.jsp], because it is stale. It was previously
compiled using a different version of WebLogic Server.
JSP build version: 8.1.2.0
WLS build version: 8.1.2.0.>
####<Jan 13, 2004 3:38:13 PM PST> <Info> <HTTP> <ppjsp01> <wlview1> <ExecuteThread:
'119' for queue: 'default'> <<anonymous>> <> <BEA-101047> <[ServletContext(id=31702491,name=phoenixViewWebApp,context-path=)]
Generated java file: /opt/p4/phoenix/6.2/app/WEB-INF/classes/jsp_servlet/_web/_jsp/_customer_45_care/__indexmain.java>
"Mark Griffith" <[email protected]> wrote:
So this is a scenario that we should support Paul.
There are a couple of issues.
1) I dont think our weblogic.Deployer api currently does a very good
job of
this at all, since it is MOSTLY concerned with redeployment of applications
and modules, and in this scenario you dont want app redpeloyment you
just
want what are essentially content files distributed. In otherwords the
api
I worry wont help you distributing files for this case, at least in this
current release and SP.
2) once you get the files to the location, things should in the servlet
containers.
Having said that it is easier if you are able to have the application's
deployed with -no-stage, or no-copying, or shared application, that way
you
have one location to copy files to vs. many stage dirs. Either way you'll
have to copy the jsp's and the classfiles to the webapp directories.
Additionally I just tried this on 8.1. sp2 and the stale-check by the
servlet container is busted. :( I opened a bug on this: CR133453.
Not
sure if this is in sp1 or not, didnt have time to check it. I suggest
you
contact support and get your name added to this CR to raise its priority.
Cheers
mbg

PageCheckSeconds (precompile jsp, stored in war file) (Weblogic 6.1)

Hi,
          I'm trying to stop the webserver from trying to recompile/check my jsp pages. I have set the pageCheckSeconds param to -1 but that doesn't seem to work. Looking at the weblogic.log file I get:
          [WebAppServletContext(601285,kcs,/kcs)] WorkflowServlet: init>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: init>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param verbose initialized to: true>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param packagePrefix initialized to: jsp_servlet>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param compilerclass initialized to: javac>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param srcCompiler initialized to weblogic.jspc>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param superclass initialized to weblogic.servlet.jsp.JspBase>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param workingDir initialized to: C:\apps\bea\wlserver6.1\config\kces\applications\.wlnotdelete\wlap17684\WEB-INF\_tmp_war_kc_kc_kcs>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param pageCheckSeconds initialized to: -1>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: initialization complete>
          [WebAppServletContext(601285,kcs,/kcs)] Generated java file: C:\apps\bea\wlserver6.1\config\kces\applications\.wlnotdelete\wlap17684\WEB-INF\_tmp_war_kc_kc_kcs\jsp_servlet\__index.java>
          If I take out the jsp class files from the war file and set the param workingDir (weblogic.xml) to the directory where the jsp class files are located... it works. But now I have a packaging problem that I can easily solve by keeping the jsp class files within the war file. As you can see from the log messages above, the pageCheckSeconds value is set to -1... yet the checking occurred anyway. Is there a way to specify the name of the war file that is located within an EAR file using the workingDir param?
          Thanks
          David
          [att1.html]


You say: "If I take out the jsp class files from the war file and set the param workingDir (weblogic.xml) to the directory where the jsp class files are located... it works. "
          Did you get this to work in a cluster using admin/managed servers, or just with a single server?
          -Greg
          Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
          www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
          "David Kostiew" <[email protected]> wrote in message news:[email protected]...
          Hi,
          I'm trying to stop the webserver from trying to recompile/check my jsp pages. I have set the pageCheckSeconds param to -1 but that doesn't seem to work. Looking at the weblogic.log file I get:
          [WebAppServletContext(601285,kcs,/kcs)] WorkflowServlet: init>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: init>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param verbose initialized to: true>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param packagePrefix initialized to: jsp_servlet>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param compilerclass initialized to: javac>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param srcCompiler initialized to weblogic.jspc>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param superclass initialized to weblogic.servlet.jsp.JspBase>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param workingDir initialized to: C:\apps\bea\wlserver6.1\config\kces\applications\.wlnotdelete\wlap17684\WEB-INF\_tmp_war_kc_kc_kcs>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: param pageCheckSeconds initialized to: -1>
          [WebAppServletContext(601285,kcs,/kcs)] *.jsp: initialization complete>
          [WebAppServletContext(601285,kcs,/kcs)] Generated java file: C:\apps\bea\wlserver6.1\config\kces\applications\.wlnotdelete\wlap17684\WEB-INF\_tmp_war_kc_kc_kcs\jsp_servlet\__index.java>
          If I take out the jsp class files from the war file and set the param workingDir (weblogic.xml) to the directory where the jsp class files are located... it works. But now I have a packaging problem that I can easily solve by keeping the jsp class files within the war file. As you can see from the log messages above, the pageCheckSeconds value is set to -1... yet the checking occurred anyway. Is there a way to specify the name of the war file that is located within an EAR file using the workingDir param?
          Thanks
          David
          [att1.html]

Need recommendation - iis with two physical servers and clusters

Hello,
I was hoping to get a recommendation/opinion or two on the configuration I've inherited. I'm looking
at the following configuration using weblogic 8.1 sp4 server (to be upgraded to sp6) running on two physical machines:
MachineA:
Domain: myDomain
Cluster: cluster1
Servers: Admin Server:9001 (not part of cluster)
ManagedServer1:7001
ManagedServer2:7010
MachineB:
Domain: myDomain
Cluster: cluster2
Servers: Admin Server:9001 (not part of cluster)
ManagedServer3:7001
ManagedServer4:7010
On MachineA: IIS Proxy Plugin with parameter in .ini file
WeblogicCluster: MachineA:7001, MachineA:7010, MachineB:7001,MachineB7010
Naturally, the IIS is acting as a round robin load balancer..
The domains were created using the wizard on both machines and basic domain template..
For proper failover to be taken advantage of, does something different need to be configured? Or is it fine?
And if so, does group replication have something to do with it?
Should either of the clusters be Managed Servers across physical machines?
or should this just be one cluster of 4 managed servers across two machines?
I really am not sure on any of this, even though i've read through much of the documentation for clustering..twice.
I should mention that there is only a .war file deployed with 4 connection pools and 4 Data Sources..No EJBs or JMS
Would really appreciate any feedback or opinions/advice..
Thanks

This is what I'd do
MachineA:
Domain: myDomain
Cluster: cluster1
Servers: Admin Server:9001 (not part of cluster)
ManagedServer1:7010
ManagedServer2:7020
MachineB:
Domain: myDomain
Cluster: cluster2
Servers: Admin Server:9001 (not part of cluster)
ManagedServer3:8010
ManagedServer4:8020
I just changed the port numbers so they flow and have a pattern - 70* port numbers belong to cluster 1, 80* port numbers belong to cluster 2. No technical benefit apart from it makes it tidier in my opinion.
Port 9001 for the admin server is normally the domain wide admin port - you could be using that, so that's fine, but my admin server is running 7001.
You also only need one admin server per domain, this can run on MachineA
Replication groups are used to help WLS figure out where to place the secondary http session. It will try servers on a different machine/replication group first, if none available, it will create secondary on the same machine.
What you will end up with is a domain with 4 managed servers in it. The admin server will run on machineA, say using port 7001, each of the managed servers will contact the admin server to download it's config.
The cluster1 will contain 2 managed servers and the same for cluster2.
providing you have your cluster multicast addresses set up and the cluster is working, that should be all you need to do for the session failover.
There's some BEA sample code somewhere which will deploy a web-app and show which managed server you've attached to. If you find that and then connect through IIS, shut down the server that the JSP tells you, you should be able to see the session fail-over nicely.
Hope that helps,
Pete

What should be the client url for managed servers in a cluster

Hi guys,
I have created a cluster(cluster_1) having 4 managed servers. 2 managed servers on my machine(IP1) and 2 managed servers on other machine(IP2).
I am able to deploy a xxx.war file on my admin server
also
I am able to deploy the same war file on my cluster
When I try to hit the client url, it gives me back the correct data, but it creates the session on the admin server and not the cluster.
If I remove the xxx.war file from the deployment(deployed on admin server) and redeploy the xxx,war file on the cluster, it gets deployed successfully , but the client url gives me a 404 error.
What should I do, so that after hitting the client url, it creates the session on the managed servers in the cluster ?
My admin server is not the part of this cluster.
cluster ip:127.0.0.1
ip1: 10.25.63.130
ip2: 10.25.63.131
please help
Salil

Hi Salil
This is exactly what I mentioned in my earlier post. You CANNOT and should NOT expose the managed server url (host, port) to the end users. Because as you already figured out, you can specify only one. Or they cannot try one at a time like that.
This is where, the Load Balancer will come into picture like Apache Web Server. After installing Apache web server, usually it runs at default port 80. So you just expose the apache host to outside world. Also most companies will have Firewalls and Apache is outside of Firewall and all weblogic servers are inside the Firewall. In apache, you configure the weblogic cluster details like the host names and ports of each managed server etc in httpd.conf file etc.
Ex: For outside users, they may try like http://apachehost/myWeb/myHello.jsp -> apachehost is the host name where Apache web server is running at port 80. NOW Apache is smart enough to do Load Balancing and Failover. If 100 users access the site with 4 managed servers, ideally each managed server will get 25 requests (load balancing). Also if 2 servers are killed, automatically, request will NOT go to them, but to other 2 live servers etc etc. Apache takes care of this.
Bottom line, please see my earlier post, and you need to have some sort of Web Server like Apache for your cluster setup.
Thanks
Ravi Jegga

Precompiling JSP with admin/managed servers

Similar Messages

Maybe you are looking for