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

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

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

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.

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

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.

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

Serious bug in Weblogic when connecting to a remote website through a local proxy server (proxyHost, proxyPort)

Hi there,
It seems that there is a serious problem with any version of Weblogic when you
have to pass through a local proxy server to connect a remote website.
Whenever I am trying to run the jsp program below either with Weblogic 7.0 SP2
or even with Weblogic 8.1, I get the following exception :
An error occured: Tried all: '1' addresses, but could not connect over HTTP to
server: 'www.sun.com', port: '80'
When I run the same program outside Weblogic, it works fine. Other people have
already reported the same problem either in this newsgroup or on Internet forums,
and up to now, the problem is not fixed yet.
In fact, Weblogic seems to block when it performs the connect() method to the
proxy, my jsp program hangs a few minutes before returning the error message shown
above.
If anyboby can tells me how this problem can be solved (or maybe via a workaround)
do not hesitate to keep me informed, thanks in advance.
Please find below my code :
public class ProxyDownload extends HttpServlet
private static final String CONTENT_TYPE = "text/html";
//Initialize global variables
public void init() throws ServletException
public String bufferedReaderToString (BufferedReader br) throws IOException
String xml = "";
String line = null;
while ( (line = br.readLine()) != null)
xml += line;
return xml;
//Process the HTTP Get request
public void doGet(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException
response.setContentType(CONTENT_TYPE);
PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<head><title>Proxy Download</title></head>");
out.println("<body bgcolor=\"#c0c0c0\">");
try{
// Set proxy stuff
System.getProperties().put( "http.proxySet", "true");
System.getProperties().put( "http.proxyHost", "ip_address" );
System.getProperties().put( "http.proxyPort", "port");
String password = "user:pass";
sun.misc.BASE64Encoder objEncoder = new sun.misc.BASE64Encoder();
String code = objEncoder.encode(password.getBytes());
// Find the file name to save
String file = null;
// Open a connection
URL url = new URL("http://www.sun.com");
URLConnection connection = url.openConnection();
// Set up the connection so it knows you are sending
// proxy user information
connection.setRequestProperty( "Proxy-Authorization", "basic " + code);
connection.connect();
// Set up the connection so you can do read and writes
connection.setDoInput( true );
BufferedReader inBuff = new BufferedReader(new InputStreamReader(connection.getInputStream()));
String str = bufferedReaderToString(inBuff);
out.println(" " + str);
catch(Exception e){
out.println(" An error occured: " + e.getMessage());
out.println("</body></html>");
//Process the HTTP Post request
public void doPost(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException
doGet(request, response);
//Clean up resources
public void destroy()

Hello,
The way to set the HTTP connection using a proxy server changed (from
using the system property
weblogic.webservice.transport.http.proxy.host/port)[1] in WLS 7.x to the
standard JDK 1.4 system properties [2] in WLS 8.1.
I would recommend opening a dialog with our outstanding support team [3]
to resolve this issue.
Thanks,
Bruce
[1]
http://edocs.bea.com/wls/docs70/webserv/client.html#1058615
[2]
http://java.sun.com/j2se/1.4/docs/guide/net/properties.html
[3]
http://support.bea.com
[email protected]
Yves Hardy wrote:
>
Hi there,
It seems that there is a serious problem with any version of Weblogic when you
have to pass through a local proxy server to connect a remote website.
Whenever I am trying to run the jsp program below either with Weblogic 7.0 SP2
or even with Weblogic 8.1, I get the following exception :
An error occured: Tried all: '1' addresses, but could not connect over HTTP to
server: 'www.sun.com', port: '80'
When I run the same program outside Weblogic, it works fine. Other people have
already reported the same problem either in this newsgroup or on Internet forums,
and up to now, the problem is not fixed yet.
In fact, Weblogic seems to block when it performs the connect() method to the
proxy, my jsp program hangs a few minutes before returning the error message shown
above.
If anyboby can tells me how this problem can be solved (or maybe via a workaround)
do not hesitate to keep me informed, thanks in advance.
Please find below my code :
public class ProxyDownload extends HttpServlet
private static final String CONTENT_TYPE = "text/html";
//Initialize global variables
public void init() throws ServletException
public String bufferedReaderToString (BufferedReader br) throws IOException
String xml = "";
String line = null;
while ( (line = br.readLine()) != null)
xml += line;
return xml;
//Process the HTTP Get request
public void doGet(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException
response.setContentType(CONTENT_TYPE);
PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<head><title>Proxy Download</title></head>");
out.println("<body bgcolor=\"#c0c0c0\">");
try{
// Set proxy stuff
System.getProperties().put( "http.proxySet", "true");
System.getProperties().put( "http.proxyHost", "ip_address" );
System.getProperties().put( "http.proxyPort", "port");
String password = "user:pass";
sun.misc.BASE64Encoder objEncoder = new sun.misc.BASE64Encoder();
String code = objEncoder.encode(password.getBytes());
// Find the file name to save
String file = null;
// Open a connection
URL url = new URL("http://www.sun.com");
URLConnection connection = url.openConnection();
// Set up the connection so it knows you are sending
// proxy user information
connection.setRequestProperty( "Proxy-Authorization", "basic " + code);
connection.connect();
// Set up the connection so you can do read and writes
connection.setDoInput( true );
BufferedReader inBuff = new BufferedReader(new InputStreamReader(connection.getInputStream()));
String str = bufferedReaderToString(inBuff);
out.println(" " + str);
catch(Exception e){
out.println(" An error occured: " + e.getMessage());
out.println("</body></html>");
//Process the HTTP Post request
public void doPost(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException
doGet(request, response);
//Clean up resources
public void destroy()

Custom Realm Bug in WebLogic SP3?

I recently upgraded WebLogic 6.1 from SP1 to SP3 and am now
receiving a ClassCastException when invoking the checkPermission
method on a Custom realm ACL that extends weblogic.security.acl.AclImpl.
This code worked fine in SP1. It seems that other developers
have experienced this problem when applying service packs to
WebLogic 5. Any one else encountering this problem with
WebLogic 6 and what is the workaround? (Stack trace attached)
TIA
[aclimplexception.txt]

I was unable to determine the cause of the problem, but I was
able to identify that AclImpl was changed between SP1 and SP3.
I updated SP3's weblogic.jar with the weblogic.security.acl.AclImpl
class in the weblogic.jar from SP1 and the exception went away.
I did not see anything in the release notes for SP2 and SP3
that indicate what may have changed. Does anyone know?
"Jason Southern" <[email protected]> wrote:
>
>
>
I recently upgraded WebLogic 6.1 from SP1 to SP3 and am now
receiving a ClassCastException when invoking the checkPermission
method on a Custom realm ACL that extends weblogic.security.acl.AclImpl.
This code worked fine in SP1. It seems that other developers
have experienced this problem when applying service packs to
WebLogic 5. Any one else encountering this problem with
WebLogic 6 and what is the workaround? (Stack trace attached)
TIA

SSL bug in WebLogic Server 6.1 SP1 ?

Anybody have any idea why I get this exception:
java.lang.ClassCastException: weblogic.management.WebLogicObjectName
 at $Proxy0.getKernelDebug(Unknown Source)
 at weblogic.management.configuration.ServerMBean_CachingStub.getKernelDebug(ServerMBean_CachingStub.java:1185)
 at weblogic.kernel.Kernel.getDebug(Kernel.java:145)
 at weblogic.security.RSApkcs1.<init>(RSApkcs1.java:58)
 at weblogic.security.RSAMDSignature.<init>(RSAMDSignature.java:48)
 at weblogic.security.RSAMDSignature.<init>(RSAMDSignature.java:77)
 at weblogic.security.X509.verifySignature(X509.java:242)
 at weblogic.security.X509.verify(X509.java:172)
 at weblogic.security.SSL.SSLCertificate.verify(SSLCertificate.java:139)
 at weblogic.security.SSL.SSLCertificate.input(SSLCertificate.java:118)
 at weblogic.security.SSL.Handshake.input(Handshake.java:115)
 at weblogic.security.SSL.SSLSocket.getHandshake(SSLSocket.java:1043)
 at weblogic.security.SSL.SSLSocket.clientInit(SSLSocket.java:405)
 at weblogic.security.SSL.SSLSocket.initialize(SSLSocket.java:265)
 at weblogic.security.SSL.SSLSocket.<init>(SSLSocket.java:212)
 at weblogic.net.http.HttpsClient.openServer(HttpsClient.java:85)
 at weblogic.net.http.HttpsClient.openServer(HttpsClient.java:143)
 at weblogic.net.http.HttpsClient.<init>(HttpsClient.java:67)
 at weblogic.net.http.HttpClient.New(HttpClient.java:151)
 at weblogic.net.http.HttpsURLConnection.connect(HttpsURLConnection.java:39)
 at weblogic.net.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:156)
when trying to open a HTTPS connection using the JSSE? Relevant code
is:
String handlers =
System.getProperty("java.protocol.handler.pkgs");
System.setProperty("java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol|" + handlers);
java.security.Security.addProvider(new
com.sun.net.ssl.internal.ssl.Provider());
X509TrustManager tm = new MyX509TrustManager();
KeyManager []km = null;
TrustManager []tma = {tm};
SSLContext sc = SSLContext.getInstance("ssl");
sc.init(km, tma, new java.security.SecureRandom());
SSLSocketFactory sf1 = sc.getSocketFactory();
HttpsURLConnection.setDefaultSSLSocketFactory(sf1);
URL u = new URL(url);
c = (HttpURLConnection) u.openConnection();

We get a similar message just by starting a server in the cluster
environment ...
We're using 6.1 SP2!
####<Jul 22, 2002 8:04:31 PM CEST> <Error> <Kernel> <su37sr48>
<su37sr48-2> <ExecuteThread: '0' for queue:
'__weblogic_admin_rmi_queue'> <system> <> <000000> <ExecuteRequest
failed>
java.lang.ClassCastException: weblogic.management.WebLogicObjectName
 at $Proxy0.getSSL(Unknown Source)
 at weblogic.management.configuration.ServerMBean_CachingStub.getSSL(ServerMBean_CachingStub.java:1962)
 at weblogic.security.WLMessageDigest.getInstance(WLMessageDigest.java:61)
 at weblogic.security.SSL.GenericCipher.generateMAC(GenericCipher.java:75)
 at weblogic.security.SSL.GenericCipher.<init>(GenericCipher.java:57)
 at weblogic.security.SSL.SSLCiphertext.<init>(SSLCiphertext.java:47)
 at weblogic.security.SSL.SSLCiphertext.<init>(SSLCiphertext.java:52)
 at weblogic.security.SSL.SSLSocket.sendRecord(SSLSocket.java:1048)
 at weblogic.security.SSL.SSLSocket.sendData(SSLSocket.java:1028)
 at weblogic.security.SSL.SSLSocketOutputStream.write(SSLSocketOutputStream.java:66)
 at weblogic.socket.SocketMuxer.write(SocketMuxer.java:130)
 at weblogic.rjvm.t3.T3JVMConnection.sendMsg(T3JVMConnection.java:311)
 at weblogic.rjvm.MsgAbbrevJVMConnection.sendOutMsg(MsgAbbrevJVMConnection.java:243)
 at weblogic.rjvm.MsgAbbrevJVMConnection.sendMsg(MsgAbbrevJVMConnection.java:139)
 at weblogic.rjvm.ConnectionManager.sendMsg(ConnectionManager.java:404)
 at weblogic.rjvm.RJVMImpl.send(RJVMImpl.java:480)
 at weblogic.rjvm.MsgAbbrevOutputStream.flushAndSendRaw(MsgAbbrevOutputStream.java:166)
 at weblogic.rjvm.MsgAbbrevOutputStream.flushAndSend(MsgAbbrevOutputStream.java:174)
 at weblogic.rjvm.MsgAbbrevOutputStream.send(MsgAbbrevOutputStream.java:235)
 at weblogic.rmi.internal.BasicServerRef.postInvoke(BasicServerRef.java:341)
 at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:272)
 at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:22)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
[email protected] (Michael Snell) wrote in message news:<[email protected]>...
Anybody have any idea why I get this exception:
java.lang.ClassCastException: weblogic.management.WebLogicObjectName
 at $Proxy0.getKernelDebug(Unknown Source)
 at weblogic.management.configuration.ServerMBean_CachingStub.getKernelDebug(ServerMBean_CachingStub.java:1185)
 at weblogic.kernel.Kernel.getDebug(Kernel.java:145)
 at weblogic.security.RSApkcs1.<init>(RSApkcs1.java:58)
 at weblogic.security.RSAMDSignature.<init>(RSAMDSignature.java:48)
 at weblogic.security.RSAMDSignature.<init>(RSAMDSignature.java:77)
 at weblogic.security.X509.verifySignature(X509.java:242)
 at weblogic.security.X509.verify(X509.java:172)
 at weblogic.security.SSL.SSLCertificate.verify(SSLCertificate.java:139)
 at weblogic.security.SSL.SSLCertificate.input(SSLCertificate.java:118)
 at weblogic.security.SSL.Handshake.input(Handshake.java:115)
 at weblogic.security.SSL.SSLSocket.getHandshake(SSLSocket.java:1043)
 at weblogic.security.SSL.SSLSocket.clientInit(SSLSocket.java:405)
 at weblogic.security.SSL.SSLSocket.initialize(SSLSocket.java:265)
 at weblogic.security.SSL.SSLSocket.<init>(SSLSocket.java:212)
 at weblogic.net.http.HttpsClient.openServer(HttpsClient.java:85)
 at weblogic.net.http.HttpsClient.openServer(HttpsClient.java:143)
 at weblogic.net.http.HttpsClient.<init>(HttpsClient.java:67)
 at weblogic.net.http.HttpClient.New(HttpClient.java:151)
 at weblogic.net.http.HttpsURLConnection.connect(HttpsURLConnection.java:39)
 at weblogic.net.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:156)
when trying to open a HTTPS connection using the JSSE? Relevant code
is:
String handlers =
System.getProperty("java.protocol.handler.pkgs");
System.setProperty("java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol|" + handlers);
java.security.Security.addProvider(new
com.sun.net.ssl.internal.ssl.Provider());
X509TrustManager tm = new MyX509TrustManager();
KeyManager []km = null;
TrustManager []tma = {tm};
SSLContext sc = SSLContext.getInstance("ssl");
sc.init(km, tma, new java.security.SecureRandom());
SSLSocketFactory sf1 = sc.getSocketFactory();
HttpsURLConnection.setDefaultSSLSocketFactory(sf1);
URL u = new URL(url);
c = (HttpURLConnection) u.openConnection();

Bug in weblogic 8.1 SP6 at weblogic.security.SSL.SSLCertificate.verify()

Hi, I got an java.lang.NullPointerException
at weblogic.security.SSL.SSLCertificate.verify(SSLCertificate.java:235)
at weblogic.security.SSL.SSLCertificate.input(SSLCertificate.java:116)
at weblogic.security.SSL.Handshake.input(Handshake.java:121)
at weblogic.security.SSL.SSLSocket.getHandshake(SSLSocket.java:1117)
at weblogic.security.SSL.SSLSocket.clientInit(SSLSocket.java:432)
at weblogic.security.SSL.SSLSocket.initialize(SSLSocket.java:276)
at weblogic.security.SSL.SSLSocket.<init>(SSLSocket.java:222)
at weblogic.security.SSL.SSLSocketFactory.createSocket(SSLSocketFactory.java:213)
at weblogic.net.http.HttpsClient.openServer(HttpsClient.java:238)
at weblogic.net.http.HttpsClient.openServer(HttpsClient.java:389)
at weblogic.net.http.HttpsClient.<init>(HttpsClient.java:209)
at weblogic.net.http.HttpClient.New(HttpClient.java:228)
at weblogic.net.http.HttpsURLConnection.getHttpClient(HttpsURLConnection.java:246)
at weblogic.net.http.HttpsURLConnection.connect(HttpsURLConnection.java:217)
at weblogic.net.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:189)
when a small piece of code running in weblogic 8.1 SP6 and trying to make url connection to a https server.
I have verified that the runtime environment has the cacerts file including the CA ( issuer for the server certificate for the server the code was trying to connect to ).
I wonder that anybody has the same problem. Or you can give a hint how to fix it.
Thank you.

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]

HttpSession Bug in WebLogic 6.0?

Similar Messages

Maybe you are looking for