JSP compiler in Weblogic 7.1 SP2 and Weblogic 8.1
I have a web application (JSp and Servlets are generated) that loads fine with
Weblogic 8.1. However, I have problems with Weblogic 7.1 SP2. In trying to load
some of the JSP pages, I get the follwing type of errors
Parsing of JSP File '/consume_int.jsp' failed:
/consume_int.jsp(17): bean type com.mypackage.ConTypes.ConTypesJspBean has no
read method for property 'consume_int_Int_parameter1'
probably occurred due to an error in /consume_int.jsp line 17:
<H4>consume_int_Int_parameter1:</H4> <jsp:getProperty name="ConTypesJspBean" property="consume_int_Int_parameter1"/>
Wed Jun 09 20:01:34 BST 2004
Looking further, I found that for property x, there are methods getx() and not
getX(). Can this cause the problem. It seems to be working for some of the getx()
methods and not for other ones.
Any help would be appreciated.
Thanks,
MIB
It does NOT seem to work with methods getX and setX for property 'x' in Weblogic
7.1 SP2. It works fine in Weblogic 8.1. Any ideas ?
- MBI
"MIB" <[email protected]> wrote:
>
>I have a web application (JSp and Servlets are generated) that loads
>fine with
>Weblogic 8.1. However, I have problems with Weblogic 7.1 SP2. In trying
>to load
>some of the JSP pages, I get the follwing type of errors
>
>Parsing of JSP File '/consume_int.jsp' failed:
>--------------------------------------------------------------------------------
> /consume_int.jsp(17): bean type com.mypackage.ConTypes.ConTypesJspBean
>has no
>read method for property 'consume_int_Int_parameter1'
>probably occurred due to an error in /consume_int.jsp line 17:
><H4>consume_int_Int_parameter1:</H4> <jsp:getProperty name="ConTypesJspBean"
>property="consume_int_Int_parameter1"/>
>
>--------------------------------------------------------------------------------
>Wed Jun 09 20:01:34 BST 2004
>
>Looking further, I found that for property x, there are methods getx()
>and not
>getX(). Can this cause the problem. It seems to be working for some of
>the getx()
>methods and not for other ones.
>
>Any help would be appreciated.
>
>Thanks,
>
>MIB
Similar Messages
-
Weblogic 9 and JSP compiler errors
Hello everyone,
I am having problems with my Jsps in my EAR file deployed on WL 9.0.
I have a Jsp called upms.jsp that contains the following code snippets:
After my import statements, I have some code that creates a resource bundle that accesses a properties file:
<%!
ResourceBundle bundle = null;
public void jspInit() {
bundle = ResourceBundle.getBundle("conf.properties");
%>
I get an error from the above code:
upms.jsp:3:11: 'try' statement has neither 'catch' nor 'finally' clause
import="java.util.ResourceBundle"
^----------------------^
I am totally clueless as to what that error means.
Next I declare a bean I use in the jsp:
<jsp:useBean
id="userPrefsManagerBean"
class="controllers.beans.UserPreferencesManagerBean"
scope="session">
</jsp:useBean>
<jsp:setProperty name="userPrefsManagerBean" property="*" />
I get these errors from the above portion:
upms.jsp:27:3: The qualifier of this name is a package, which cannot contain fields.
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: The qualifier of this name is a package, which cannot contain fields.
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Expression expected (found '.' instead)
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Syntax error: expected ) (found 'class' instead)
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Syntax error: expected <identifier> (found ')' instead)
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
Has anyone encountered these before?
This jsp worked perfectly well when I deployed my EAR file on JBoss...no such luck using Weblogic.
Is there something I am missing here? I appreciate any help.
Cheers, :-)
M.Mildred,
Two suggestions:
1) use option weblogic.jspc's "-keepgenerated", you can keep the generated
servlet's source code.
Please paste it here.
2) Can you create a simple reproducer(e.g. a war), and put it here, so that
we can debug it and give more clues.
To reproduce your issue, I write a simple a simple
UserPreferencesManagerBean classs below :
package controllers.beans;
public class UserPreferencesManagerBean {
private int p1;
public void setP1(int p)
p1 = p;
public int getP1()
return p1;
But it works(oh, I run it under 910MP1).
We cannot tell too much without your further information
Thanks
Leon
<Mildred A> wrote in message news:[email protected]...
I am still fighting with this issue.. Dang!
I don't know what to change in my JSP because the WL JSP compiler errors are
so out there..
Here is the first portion of the JSP file:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
session="true"
pageEncoding="ISO-8859-1"
import="java.util.ArrayList"
import="java.util.HashSet"
import="java.util.Date"
import="java.util.Collections"
import="java.util.ResourceBundle"
%>
<%!
ResourceBundle bundle = null;
public void jspInit() {
bundle = ResourceBundle.getBundle("conf.properties");
%>
<jsp:useBean
id="userPrefsManagerBean"
class="controllers.beans.UserPreferencesManagerBean"
scope="session">
</jsp:useBean>
<jsp:setProperty name="userPrefsManagerBean" property="*" />
Below is the error I get from this section alone (after precompiling):
upms.jsp:3:11: 'try' statement has neither 'catch' nor 'finally' clause
import="java.util.ArrayList"
^-----------------^
upms.jsp:27:3: The qualifier of this name is a package, which cannot contain
fields.
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: The qualifier of this name is a package, which cannot contain
fields.
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Expression expected (found '.' instead)
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Syntax error: expected ) (found 'class' instead)
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Syntax error: expected <identifier> (found ')' instead)
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Expression expected (found 'catch' instead)
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Illegal use of an expression as a statement.
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: No variable or field with this name could be found at this
location.
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: No variable or field with this name could be found at this
location.
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Syntax error: expected ) (found '__ee' instead)
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Illegal use of an expression as a statement.
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Syntax error: expected ; (found ')' instead)
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: No variable or field with this name could be found at this
location.
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: No variable or field with this name could be found at this
location.
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
upms.jsp:27:3: Syntax error: expected } (found 'EOF' instead)
<jsp:setProperty name="userPrefsManagerBean" property="*" />
^-------------^
Can anyone see what I am doing wrong here? ?:| ?:|
Cheers,
M -
JSP compilation errors in weblogic 6.1
I'm getting these JSP compilation errors in weblogic 6.1 on Solaris. Please help.
Full compiler error(s):
error: Invalid class file format:
^
/opt/projects/redherring/beahome/wlserver6.1/config/mydomain/applica
tions/.wlnotdelete/WEB-INF/_tmp_war_myserver_myserver_redherring/jsp_servlet/_w
eb/_jsp/_event/__eventForm.java:34: Class
com.ford.redherring.model.PropertiesAttributesModel not found in import.
import com.ford.redherring.model.PropertiesAttributesModel; <file://[>
/web/jsp/event/eventForm.jsp; Line: 64]
^
/opt/projects/redherring/beahome/wlserver6.1/config/mydomain/applica
tions/.wlnotdelete/WEB-INF/_tmp_war_myserver_myserver_redherring/jsp_servlet/_w
eb/_jsp/_event/__eventForm.java:38: Class com.ford.redherring.util.DialogHeader
not found in import.
import com.ford.redherring.util.DialogHeader; <file://[> /web/jsp/event/eventForm.jsp;
Line: 68]
^
/opt/projects/redherring/beahome/wlserver6.1/config/mydomain/applica
tions/.wlnotdelete/WEB-INF/_tmp_war_myserver_myserver_redherring/jsp_servlet/_w
eb/_jsp/_event/__eventForm.java:39: Class com.ford.redherring.util.DialogFooter
not found in import.
import com.ford.redherring.util.DialogFooter; <file://[> /web/jsp/event/eventForm.jsp;
Line: 69]
^
/opt/projects/redherring/beahome/wlserver6.1/config/mydomain/applica
tions/.wlnotdelete/WEB-INF/_tmp_war_myserver_myserver_redherring/jsp_servlet/_w
eb/_jsp/_event/__eventForm.java:40: Class com.ford.redherring.model.DDContainer
not found in import.
import com.ford.redherring.model.DDContainer; <file://[> /web/jsp/event/eventForm.jsp;
Line: 70]
^
/opt/projects/redherring/beahome/wlserver6.1/config/mydomain/applica
tions/.wlnotdelete/WEB-INF/_tmp_war_myserver_myserver_redherring/jsp_servlet/_w
eb/_jsp/_event/__eventForm.java:41: Class
com.ford.redherring.model.DDValidationModel not found in import.
import com.ford.redherring.model.DDValidationModel; <file://[>
/web/jsp/event/eventForm.jsp; Line: 71]
This appears to be a CLASSPATH problem (you are missing references to
'com.ford.redherring.model.*' and 'com.ford.redherring.util.*'). The
CLASSPATH may be set in the server startup script. Hope this helps.
Wade.
"Katri Alur" <[email protected]> wrote in message news:<[email protected]>...
> I'm getting these JSP compilation errors in weblogic 6.1 on Solaris. Please help.
>
> ----------------------------------------------------------------------------
> ----
> Full compiler error(s):
> error: Invalid class file format:
>
>
> ^
> /opt/projects/redherring/beahome/wlserver6.1/config/mydomain/applica
> tions/.wlnotdelete/WEB-INF/_tmp_war_myserver_myserver_redherring/jsp_servlet/_w
> eb/_jsp/_event/__eventForm.java:34: Class
> com.ford.redherring.model.PropertiesAttributesModel not found in import.
> import com.ford.redherring.model.PropertiesAttributesModel; <file://[>
> /web/jsp/event/eventForm.jsp; Line: 64]
> ^
> /opt/projects/redherring/beahome/wlserver6.1/config/mydomain/applica
> tions/.wlnotdelete/WEB-INF/_tmp_war_myserver_myserver_redherring/jsp_servlet/_w
> eb/_jsp/_event/__eventForm.java:38: Class com.ford.redherring.util.DialogHeader
> not found in import.
> import com.ford.redherring.util.DialogHeader; <file://[> /web/jsp/event/eventForm.jsp;
> Line: 68]
> ^
> /opt/projects/redherring/beahome/wlserver6.1/config/mydomain/applica
> tions/.wlnotdelete/WEB-INF/_tmp_war_myserver_myserver_redherring/jsp_servlet/_w
> eb/_jsp/_event/__eventForm.java:39: Class com.ford.redherring.util.DialogFooter
> not found in import.
> import com.ford.redherring.util.DialogFooter; <file://[> /web/jsp/event/eventForm.jsp;
> Line: 69]
> ^
> /opt/projects/redherring/beahome/wlserver6.1/config/mydomain/applica
> tions/.wlnotdelete/WEB-INF/_tmp_war_myserver_myserver_redherring/jsp_servlet/_w
> eb/_jsp/_event/__eventForm.java:40: Class com.ford.redherring.model.DDContainer
> not found in import.
> import com.ford.redherring.model.DDContainer; <file://[> /web/jsp/event/eventForm.jsp;
> Line: 70]
> ^
> /opt/projects/redherring/beahome/wlserver6.1/config/mydomain/applica
> tions/.wlnotdelete/WEB-INF/_tmp_war_myserver_myserver_redherring/jsp_servlet/_w
> eb/_jsp/_event/__eventForm.java:41: Class
> com.ford.redherring.model.DDValidationModel not found in import.
> import com.ford.redherring.model.DDValidationModel; <file://[>
> /web/jsp/event/eventForm.jsp; Line: 71]
-
Weblogic.appc compiler for Weblogic 9 and higher version
We had problem precompiling the jsp's using weblogic.jspc compiler after migrating the project from 8.1 to 9.2. From the edocs weblogic documentation we see that jspc compiler is deprecated from weblogic 9 onwards and they recommend using weblogic.appc for precompiling the jsp's.
Please note if you are passing runtime expression values in the name attribute of the jsp param tag, you will have to explicitly enabke "<rtexprvalue-jsp-param-name>" to true in weblogic.xml deployment descriptor (format shown below).
<weblogic-web-app>
<jsp-descriptor>
<rtexprvalue-jsp-param-name>true</rtexprvalue-jsp-param-name>
</jsp-descriptor>
</weblogic-web-app>
Below is the edocs link which has JSP descriptors information for Weblogic 9,2
http://e-docs.bea.com/wls/docs92/webapp/weblogic_xml.html#wp1038491
- - TarunThe solution given in the below link worked for me .
http://a-developer-life.blogspot.com/2010/11/injecting-into-ejb3-with-google-guice.html?showComment=1328674836129#c7251888680841418914 -
EAR and long CLASSPATH at JSP compilation time
Hi all,
we have an EAR-packaged application with over 260 jars (mainly
EJB) that is deployed to a managed server WL6.1SP3(AIX). Then
we hit a JSP page of this app. and Weblogic generates the
adecuate .java file that is passed as an argument to a forked
process for the javac compiler with a CLASSPATH that is more
than 22KB!! of length because of the EAR classloader schema
(it must include all the jars of the EJB level).
The problem is that the EAR deployment in WL6.1 generates a fixed and very long
path for every jar that it is composed of:
$WL_HOME/./config/DOMAIN/applications/.wl_notdelete_EARNAME
/wlap#####/ejbjarname.jar
and the invoke of the compiler fails with argument too long.
We can control the EJB jar name, EARNAME, WL_HOME
and DOMAIN to shorten the CLASSPATH, but that is not enough
giving that the fixed part of the PATH is very long, for example:
with DOMAIN=DOM1, WL_HOME=W, ejbjar name=EJB1, EARNAME=EAR1
you get:
/w/./config/DOM1/applications/.wl_notdelete_EAR1/wlap#####/EJB1.jar: that is
68 chars * 260 jars = more than 17KB only with the
EJB part of the CLASSPATH (plus the standard SYSTEM CLASSPATH
and WARS CLASSPATH.)
As workarounds we can:
1.- Use an "pseudo exploded" EAR with EJBREMOTE and EJBHOME in clientclasses path
with every jar and war by their own. Not very
clean and we've lost the benefits of EAR deployment.
2.- Consolidate a bunch of EJB in every jar. More administrative
tasks (common xml descriptors:ejb-jar.xml,...) and less isolation
between developer teams.
3.- Consolidate at functionality level (source) a bunch of EJB
in a few one. :(
4.- Precompile every JSP outside of WEBLOGIC and generate
the corresponding class and entries at web.xml and weblogic.xml
5.- ...?
or maybe:
6.- configure this very long directory of deployment
to a shorter deployer choosen and use relative paths.
Is this possible? :)
PacoG.
You may try to use JSP compiler class. Please specify 'compilerclass'
option in weblogic.xml. This option specifies name of a Java compiler
that is executed in WebLogic Servers's virtual machine. (Used in place of
an executable compiler such as javac or sj.)
Please see
http://e-docs.bea.com/wls/docs61/webapp/weblogic_xml.html#jsp-descriptor.
Paco Garcia wrote:
> oops!
>
> >$WL_HOME/./config/DOMAIN/applications/.wl_notdelete_EARNAME
> >/wlap#####/ejbjarname.jar
>
> >with DOMAIN=DOM1, WL_HOME=W, ejbjar name=EJB1, EARNAME=EAR1
> >you get:
> >/w/./config/DOM1/applications/.wl_notdelete_EAR1/wlap#####/EJB1.jar:
>
> please read SERVERNAME instead of EARNAME
>
> PacoG.
Regards,
Ann
Developer Relations Engineer
BEA Support
-
URGENT: sp6 and JSP compiling/classpath problem?
Hi,
We installed sp6 on our production site a little over a week and started
seeing this problem on our logs with regards to any JSP with an include tag,
such as:
<%@ include file="/inc/insideHeadTag.jsp" %>
INTERMITTENTLY, we will get the following error in the page on the client
side at runtime:
< ! -- cannot include file '/inc/insideHeadTag.jsp', resource not
found -- >
I grepped this newsgroup and noticed a previous unanswered post of the same
nature, "Static compiles do not seem to include JSP's". Except in our case,
this problem also manifest for dynamic JSP compiles, happens sporatically,
and only started with sp6.
Bug???
Gene Chuang
Join Kiko.com!
Just to clarify - I'm not from BEA, I'm from EA - short a letter.
As far as I know, there is no synchronization between WL instances in a cluster regarding the
the compiling of JSPs. So when you start up two WL instances that share the same workingDir,
and each WL instances gets a hit on your shiny new index.jsp, they both need to compile it. So the first
one compiles it and writes index.class, the second does the same, overwriting the first _index.class,
possibly at the same time that the first instance is trying to load _index.class into memory. And you
get a mysterious 'class not found' error. Not likely, but possible.
"Gene Chuang" <[email protected]> wrote:
>Hmm, interesting... I thought Weblogic strongly recommends clustered
>servers sharing the same file system?
>
>So you're saying the system-wide, cluster and node specific directories can
>reside on the shared drive, but workingDirs should reside on local drives?
>
>--
>Gene Chuang
>Join Kiko.com!
>
>"Mike Reiche" <[email protected]> wrote in message
>news:[email protected]...
>>
>> Make sure that your WLS instances are NOT sharing the workingDir. If two
>instances
>> try to compile the same JSP at the same time, bad things can happen.
>>
>> Mike
>>
>> "Gene Chuang" <[email protected]> wrote:
>> >Hi Jong,
>> >
>> >Thanks for the reply; but I wish the solution is as simple as that.
>Yes,
>> >my .jsps are in the proper directory. They have been working properly
>for
>> >the past 6 months, since we were running WL 4.5.1. Only when I switched
>to
>> >WL 5.1 sp6 did this bug start showing up. Plus, like I said in my
>original
>> >post, this bug is sporatic. SOMETIMES the included jsp is found by
>Weblogic
>> >and the includer jsp compiles correctly; other times it isn't found and
>the
>> >includer jsp leaves a gap! What's going on?
>> >
>> >We are running clustered web servers in Solaris 2.7 with a shared file
>> >system. This sporatic behavior may be because some nodes aren't working
>> >properly???
>> >
>> >--
>> >Gene Chuang
>> >Join Kiko.com!
>> >
>> >"Jong Lee" <[email protected]> wrote in message
>> >news:[email protected]...
>> >>
>> >> "Gene Chuang" <[email protected]> wrote:
>> >> >Hi,
>> >> >
>> >> >We installed sp6 on our production site a little over a week and
>started
>> >> >seeing this problem on our logs with regards to any JSP with an
>include
>> >tag,
>> >> >such as:
>> >> I assumed insideHeadTag.jsp is in
>> >> YOUR_DOCUMENT_ROOT/inc/insideHeadTag.jsp
>> >>
>> >> if you haven't read the spec of relative URI please do so:
>> >> jsp spec 1.1 - section 2.5.2
>> >>
>> >> Jong
>> >>
>> >> >
>> >> > <%@ include file="/inc/insideHeadTag.jsp" %>
>> >> >
>> >> >INTERMITTENTLY, we will get the following error in the page on the
>client
>> >> >side at runtime:
>> >> >
>> >> > < ! -- cannot include file '/inc/insideHeadTag.jsp', resource not
>> >> >found -- >
>> >> >
>> >> >I grepped this newsgroup and noticed a previous unanswered post of the
>> >same
>> >> >nature, "Static compiles do not seem to include JSP's". Except in our
>> >case,
>> >> >this problem also manifest for dynamic JSP compiles, happens
>> >sporatically,
>> >> >and only started with sp6.
>> >> >
>> >> >Bug???
>> >> >
>> >> >Gene Chuang
>> >> >Join Kiko.com!
>> >> >
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>
-
JSP Compiler and ClassCastException
Have been using JDK1.2.2 from sun since day one and I've been seeing
ClassCastException since day 1 too.
Don't think it had anything to do with the compiler.
"Jun Ying" <[email protected]> wrote in message
news:[email protected]...
> I noticed something that might be causing the ClassCastException and has
not
> been mentioned: the compiler that is used for jspc. I remember seeing a
few
> people mentioning extra classes in the workDir (ie, the bean class that is
> being used). This is caused by using a smart compiler such as jikes or
sj.
> While those compilers will get you more speed for newly modified jsp's,
they
> resolve dependencies and recompile all the referenced classes. The result
> is that the bean class gets recompiled and put into workDir. So no matter
> where you put the workDir, you end up getting a new copy of the bean class
> file, which is reloaded by the classloader that loads the newly compiled
> JSP. That copy of the class file is considered "different" from the one
> from the normal system classpath or the weblogic.class.path. Thus the
> ClassCastException. So if you see java classes other than the jsp's in
the
> workDir, make sure you are using javac from the sun jdk. So to answer
> Anish's question, WebLogic is not sticking a copy of the bean class.
> Rather, it's the java compiler that you are using.
>
> Jun Ying
> Meritsoft, Inc
>
>
> "Michael Boudreau" <[email protected]> wrote in message
> news:[email protected]...
> > Hello,
> >
> > Well we ran into the same problem here at my company, and we have been
> > pulling our hair out. I was reading through the jsp 1.1 spec, and
> > thought I might try using the <jsp:useBean ...> tag instead of the <%@
> > page import ...> tag. After careful inspection of the resulting .java
> > file, I found that the <jsp:useBean ...> tag does not put insert any
> > import statements, but simply declares the bean with the fully
> > qualified package name. I am sure that this is not new news to anyone;
> > however, the class cast exception went away (knock on wood, cross
> > fingers, whatever).
> >
> > Basically, my statement looked like this:
> > <jsp:useBean id="beanname" type="com.company.Class" scope="session" />
> >
> > My question is: is there something that I am missing or have not
> > thought of? Because so far, this "seems" to be working, but I have
> > been reading posts that say this does not work.
> >
> > Oh, one last quick note to BEA. While I was looking at the
> > generated .java file from the jsp file, I found that weblogic's jspc is
> > still generating getValue and setValue methods for HttpSession....
> > which has been deprecated as of the servlet 2.2 spec.
> >
> > Michael
> >
> >
> >
> >
> > Anish Parvataneni wrote:
> >
> > > Hi,
> > >
> > > I have a JSP which uses two different classes. Whenever, I change the
> > > JSP and save it to recompile, there is a ClassCastException. ( I store
> > > them in the session and load them) . Thats common ! The solution to
this
> > > as per documentation is to get rid of the classes in the workingDir of
> > > JSP. However, I can find ONLY ONE of the classes in the workingDir. I
> > > delete that class and the JSP works. I change the JSP , problem
recurrs.
> > >
> > > 1. Why does weblogic stick a copy of the class in the workingDir,
> > > everytime the JSP compiles, although it is available in the weblogic
> > > classpath ?
> > > 2. Why is it happening to only one of the classes I use in the JSP ?
> > > 3. How can I make sure that this class is not available in the
> > > workingDir, other than deleting it EVERYTIME.
> > >
> > > Thanks
> > > Anish
> >
>
>
-
How to compile jsp project on the plateform of Myeclipse and jboss
hi
I m new in jboss application server with myeclipse plateform.
im unable to solve this error.which are occured doring the starting of server in my eclipse.
the error is:-----
13:12:41,484 INFO [Server] Starting JBoss (MX MicroKernel)...
13:12:41,500 INFO [Server] Release ID: JBoss [Zion] 4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)
13:12:41,515 INFO [Server] Home Dir: C:\Program Files\jboss-4.0.4.GA
13:12:41,515 INFO [Server] Home URL: file:/C:/Program Files/jboss-4.0.4.GA/
13:12:41,515 INFO [Server] Patch URL: null
13:12:41,515 INFO [Server] Server Name: default
13:12:41,515 INFO [Server] Server Home Dir: C:\Program Files\jboss-4.0.4.GA\server\default
13:12:41,515 INFO [Server] Server Home URL: file:/C:/Program Files/jboss-4.0.4.GA/server/default/
13:12:41,531 INFO [Server] Server Log Dir: C:\Program Files\jboss-4.0.4.GA\server\default\log
13:12:41,531 INFO [Server] Server Temp Dir: C:\Program Files\jboss-4.0.4.GA\server\default\tmp
13:12:41,531 INFO [Server] Root Deployment Filename: jboss-service.xml
13:12:44,015 INFO [ServerInfo] Java version: 1.4.2_05,Sun Microsystems Inc.
13:12:44,015 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.2_05-b04,Sun Microsystems Inc.
13:12:44,015 INFO [ServerInfo] OS-System: Windows XP 5.1,x86
13:12:45,750 INFO [Server] Core system initialized
13:12:55,515 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resource:log4j.xml
13:13:09,218 INFO [WebService] Using RMI server codebase: http://shabrez:8083/
13:13:19,578 INFO [MailService] Mail Service bound to java:/Mail
13:13:20,484 INFO [NamingService] JNDI bootstrap JNP=/0.0.0.0:1099, RMI=/0.0.0.0:1098, backlog=50, no client SocketFactory, Server SocketFactory=class org.jboss.net.sockets.DefaultSocketFactory
13:13:20,718 INFO [SubscriptionManager] Bound event dispatcher to java:/EventDispatcher
13:13:25,109 INFO [CorbaNamingService] Naming: [IOR:000000000000002B49444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578744578743A312E3000000000000200000000000000D8000102000000000E3139322E3136382E302E313331000DC8000000114A426F73732F4E616D696E672F726F6F74000000000000050000000000000008000000004A414300000000010000001C00000000000100010000000105010001000101090000000105010001000000210000005000000000000000010000000000000024000000200000007E00000000000000010000000E3139322E3136382E302E313331000DC9000000000000000000000000000000000000000000000000000000000000002000000004000000000000001F0000000400000003000000010000002000000000000000020000002000000004000000000000001F0000000400000003]
13:13:25,812 INFO [CorbaTransactionService] TransactionFactory: [IOR:000000000000003049444C3A6F72672F6A626F73732F746D2F69696F702F5472616E73616374696F6E466163746F72794578743A312E30000000000200000000000000D8000102000000000E3139322E3136382E302E313331000DC8000000144A426F73732F5472616E73616374696F6E732F46000000050000000000000008000000004A414300000000010000001C00000000000100010000000105010001000101090000000105010001000000210000005000000000000000010000000000000024000000200000007E00000000000000010000000E3139322E3136382E302E313331000DC9000000000000000000000000000000000000000000000000000000000000002000000004000000000000001F0000000400000003000000010000002000000000000000020000002000000004000000000000001F0000000400000003]
13:13:27,875 INFO [Embedded] Catalina naming disabled
13:13:28,140 INFO [ClusterRuleSetFactory] Unable to find a cluster rule set in the classpath. Will load the default rule set.
13:13:28,140 INFO [ClusterRuleSetFactory] Unable to find a cluster rule set in the classpath. Will load the default rule set.
13:13:29,390 INFO [Http11BaseProtocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
13:13:29,390 INFO [Catalina] Initialization processed in 1250 ms
13:13:29,406 INFO [StandardService] Starting service jboss.web
13:13:29,406 INFO [StandardEngine] Starting Servlet Engine: Apache Tomcat/5.5.17
13:13:29,562 INFO [StandardHost] XML validation disabled
13:13:29,640 INFO [Catalina] Server startup in 250 ms
13:13:30,671 INFO [TomcatDeployer] deploy, ctxPath=/invoker, warUrl=.../deploy/http-invoker.sar/invoker.war/
13:13:31,906 INFO [WebappLoader] Dual registration of jndi stream handler: factory already defined
13:13:33,515 INFO [TomcatDeployer] deploy, ctxPath=/, warUrl=.../deploy/jbossweb-tomcat55.sar/ROOT.war/
13:13:34,015 INFO [TomcatDeployer] deploy, ctxPath=/jbossws, warUrl=.../tmp/deploy/tmp13610jbossws-exp.war/
13:13:34,531 INFO [TomcatDeployer] deploy, ctxPath=/jbossmq-httpil, warUrl=.../deploy/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
13:13:35,359 INFO [TomcatDeployer] deploy, ctxPath=/web-console, warUrl=.../deploy/management/console-mgr.sar/web-console.war/
13:13:39,453 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-local-jdbc.rar
13:13:39,593 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-ha-xa-jdbc.rar
13:13:39,687 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-local-jdbc.rar
13:13:39,781 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jboss-xa-jdbc.rar
13:13:39,906 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/jms/jms-ra.rar
13:13:40,031 INFO [RARDeployment] Required license terms exist, view META-INF/ra.xml in .../deploy/mail-ra.rar
13:13:44,234 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:name=DefaultDS,service=DataSourceBinding' to JNDI name 'java:DefaultDS'
13:13:45,640 INFO [A] Bound to JNDI name: queue/A
13:13:45,656 INFO Bound to JNDI name: queue/B
13:13:45,656 INFO [C] Bound to JNDI name: queue/C
13:13:45,656 INFO [D] Bound to JNDI name: queue/D
13:13:45,656 INFO [ex] Bound to JNDI name: queue/ex
13:13:45,718 INFO [testTopic] Bound to JNDI name: topic/testTopic
13:13:45,734 INFO [securedTopic] Bound to JNDI name: topic/securedTopic
13:13:45,734 INFO [testDurableTopic] Bound to JNDI name: topic/testDurableTopic
13:13:45,750 INFO [testQueue] Bound to JNDI name: queue/testQueue
13:13:46,000 INFO [UILServerILService] JBossMQ UIL service available at : /0.0.0.0:8093
13:13:46,140 INFO [DLQ] Bound to JNDI name: queue/DLQ
13:13:46,609 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:name=JmsXA,service=ConnectionFactoryBinding' to JNDI name 'java:JmsXA'
13:13:46,750 ERROR [MainDeployer] Could not create deployment: file:/C:/Program Files/jboss-4.0.4.GA/server/default/deploy/helloword.war/
java.lang.UnsupportedClassVersionError: com/jbosstest/testJboss (Unsupported major.minor version 49.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at org.jboss.ws.server.WebServiceDeployerJSE.isWebserviceDeployment(WebServiceDeployerJSE.java:151)
at org.jboss.ws.server.WebServiceDeployer.create(WebServiceDeployer.java:101)
at org.jboss.ws.server.WebServiceDeployerJSE.create(WebServiceDeployerJSE.java:66)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy41.create(Unknown Source)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy6.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:464)
at java.lang.Thread.run(Thread.java:534)
13:13:47,000 INFO [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
13:13:47,625 INFO [TomcatDeployer] deploy, ctxPath=/testproject, warUrl=.../deploy/testproject.war/
13:13:48,578 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
--- Incompletely deployed packages ---
org.jboss.deployment.DeploymentInfo@abba8a12 { url=file:/C:/Program Files/jboss-4.0.4.GA/server/default/deploy/helloword.war/ }
deployer: MBeanProxyExt[jboss.web:service=WebServer]
status: Deployment FAILED reason: com/jbosstest/testJboss (Unsupported major.minor version 49.0)
state: FAILED
watch: file:/C:/Program Files/jboss-4.0.4.GA/server/default/deploy/helloword.war/WEB-INF/web.xml
altDD: null
lastDeployed: 1148111026703
lastModified: 1147940958000
mbeans:
13:13:48,796 INFO [Http11BaseProtocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
13:13:49,125 INFO [ChannelSocket] JK: ajp13 listening on /0.0.0.0:8009
13:13:49,312 INFO [JkMain] Jk running ID=0 time=0/328 config=null
13:13:49,328 INFO [Server] JBoss (MX MicroKernel) [4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)] Started in 1m:7s:797ms
plz send me the solution of this error.
Thanks.I m new in jboss application server with myeclipse plateform.
im unable to solve this error.which are occured doring the starting of server in my eclipse.
How to compile jsp project on the plateform of Myeclipse and jboss
hi :-) this is not eclipse forum and not that sure about your problem but i'll try to answer :-)
i'm not sure how you create your war but there something wrong with your web.xml. kindly check it :-)
by d way, you can deploy your project in my-eclipse by
- right click on the project then select my-eclipse > Add and Remove Project Deployment's
- a new window will open and you can now configure how you deploy your project :-)
other alternative edit your jboss-service.xml then put something like this
<attribute name="URLs">deploy/, file:/D:/workspace/deploy</attribute>
(note, change the path according to your needs)
regards, -
Different session handling of weblogic on SP2 and SP3
I have set up 2 weblogic servers which are using the same cookie name, and having
the same webapp name, on the same physical machine thus
http://127.0.0.1:7220/test (Server A).
http://127.0.0.1:9999/test (Server B).
Using Weblogic 6.1 Service Pack 2
1. Access Server A
- Server A generate a new Session ID "123456...."
2. Redirect Link from Server A to Server B
3. Access Server B
- Server B generate a new Session ID "987654..."
4. Redirect Link from Server B to Server A
5. Access Server A
- Reused the same session ID "123456...."
Using Weblogic 6.1 Service Pack 3
1. Access Server A
- Server A generate a new Session ID "123456...."
2. Redirect Link from Server A to Server B
3. Access Server B
- Server B generate a new Session ID "987654..."
4. Redirect Link from Server B to Server A
5. Access Server A
- Regenerate a new session ID "ABCDEFGHI...."
Why weblogic server handle session differently in SP2 and SP3??
I think this was a bug in SP3. You could raise a support ([email protected]) call to
confirm.
Rick Bongpipat wrote:
> "Rick Bongpipat" <[email protected]> wrote:
> >
> >I have set up 2 weblogic servers which are using the same cookie name,
> >and having
> >the same webapp name, on the same physical machine thus
> >
> >http://127.0.0.1:7220/test (Server A).
> >http://127.0.0.1:9999/test (Server B).
> >
> >Using Weblogic 6.1 Service Pack 2
> >
> >1. Access Server A
> >- Server A generate a new Session ID "123456...."
> >2. Redirect Link from Server A to Server B
> >3. Access Server B
> >- Server B generate a new Session ID "987654..."
> >4. Redirect Link from Server B to Server A
> >5. Access Server A
> >- Reused the same session ID "123456...."
> >
> >Using Weblogic 6.1 Service Pack 3
> >
> >1. Access Server A
> >- Server A generate a new Session ID "123456...."
> >2. Redirect Link from Server A to Server B
> >3. Access Server B
> >- Server B generate a new Session ID "987654..."
> >4. Redirect Link from Server B to Server A
> >5. Access Server A
> >- Regenerate a new session ID "ABCDEFGHI...."
> >
> >Why weblogic server handle session differently in SP2 and SP3??
>
> In relation to previous question.
>
> I have 3 qns about session creation behaviour:
>
> 1. When a web container receives a session cookie (eg. JSESSIONID) whose session
> id does not exists in this
> server, should the server create a new session ?
>
> 2. If a session is to be created because there is a session cookie, then should
> the new session id
> be the one sent or should it be a newly generated session id ?
>
> 3. If a new session id is to be generated, then should the new session id be used
> to overwrite that in the cookie
> and send it back to the client ?
Rajesh Mirchandani
Developer Relations Engineer
BEA Support
-
How to run JSP pages in weblogic 8.1 sp2
hi frnzs,
plese give me some idea about how to run JSP pages in weblogic server.enen i dont know hw to fly palne otherwise i can definitely give u sm guides abt that......
-
WL SP4 jsp compilation bug? - redeployment
Last week I've upgraded WebLogic from SP2 to SP4. Since then after each application redeploy i'm getting jsp compilation error.<br><br>
The only solution I've found is to restart the cluster. Then it works fine until next redeployment.<br><br>
It looks like WebLogic couldn't find some libraries. Maybe it is problem with ClassLoader.<br><br>
Did you encounter any behaviour like this? Is it some kind of WebLogic SP4 bug?<br><br>
<br>
####<Apr 11, 2005 6:29:25 PM CEST> <Error> <HTTP> <K2DA002> <man1ITG20> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <<WLS Kernel>> <> <BEA-101017> <[ServletContext(id=8986766,name=plans,context-path=/plans)] Root cause of ServletException.
java.lang.Throwable: Failed to compile JSP /login/remotelogin.jsp<html><br>
<head><br>
<title>Javelin JSP compilation error</title><br>
</head><br>
<body><br>
<br>
<b>Compilation of JSP File '/login/remotelogin.jsp' <font color=#FF0000>failed</font>:</b><HR><br>
<pre><br>
Errors found in <br>man1ITG20/stage/integration/TD/login/remotelogin.jsp:
Error at line 17 column 1:<br>
Description: Package org.apache contains no member package or type of this name.
<br>
Error at line 17 column 1:
Description: Package org.apache contains no member package or type of this name.
<br>
Error at line 55 column 2:
Description: Package org.apache contains no member package or type of this name.
<br>
Error at line 56 column 4:
Description: Package org.apache contains no member package or type of this name.
<br>
Found 4 error(s) and 0 warning(s).
<br>
</pre><br>
</body></html><br>
<br>
at weblogic.servlet.jsp.WlwJspStub.compilePage(WlwJspStub.java:207)
at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:238)
at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:188)
at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:535)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:373)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:463)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at com.bea.wlw.netui.pageflow.PageFlowJspFilter.doFilter(PageFlowJspFilter.java:223)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6724)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3764)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2644)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)I've a similiar problem when redeploying apps on WL SP4/Jrockit JVM on Linux. The redeploy results in a NoClassDefFound error, while a fresh deployment works fine. Two points to note here:
- The domain is on a NFS mounted drive - The redeploy works fine if the domain is on a local disk.
- The redeploy works fine if I use the bundled JDK142_05
Here's the exception -
--------------- nested within: ------------------
weblogic.management.ManagementException: - with nested exception:
[java.lang.NoClassDefFoundError: com/mypackage/common/util/LoggerBase]
at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.prepare()V(SlaveDeployer.java:2396)
at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(Lweblogic.management.deploy.OamVersion;Lweblogic
.management.runtime.DeploymentTaskRuntimeMBean;Z)V(SlaveDeployer.java:866)
at weblogic.management.deploy.slave.SlaveDeployer.prepareDelta(Lweblogic.management.deploy.OamDelta;Lweblogic.managem
ent.deploy.OamVersion;ZLjava.lang.StringBuffer;)Z(SlaveDeployer.java:594)
at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(Ljava.util.ArrayList;Z)V(SlaveDeployer.java:508)
at weblogic.drs.internal.SlaveCallbackHandler$1.execute(Lweblogic.kernel.ExecuteThread;)V(SlaveCallbackHandler.java:2
5)
at weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest;)V(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:178)
at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown Source)
> -
JSP compiler reading the web.xml file?
Hi,
I am trying to use the weblogic JSP compiler (weblogic.jspc) to
pre-compile some JSP that use custom tags. Does the compiler
read the web.xml file if there is one? In particular the taglib
elements in that file so that the compiler understands the
<%@ taglib ... %> directive.
In the JSP I try to compile I use this statement to declare a taglib:
<%@ taglib uri="xyz/xyz-taglib" prefix="xyz" %>
and in my web.xml I have:
<taglib>
<taglib-uri>xyz/xyz-taglib</taglib-uri>
<taglib-location>/WEB-INF/tlds/xyz.tld</taglib-location>
</taglib>
When I try to compile the JSP I get the following error:
Could not parse embedded JSP code: weblogic.utils.ParsingException: nested
IOException: java.io.IOException: cannot resolve 'xyz/xyz-taglib' into a
valid tag library.
Any ideas how I can resolve this?
In advance thank you for any help.
Florian
open it in a text editor and modify it.
% -
JSP compiler obfuscates generated servlet debug line numbers
Here's something that's been baffling me for a couple of days now.
When WebLogic parses a JSP into servlet Java source, and then compiles the Java
source into a class, it seems to perform a further step to obfuscate debug line
numbers in the _jspService method. This converts the debug line numbers from Java
source code line numbers into JSP line numbers.
At first sight, this may appear to be useful- it means that when an exception
is thrown then it references a line number in the original JSP rather than one
in the generated servlet. However, it actually makes life more difficult when
you consider included JSPs.
Suppose you have a file loginresult.jsp, which uses @include to include a header.jsp
and footer.jsp, both of which contain dynamic content. When WebLogic converts
line numbers, it ignores the JSP that the code came from, so this causes a many-to-one
mapping of line numbers. When an error occurs, the exception will tell you the
line number that it came from, but it won't tell you which JSP caused it. The
many-to-one mapping ensures a loss of information- and no way of retrieving the
real line numbers.
This is an even bigger nuisance when trying to debug JSPs- the debugger hops around
in the generated servlet file without giving any clue as to whereabouts it really
is in the code.
My question is: is there any way of switching off this post-processor behaviour?
One obvious way would be to locate the WebLogic class that does this post-processing,
stub it out and run WebLogic with this class higher up in the classpath. But that's
a last resort.
Secondly, would there be any other impact in turning off this behaviour? Do other
parts of WebLogic rely on this?
Thanks in advance,
Kevin.
Actually, this option turns line-number table replacement on and off, for example,
with jsp like this:
test.jsp
<%
throw new Exception();
%>
and weblogic.xml:
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA
Systems, Inc.//DTD Web Application 7.0//EN"
"http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd">
<weblogic-web-app>
<jsp-descriptor>
<jsp-param>
<param-name>debug</param-name>
<param-value>true</param-value>
</jsp-param>
</jsp-descriptor>
</weblogic-web-app>
the stacktrace looks like this (note line number 2 - this is JSP line number):
java.lang.Exception
at jsp_servlet.__test._jspService(test.jsp:2)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:945)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:332)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:376)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5360)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:721)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3043)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2468)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
and with debug option turned off:
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA
Systems, Inc.//DTD Web Application 7.0//EN"
"http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd">
<weblogic-web-app>
<jsp-descriptor>
<jsp-param>
<param-name>debug</param-name>
<param-value>false</param-value>
</jsp-param>
</jsp-descriptor>
</weblogic-web-app>
exception stacktrace looks like this (note that line number now is from generated .java file):
java.lang.Exception
at jsp_servlet.__test._jspService(__test.java:87)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:945)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:332)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:376)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5360)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:721)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3043)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2468)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
Kevin Thomas <[email protected]> wrote:
> But this isn't useful, as you don't know which JSP the line number is referring
> to! (did it come from the main JSP, or one of the files that it included?)
> Turning debug off is not an answer- because that will lose other useful information
> that is useful to the debugger.
> Kevin.
> "Dimitri I. Rakitine" <[email protected]> wrote:
>>Actually, this is useful when you want to debug .jsp's and not generated
>>..java files. Did you try setting 'debug' jsp-param in the weblogic.xml
>>to
>>false? I think it turns class postprocessing on and off.
>>
>>Kevin Thomas <[email protected]> wrote:
>>
>>> Here's something that's been baffling me for a couple of days now.
>>
>>> When WebLogic parses a JSP into servlet Java source, and then compiles
>>the Java
>>> source into a class, it seems to perform a further step to obfuscate
>>debug line
>>> numbers in the _jspService method. This converts the debug line numbers
>>from Java
>>> source code line numbers into JSP line numbers.
>>
>>> At first sight, this may appear to be useful- it means that when an
>>exception
>>> is thrown then it references a line number in the original JSP rather
>>than one
>>> in the generated servlet. However, it actually makes life more difficult
>>when
>>> you consider included JSPs.
>>
>>> Suppose you have a file loginresult.jsp, which uses @include to include
>>a header.jsp
>>> and footer.jsp, both of which contain dynamic content. When WebLogic
>>converts
>>> line numbers, it ignores the JSP that the code came from, so this causes
>>a many-to-one
>>> mapping of line numbers. When an error occurs, the exception will tell
>>you the
>>> line number that it came from, but it won't tell you which JSP caused
>>it. The
>>> many-to-one mapping ensures a loss of information- and no way of retrieving
>>the
>>> real line numbers.
>>
>>> This is an even bigger nuisance when trying to debug JSPs- the debugger
>>hops around
>>> in the generated servlet file without giving any clue as to whereabouts
>>it really
>>> is in the code.
>>
>>> My question is: is there any way of switching off this post-processor
>>behaviour?
>>> One obvious way would be to locate the WebLogic class that does this
>>post-processing,
>>> stub it out and run WebLogic with this class higher up in the classpath.
>>But that's
>>> a last resort.
>>
>>> Secondly, would there be any other impact in turning off this behaviour?
>>Do other
>>> parts of WebLogic rely on this?
>>
>>> Thanks in advance,
>>
>>> Kevin.
>>
>>--
>>Dimitri
>>
Dimitri
-
Precompile JSP's in Weblogic 5.1/SP6
Hello,
How do you get the precomplilation of JSP's to work in 5.1? I have
seen some emails on this mailing list about how to precompile the
JSP's in 6.0 but I would like to know how to do it in 5.1. looking
at the documentation here: http://www.weblogic.com/docs51/classdocs/API_jsp.html#register
In the weblogic properties file we have them set as follows:
weblogic.httpd.documentRoot=htdocs/
# WEBLOGIC JSP PROPERTIES
# Sets up automatic page compilation for JSP. Adjust init argsfor
# directory locations and uncomment to use.
weblogic.httpd.register.*.jsp=weblogic.servlet.JSPServlet
weblogic.httpd.initArgs.*.jsp=\
pageCheckSeconds=1,\
keepgenerated=true,\
compileCommand=d:/jdk1.2.2/bin/javac.exe,\
workingDir=D:/Mediaprise/mpsite/WebLogicServer,\
verbose=true
that should be picking up any JSP's underneath the document root
folder (htdocs, in this case) and precompile them to the working
dir. now we have JSP's in the htdocs folder and a whole stucture
of JSP's underneath the htdocs folder in a folder called JSP with
it's own file and directory structure. The weblogic.log file shows
that the above properties are being set correctly on startup but
no precompilation seems to be happening to the working dir. any
ideas on how to make this work in 5.1??
I am working on Weblogic 5.1 with SP6.
Thanks,
Gagan
In WebLogic 6.0 register each jsp in the web.xml with a <servlet-name>, <jsp-file>
and <load-on-startup>. For example:
<web-app>
<servlet>
<servlet-name></servlet-name>
<jsp-file></jsp-file>
<load-on-startup></load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name></servlet-name>
<url-pattern></url-pattern>
</servlet-mapping>
</web-app>
The optional value of load-on-startup element must be a positive integer indicating
the order in which the servlet should be loaded.
In WebLogic 6.1 set the precompile parameter in weblogic.xml.
<jsp-descriptor>
<jsp-param>
<param-name>
precompile
</param-name>
<param-value>
true
</param-value>
</jsp-param>
</jsp-descriptor>
Vaibhav wrote:
> This solution is with web.xml, if I am
> using weblogic.properties only and no web.xml, How do I specify precompile=true ?
-
JSP compilation: code too large on SP14
Hello,
I developed EP application based on JSPDynPage on SP13 with big jsp file. This application was running on SP13 without problem.
Later, we upgraded to SP14 and application logged exception: "code too large" when compiling jsp.
I tried to devide the big jsp to several jsp, but problems remains the same.
I searched SDN. I tried set jsp.bigmode.delimit.size to 10000, 20000 and 1. Nothing helps.
I followed OSS Note:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes/bc-jas/~form/handler{5f4150503d3030323030363832353030303030303031393732265f4556454e543d444953504c4159265f4e4e554d3d383230323832}
Best regards,
Josef MotlHi Detlev,
the OSS number is 820282. But I was unable to wiew this message on http://service.sap.com. So below I put snapshot of this message.
Regards,
Josef
Portal JSP compiler fails when code generated is too long
SAP Note Number: 820282
Symptom
In a few cases, the compilation of jsp files fails (if their size is very large) because the generated Java code exceeds the 65K limitation (per method) of SUN JVM or the system crashes when it tries to load a class file that was not correctly constructed (method size > 65K).
Other terms
JSP, Portal, too long, compilation, compiler, over size, try
Reason and Prerequisites
SUN JVM and othes do not support a method which has more than 65K of byte code.
Solution
The fix is available in +SP2 PL 31 and +EP6 SP11 Patch 2.
Once you have installed the fix, you need to edit the file irj\root\WEB-INF\portal\system\properties\prtCentral.properties.bak.
Check if the property "jsp.bigmode.delimit.size" is present. Otherwise add the line "jsp.bigmode.delimit.size=10000", rename the file to "prtCentral.properties" and restart the server.
The number is the limit size in bytes when the big jsp mode is enabled (you should therefore change the Java template generated from the jsp file to a size larger than the limit)
In rear cases where JSP files are including sources prior to their compilation you should set the parameter to a lower value. In the extreme case you can use jsp.bigmode.delimit.size=1 and enable the big mode jsp optimization for all files.
To deactive the big jsp mode, set jsp.bigmode.delimit.size=-1
Header Data
Release Status Released for Customer
Released on 21.07.2005
Priority Correction with medium priority
Category Advance development
Primary Component BC-JAS-PIN-PRT Portal Runtime
Maybe you are looking for
-
[Solved] Libreoffice 3.6.1.4 don't start
Hello, please excuse my bad english. I have a problem. Since the libreoffice update from 3.5.6 to 3.6.1.4 libreoffice don't start. For a short time i see the splash-screen and that's it. In the terminal, when i type soffice or lowriter or libreoffice
-
Can you delete the private brower option
-
SAP Conversion Agent for PI 7.1 EHP 1 and Windows 2008 Support
Hello I have read that some people were able to run SAP Conversion Agent on a PI 7.1 EHP1 Installation on Windows 2008 Sever. But in the Product Availability Matrix there is no support for 2008 yet. In the SAP Library (http://help.sap.com/saphelp_nwp
-
Managing CAL ABAP on HANA instance and removing the secondary windows instance?
When you setup the ABAP on HANA CAL instance with AWS you get two AWS instances. One which is the ABAP on HANA server and one which is a Windows system holding copies of the development tools, etc. I never use this second instance as I log on from my
-
I need load jar in ClassLoad, I did write code, but he not work. what is the problem? package jar; import java.io.File; import java.io.IOException; import java.lang.reflect.Method; import java.net.MalformedURLException; import java.net.URL; import ja