Bug in weblogic classloader?

          Hi,
          has any body seen this exception before with respect to war files and have a known
          work around?
          java.lang.LinkageError: loader constraints violated when linking org/xml/sax/InputSource
          class
          We get this error if we include xerces.jar in the web-inf/lib and set PreferWebInfClasses=true.
          also, if we do not set the PreferWebInfClasses it fails to see classes which extend
          classes in the system class path and are in web-inf\classes.
          We are using WLS 7.0.
          thanks,
          Mahesh

Hi Mahesh,
 thats cause you got more than one sax.jar in your classpath.
 Check which versions are there and try to have only one.
 fear
 "mahesh murthy" <[email protected]> wrote:
 >
 >Hi,
 >
 >has any body seen this exception before with respect to war files and
 >have a known
 >work around?
 >
 >java.lang.LinkageError: loader constraints violated when linking org/xml/sax/InputSource
 >class
 >
 >We get this error if we include xerces.jar in the web-inf/lib and set
 >PreferWebInfClasses=true.
 >
 >also, if we do not set the PreferWebInfClasses it fails to see classes
 >which extend
 >classes in the system class path and are in web-inf\classes.
 >
 >We are using WLS 7.0.
 >
 >thanks,
 >
 >Mahesh
 >
 >

Similar Messages

Signature Validation Bug in WebLogic 10.3

I believe I have come across a bug in WebLogic 10.3. I send a signed soap message to the server, but it gets rejected because it fails validation. Fair enough... Took a look at the trace and here is what I found:
<Sep 23, 2008 9:41:03 AM EDT> <Info> <> <BEA-000000> <transformed data: [OctetData, as String in platform default encoding:<soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="id-18724844"><ser:deposit xmlns:ser="http://services/">
 <arg0>100</arg0>
</ser:deposit></soapenv:Body>]>
<Sep 23, 2008 9:41:03 AM EDT> <Info> <> <BEA-000000> <digest input: (as string, platform default encoding) <soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="id-18724844"><ser:deposit xmlns:ser="http://services/">
<arg0>100</arg0>
</ser:deposit></soapenv:Body>>
ReferenceImpl.ValidateResultImpl:
refURI: #id-18724844
status: false
digestValue: 1B35E823E5137581751EF6A8AB8DD8943D21F024
unmarshalledDigestValue: B3DAB5E81C128858C84DBB05B361C8736C972443
The reason the digest does not match is because WebLogic is not receiving the correctly formatted soap message. For some reason, weblogic does not see the carriage return between </ser:deposit> and </soapenv:Body>. I send the same message to a WebLogic 10.0 server and it does not run into this problem. I use soapUI 2.0.2 as my client.

instead of import weblogic.security.SubjectUtils; use import weblogic.security.spi.WLSUser; and get the username as below
Set users = subject.getPrincipals(WLSUser.class);
 Iterator iter = users.iterator();
 while (iter.hasNext()){
 userName = ((WLSUser)iter.next()).getName();
 System.out.println(userName);
this returns you the username

Static variable, a bug in applet classloader, Java plug-in?

I found a potential bug in java plug-in.
Environment,
1. IE 6.0
2. Windows XP
3. JRE 1.3.1.06 and JRE 1.4.1.01
Steps,
1. build a very simple applet (attached below)
2. embed the applet into a .html page.
3. enable java plug-in for IE and Netscape.
4. launch the .html page in either of the two browsers.
5. for the 1st time, I can see 'tmp = 0' in the java console window.
6. keep the browser open, browse to 'www.google.com'
7. click 'Back' button of the browser.
8. I notice 'tmp = 1' in the java console window.
9. if I browse to google.com and back again, it will display 'tmp = 2'. and the number will keep on increasing if I repeat those steps.
10. But if I press F5 to refresh the page, the log message will go back to 'tmp = 0'. and if I press 'x' inthe console window to clean up the classloader cache, I will get 'tmp = 0'. If I close the browser and open a new one, I will still get 'tmp = 0', which is what the applet should output.
11. If I click 't' in the console window to list the thread while I am in the 'google' page, I can't see the applet thread, which means the applet should have been destroyed.
12. No matter I try 'g' to do garbage collect, or 'f' to finalize objects, the problem still happens. the only solution is what I did in the step 10.
Is it a bug in the classloader or the JRE itself? Why the value of the static variable won't be cleaned up along with the applet?
----------- HERE IS THE APPLET --------------------
import java.applet.Applet;
public class AA extends Applet
private static long tmp = 0;
public void init() {
System.out.println("tmp value = " + tmp);
tmp++;
public void start() {}
public void stop() {}
public void destroy() {}

Static values are stored in the class. Once a class is loaded into a classloader, it cannot be unloaded (the only thing you can do is use another classloader).
Apparently, the classloader cache allows sharing of classloaders between applet instances. Perhaps F5 (reload) causes the classloader cache to be cleared.
I don't see any bug. When developing applications or applets that must run in the same JVM, you should program defensively and avoid using static values which can change over time.

Optimistic Locking - Possible bug with Weblogic

After extensive testing of a j2ee application Im involved with, it would appear their exists a problem with using Weblogic's Optimistic Concurrency (OL) mechanism.
The exact problem is as follows:
The ejbCreate and ejbRemove methods of a particular entity bean are as follows:
public abstract class ProductBean implements javax.ejb.EntityBean {
ejbCreate(){
FolderEntityHome folderEH = FolderComponent.getFolderEntityHome();
folderEH.create(getId());
ejbRemove(){
FolderEntityHome folderEH = FolderComponent.getFolderEntityHome();
try {
FolderBean folderEH.findByProductId(getId());
catch(InvalidAccessRightsException iare)
throw new RemoveException();
Previously before OL was added when a RemoveException was thrown, this would cause the ejbRemove exception to fail, thus both the product and folder would still exist.
After adding OL, when an InvalidAccessRightsException occurs giving rise to a RemoveException being thrown, weblogic simply ignores the RemoveException and deletes the Product even though the Folder could not be deleted. This causes system errors when users try to access the folder which contains a link to a product which no longer exists!
Is anyone aware of this particular problem? Is it indeed a bug with Weblogic? For clarity, I believe I am using version 8.1 and the way in which I have implemented OL is to use an additional version column in the underlying tables for all entity beans.

In case anyone's interested, it appears from further testing that the problem I've been having in the way the RemoveException behaves is down to the difference in which version 6.0 treats this exception compared to version 8.1!
In version 6.0, if you threw a RemoteException at any point in the ejbRemove(), the entity would not be removed!
In version 8.1, something wierd happens. If a RemoteException() is thrown in the ejbRemove() and sometime during the same transaction at the point of commit, the entity on which the exception is thrown is attempted to be accessed (through a finder), then the entity continues to be deleted! If on the other hand, a RemoveException is thrown and no access/modification is attempted on that entity within the same transaction, then at the point of commit, the entity is not removed!
Seems this is indeed a problem which needs to be addressed in future releases.
Message was edited by:
rotan_imretxe
Message was edited by:
rotan_imretxe

New bee weblogic classloader

I read some articles on weblogic classloading. This is what is my understanding any jar files needed by both ejb and war shoud be placed in the root of an ear file ,suppose i need log4j for both ejb and war i place it inside ear and add amanifest entry in ejb , and war can also see log4j becaue the war parent class-loader is ejb classloader.Now suppose I need struts jar for my war , Should I just place in web-inf/lib and no entry in war manifest ? is this right?
I am facing lot of troubles with my war classloader,any utility class I call in war I get get class not found exception, what stops war classloader not to see classes inside jar inside web-inf/lib ?

Isn't the documentation link I responded with pretty clear? APP-INF is a directory directly in the root of the EAR and you can create it yourself.
Class Loading for Shared Classes+
The classes and libraries stored under APP-INF/classes and APP-INF/lib are available to all modules in the Enterprise Application. The application classloader always attempts to resolve class requests by first looking in APP-INF/classes, then APP-INF/lib.
If you want to isolate jars and classes to a particular Web module, then you can put them in the Web module's WEB-INF/lib or use the manifest mechanism that you referenced. I find the manifest mechanism to be brittle in comparison, but it is standard and portable. Putting jars that I want in APP-INF/lib for universal access and WEB-INF/lib for web module isolated access is easier in my opinion because the location of the jar file denotes your intention.
http://edocs.bea.com/wls/docs103/programming/classloading.html#wp1069420

Backslash in string: bug in Weblogic Studio?

I'm trying to create a string variable containing a file path that is the concatenation
of a directory path and a file name. I tried to write an expression like this
one for the new value for $FilePath:
$FileDirectory + "\\" + $FileName
However, the Set Workflow Variable dialog fails, saying
Unclosed string, "\" + $Filename"
In other words, the dialog is right-associating the backslash, assuming that I'm
trying to escape the quotation mark, not the backslash itself. Given this, how
can I possibly enter a string that contains nothing but a single backslash? Unless
I'm missing something, this is a bug in Weblogic Studio.
I may have to resort to creating a business operation that calls Java to build
the filename. That seems a bit drastic, but I don't see any other way around this.

I have found a way around this that is not too messy.
1. Assign the string containing the single backslash to a string variable. For
example, set $Separator to "\\".
2. Use the variable in the concatenation expression. For example $FilePath + $Separator
+ $FileName.
Attempting to put the literal in the concatenation expression fails with the aforementioned
error message. It's still a bug, but there is a workaround.

Bug in weblogic.rmic: produces incorrect IDL in factory decls.

My EJB when producing IDL produces incorrect IDL: One of the outputs
is java/net/URL.idl but when I try to compile it using Inprise
visibroker
4.0 for C++, I get the following parse error:
/opt/inprise/vbrokercpp/bin/idl2cpp -no_servant -idl_strict
-I/opt/inprise/vbrokercpp/idl -tie -namespace -no_pretty_print -Iidl
-src_suffix cpp -root_dir cpp/java/lang idl/java/lang/ClassLoader.idl
idl/java/net/URL.idl: 76:syntax error after )
idl/java/net/URL.idl: 76:expected a[n]: ;
idl/java/net/URL.idl: 76:instead of raises
idl/java/net/URL.idl: 78:syntax error after )
idl/java/net/URL.idl: 78:expected a[n]: ;
idl/java/net/URL.idl: 78:instead of raises
idl/java/net/URL.idl: 82:java::net::URLStreamHandler not found (expected
type name)
idl/java/net/URL.idl: 83:syntax error after )
idl/java/net/URL.idl: 83:expected a[n]: ;
idl/java/net/URL.idl: 83:instead of raises
idl/java/net/URL.idl: 84:java::net::URLStreamHandler not found (expected
type name)
idl/java/net/URL.idl: 88:syntax error after )
idl/java/net/URL.idl: 88:expected a[n]: ;
idl/java/net/URL.idl: 88:instead of raises
6 errors
This is an error in the IDL: factory methods are trying to raise
exceptions; however this is disallowed by the OMG IDL specification
version 2.3:
<init_dcl> ::= "factory" <identifier>"(" [ <init_param_decls> ]
<init_param_decls> ::= <init_param_decl> { , <init_param_decl> }
<init_param_decl> ::= <init_param_attribute> <param_type_spec>
<simple_declarator>
<init_param_attribute> ::= "in"
As you can see, when using the keyword "factory" there is no "raises"
clause allowed by the grammar.
This is one of a few instances of the problem (this problem only
occurred
in one file but for several methods):
factory
create__CORBA_WStringValue__CORBA_WStringValue__CORBA_WStringValue( in
::CORBA::WStringValue arg0, in ::CORBA::WStringValue arg1, in
::CORBA::WStringValue arg2) raises (::java::net::MalformedURLEx);
-Kim.

the difference here is Thread-based security vs. Object-based security. WLS opts for the Thread-based model. this model was also
backed up by the original revisions of the JAAS spec. it's just something to take into consideration when designing applications.
.paul
Marcel Stremming wrote:
I have a SessionBean Method :
public void contextTest() throws RemoteException {
try {
System.out.println("Principal 1: " + ctx.getCallerPrincipal());
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, "t3://localhost:7001");
h.put(Context.SECURITY_PRINCIPAL, "toto");
h.put(Context.SECURITY_CREDENTIALS, "test");
Context new_ctx = new InitialContext(h);
System.out.println("Principal 2: " + ctx.getCallerPrincipal());
} catch (Exception e) {e.printStackTrace(); }
When principal "titi" invokes this Method it produces the following output:
Principal 1: titi
Principal 2: toto
As You can see the Method just replaced the Caller Context's principal stored in the ctx field without even touching it. Since
my Servlets run on the same JVM and use PassByReference calling this Method twice results in :
Principal 1: titi
Principal 2: toto
Principal 1: toto
Principal 2: toto
I think this is a Bug because it makes it quiet difficult to open two Context's at the same time.
I would like to read some opinions.

WebLogic classloader issue

Hi,
I'm trying to resolve a "cannot be cast" error on Oracle JDeveloper 11.1.2.2.0. My application is using eclipselink JPA provider, which works fine on a fresh start WLS. However, when I redeployed my application without restarting the WLS, I got a very strange runtime error:
gov.noaa.gcld.model.jpa.User cannot be cast to gov.noaa.gcld.model.jpa.User
The code is:
List<User> users = dao.findByUserLdapId(userId);
The compile has no error. I checked the classloader of the User object returned by the entityManager. This is what I've found:
1) When I did a fresh start of the WLS,
The classloader of User object in my application: weblogic.utils.classloaders.ChangeAwareClassLoader@1bf353c
The classloader of User object returned from the entity manager: weblogic.utils.classloaders.ChangeAwareClassLoader@1bf353c
The application is working fine at this time.
2) When I redeployed my application without restarting the WLS,
The classloader of User object in my application: weblogic.utils.classloaders.ChangeAwareClassLoader@14e4ae9
The classloader of User object returned from the entity manager: weblogic.utils.classloaders.ChangeAwareClassLoader@1bf353c
Now I got the "gov.noaa.gcld.model.jpa.User cannot be cast to gov.noaa.gcld.model.jpa.User" error.
It looks the WLS is using a new classloader when I redeploy my application but still using the old classoloader for eclipselink entity manager, even after I undeployed my application completely, and there's no other applications using the same persistence unit.
Does anybody know how to force the WLS to reload the eclipselink entity manager using the same classloader as the application? Our server admin will not restart the WLS when we redeploy our applications.
Thanks very much for your help!
Edited by: huaichen on Aug 8, 2012 12:00 PM

I assume you are using a non (application) managed persistence unit. For application managed persistence units you are responsible for closing the EntityManagerFactory when undeploying.
If any EntityManagerFactory are not closed, then the old persistence unit remains deployed, and will have the wrong class loader.
See,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=326552

TransformerException -- possible bug in weblogic.apache.xalan.transformer.TransformerImpl

Using WebLogic Server 6.1 SP2. Am using xslt to transform xml into html. After
repeatedly
using the same Transformer object to transform different xml documents, the Transformer
eventually becomes corrupt – sometimes after 20 or so transforms, sometimes only
after
thousands.
Once the Transformer object becomes corrupt, any additional attempt to call the
transform
method results in the following exception:
=============================
javax.xml.transform.TransformerException: -1
at weblogic.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1248)
at weblogic.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:483)
at weblogic.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1153)
at … <snip>
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at weblogic.apache.xml.utils.NodeVector.popQuick(NodeVector.java:247)
at weblogic.apache.xpath.XPathContext.popCurrentNode(XPathContext.java:552)
at weblogic.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2100)
at weblogic.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1225)
at … <snip>
=============================
Using cavaj to decompile weblogic.apache.xalan.transformer.TransformerImpl yields:
Method: applyTemplateToNode:
try
pushElemTemplateElement(elemtemplateelement1);
m_xcontext.pushCurrentNode(node);
 <snip>
catch(SAXException saxexception)
throw new TransformerException(saxexception);
finally
m_xcontext.popCurrentNode();
 <snip>
So what appears to be happening is that one of the two push calls at the beginning
of the try
block is throwing an Exception, causing the pop method to be called in the finally
block without
first having had a successful call to push. The corresponding NodeVector inside
m_xcontext
thereupon becomes corrupt, and it is only a matter of time before the above
ArrayIndexOutOfBoundsException appears.
Unfortunately, we are unable to consistently reproduce this Transformer corruption
and
currently have no idea how it happens in the first place. We figure there’s probably
some sort
of error in our xsl stylesheet which is at the root of all this, but have had
no luck in finding it.
So, two questions:
1.) Has anyone encountered this problem of having a bad xsl stylesheet which,
when applied
repeatedly on certain xml documents, can cause the Transformer to become corrupt
as a result
of calling NodeVector.pop without a corresponding call to NodeVector.push? If
so, do you have
a simple example of the type of xsl template and/or xml document which might reproduce
the
scenario.
2.) Would not the above code snippet in TransformerImpl be considered buggy in
any case,
since it should not be possible for an invalid xsl stylesheet to permanently corrupt
the
Transformer? If there’s agreement that this represents a bug in TransformerImpl,
has it been
fixed in 6.1 SP3 or higher, or in subsequent versions of the Weblogic Server?
Thanks,
John

hi,
I've just recently started getting this error too. It's completely random as
to when it occurs. My system can process hundreds of translations with no problems
and then once and awhile I get this exact error.
I'm using WebLogic v7.0 sp2. I've noticed however that this only happens on my
Windows system - I've got it running on a solairs box with no problems.
Has anyone else seen this ?
Thanks.
Jerry
"John Lame" <[email protected]> wrote:
>
Using WebLogic Server 6.1 SP2. Am using xslt to transform xml into html.
After
repeatedly
using the same Transformer object to transform different xml documents,
the Transformer
eventually becomes corrupt – sometimes after 20 or so transforms, sometimes
only
after
thousands.
Once the Transformer object becomes corrupt, any additional attempt to
call the
transform
method results in the following exception:
=============================
javax.xml.transform.TransformerException: -1
at weblogic.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1248)
at weblogic.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:483)
at weblogic.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1153)
at … <snip>
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at weblogic.apache.xml.utils.NodeVector.popQuick(NodeVector.java:247)
at weblogic.apache.xpath.XPathContext.popCurrentNode(XPathContext.java:552)
at weblogic.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2100)
at weblogic.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1225)
at … <snip>
=============================
Using cavaj to decompile weblogic.apache.xalan.transformer.TransformerImpl
yields:
Method: applyTemplateToNode:
try
pushElemTemplateElement(elemtemplateelement1);
m_xcontext.pushCurrentNode(node);
 <snip>
catch(SAXException saxexception)
throw new TransformerException(saxexception);
finally
m_xcontext.popCurrentNode();
 <snip>
So what appears to be happening is that one of the two push calls at
the beginning
of the try
block is throwing an Exception, causing the pop method to be called in
the finally
block without
first having had a successful call to push. The corresponding NodeVector
inside
m_xcontext
thereupon becomes corrupt, and it is only a matter of time before the
above
ArrayIndexOutOfBoundsException appears.
Unfortunately, we are unable to consistently reproduce this Transformer
corruption
and
currently have no idea how it happens in the first place. We figure
there’s probably
some sort
of error in our xsl stylesheet which is at the root of all this, but
have had
no luck in finding it.
So, two questions:
1.) Has anyone encountered this problem of having a bad xsl stylesheet
which,
when applied
repeatedly on certain xml documents, can cause the Transformer to become
corrupt
as a result
of calling NodeVector.pop without a corresponding call to NodeVector.push?
If
so, do you have
a simple example of the type of xsl template and/or xml document which
might reproduce
the
scenario.
2.) Would not the above code snippet in TransformerImpl be considered
buggy in
any case,
since it should not be possible for an invalid xsl stylesheet to permanently
corrupt
the
Transformer? If there’s agreement that this represents a bug in TransformerImpl,
has it been
fixed in 6.1 SP3 or higher, or in subsequent versions of the Weblogic
Server?
Thanks,
John

Serious security bug in weblogic 6.0

when I use jaas authenticated to weblogic server 6.0. everything is beatiful. but
I easily bypass the jaas authentication and could login to weblogic server 6.0
as anybody with any credential. Think about it, if I login as system and with
wrong password, and I get in , and the caller will be system.
If anyone inside weblogic team is interested in talking about it, please give
me a email. I don't want to post the way how I did it right now

This potential vulnerability has been confirmed and has been fixed in BEA WebLogic
Server 6.0 Service Pack 1 (SP1). SP1 is currently available for download from
the BEA Download Center at
http://commerce.bea.com/downloads/weblogic_server.jsp#wls.
BEA advises every Service Pack be applied as they are released. Service Packs
include a roll up of all bug fixes for each version of the product, as well as
each of the previously released Service Packs.
BEA treats security issues with the highest degree of urgency and does everything
possible to ensure the security of all customer assets. As a policy, if there
are any security-related issues with any BEA product, BEA will distribute an advisory
and instructions with the appropriate course of action.
Because the security of your site, data, and code is
our highest priority, we are committed to communicating all
security-related issues clearly and openly.
BEA has established a permission-based emailing list specifically
targeted for product security advisories. As a policy, if a user has opted in
to our emailing list and there are any security issues with the BEA product(s)
he/she is using, BEA will distribute an advisory and instructions via email with
the appropriate course of action.
REPORTING SECURITY ISSUES
For immediate attention, BEA has established an email address to which you can
send reports of any possible security issues in BEA products.
These reports should be sent to: [email protected]
All correspondence to this address will be promptly reviewed and all necessary
actions taken to ensure the continued security of all customer assets.
SUBSCRIBE TO EMAIL ALERT
You may subscribe to the permission-based emailing list to receive alerts of security
advisories by registering with BEA at:
http://contact.beasys.com/bea/www/securityelogin.jsp.
Sincerely,
Marc Bishop
Security Product Manager
BEA WebLogic Server

HttpSession Bug in WebLogic 6.0?

          I've been having trouble getting sessions restored by jsps in my web
          applications under WebLogic 6.0. In order to shed some light on the issue,
          I tried deploying the jsp examples in the examples server. When I run
          SimpleSession.jsp I am getting unexpected behavior. What that jsp does is
          keep track of a counter in the HttpSession and a counter in the Servlet
          Context and increments them each time a browser reloads the page. When I
          hit that jsp the first time, the page prints out "1" for the HttpSession
          counter and "1" for the Servlet Context counter. When I hit the page a
          second time, the page still prints out "1" for the HttpSession counter and
          prints out "2" for the Servlet Context counter. The page should print out a
          "2" for the HttpSession counter if my session did not expire. I don't
          understand why the HttpSession is not being persisted across page reloads.
          My browser accepts cookies so that can't be the issue. I've read the
          WebLogic documentation and it says that the default session timeout is 3600
          seconds. So what gives? Has anyone else come across this problem? Is this
          a known bug?
          --Tim


I think the way we display the output was quite confusing. Here we shouldn't
          have display '1' in red ink.
          It actually means, the counter will be reset to 1. So you should only see the
          counter in red ink..
          Kumar
          Timothy O'Hara wrote:
          > I've been having trouble getting sessions restored by jsps in my web
          > applications under WebLogic 6.0. In order to shed some light on the issue,
          > I tried deploying the jsp examples in the examples server. When I run
          > SimpleSession.jsp I am getting unexpected behavior. What that jsp does is
          > keep track of a counter in the HttpSession and a counter in the Servlet
          > Context and increments them each time a browser reloads the page. When I
          > hit that jsp the first time, the page prints out "1" for the HttpSession
          > counter and "1" for the Servlet Context counter. When I hit the page a
          > second time, the page still prints out "1" for the HttpSession counter and
          > prints out "2" for the Servlet Context counter. The page should print out a
          > "2" for the HttpSession counter if my session did not expire. I don't
          > understand why the HttpSession is not being persisted across page reloads.
          > My browser accepts cookies so that can't be the issue. I've read the
          > WebLogic documentation and it says that the default session timeout is 3600
          > seconds. So what gives? Has anyone else come across this problem? Is this
          > a known bug?
          >
          > --Tim

WLS 9.1 bug with WebLogic Plug-In Enabled?

We are currently upgrading from WLS 8.1 to WLS 9.1. We use Apache HTTP Server 2.0 on Red Hat Enterprise 4 with the weblogic plugin. We have the plugin configured properly as the application functions properly except for calls to request.getRemoteAddr(). We have WebLogic Plug-In Enabled enabled at the cluster and server level. We verified MBeans reported true using the weblogic scripting tool in interactive mode. We see the WL-Client-Proxy-IP header in the request as expected. We've searched the newsgroups and BEA site and they mention setting the WebLogic Plug-In Enabled option as the problem. It doesn't appear to be ours.
Is there a bug or are we missing something else? If it is a bug, is there a patch? We have a workaround in place which gets the WL-Client-Proxy-IP header directly, but obviously this isn't the optimal solution for something that was working properly in 8.1.
Thank you in advance,
Daniel

Sure! Calling directly a server is more fast then pass through a load balancer and through a webserver and through (again?) the weblogic plugin (even if it's only a lib!!!)...
          Moreover you could have performance problem if you use hostname instead of IP address, cause for every client call a DNS query must be executed.
          One more thing... The only one load balancer algorithm you must use is the round robin, I'm not speaking about weblogic load balancing algorithm... But about hardware load balancer above the webserver.
          Regards
          Antenore Gatta
          Middleware Specialist
          Hequa S.r.l
          C.so Buenos Aires 77
          20124 Milano
          http://www.Hequa.it
          Tel +39(0)267493078
          Fax +39(0)267493079
          Mobile +39 3481537897
          ______________________________________

Bug in WebLogic 8.1 SP4 for IBM JDK 1.4.2?

Hello,

In a previous thread i posted (http://forums.bea.com/bea/thread.jspa?threadID=600006934&tstart=0), I reported that we had problems in trying to use JAAS in connecting Acegi with WebLogic 8.1 SP4 on IBM JDK 1.4.2

We did some more research and found the following:
 
WebLogic uses the class weblogic.security.service.ServerConfiguration for reading the JAAS config file. This class extends the default javax.security.auth.login.Configuration class. To see what's going on we decompiled the class and it looks like this:


try {
 // code omitted.
} catch (Exception exception) {
 String s1 = System.getProperty("login.configuration.provider");
 if(s1 == null)
 s1 = "com.sun.security.auth.login.ConfigFile";
 if(!s1.equals("weblogic.security.service.ServerConfiguration"))
 try
 Configuration configuration = (Configuration)Class.forName(s1).newInstance();
 configuration.refresh();
 aappconfigurationentry = configuration.getAppConfigurationEntry(s);
 catch(Exception exception1) { }


The following happens when trying to authenticate through JAAS:

- The "omitted code" throws the Exception weblogic.security.service.InvalidParameterException: [Security:090396]Security Realm sample does not exist.

Why is this Exception thrown? Why does the name of my JAAS configuration in the JAAS config file needs to be the same as a Security Realm? Or this try-catch block used as some kind of control flow and is this exception expected?

- Then in the catch block the System.property login.configuration.provider is retrieved. However the JDK Specification of the class javax.security.auth.login.Configuration (sse the javadoc) states that:
The default Configuration implementation can be changed by setting the value of the "login.configuration.provider" security property (in the Java security properties file) to the fully qualified name of the desired Configuration implementation class

So because the System property is read instead of the Security property (which contains the correct IBM class), null is returned. Is this a bug?

- Because the System property is null the code then tries to load the class com.sun.security.auth.login.ConfigFile, which of course is not present in the IBM JDK, and a ClassNotFoundException is thrown. Since
the Exception is swallowed by the nested catch block we will not see this exception and null is returned that eventually leads to the "No LoginModule found..." exception.

So to summarize, my questions are these:

- Does the name of the JAAS configuration in the JAAS config file need to be the same as the name of the Realm? And if so why? 
- Is it a bug that instead of reading the Security this code is reading the System property?

Regards, 
Lars Vonk

PS 
As a workaround we set the System property login.configuration.provider to the correct value com.ibm.security.auth.login.ConfigFile and then it works.

Sorry, i saw the forum about your problem in BEA 8.1 SP 6 about a
weblogic.security.SSL.SSLCertificate.verify(SSLCertificate.java:235)
error and you said that bea sent a path named CR295205_810sp6.jar.
I have the same problem
Do you have this patch?
Could you send it to me?
my email address is
[email protected]

Big jsp Bug in Weblogic! UnNoticed by weblogic!

 <%@ page language="java" contentType="text/html" %> <%! public void jspInit() { System.out.println("Hello"); } %> <% out.println("jsp executed"); %>
 The above code displays "Hello" on the command line or Dos and "jsp executed" on the browser!
 When this jsp is loaded first time it executes correctly. when it is again loaded then jsp init method is not executed. This is also fine.
 But the problem is when I restart my weblogic server and clear the browser cache and then load the jsp file then the init method is called TWO times! "Hello" is displayed two times!
 why this is so? Is there any bug in weblogic5.1? Or am I doing something wrong? please tell


 You hit the JSP and the .class file gets loaded into memory and jspInit() executes. Fine.
 Once loaded into memory, the next thing the JSP does is check if it 'isStale()' -
 this compares the date-stamp that was on the .jsp file when the jsp was compiled
 with the date-stamp on the .jsp file on disk. This is in the code of the JSP itself, it
 does not compare the date of the .class file with the date of the .jsp file - so it was
 necessary to load the JSP in memory (an call jspInit()) simply to check the if it was
 up-to-date. In your case, it is not up-to-date. The JSP is compiled, loaded into
 memory and jspInit() executes - again.
 Mike Reiche
 Robert Patrick <[email protected]> wrote:
 >Hi,
 >
 >Please realize that this is NOT an official BEA support forum. All BEA personnel that monitor this newsgroup and answer questions do it on their own time because we (yes, I work for
 >BEA) want to help people be successful with our products. If you want an official response from BEA to your problem, then I suggest that you send mail to [email protected], call our toll
 >free support number (888)232-7878 and/or talk with your BEA Account Representative.
 >
 >As for your problem, I am not sure what is happening but this may be a simple matter of not understanding how JSP reloading works. I am more than willing to help you but you need to
 >provide me with a more detailed description of exactly what it is that you are doing, what service pack level are you using, etc.
 >
 >Thanks,
 >Robert
 >
 >gopal wrote:
 >
 >> <%@ page language="java" contentType="text/html" %> <%! public void jspInit() { System.out.println("Hello"); } %> <% out.println("jsp executed"); %>
 >>
 >> The above code displays "Hello" on the command line or Dos and "jsp executed" on the browser!
 >>
 >> When this jsp is loaded first time it executes correctly. when it is again loaded then jsp init method is not executed. This is also fine.
 >>
 >> But the problem is when I restart my weblogic server and clear the browser cache and then load the jsp file then the init method is called TWO times! "Hello" is displayed two times!
 >>
 >> why this is so? Is there any bug in weblogic5.1? Or am I doing something wrong? please tell
 >

Security Bug in weblogic.httpd.enable

Hi!
When I set this "weblogic.httpd.enable=false". I will get UnmarshalException
for WLStub at ejb client whenever I update my classes. Is this by design?
When I comment out this, the error is gone.
Regards
Yew Yap
"Vince" <[email protected]> wrote in message
news:87f5ng$g7g$[email protected]..
Hi all,
I don't know whether you all know this or not, but I would feel guilty ifI
didn't tell all of you. I found a bug in the properties file. WebLogic
claimed that the httpd can be disabled for security purposes. However, I
realized that no matter what boolean you assign to weblogic.httpd.enable,
the httpd is still alive. The setting in the properties file has noeffect
at all. For those of you who have to disable httpd for the security ofyour
internal networks, this is really a problem. I have reported this to BEA
and will see how they fix this. You can test this on your WebLogic server
by setting the property to false and test to see if the clients canconnect
to your server using http. I was be able to use a browser to connect tothe
server and even more I could replace t3 with http in my java code toconnect
to my EJBs after I disabled httpd.
Vince

Bug in weblogic classloader?

Similar Messages

Maybe you are looking for