Portlet question- session.invalidate()- with weblogic

Guys:
Has anyone had a issue with session.invalidate() using weblogic 8.1.
we have vignette and weblogic 8.1.
the problem i have noticed is session.getId retunrns a extra timestamp string in the end. And i am thinking since this changes the entire sessionid, it does not get invalidated. I tried adjusting the weblogic.xml's idlength session-param to 52 but this still happens after that. can anyone suggest any insights. i am unable to kill the session and hence the user is always logged in. the only way is to close to broswer window.
session id:
F1z2YTQMyD3Yy1Xs4VBHyq3M7LWVfYMnvWJgYLnrR3cPYnKL9NW9!-682555724!1170191618061
any help will be appreciated..thanks.
Harsh

i havent gone to weblogic support yet. Want to check
if anyone of us might have seen a similar issue.I haven't used weblogic in a while. I doubt many people here have. I would suggest you ask on a weblogic forum. This is a java forum.

Similar Messages

Deploying session beans with weblogic 5.1 in NT

Hello ,
I have a problem with deploying session beans in weblogic 5.0. I have
written the code and compiled it. My Compilation is fine. Cud any one give
me a step by step of how I should deploy my bean with weblogic 5.0 on
windows NT.
Raj Urs

Hello ,
I have a problem with deploying session beans in weblogic 5.0. I have
written the code and compiled it. My Compilation is fine. Cud any one give
me a step by step of how I should deploy my bean with weblogic 5.0 on
windows NT.
Raj Urs

ViewExpiredException issue with session invalidate on IE9

Hi guys,
I have posted this on the ADF forum as well as I'm not sure of the root cause is JHeadstart related or not - but I thought I would check also here to see if anyone else has encountered this ...
I'm using JDeveloper 11.1.1.6 (JHeadstart 11.1.1.4.26) and having problems when calling "session.invalidate();" with my custom JhsAuthenticationFilter. If i log on and immediately log out (so no web.xml timeout which is set to 25 min) - The message shown on screen is
"Because of inactivity, your session is timed out and is no longer active. Click on OK to reload the page"
In the log files, the following error is thrown
<BindingContext> <put> [3126] Replacing: null with: XXXXX_UIShellPageDef
<StateManagerImpl> <restoreView> Could not find saved view state for token -a6jozll3a
<LifecycleImpl> <_handleException> ADF_FACES-60098:Faces lifecycle receives unhandled exceptions in phase RESTORE_VIEW 1
javax.faces.application.ViewExpiredException: viewId:/pages/UIShell.jspx - ADF_FACES-30107:The view state of the page has expired. Reload the page.
     at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._restoreView(LifecycleImpl.java:751)
     at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:374)
     at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:194)
     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
     at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
     at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
     at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
     at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:205)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter(RegistrationFilter.java:106)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:446)
     at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter(AdsFilter.java:60)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:446)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:271)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:177)
     at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at hmdclinical.pulse.view.PulseAuthenticationFilter.doFilter(PulseAuthenticationFilter.java:273)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119)
     at java.security.AccessController.doPrivileged(Native Method)
     at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
     at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:442)
     at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103)
     at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171)
     at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119)
     at java.security.AccessController.doPrivileged(Native Method)
     at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
     at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:442)
     at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103)
     at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171)
     at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:139)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
     at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)
     at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
     at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
     at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
     at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
     at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
     at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
<ADFLogger> <addContextData> Execute queryI have the web.xml parameter org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS set to 15.
This ONLY happens when using IE9 - using Firefox or Chrome it's not a problem. I'm guessing something is trying to access the page def after the token for the view has already been removed as part of the session.invalidate() ?
How can I find out what the root cause is and why is this only a problem with IE and not Chrome or Firefox ?
Any help greatly appreciated !!
Cheers,
Brent

Brent,
I think it is best to make a very simple testcase without JHeadstart (you can cust and paste code from the jhs auth fillter as needed) and then attach your testcase to the post on JDev forum, or copntact Oracle support.
Looks like a browser-specific ADF bug to me.
Steven Davelaar,
JHeadstart Team.

Urgent: session invalidate problem

Guys:
Has anyone had a issue with session.invalidate() using weblogic 8.1.
we have vignette portal and weblogic 8.1.
the problem i have noticed is session.getId retunrns a extra timestamp string in the end. And i am thinking since this changes the entire sessionid, it does not get invalidated. I tried adjusting the weblogic.xml's idlength session-param to 52 but this still happens after that. can anyone suggest any insights. i am unable to kill the session and hence the user is always logged in. the only way is to close to broswer window.

here is the error printed out:
java.lang.NullPointerException
     at com.sssw.srv.http.CommonLogger.log(CommonLogger.java:217)
     at com.sssw.srv.http.httpd.log(httpd.java:4229)
     at com.sssw.srv.http.Client.log(Client.java:254)
     at com.sssw.srv.http.Client.loop(Client.java:1300)
     at com.sssw.srv.http.Client.runConnection(Client.java:1495)
     at com.sssw.srv.http.Client.run(Client.java:1442)
     at java.lang.Thread.run(Thread.java:479)

Invalidate session with weblogic.Admin

Hi,
I tried to invalidate sessions using weblogic.Admin using the command: java weblogic.Admin -url t3://localhost:8013 -username system -password *** GET -pretty -type ServletSessionRuntime. The output was:
MBeanName: "R3:Location=PIA,Name=B0lYRDnVqlw1VzPZO1XszSFlIASW017b!1102341400731,ServerRuntime=PIA,Type=ServletSessionRuntime"
CachingDisabled: true
MainAttribute: [email protected]/ps
Name: B0lYRDnVqlw1VzPZO1XszSFlIASW017b!1102341400731
ObjectName: B0lYRDnVqlw1VzPZO1XszSFlIASW017b!1102341400731
Parent: PIA
Registered: true
TimeLastAccessed: 1102341410448
Type: ServletSessionRuntime
Then tried to invalidate it using:
java weblogic.Admin -url t3://localhost:8013 -username system -password *** INVOKE -mbean "R3:Location=PIA,Name=B0lYRDnVqlw1VzPZO1XszSFlIASW017b!1102341400731,ServerRuntime=PIA,Type=ServletSessionRuntime" -method INVALIDATE
ANd the error message: bash: !1102341400731: event not found
Do you know how to handle this? Or any other way to invalidate session from weblogic.Admin?
WLS 8.1 SP1
Regards
Tomi

Hello,
I have a system consisting of three different departments, each department has its own login page with different username and password.
from the same browser, all three administrators can log in successfully, during there login, one session is created with different attributes for each of them, if any one administrator logs out, I invalidate the session, which logs out the other two administrators.
Can I use session Id to log out on administrator while the other two can stay logs in?
If I am using the wrong approach all together, can anyone suggest an alternative please?
here is my code to create session:
// if correct username and password entered then create session
String financeAdminSess = adminUsername;
session.setAttribute("financeAdminSess", adminUsername);
String redirectURL = "finance_admin_home.jsp";
response.sendRedirect(redirectURL);
and here is the code for loggin out:
// get session
String financeAdminSess=(String) session.getAttribute("financeAdminSess");
// remove session
session.removeAttribute("financeAdminSess<br />");
// invalidate session
session.invalidate();
Any suggestion would be much appreciated.
Thanks
Shaxo

Announcing: Developing JSF Portlets with WebLogic Portal Whitepaper

Just Released: Developing JSF Portlets with WebLogic Portal Whitepaper
A supplemental developer's guide has been published to help guide WLP 10.x customers that wish to use JSF as the web framework for building portlets on WebLogic Portal. This is a sizable document (150 pages) that covers a large number of topics. It also coaches developers on best practices and common pitfalls.
Important: It also clarifies the supported configuration of JSF within Portal Web Projects. Workshop for WebLogic by default configures a web project in a configuration that is not supported by WebLogic Portal. The guide explains how to address this:
* Change from the unsupported MyFaces JSF implementation to the supported Sun Reference Implementation (RI)
* Change from the unsupported "client" STATE_SAVING_METHOD to the supported "server"
The guide can be downloaded here:
http://download.oracle.com/technology/products/weblogic/portal/weblogic-portal-jsf-whitepaper.pdf
To help internet searches locate this document, the table of contents is reproduced below:
Introduction
1.1. Prerequisites...................................................................... 8
1.2. Applicable Versions............................................................ 8
1.3. Native Portlet Bridges and Standard Portlet Bridges .......... 8
1.4. JSF Portlet Support Roadmap ........................................... 9
1.5. Whitepaper Structure ....................................................... 10
1.6. Look Before You Leap ..................................................... 10
1.7. For More Information........................................................ 10
Part 1: Converting JSF Applications into Portlets
2. IDE Support for JSF Portlets Chapter ...................................... 12
2.1. Workshop for WebLogic – WebLogic Portal's Supported IDE 12
2.2. Workshop Features for JSF Support in WebLogic Portal.. 12
3. Introduction to JSF Portlets Chapter ........................................ 18
3.1. Creating Your First JSF Portlet......................................... 18
3.2. Essentials of JSF Portlet Views........................................ 21
3.3. WebLogic Portal Artifacts................................................. 22
4. Configuring JSF within WebLogic Portal Chapter..................... 24
4.1. JSF Library Modules in WebLogic Server ........................ 24
4.2. Installing the JSF Libraries into a Portal Web Project ....... 25
4.3. JSF Configuration Settings............................................... 27
4.4. Configuring JSF 1.2 ......................................................... 29
4.5. Building an Unsupported JSF Implementation Library Module 31
4.6. Faces Configuration is Web Application Scoped.............. 31
5. Navigation within a JSF Portlet Chapter................................... 33
5.1. Navigating within a Portlet with the JSF Controller ........... 33
5.2. Redirects.......................................................................... 34
6. Namespacing Chapter ............................................................. 35
6.1. Namespacing Managed Bean Names.............................. 35
6.2. Client ID Namespacing with the View and Subview Components 35
6.3. Client ID Namespacing with the WLP NamingContainer .. 36
7. Logging, Iterative Development, and Debugging Chapter ........ 39
7.1. Logging............................................................................ 39
7.2. Iterative Development ...................................................... 39
7.3. Debugging ....................................................................... 40
8. Custom JavaScript Chapter ..................................................... 42
8.1. DOM Manipulation within a JSF ....................................... 42
8.2. Form Validation within a JSF Portlet ................................ 45
9. Preparing JSF Portlets for Production Chapter ........................ 46
9.1. Configuration.................................................................... 46
9.2. Performance and Scalability............................................. 47
9.3. Security............................................................................ 49
9.4. Localization...................................................................... 50
Part 2: Interacting with the Portal Environment
10. Native Bridge Architecture Chapter ...................................... 54
10.1. Container Architecture Overview.................................. 54
10.2. Container Architecture.................................................. 54
10.3. Container Interactions .................................................. 55
11. Interportlet Communication Chapter .................................... 56
11.1. Using Session and Request Attributes for IPC (Anti-pattern) 56
11.2. Using the WLP Event Facility for IPC with JSF Portlets 56
11.3. Notifications ................................................................. 60
11.4. Comparison of the IPC Approaches ............................. 60
12. Scopes Chapter ................................................................... 62
12.1. Conceptual Scopes for Standard JSF Applications ...... 62
12.2. Conceptual Scopes for Portal Applications................... 63
12.3. Implementation Patterns for Portal Scopes .................. 63
13. State Sharing Patterns Chapter ........................................... 66
13.1. State Sharing Concepts ............................................... 66
13.2. HttpSession Versus HttpServletRequest ...................... 66
13.3. Base Code for HttpSession Patterns ............................ 67
13.4. Single Portlet Pattern ................................................... 68
13.5. Multiple Portlet Patterns ............................................... 69
14. Rendering Lifecycles Chapter .............................................. 77
14.1. WLP and JSF Lifecycles .............................................. 77
14.2. Invocation Order of WLP and JSF Lifecycle Methods... 77
14.3. Accessing WLP Context Objects from JSF Managed Beans 78
15. Portal Navigation Chapter .................................................... 80
15.1. Programmatically Constructing JSF Portlet URLs ........ 80
15.2. Changing the Active Portal Page.................................. 80
15.3. Redirects within a Portal............................................... 83
16. Ajax Enablement Chapter .................................................... 85
16.1. Ajax in JSF Portlets...................................................... 85
16.2. Partial Page Rendering Pattern.................................... 85
16.3. Stateless API Request Pattern ..................................... 86
16.4. Portlet Aware API Request Pattern .............................. 87
16.5. Controlling the WLP Ajax Framework........................... 91
17. Additional WLP Features Chapter........................................ 93
17.2. Portlet Container Features ........................................... 93
17.3. Portal Container Features ............................................ 98
18. Example: Implementing a Login Portlet Chapter .................. 99
18.1. Login Portlet Motivation................................................ 99
18.2. Login Portlet Design..................................................... 99
18.3. Login Portlet Implementation...................................... 101
Part 3: Integrating Third Party Libraries
19. Integration Overview Chapter............................................. 111
19.1. Types of Libraries....................................................... 111
19.2. Roadmap for MyFaces Trinidad and ADF Faces Rich Client 111
20. Using the Facelets View Technology Chapter.................... 113
20.1. Introduction to Facelets .............................................. 113
20.2. Configuring Facelets Support ..................................... 113
21. Using the Apache MyFaces Tomahawk Component Library Chapter 115
21.1. What is Apache MyFaces Tomahawk? ...................... 115
21.2. Support for Tomahawk in WLP................................... 115
21.3. Tomahawk Component List........................................ 116
21.4. Installing and Configuring Tomahawk......................... 119
21.5. Resolving the Duplicate ID Issue................................ 120
21.6. Referring to Resources .............................................. 120
21.7. forceId Attribute.......................................................... 124
21.8. File Upload................................................................. 125
22. Using the Apache Beehive Navigation Controller Chapter . 126
22.1. Apache Beehive Page Flow ....................................... 126
22.2. JSF and Page Flows .................................................. 126
22.3. Configuring the JSF Integration with Page Flows ....... 127
Appendices
23. Appendix 1: Consolidated List of Best Practices ................ 130
24. Appendix 2: Known Issues and Workarounds.................... 132
24.1. CR383659, CR383662 Inconsistent failures with JSF portlets 132
24.2. CR342124: IllegalStateException due to duplicate client-id 132
24.3. CR384916: IllegalStateException due to duplicate client-id when using certain components such as Tomahawk and Trinidad...... 133
24.4. CR361477 Problems with the integration of JSF portlets with Apache Beehive Page Flows.................................................................. 133
24.5. CR377945 JSF 1.2 suffers from a memory leak during iterative development .............................................................................. 134
25. Appendix 3: The JSFPortletHelper Class ........................... 135
26. Appendix 4: The CleanupPhaseListener Class .................. 147

Hi Peter!
First, I wish to thank you for the great work.
We followed your whitepaper and managed to deploy a JSF portlet on WLS.
But we are not able to register it (consume it) as remote portlet in Oracle Portal 10.1.4. The error log is as follows:
An error occurred while trying to refresh the provider. (WWC-43190)
An error occurred during the call to the WSRP Provider:
java.rmi.RemoteException: serialization error: serialization error:
unexpected null value for literal data; nested exception is:
serialization error: serialization error: unexpected null value for literal data
com.sun.xml.rpc.encoding.SerializationException: serialization error:
serialization error: unexpected null value for literal data
com.sun.xml.rpc.encoding.SerializationException: serialization error:
unexpected null value for literal data
Java stack trace from root exception:
unexpected null value for literal data
at
oracle.webdb.wsrp.RegistrationContext_LiteralSerializer.doSerialize(RegistrationContext_LiteralSerializer.java:107)
at
com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.internalSerialize(LiteralObjectSerializerBase.java:119)
at
com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.serialize(LiteralObjectSerializerBase.java:70)
at
oracle.webdb.wsrp.GetServiceDescription_LiteralSerializer.doSerialize(GetServiceDescription_LiteralSerializer.java:88)
at
com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.internalSerialize(LiteralObjectSerializerBase.java:119)
at
com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.serialize(LiteralObjectSerializerBase.java:70)
at
com.sun.xml.rpc.client.StreamingSender._writeRequest(StreamingSender.java:473)
at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:62)
at
oracle.webdb.wsrp.WSRP_v1_ServiceDescription_PortType_Stub.getServiceDescription(WSRP_v1_ServiceDescription_PortType_Stub.java:63)
at
oracle.webdb.wsrp.client.design.v1.OraWSRP_v1_ServiceDescription_PortType.getServiceDescription(Unknown
Source)Do you have any idea why this happens? Or you can provide some useful links to WLP -Oracle Portal federation?
Thank you and best regards,
PaKo

Are beans also destroyed with session invalidate()?

Hi,
I have a login JSP which creates a new session and puts the username into it.
My other JSP's also have page session=true, and each of them uses a bean. For example,
<jsp:useBean id="transferbean" class="transactions.transferBean" scope="session"/>
My logout JSP calls session.invalidate() and returns the user to the login page.
My question is- does the session.invalidate() call also destroy the transferbean data? The user will not close his browser window after logging out- he may choose to log in again as a different user. Will he have a new transferbean created for him, or will the previous transferbean data persist?
Thanks
Luanne

This is almost my case... I have a page called index.jsp which holds the session variables;
<jsp:useBean id="ValidationBean" scope="session" class="com.nbdesigns.beans.nbstore.Validation" />
<jsp:useBean id="OrderBean" scope="session" class="com.nbdesigns.beans.nbstore.Order" />If you start to shop, the orderbean holds your order. When you checkout you have to register or log in, in both cases the cart will be deleted.
All pages are included in the index.jsp with the <%include page="" %> tag.
Any ideas why the editing of values in validationbean causes the values in orderbean to be deleted?

Issue with session.invalidate() in OC4J

Ok, here's the thing- I've got a servlet that autogenerates
pages to the client via XSL; so far so good. However whenever
the login page is displayed, we would like to "logout" the
current user if there is one and start fresh, as it were. All of
our persistent data is stored via the user's session object so
we are doing something like this:
public void doGet( HttpServletRequest request) {
HttpSession session = request.getSession();
// Some misc. stuff happens here;
// Nothing is written to the session, however
if ( page == LOGIN_PAGE) {
session.invalidate();
session = request.getSession();
String info = session.getAttribute( "INFO");
As soon as we request the attribute, after performing the
session invalidation & re-obtaining a new session the system
bails with an IllegalStateException: Session invalidated
exception.
Note that the exact same code works under the Sun Reference
Implementation (Apache Groups Tomcat 4.0) and is pretty much
verbatim from Jason Hunter's book Java Servlet Programming 2nd
Edition pg. 220.
Any ideas for a fix and/or workaround?

Hi
This works, here is a sample I've run on OC4J
public class SessionTestServlet extends HttpServlet
private static final String CONTENT_TYPE = "text/html";
HttpSession sess = null;
private static boolean login_page = true;
public void init(ServletConfig config) throws ServletException
super.init(config);
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException
sess = request.getSession(true);
try
if (login_page)
if(sess != null)
sess.invalidate();
sess = request.getSession(true);
sess.setAttribute("name","kalle");
catch(Exception e)
e.printStackTrace();
response.setContentType(CONTENT_TYPE);
PrintWriter out = response.getWriter();
out.println("<html>");
out.println
("<head><title>SessionTestServlet</title></head>");
out.println("<body>");
out.println("<p>Session: "+ sess+"<p>Name: "+
sess.getAttribute("name"));
out.println("</body></html>");
out.close();
Regards
//Mike

Weblogic Portlet doesn't work with Icefaces

Hi..
I've created a simple helloworld portlet using oracle workshop for weblogic. I can open the icefaces pages, but when I open it from portlet seems like they don't render all the tag.
Anyway, here's my facesportlet.portlet
<?xml version="1.0" encoding="UTF-8"?>
<portal:root xmlns:netuix="http://www.bea.com/servers/netuix/xsd/controls/netuix/1.0.0"
     xmlns:portal="http://www.bea.com/servers/netuix/xsd/portal/support/1.0.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/servers/netuix/xsd/portal/support/1.0.0 portal-support-1_0_0.xsd">
     <netuix:portlet definitionLabel="facesportlet" title="Ice Faces">
         <netuix:titlebar>
             <netuix:maximize/>
             <netuix:minimize/>
             <netuix:delete/>
         </netuix:titlebar>
         <netuix:content>
             <netuix:facesContent contentUri="/fcsport/facesportlet.faces"/>
         </netuix:content>
     </netuix:portlet>
</portal:root>faces-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE faces-config PUBLIC
   "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
   "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
<faces-config>
     <managed-bean>
          <managed-bean-name>TestBean</managed-bean-name>
          <managed-bean-class>com.av.test.TestBean</managed-bean-class>
          <managed-bean-scope>request</managed-bean-scope>
     </managed-bean>
     <navigation-rule>
          <from-view-id>/fcsport/facesportlet.jsp</from-view-id>
          <navigation-case>
               <from-outcome>process</from-outcome>
               <to-view-id>/fcsport/facesportlet.jsp</to-view-id>
          </navigation-case>
     </navigation-rule>
     <navigation-rule>
          <from-view-id>/fcsport/anotherjsf.jsp</from-view-id>
          <navigation-case>
               <from-outcome>process</from-outcome>
               <to-view-id>/fcsport/anotherjsf.jsp</to-view-id>
          </navigation-case>
     </navigation-rule>
</faces-config>and jsp file is
<f:view
     xmlns:h="http://java.sun.com/jsf/html"
     xmlns:ice="http://www.icesoft.com/icefaces/component"
     xmlns:f="http://java.sun.com/jsf/core">
     <html>
     <head></head>
     <body>
          <ice:form id="UserForm">
               <table>
               <tr>
                    <td colspan="2"><ice:outputText value="#{TestBean.message}"/></td>
               </tr>
               <tr>
                    <td><ice:outputLabel value="Enter Your Name:"/></td>
                    <td><ice:inputText value="#{TestBean.username}"/></td>
               </tr>
               <tr>
                         <td></td>
                         <td><ice:commandButton action="#{TestBean.processName}" value="OK"/></td>
               </tr>
               </table>
          </ice:form>
     </body>
     </html>
</f:view>if I open facesportlet.portlet from browser and view the source code, it'll display the whole complete tag without rendering it at all (eg: <f:view/> etc..)
Anybody have a clue or reference document for it?
Thanks in Advance..

You should use java portlet in order to use icefaces work. Please follow the instructions from ICEfacesDevelopersGuide.pdf which comes with icefaces installation.

Weblogic security authentication; question to interact with the realm

Hi, I have a quick question about weblogic security authentication....
We are using weblogic 81sp3. We have user-group info in an Novell eDirectory LDAP server.
Currently, a Novell Authenticator provider is configured under : Security > Realms > myRealm > Providers > Authentication This tells Weblogic from where to get the user and groups. Weblogic caches this information of the logged on users for certain time ( example : 60 secs ) after which it cleans the cache for all inactive users. We want to interact with the Weblogic cache. Add more user profile information to this cache and use it in our application .
Does somebody know how to programmatically interact with Weblogic user-group cache - read , write , update and delete user-group info in cache and control time to live for the cache ?

already checked
TTLCache class which weblogic provides. But they seem to depracetd it
help ?

QUESTION Re. Integrating TIBCO EMS with Weblogic 8.1 using MDB

Hi All,
          I am trying to integrate TIBCO EMS 4.3.0 with Weblogic 8.1 SP6.
          I have created a topic "SIMPLE.TOPIC" on the EMS. I have configured the Foreign JMS Server as follows:
          Name: TIBCO JMSServer
          JNDI Initial Context Factory:com.tibco.tibjms.naming.TibjmsInitialContextFactory
          JNDI Connection URL:tibjmsnaming://emshost:emsport
          I have configured the connection factory as follows:
          Name: TIBCO JMSTopicConnectionFactory
          Local JNDI Name: TopicConnectionFactory.Local
          Remote JNDI Name:TopicConnectionFactory
          User Name:username to connect to EMS server
          Password::pssword to connect to EMS server
          My JMS destination is configured as follows:
          Name: Tibco JMS Destination
          Local JNDI Name:SIMPLE.TOPIC.LOCAL
          Remote JNDI Name:SIMPLE.TOPIC
          My weblogic-ejb-jar.xml consists of the following code:
                    <weblogic-ejb-jar>
            <weblogic-enterprise-bean>
              <ejb-name>SimpleTopicListener</ejb-name>
              <message-driven-descriptor>
                <pool>
                  <max-beans-in-free-pool>200</max-beans-in-free-pool>
                  <initial-beans-in-free-pool>20</initial-beans-in-free-pool>
                </pool>
                <destination-jndi-name>SIMPLE.TOPIC</destination-jndi-name>
               <connection-factory-jndi-name>TopicConnectionFactory</connection-factory-jndi-name>
              </message-driven-descriptor>
              <enable-call-by-reference>True</enable-call-by-reference>
            </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
                              The problem is, when I try to deploy this mdb, I get the following error:
          The Message-Driven EJB attempted to connect to the JMS destination with the JNDI name: SIMPLE.TOPIC. However, the object with the JNDI name: SIMPLE.TOPIC is not a JMS destination, or the destination found was of the wrong type (Topic or Queue).
          I have checked and double checked to make sure that the topic SIMPLE.TOPIC does exist on the EMS server.
          Does anyone know what is the issue here and how to resolve it?
          Many thanks!
          -Kinshuk
          Edited by kinshukk at 05/14/2007 8:35 AM

(1) Check the standard ejb jar and make sure you've specified a topic destination type (the default is queue). For details, you can reference the WebLogic 9.0 MDB developer guide (the MDB dev guide was revised in 9.0 to include more detail than the 8.1 guide). Also, you might want to take a look at our integration/interop FAQ (again for 9.0 or later).
          (2) Change the weblogic-ejb-jar to reference the foreign local JNDI names - not the remote JNDI names.
          (3) Be careful about using the "." and "/" characters in local JNDI names - these have side-effects in JNDI (they force creation of subcontexts).
          Tom

IllegalStateException : sesssion.invalidate() with sp9

          I am using Weblogic 5.1 with sp9. I was told this has been fixed in sp12 but I need
          to fix this with sp9 for now. Just wondering if anyone found an easy fix for sp9.
          When I use session.invalidate()in JSP page, it throws IllegalStateException if it
          is first JSP page or servlet (i.e. first session) in that browser. <%session.invalidate();%>
          is the last line of this JSP.
          java.lang.IllegalStateException: HttpSession is invalid
          at weblogic.servlet.internal.session.SessionData.getAttribute(SessionDat
          a.java:159)
          at weblogic.servlet.internal.session.SessionData.getValue(SessionData.ja
          va:131)
          at weblogic.servlet.internal.ServletRequestImpl.getRemoteUser(ServletReq
          uestImpl.java:668)
          at weblogic.t3.srvr.httplog.CLFLogger.log(CLFLogger.java:46)
          at weblogic.t3.srvr.httplog.LogManagerHttp.log(LogManagerHttp.java:421)
          at weblogic.t3.srvr.HttpServer.log(HttpServer.java:882)
          at weblogic.servlet.internal.ServletContextManager.invokeServlet(Servlet
          ContextManager.java:309)
          at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.jav
          a:365)
          at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:253)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129)
          I guess the following is the reason. When this JSP gets compiled, try catch finally
          block is generated surrounding session.invalidate(). After current session gets invalidated,
          finally block is executed and it seems that's where the exception gets thrown.
          // this is generated by compiler
          finally{
          while (_activeTag != null) {
          // release() all active tags...
          Tag tmpTag = activeTag;
          activeTag = activeTag.getParent();
          try { _tmpTag.release(); } catch (Exception __ignore) {}
          I can't think clean simple fix for this. Either change this compiled java code manually
          (put another try catch inside finally) or use server side redirection and put session.invalidate
          in second page. Both workarounds are pretty ugly.


Hi
This works, here is a sample I've run on OC4J
public class SessionTestServlet extends HttpServlet
private static final String CONTENT_TYPE = "text/html";
HttpSession sess = null;
private static boolean login_page = true;
public void init(ServletConfig config) throws ServletException
super.init(config);
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException
sess = request.getSession(true);
try
if (login_page)
if(sess != null)
sess.invalidate();
sess = request.getSession(true);
sess.setAttribute("name","kalle");
catch(Exception e)
e.printStackTrace();
response.setContentType(CONTENT_TYPE);
PrintWriter out = response.getWriter();
out.println("<html>");
out.println
("<head><title>SessionTestServlet</title></head>");
out.println("<body>");
out.println("<p>Session: "+ sess+"<p>Name: "+
sess.getAttribute("name"));
out.println("</body></html>");
out.close();
Regards
//Mike

Web logic Session Invalidate

hi,
i developed j2ee code in eclipse and using tomcat server ver. 4.1. after completing the code, i uploaded the war file into web logic server. In weblogic server when i click on "LogOut" the server is also shutting down along with the page. but this is not happened with TOMCAT.
my invalidation code is
if (event.equals(Constant.EVENT_LOGOFF)) {
     /* invalidate the session and forward to logout url */
                              session.invalidate();
                              System.out.println("url logoff -> " + logoutUrl);
                              response.sendRedirect(logoutUrl);
please tell me what could be the problem.
thanks
Ananda

Hi,
To set these values you can use "plan.xml" which is not part of your application physically. Only u need to have a weblogic.xml file in your application ....even it may be empty...because you can add the Tags functionality on the fly without editing your application.....
Please refer to:
http://jaysensharma.wordpress.com/2009/12/16/updating-cookiename-using-plan-xml/
http://jaysensharma.wordpress.com/2009/11/29/shared-library-with-plan-xml/
http://jaysensharma.wordpress.com/2010/03/24/changing-context-root-of-an-ear-app-using-plan-xml/
Thanks
Jay SenSharma

Form-based authentication problem with weblogic

Hi Everyone,
The following problem related to form-based authentication
was posted one week ago and no reponse. Can someone give it
a shot? One more thing is added here. When I try it on J2EE
server and do the same thing, I didn't encounter this error
message, and I am redirected to the homeage.
Thanks.
-John
I am using weblogic5.1 and RDBMSRealm as the security realm. I am having the following problem with the form-based authentication login mechanism. Does anyone have an idea what the problem is and how to solve it?
When I login my application and logout as normal procedure, it is OK. But if I login and use the browser's BACK button to back the login page and try to login as a new user, I got the following error message,
"Form based authentication failed. Could not find session."
When I check the LOG file, it gives me the following message,
"Form based authentication failed. One of the following reasons could cause it: HTTP sessions are disabled. An old session ID was stored in the browser."
Normally, if you login and want to relogin without logout first, it supposes to direct you to the existing user session. But I don't understand why it gave me this error. I also checked my property file, it appears that the HTTP sessions are enabled as follows,
weblogic.httpd.session.enable=true

Hi...
Hehe... I actually did implement the way you implement it. My login.jsp actually checks if the user is authenticated. If yes, then it will forward it to the home page. On the other hand, I used ServletAuthentication to solve the problem mentioned by Cameron where Form Authentication Failed usually occurs for the first login attempt. I'm also getting this error occasionally. Using ServletAuthentication totally eliminates the occurence of this problem.
I'm not using j_security_check anymore. ServletAuthentication does all the works. It also uses RDBMSRealm to authenticate the user. I think the biggest disadvantage I can see when using ServletAuthentication is that the requested resource will not be returned after authentication cause the page returned after authenticating the user is actually hard coded (for my case, it's the home.jsp)
cheers...
Jerson
"John Wang" <[email protected]> wrote:
>
Hi Jerson,
I tried your code this weekend, it didn't work in my case. But
I solved my specific problem other way. The idea behind my problem is that the user tries to relogin when he already logs in. Therefore, I just redirect the user into another page when he is getting the login page by htting the BACK button, rather than reauthenticate the user as the way you did.
But, I think your idea is very helpful if it could work. Problems such multiple concurrence logins can be solved by pre-processing.
In your new code, you solved the problem with a new approach. I am just wondering, do you still implement it with your login.jsp file? In other word, your action in login.jsp is still "Authenticate"? Where do you put the URL "j_security_check"?
Thanks.
-John
"Jerson Chua" <[email protected]> wrote:
I've solved the problem by using ServletAuthentication. So far I'm not getting the error message. One of the side effects is that it doesn't return the requested URI after authentication, it will always return the home page.
Jerson
package com.cyberj.catalyst.web;
import weblogic.servlet.security.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class Authenticate extends HttpServlet {
private ServletAuthentication sa = new ServletAuthentication("j_username", "j_password");
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, java.io.IOException {
int authenticated = sa.weak(request, response);
if (authenticated == ServletAuthentication.NEEDS_CREDENTIALS ||
authenticated == ServletAuthentication.FAILED_AUTHENTICATION) {
response.sendRedirect("fail_login.jsp");
} else {
response.sendRedirect("Home.jsp");
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, java.io.IOException {
doPost(request, response);
"Jerson Chua" <[email protected]> wrote:
The problem is still there even if I use page redirection. Grrr... My boss wants me to solve this problem so what are the alternatives I can do? Are there any other ways of authenticating the user? In my web tier... I'm using isUserInRole, getRemoteUser and the web tier actually connects to EJBs. If I implement my custom authentication, I wouldn't be able to use this functionalities.
Has anyone solved this problem? I've tried the example itself and the same problem occurs.
Jerson
"Cameron Purdy" <[email protected]> wrote:
Jerson,
First try it redirected (raw) to see if that indeed is the problem ... then
if it works you can "fix" it the way you want.
Peace,
Cameron Purdy
Tangosol, Inc.
http://www.tangosol.com
+1.617.623.5782
WebLogic Consulting Available
"Jerson Chua" <[email protected]> wrote in message
news:[email protected]...
Hi...
Thanks for your suggestion... I've actually thought of that solution. Butusing page redirection will expose the user's password. I'm thinking of
another indirection where I will redirect it to another servlet but the
password is encrypted.
What do you think?
thanks....
Jerson
"Cameron Purdy" <[email protected]> wrote:
Maybe redirect to the current URL after killing the session to let the
request clean itself up. I don't think that a lot of the request (such
as
remote user) will be affected by killing the session until the nextrequest
comes in.
Peace,
Cameron Purdy
Tangosol, Inc.
http://www.tangosol.com
+1.617.623.5782
WebLogic Consulting Available
"Jerson Chua" <[email protected]> wrote in message
news:[email protected]...
Hello guys...
I've a solution but it doesn't work yet so I need your help. Because
one
of the reason for getting form base authentication failed is if an
authenticated user tries to login again. For example, the one mentionedby
John using the back button to go to the login page and when the user logsin
again, this error occurs.
So here's my solution
Instead of submitting the page to j_security_check, submit it to a
servlet
which will check if the user is logged in or not. If yes, invalidates its
session and forward it to j_security_check. But there's a problem in this
solution, eventhough the session.invalidate() (which actually logs theuser
out) is executed before forwarded to j_security_check, the user doesn't
immediately logged out. How did I know this, because after calling
session.invalidate, i tried calling request.RemoteUser() and it doesn't
return null. So I'm still getting the error. What I want to ask you guyis
how do I force logout before the j_security_check is called.
here's the code I did which the login.jsp actually submits to
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class Authenticate extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponseresponse)
throws ServletException, java.io.IOException {
if (request.getRemoteUser() != null) {
HttpSession session = request.getSession(false);
System.out.println(session.isNew());
session.invalidate();
Cookie[] cookies = request.getCookies();
for (int i = 0; i < cookies.length; i++) {
cookies.setMaxAge(0);
getServletContext().getRequestDispatcher("/j_security_check").forward(reques
t, response);
public void doGet(HttpServletRequest request, HttpServletResponseresponse)
throws ServletException, java.io.IOException {
doPost(request, response);
let's help each other to solve this problem. thanks.
Jerson
"Jerson Chua" <[email protected]> wrote:
I thought that this problem will be solved on sp6 but to my
disappointment, the problem is still there. I'm also using RDBMSRealm,same
as John.
Jerson
"Cameron Purdy" <[email protected]> wrote:
John,
1. You are using a single WL instance (i.e. not clustered) on that
NT
box
and doing so without a proxy (e.g. specifying http://localhost:7001),
correct?
2. BEA will pay more attention to the problem if you upgrade to SP6.If
you don't have a reason NOT to (e.g. a particular regression), then
you
should upgrade. That will save you one go-around with support: "Hi,I
am
on SP5 and I have a problem.", "Upgrade to SP6 to see if that fixes
it.
Call back if that doesn't work."
3. Make sure that you are not doing anything special before or after
J_SECURITY_CHECK ... make sure that you have everything configuredand
done
by the book.
4. Email BEA a bug report at [email protected] ... see what they say.
Peace,
Cameron Purdy
Tangosol, Inc.
http://www.tangosol.com
+1.617.623.5782
WebLogic Consulting Available
"John Wang" <[email protected]> wrote in message
news:[email protected]...
Cameron,
It seems to me that the problem I encountered is different a little
from
what you have, evrn though the error message is the same eventually.
Everytime I go through, I always get that error.
I am using weblogic5.1 and sp5 on NT4.0. Do you have any solutions
to
work
around this problem? If it was a BUG as you
pointed out, is there a way we can report it to the Weblogic
technical support and let them take a look?
Thnaks.
-John
"Cameron Purdy" <[email protected]> wrote:
John,
I will verify that I have seen this error now (after having read
about it
here for a few months) and it had the following characteristics:
1) It was intermittent, and appeared to be self-curing
2) It was not predictable, only seemed to occur at the first
login
attempt,
and may have been timing related
3) This was on Sun Solaris on a cluster of 2 Sparc 2xx's; the
proxy
was
Apache (Stronghold)
4) After researching the newsgroups, it appears that this "bug"
may
have gone away temporarily (?) in SP5 (although Jerson Chua
<[email protected]> mentioned that he still got it in SP5)
I was able to reproduce it most often by deleting the tmpwar and
tmp_deployments directories while the cluster was not running,
then
restarting the cluster. The first login attempt would fail(roughly
90%
of
the time?) and that server instance would then be ignored by the
proxy
for a
while (60 seconds?) -- meaning that the proxy would send all
traffic,
regardless of the number of "clients", to the other server in thecluster.
As far as I can tell, it is a bug in WebLogic, and probably has
been
there
for quite a while.
Peace,
Cameron Purdy
Tangosol, Inc.
http://www.tangosol.com
+1.617.623.5782
WebLogic Consulting Available
"John Wang" <[email protected]> wrote in message
news:[email protected]...
Hi Everyone,
The following problem related to form-based authentication
was posted one week ago and no reponse. Can someone give it
a shot? One more thing is added here. When I try it on J2EE
server and do the same thing, I didn't encounter this error
message, and I am redirected to the homeage.
Thanks.
-John
I am using weblogic5.1 and RDBMSRealm as the security realm. I
am
having
the following problem with the form-based authentication login
mechanism.
Does anyone have an idea what the problem is and how to solve it?
When I login my application and logout as normal procedure, it
is
OK.
But
if I login and use the browser's BACK button to back the login
page
and
try
to login as a new user, I got the following error message,
"Form based authentication failed. Could not find session."
When I check the LOG file, it gives me the following message,
"Form based authentication failed. One of the following reasons
could
cause it: HTTP sessions are disabled. An old session ID was stored
in
the
browser."
Normally, if you login and want to relogin without logout first,
it
supposes to direct you to the existing user session. But I don'tunderstand
why it gave me this error. I also checked my property file, it
appears
that
the HTTP sessions are enabled as follows,
weblogic.httpd.session.enable=true

Crating J2EE webservice manually with Weblogic 8.1

HI
IS it possible to create the J2EE web service manually using weblogic 8.1 ?

My understanding is that the answer is 'maybe'.
By 'J2EE web service' are you referring to:
* WSEE, specified by JSRs 109/921? This is the standard that allows you to expose a session bean as a Web service, without (?) using any platform-specific Java-XML mapping classes.
* Or, are you just referring to hosting or accessing a Web service from within a J2EE application?
So, some things that might satisfy your question:
* You can create Web services (non-WSEE) manually with Weblogic, using Ant tasks to generate the bindings and XML documents. The Ant tasks are decribed here: http://e-docs.bea.com/wls/docs81/webserv/anttasks.html. This to me is 'manual' because you're manually generating the binding classes and assembling a WAR, etc.
* I'm pretty sure (but not 100%) that WLAS8.1 doesn't support WSEE Web services, as it's a feature introduced with J2EE 1.4. Still, I could be wrong on this.
Not sure if any of that helped, but there you go.
Cheers,
-Tim

Portlet question- session.invalidate()- with weblogic

Similar Messages

Maybe you are looking for