When you access your ADF Faces application and navigate through the different pages, parameters like "_afrLoop" are added dynamically to the URL.
Because I had some problems to find informations regarding _afrLoop parameter, when I found finally needed informations, I decided to share them:)
As Oracle says parameter called New Window Detection Token: "is an unique identifier that is used by ADF Faces java script to determine if the current browser window is new or an existing window it's managing."
In addition, I found the info, that in ADF Faces 12c this "feature" is disabled.
But let's start from the beginning. I started looking for informations about _afrLoop cause of strange problem in my Webcenter Portal Application. Well, after the one of deployments I couldn't log in because of continuous reloads of the login page within the Internet Browser. While reloading, the value of the URL parameter _afrLoop was each time increased.
As it turned out I sought for the cause of the problem in wrong place. The problem was caused in the error in one of shared libraries.
Monday, September 30, 2013
Thursday, September 19, 2013
Polemics with article "Top 10 reasons why I don't like JSF"
I stumbled accidentally on the Bruno Borges article "Top 10 reasons why I don't like JSF". The title made me very interested, but soon I found that I do not agree with most of arguments. Hence my polemic.
Bruno wrotes (about the shortcomings of JSF):
Extra step when defining a project's architecture
" ... People insist on comparing JSF with other frameworks. They should stop doing that. You can compare MyFaces to RichFaces to Tapestry to Vaadin to GWT. JSF is a specification, not a final product.
Vendors too insist on marketing JSF as a Web Framework. But they forget to mention that you will be locked-in to their implementation because of lots and lots of non-standard components. It ain't cool.
You spend a week comparing *one* JSF implementation with other frameworks, and if you chose JSF, you then realize you have an extra step: you have to pick a vendor, an implementation, and then goes another week of POCs, tests and evaluations. And you'll be locked. It is not easy to move from one to another. Specially when you have to use those non-standard components to turn your project on something really functional."
In my opinion, the part of the problem here lies in the confusion of concepts. If we talk about JSF implementation, we should know that there exists only few implementations of JSF specification. And mentioned RichFaces isn't JSF implementation, but it is a component library. Whereas in fact, MyFaces is an Apache implementation of JSF. JSF implementation implements the JSF API specification and contains at least the standard components to display any of the available basic ("plain vanilla") HTML elements, whereas JSF component library just adds extra components on top of the basic implementation. You can't compare MyFaces and RichFaces, cause it's no sense.
In your projects you will usually use one selected JSF implementation. Generally if you will deploy applications to "full-featured" application server, you will have built-in JSF implementation. Of course you can change default implementations, but why?
In servlet container environment (by example Tomcat) you should select the implementation and add appropriate libraries manually.
Anyway, the main available implementations are:
Worse, when the libraries are not properly designed and interfere with each other. But it is a problem of a different nature...
Generally speaking, I think the above arguments are irrelevant. The only problem I see is, as they say in my country, the problem of wealth.
Fragmented Community
" ... Now, let's say you, developer, works on a project for 6 months, on top of RichFaces. Then you move to another project built on top of MyFaces. Yes, you will have to sign in to another mailing list. To another forum. Different from other products, JSF has no centralized community. If you are working with Wicket, you go to users@wicket.apache.org. If you are working with VRaptor, you go to their Forum. If you are working with JSF, you will need to sign up for at least 3 different mailing lists, sign up for 3 forums and probably, tens of blogs... "
I agree, i can be a somte kind of problem, but the case is perhaps somewhat demonized :) Most of the problems which mus be solved during the development is common. Of course there exist large libraries, with complicated components, thus sometimes necessity of deep understanding its specifics is inevitable. But as I wrote, in my opinion it's the problem of wealth.
As regards the comparing MyFaces and RichFaces I wrote earlier.
Fragmented Documentation
" ...If community is important, imagine documentation. You must have bookmarks of all JSF implementations. If you work with GWT, you need only one. If you work with SpringMVC, just go to springframework.org. Also there's the problem of non-standard components. Let's say you are working with Seam, and you have to bind some component to some RichFaces component. Where will you find a documentation about that? There's no such thing. If you are luck, you might find some blog post on Google. Odds you won't find. You will discover by yourself after hours of debugging and tracing, and in the end, you will not blog about that too. You will just move on... "
We are dealing again with the problem of mixing of concepts. If you have any problem with core JSF, then regardless of the implementation you can solve it in common way. In my opinion JSF is standarized sufficient. You don't need search the solutions in community because you have a lot of documentation, starting from JSF and Java EE specification to the lot of books like "Core JSF","JavaServer Faces 2.0, The Complete Reference", and so on. Whereas, if you have a problem which is specific to (by example) RichFaces components, you should search in RichFaces documentation. But this isn't a problem of poor documented JSF framework but eventual problem of documentation of RichFaces library.
Personally I work in recent years with ADF Faces which is in fact poorly documented. The ADF component library is very huge and often causes some problems:) but I haven't lot of difficulties to distinguish between problems on core, implementation level and problems caused clearly by ADF. And if the problem lies on core JSF level, the solution can be find quite easily and it was because of extensive documentation.
Component Incompatibility
"... Component interoperability between different components can't be easily documented because of JSF's nature. This (documentation) also happens on some non-standard frameworks, but there are others that the core architecture helps a lot the developer to just don't care about this. Wicket is one of them. Components are grained and independent. If you want to interoperate different components, you simply share a Model or deal with events..."
This is a truth. Some of the components sourced from outside the standard libraries have the problems of interoperability. On the other hand, it is rather a problem of ill-conceived implementation.
Caveats on some scenarios because of different implementations
" ...This one I heard from a JSF developer. He said RichFaces fires rendering updates in a different way to MyFaces Trinidad. If the developer must be aware of that, odds are you won't find proficient JSF developers.
I pointed about this one at the Web Frameworks discussion at JavaOne. It is not easy to find a Wicket developer, or a Vaadin developer. But when you find them, probability is they will be proficient, or at least above regular web developers.
With JSF, which has tons and tons of job offers around the world, but lots of implementations and caveats, probability is that you will easily and quickly find a JSF developer to hire, but he or she won't be proficient. They will be regular developers. I'm not saying this is 100% true. Of course it is possible to find a proficient JSF developer. But with different implementations, it is hard to find one that knows all about of their tricks, tips, issues and secrets..."
Next problem of wealth:). The libraries of components are sometimes really huge. And there is lot of libraries. But I thought that it proof that JSF is popular and better than others.
Actually there is difficult to find a specialist in everything. But it is not true that it is so difficult to move from one library to another. Basis, the implementation remains the standard.
Designers and developers roles mixed
"Oracle said it has set up JDeveloper or some other inside tool with JSF support to their web designers. Now, this is cool. You teach web designers to define templates, UIs, using the Java IDE. In the end you have the view done and all JEE devs need to do is to bind, code and run.
This is one way of doing it. But usually, it is not the case. Most companies have Web Designers working on Mac, with Photoshop and Dreamweaver or some other WYSIWYG editor. They are great designers partly because of great tools.
With JSF, designers and developers mix their work. Designers spend their time templating. Developers spend most of their time fixing broken templates after mixing them with JSF components. Now this, ain't cool at all.rs..."
Facelets changes a lot, and now this is default view declaration language for JSF. Using facelets you design webpages in "plain" xhtml.
Non-functional prototype
"... it sucks a lot when your web designer changes the UI and you must merge those changes. What if you had a functional prototype you can share with your Web Designer? Some frameworks do that. Tapestr and Wicket for example. The output is HTML, your are building HTML, your designer gives you HTML, so why not take advantage of that work done on a previous stage?"
Facelets (nowe default VDL) has a built-in powerful templating functionality:)
Performance
"Just Google for benchmarks comparing JSF with any other Java Web Framework. The lifecycle is just huge.... "
Hmm. Maybe agree, maybe not. As I suppose most of benchmarks compares old style JSF apps (JSF 1.* and JSP based).
Web is fast, standards are slow
"... HTML5 is almost there, and we are still waiting for a specification that really improves the Web Development Process. Again, JSF2 is a huge step forward, but too late, and just like to what happened with EJB, people are now afraid of it because its previous version. And that's why people started to choose Rails, Python, GWT and other frameworks.
Long learning curve. Slow improvements (thanks to JCP). Everything the Web does not need. Everything Agile methodologies are against to."
Agree:) The learning curve is not optimal. But when a developer has the necessary experience her/his productivity is really very well.
Bruno wrotes (about the shortcomings of JSF):
Extra step when defining a project's architecture
" ... People insist on comparing JSF with other frameworks. They should stop doing that. You can compare MyFaces to RichFaces to Tapestry to Vaadin to GWT. JSF is a specification, not a final product.
Vendors too insist on marketing JSF as a Web Framework. But they forget to mention that you will be locked-in to their implementation because of lots and lots of non-standard components. It ain't cool.
You spend a week comparing *one* JSF implementation with other frameworks, and if you chose JSF, you then realize you have an extra step: you have to pick a vendor, an implementation, and then goes another week of POCs, tests and evaluations. And you'll be locked. It is not easy to move from one to another. Specially when you have to use those non-standard components to turn your project on something really functional."
In my opinion, the part of the problem here lies in the confusion of concepts. If we talk about JSF implementation, we should know that there exists only few implementations of JSF specification. And mentioned RichFaces isn't JSF implementation, but it is a component library. Whereas in fact, MyFaces is an Apache implementation of JSF. JSF implementation implements the JSF API specification and contains at least the standard components to display any of the available basic ("plain vanilla") HTML elements, whereas JSF component library just adds extra components on top of the basic implementation. You can't compare MyFaces and RichFaces, cause it's no sense.
In your projects you will usually use one selected JSF implementation. Generally if you will deploy applications to "full-featured" application server, you will have built-in JSF implementation. Of course you can change default implementations, but why?
In servlet container environment (by example Tomcat) you should select the implementation and add appropriate libraries manually.
Anyway, the main available implementations are:
- JSF RI (Mojarra)
- JBoss JSF
- MyFaces
Worse, when the libraries are not properly designed and interfere with each other. But it is a problem of a different nature...
Generally speaking, I think the above arguments are irrelevant. The only problem I see is, as they say in my country, the problem of wealth.
Fragmented Community
" ... Now, let's say you, developer, works on a project for 6 months, on top of RichFaces. Then you move to another project built on top of MyFaces. Yes, you will have to sign in to another mailing list. To another forum. Different from other products, JSF has no centralized community. If you are working with Wicket, you go to users@wicket.apache.org. If you are working with VRaptor, you go to their Forum. If you are working with JSF, you will need to sign up for at least 3 different mailing lists, sign up for 3 forums and probably, tens of blogs... "
I agree, i can be a somte kind of problem, but the case is perhaps somewhat demonized :) Most of the problems which mus be solved during the development is common. Of course there exist large libraries, with complicated components, thus sometimes necessity of deep understanding its specifics is inevitable. But as I wrote, in my opinion it's the problem of wealth.
As regards the comparing MyFaces and RichFaces I wrote earlier.
Fragmented Documentation
" ...If community is important, imagine documentation. You must have bookmarks of all JSF implementations. If you work with GWT, you need only one. If you work with SpringMVC, just go to springframework.org. Also there's the problem of non-standard components. Let's say you are working with Seam, and you have to bind some component to some RichFaces component. Where will you find a documentation about that? There's no such thing. If you are luck, you might find some blog post on Google. Odds you won't find. You will discover by yourself after hours of debugging and tracing, and in the end, you will not blog about that too. You will just move on... "
We are dealing again with the problem of mixing of concepts. If you have any problem with core JSF, then regardless of the implementation you can solve it in common way. In my opinion JSF is standarized sufficient. You don't need search the solutions in community because you have a lot of documentation, starting from JSF and Java EE specification to the lot of books like "Core JSF","JavaServer Faces 2.0, The Complete Reference", and so on. Whereas, if you have a problem which is specific to (by example) RichFaces components, you should search in RichFaces documentation. But this isn't a problem of poor documented JSF framework but eventual problem of documentation of RichFaces library.
Personally I work in recent years with ADF Faces which is in fact poorly documented. The ADF component library is very huge and often causes some problems:) but I haven't lot of difficulties to distinguish between problems on core, implementation level and problems caused clearly by ADF. And if the problem lies on core JSF level, the solution can be find quite easily and it was because of extensive documentation.
Component Incompatibility
"... Component interoperability between different components can't be easily documented because of JSF's nature. This (documentation) also happens on some non-standard frameworks, but there are others that the core architecture helps a lot the developer to just don't care about this. Wicket is one of them. Components are grained and independent. If you want to interoperate different components, you simply share a Model or deal with events..."
This is a truth. Some of the components sourced from outside the standard libraries have the problems of interoperability. On the other hand, it is rather a problem of ill-conceived implementation.
Caveats on some scenarios because of different implementations
" ...This one I heard from a JSF developer. He said RichFaces fires rendering updates in a different way to MyFaces Trinidad. If the developer must be aware of that, odds are you won't find proficient JSF developers.
I pointed about this one at the Web Frameworks discussion at JavaOne. It is not easy to find a Wicket developer, or a Vaadin developer. But when you find them, probability is they will be proficient, or at least above regular web developers.
With JSF, which has tons and tons of job offers around the world, but lots of implementations and caveats, probability is that you will easily and quickly find a JSF developer to hire, but he or she won't be proficient. They will be regular developers. I'm not saying this is 100% true. Of course it is possible to find a proficient JSF developer. But with different implementations, it is hard to find one that knows all about of their tricks, tips, issues and secrets..."
Next problem of wealth:). The libraries of components are sometimes really huge. And there is lot of libraries. But I thought that it proof that JSF is popular and better than others.
Actually there is difficult to find a specialist in everything. But it is not true that it is so difficult to move from one library to another. Basis, the implementation remains the standard.
Designers and developers roles mixed
"Oracle said it has set up JDeveloper or some other inside tool with JSF support to their web designers. Now, this is cool. You teach web designers to define templates, UIs, using the Java IDE. In the end you have the view done and all JEE devs need to do is to bind, code and run.
This is one way of doing it. But usually, it is not the case. Most companies have Web Designers working on Mac, with Photoshop and Dreamweaver or some other WYSIWYG editor. They are great designers partly because of great tools.
With JSF, designers and developers mix their work. Designers spend their time templating. Developers spend most of their time fixing broken templates after mixing them with JSF components. Now this, ain't cool at all.rs..."
Facelets changes a lot, and now this is default view declaration language for JSF. Using facelets you design webpages in "plain" xhtml.
Non-functional prototype
"... it sucks a lot when your web designer changes the UI and you must merge those changes. What if you had a functional prototype you can share with your Web Designer? Some frameworks do that. Tapestr and Wicket for example. The output is HTML, your are building HTML, your designer gives you HTML, so why not take advantage of that work done on a previous stage?"
Facelets (nowe default VDL) has a built-in powerful templating functionality:)
Performance
"Just Google for benchmarks comparing JSF with any other Java Web Framework. The lifecycle is just huge.... "
Hmm. Maybe agree, maybe not. As I suppose most of benchmarks compares old style JSF apps (JSF 1.* and JSP based).
Web is fast, standards are slow
"... HTML5 is almost there, and we are still waiting for a specification that really improves the Web Development Process. Again, JSF2 is a huge step forward, but too late, and just like to what happened with EJB, people are now afraid of it because its previous version. And that's why people started to choose Rails, Python, GWT and other frameworks.
Long learning curve. Slow improvements (thanks to JCP). Everything the Web does not need. Everything Agile methodologies are against to."
Agree:) The learning curve is not optimal. But when a developer has the necessary experience her/his productivity is really very well.
Tuesday, September 17, 2013
JSF Errors: JSF1011: Evaluation of expression for attribute ''..'' resulted in unexpected type. Expected .. , but received .. .
Exception encountered in Mojarra classes
com.sun.faces.taglib.jsf_core.ConvertDateTimeTag and com.sun.faces.taglib.jsf_core.ConvertNumberTag in method evaluateExpressions when value of specified locale (localeExpression) isn't literal text and also isn't valid expression value.private void evaluateExpressions()
{
FacesContext facesContext = FacesContext.getCurrentInstance();
ELContext elContext = facesContext.getELContext();
// ...
if (this.localeExpression != null) {
if (this.localeExpression.isLiteralText()) {
this.locale = getLocale(this.localeExpression.getExpressionString());
} else {
Object loc = ELUtils.evaluateValueExpression(this.localeExpression, elContext);
if (loc != null) {
if ((loc instanceof String)) {
this.locale = getLocale((String)loc);
} else if ((loc instanceof Locale)) {
this.locale = ((Locale)loc);
} else {
// Exception JSF 1011
}
}
else
{
this.locale = facesContext.getViewRoot().getLocale();
}
}
}
// ...
}
JSF Errors: JSF1010: Illegal view ID .. . The ID must begin with ''/''
The error message "JSF 1010 Illegal view ID ..." states clearly you provided bad VIEW ID somewhere in your jsf/xhtml code. Oh, remember, VIEW ID is not a component ID:)
The error could be raised in classes (Mojarra)
The error could be raised in classes (Mojarra)
com.sun.faces.application.ViewHandlerImpl or com.sun.faces.application.MultipleViewHandlerImpl in method:
public String getActionURL(FacesContext context, String viewId){
...
if (viewId.charAt(0) != '/') {
// The error will be raised HERE
}
...
}
JSF Errors: JSF1017: ''..' was thrown while handling the PreDestroy annotation(s) for bean ''..'' in scope ''..''. Message: ..
JSF Error 1017 could be found in application server logs in form:
The exception can be raised in Mojarra method com.sun.faces.application.WebappLifecycleListener.handleAttributeEvent if an error occured when BeanManager tries to destroy specified Bean, as shown below:
INFO: JSF1017: 'java.lang.NullPointerException' was thrown while handling the PreDestroy annotation(s) for bean 'ajaxBean' in scope 'REQUEST'
The exception can be raised in Mojarra method com.sun.faces.application.WebappLifecycleListener.handleAttributeEvent if an error occured when BeanManager tries to destroy specified Bean, as shown below:
private void handleAttributeEvent(String beanName, Object bean, ELUtils.Scope scope)
{
ApplicationAssociate associate = getAssociate();
try {
if (associate != null) {
BeanManager beanManager = associate.getBeanManager();
if ((beanManager != null) && (beanManager.isManaged(beanName)))
beanManager.destroy(beanName, bean);
// Thr error will be rised HERE
}
}
...
JSF Errors: JSF1027: .. The ELResolvers for JSF were not registered with the JSP container.
When you got an error described in form:
please read this article
INFO: JSF1027: [null] The ELResolvers for JSF were not registered with the JSP container.
please read this article
Saturday, September 14, 2013
JSF Errors: JSF1006: Cannot instantiate converter of type ..
JSF1006 error is one of less common. The error can be thrown when JSF
In the Mojarra implementation, if the Converter cannot be find, additional exception message can be logged:
When Converter object cannot be created for other reasons then will be thrown:
Application object tries to create new Converter. To create a Converter, the framework uses the method createConverter. Exception could be thrown when specified Converter can not be found, primarily when Converter Id Map (contained by Application object) doesn't contain it:public Converter createConverter(String converterId)
{
Util.notNull("converterId", converterId);
Converter returnVal = (Converter)newThing(converterId, this.converterIdMap);
if (returnVal == null) {
Object[] params = { converterId };
if (LOGGER.isLoggable(Level.SEVERE)) {
LOGGER.log(Level.SEVERE, "jsf.cannot_instantiate_converter_error", converterId);
// !!! The error will be thrown here.
etc..
In the Mojarra implementation, if the Converter cannot be find, additional exception message can be logged:
Expression Error: Named Object: 'your_converter_name' not foundWhen Converter object cannot be created for other reasons then will be thrown:
AssertionErrorFacesExceptionwith message "Cannot instantiate class"- Under certain conditions another FacesMessage form methods
com.sun.faces.Application.newThingorcom.sun.faces.util.Util.loadClass
Friday, September 13, 2013
JSF Errors: JSF1007: Duplicate component ID .. found in view
The exception described as JSF1007 could be thrown when in JSF View (JSF JSP or Facelets page) duplicate component IDs are found. In Mojarra implementation the exception can be thrown from method
com.sun.faces.util.Util.checkIdUniqueness:public static void checkIdUniqueness(FacesContext context, UIComponent component, Set<string> componentIds)
{
Iterator kids = component.getFacetsAndChildren();
while (kids.hasNext())
{
UIComponent kid = (UIComponent)kids.next();
String id = kid.getClientId(context);
if (componentIds.add(id)) {
checkIdUniqueness(context, kid, componentIds);
} else {
if (LOGGER.isLoggable(Level.SEVERE)) {
LOGGER.log(Level.SEVERE, "jsf.duplicate_component_id_error", id);
FastStringWriter writer = new FastStringWriter(128);
DebugUtil.simplePrintTree(context.getViewRoot(), id, writer);
LOGGER.severe(writer.toString());
}
// The exception described as JSF1007 will be thrown here
JSF Errors: JSF1005: Cannot instantiate validator of type ...
JSF1005 error is one of less common. The error can be thrown when JSF
In the Mojarra implementation, if the Validator cannot be find, additional exception message can be logged:
When Validator object cannot be created for other reasons then will be thrown:
Application object tries to create new Validator. To create a Validator, the framework uses the method createValidator. Exception could be thrown when specified Validator can not be found, primarily when Validator Map (contained by Application object) doesn't contain it:public Validator createValidator(String validatorId)
throws FacesException
{
Util.notNull("validatorId", validatorId);
Validator returnVal = (Validator)newThing(validatorId, this.validatorMap);
if (returnVal == null) {
Object[] params = { validatorId };
if (LOGGER.isLoggable(Level.SEVERE)) {
LOGGER.log(Level.SEVERE, "jsf.cannot_instantiate_validator_error", params);
}
// !!! The error will be thrown here.
etc..
In the Mojarra implementation, if the Validator cannot be find, additional exception message can be logged:
Expression Error: Named Object: 'your_validator_name' not foundWhen Validator object cannot be created for other reasons then will be thrown:
AssertionErrorFacesExceptionwith message "Cannot instantiate class"- Under certain conditions another FacesMessage form methods
com.sun.faces.Application.newThingorcom.sun.faces.util.Util.loadClass
JSF Error: JSF1009: Unable to determine FaceServlet mapping for servlet path ..
Rarely encountered error raised in Mojarra implementation in method
com.sun.faces.util.Util.getFacesMapping when com.sun.faces.util.Util.getMappingForRequest returns null:...
ExternalContext extContext = FacesContext.getCurrentInstance()..getExternalContext();
String servletPath = extContext.getRequestServletPath();
String pathInfo = extContext.getRequestPathInfo();
...
mapping = getMappingForRequest(servletPath, pathInfo);
...
//Method getMappingForRequest
private static String getMappingForRequest(String servletPath, String pathInfo)
{
if (servletPath == null) {
return null;
}
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.log(Level.FINE, "servletPath " + servletPath);
LOGGER.log(Level.FINE, "pathInfo " + pathInfo);
}
if (servletPath.length() == 0) {
return "/*";
}
if (pathInfo != null)
return servletPath;
if (servletPath.indexOf('.') < 0)
{
return servletPath;
}
return servletPath.substring(servletPath.lastIndexOf('.')); }
JSF Warning: WARNING: FacesMessage(s) have been enqueued, but may not have been displayed. ..
Warning raised from
com.sun.faces.renderkit.RenderKitUtils.renderUnhandledMessages (Mojarra) when while iterating through the list of unhandled messages none of them can be rendered. This problem can occur in production mode because in the project (application) which is in production stage the unhandled messages are suppressed. In development stage the problem doesn't occurs.
JSF Warnings: JSF1015: Request path ''..'' begins with one or more occurrences of the FacesServlet prefix path mapping ''..''.
The warning JSF1015 can be raised when redirect URI starts with multiple occurences of Faces Servlet mapping (usually string:
faces/ ), by example: /faces/faces/index.xhtml. In Mojarra implementation warning can be raised from methods:- com.sun.faces.application.ViewHandlerImpl.normalizeRequestURI
- com.sun.faces.application.view.MultiViewHandler.normalizeRequestURI
JSF Errors: JSF1008: Redirect to path .. failed
Rarely encountered exception. In Mojarra implementation thrown from method
com.sun.faces.application.NavigationHandlerImpl.handleNavigation when IOException was thrown from:...
public void handleNavigation(FacesContext context, String fromAction, String outcome)
{
...
ExternalContext extContext = context.getExternalContext();
...
String redirectUrl = viewHandler.getRedirectURL( ... );
...
extContext.redirect(redirectUrl);
...
Tuesday, September 10, 2013
Configuring High Availability for Oracle ADF Applications - short manual
When the ADF web application runs in a clustered environment, a portion of the application's state is serialized and copied to another server or a data store at the end of each request so that the state is available to other servers in the cluster.
To make an ADF application runnable in clustered environment you should configure it properly to ensure it's state can be restored from any server in the cluster. To do this:
- Ensure if any object that might be replicated to another instance of the server, should be Serializable. In other words: all managed beans with a life span longer than one request (beans stored in session scope, page flow scope, and view scope) should be serializable (they should implement the
java.io.Serializableinterface). - Don't bind ADF UI Components to Backing Beans other than request scoped because ADF UI Components are not serializable.
- Ensure that Oracle ADF is aware of changes to managed beans stored in
ADF scopes (view scope and page flow scope) and enable the tracking of
changes to ADF memory scopes.
You can mannualy inform ADF Controller about modifications in both scopes callingmarkScopeDirty()method. You can also enable automatic tracking of scope modifications. To do this you should modifyadf-config.xmlas shown below:
- To enable support for ADF Business Components failover, set the
jbo.dofailoverparameter totrueso that the application module state is saved on release. This allows Oracle ADF to restore the application module state from a snapshot saved from a previous checkin. - To support automatic replication and failover for web applications
within a clustered environment, WebLogic Server supports
mechanisms for replicating HTTP session state across clusters. To enable this option you should also modify
weblogic-application.xmlfile:
Thursday, September 5, 2013
How to replace internal WebLogic server 10.3.5 shipped with JDeveloper 11.1.1.6/7 with WebLogic server 10.3.6
The procedure I will share is in my opinion excellent and probably hardly known. Curren version of Oracle FMW (11.1.1.7/8) is shipped with WeblogicServer 10.3.6, but JDeveloper 11.1.1.7 is shipped still with WebLogic 10.3.5.
Difference between both versions isn't very big, but sometimes can provide huge problems in software production and deployment process. It is truism, that the thing that is vital to developers is the ability to run the exact same platform in development and QA as you do in production. Especially in so big, complicated software envinronment like Oracle FMW stack. So, possibility to "improve" development envinronment will be in this situation wothless.
As I suppose possibility to change "built-in" WebLogic will be surprise to many users of JDeveloper. Especially because the procedure of "replacement" is very simple:
In the first, to replace old version of WebLogic, you should install the newer version. Let's install it for example to folder c:\Oracle\Middlewarew7\.
Next you should run Application Server Navigator in your JDeveloper (menu Application | Application Server Navigator)
In Application Server Navigator add New Application Server, and next choose Integrated Server
In next step set instance name, select "Let JDeveloper manage the lifecycle for this Server Instance", fill fields "Domain Directory" and "Server Instance".
The remaining steps are already common. Finally we will have new Integrated Server connection.
There is one ... but ... here. You can run, debug and deploy your web applications, but you can't use this command:
however you can start server instance from main menu:
Difference between both versions isn't very big, but sometimes can provide huge problems in software production and deployment process. It is truism, that the thing that is vital to developers is the ability to run the exact same platform in development and QA as you do in production. Especially in so big, complicated software envinronment like Oracle FMW stack. So, possibility to "improve" development envinronment will be in this situation wothless.
As I suppose possibility to change "built-in" WebLogic will be surprise to many users of JDeveloper. Especially because the procedure of "replacement" is very simple:
In the first, to replace old version of WebLogic, you should install the newer version. Let's install it for example to folder c:\Oracle\Middlewarew7\.
Next you should run Application Server Navigator in your JDeveloper (menu Application | Application Server Navigator)
In Application Server Navigator add New Application Server, and next choose Integrated Server
In next step set instance name, select "Let JDeveloper manage the lifecycle for this Server Instance", fill fields "Domain Directory" and "Server Instance".
The remaining steps are already common. Finally we will have new Integrated Server connection.
There is one ... but ... here. You can run, debug and deploy your web applications, but you can't use this command:
however you can start server instance from main menu:
Problem when deploying SOA composites to instance with IPv6 enabled
In some configurations, when Weblogic SOA domain was installed on Windows Server machine with enabled IPv4 and IPv6 addressing, we observed some difficulties.
Particularly irritating was the problem with deploying SOA composites directyly from JDeveloper (for example in 11.1.1.7), when you can get:
As I found in documentation (although it concerned a different issue) :
... this scenario typically happens when an administrator does not
specify the listen address for a server in the configuration and the
server is running on a dual stack (IPv6/IPv4) machine where Java and the
operating system are configured to use IPv6 in preference to IPv4. In
these mixed environments where the IPv4 stack cannot communicate with
IPv6, Oracle recommends starting all server instances with the following
command so that all servers are downgraded to use IPv4 only:
-Djava.net.preferIPv4Stack=true
You can set this in administration console as shown below:
However, I noticed this does not always work. Therefore I propose a different solution. You can simply specify the listen IPv4 address for a server in the configuration file.
Subscribe to:
Posts (Atom)