Java Portlet spefication168 (v1.0) has very basic portlet porgramming model and had lot of limitations for portlet development. Java Portlet spefication286 (v2.0) was developed to overcome the shortcomings on v1.0 specs(JSR 168) such as:
1. Inter portlet communicaiton (IPC) - IPC through events and public render parameters
2. Support for WSRP 2.0
3. Public render paremeters - Allows portlets to share parameters with other portlets.
4. Portlet filters and listeners.
5. Resource serving - Provide ability for portlets to server a resource
6. AJAX support
Weblogic Portal Interview Questions III
Answers to follow:..
1. What is the difference between JSR 168 and JSR 286 specs?
2. What is managed bean?
3. What is the difference between managed bean and backing bean?
4. If you have two same portlet instances in a single page, what are the things you need to consider in using java script?
5. How did you handle security in WSRP?
6. What are the performance issues you had in WSRP?
1. What is the difference between JSR 168 and JSR 286 specs?
2. What is managed bean?
3. What is the difference between managed bean and backing bean?
4. If you have two same portlet instances in a single page, what are the things you need to consider in using java script?
5. How did you handle security in WSRP?
6. What are the performance issues you had in WSRP?
Labels:
Interviews,
Questions,
Weblogic Portal
Why SOA?
SOA helps create greater alignment between IT and line of business while generating more flexibility - IT flexibility to support greater business flexibility. Your business processes are changing faster and faster and global competition requires the flexibility that SOA can provide.
- SOA can help you get better reuse out of your existing IT investments as well as the new services you're developing today.
- SOA makes integration of your IT investments easier by making use of well-defined interfaces between services.
- SOA also provides an architectural model for integrating business partners’, customers’ and suppliers’ services into an enterprise’s business processes. This reduces cost and improves customer satisfaction.
- SOA can help you get better reuse out of your existing IT investments as well as the new services you're developing today.
- SOA makes integration of your IT investments easier by making use of well-defined interfaces between services.
- SOA also provides an architectural model for integrating business partners’, customers’ and suppliers’ services into an enterprise’s business processes. This reduces cost and improves customer satisfaction.
Set session timeout in Weblogic
There are two ways user's HTTP session timeout can be set for your web application.
1. Web.xml
2. Weblogic.xml
Web.xml
<session-config>
<session-timeout>60</session-timeout>
</session-config>
Please note in web.xml the session timeout is set in minutes.
Weblogic.xml
<session-descriptor>
<session-param>
<param-name>TimeoutSecs</param-name>
<param-value>3600</param-value>
</session-param>
</session-descriptor>
In weblogic.xml the session timeout is set in seconds.
More importantly the timeout value set in web.xml takes precedence over weblogic.xml. If you don't set any values in web.xml, weblogic.xml takes over. I think it is better to handle session timeout in web.xml itself since web.xml takes precedence over application server’s deployment descriptors.
1. Web.xml
2. Weblogic.xml
Web.xml
<session-config>
<session-timeout>60</session-timeout>
</session-config>
Please note in web.xml the session timeout is set in minutes.
Weblogic.xml
<session-descriptor>
<session-param>
<param-name>TimeoutSecs</param-name>
<param-value>3600</param-value>
</session-param>
</session-descriptor>
In weblogic.xml the session timeout is set in seconds.
More importantly the timeout value set in web.xml takes precedence over weblogic.xml. If you don't set any values in web.xml, weblogic.xml takes over. I think it is better to handle session timeout in web.xml itself since web.xml takes precedence over application server’s deployment descriptors.
Labels:
Weblogic
Drawbacks of Ajax
We all know how Ajax is important in today's world. Thanks to google. You can develop rich and interactive web/portal applications by using combination of Ajax, Java script, REST APIs. I am not against Ajax but I honestly think one should know when to use it and when NOT to use it. Here are some known limitations of using Ajax.
1. Not all browsers supports Ajax. Though IE 5.x, 6.x, Mozilla 1.x, Firefox still supports.
2. XMLHttpRequest is not supported in older version. No standardization of XMLHttpRequest yet.
3. Java Script code could be visible to a hacker.
4. UI developers must have JavaScript skills.
5. Ajax based applications are difficult to debug, test and maintain.
6. Toolkit/Frameworks are still maturing.
7. Lack of design patterns or best practices guidelines yet.
8. Server side developers need to understand, presentation logic is required both at client & server side as well.
9. Namespace collision is possible.
1. Not all browsers supports Ajax. Though IE 5.x, 6.x, Mozilla 1.x, Firefox still supports.
2. XMLHttpRequest is not supported in older version. No standardization of XMLHttpRequest yet.
3. Java Script code could be visible to a hacker.
4. UI developers must have JavaScript skills.
5. Ajax based applications are difficult to debug, test and maintain.
6. Toolkit/Frameworks are still maturing.
7. Lack of design patterns or best practices guidelines yet.
8. Server side developers need to understand, presentation logic is required both at client & server side as well.
9. Namespace collision is possible.
Subscribe to:
Posts (Atom)