We are using JSF 1.2 and WAS 6.1 in our application.
I am from servlet background and understand instance variable of a servlet class are not thread safe because instance variable are shared among all requests AND each request creates a new thread and gets served using doGet or doPost or any other handler.
How is above scenario handled in JSF 1.2?
We are using ChangeAddress managed bean with the following entry in faces-config.xml. Does Faces Servlet create new instances of ChangeAddressBean for each request?
<managed-bean>
<managed-bean-name>ChangeAddress</managed-bean-name>
<managed-bean-class>com.ChangeAddressBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
If the answer to point 2 is yes then how are final static variable used for all requests? Do final static variables remain common for all requests? Value of
anAddressFinder is populated in a static block but value may differ for different type of users based on some condition. Does that mean value of anAddressFinder once populated for first request/user will remain same for all subsequent requests/users?
public class ChangeAddressBean{
int flatNumber;
final static AddressFinder anAddressFinder;
.
.
.
}
Yes. 2. The value of "anAddressFinder" is bound the the class definition, not a particular class instance. You're assumption is correct. This is not the approach you should use. Based on the name alone, "AddressFinder" sounds very much like it should be a singleton service. Let Spring manage and inject this dependency in your ManagedBean. Fetch the needed data in an init() post-construct method or similar. In general, avoid static members in this context. They make testing more difficult, and it your case are not thread-safe.
Related
in this code, should i use transient?
when can i use transient?
what is the difference ?
need your help
private Map<String, HermesCustomConsumer> topicSourceMap = new ConcurrentHashMap();
private Map<TopicAndPartition, Long> currentOffsets = new HashMap<>();
private transient Map<TopicAndPartition, Long> restoredState;
TL;DR
If you use transient variable, you'd better instantiate it in open() method of operators which implemented Rich interface. Otherwise, declare the variable with an initial value at the same time.
The states you use here are called raw states managed by the user itself. Whether you should use transient modifier depending on serialization purpose. Before you submit the Flink job. The computation topology will be generated and distributed into Flink cluster. And operators including source and sink will instantiate with fields e.g, topicSourceMap in your code. Variables topicSourceMap and currentOffsets have been instantiated with constructor. While restoredState is a transient variable, thus no matter what initial value you assigned with, it will not be serialized and distributed into some task to execute. So you usually need to instanciate it in open() method of operator which implemented Rich interface. After this operator is deserialized in some task, open() method would be invoked into instantiate your own states.
I need to create an MasterEndpoint from a given (as Endpoint instance in Java) FileEndpoint.
Normally i create an class extending the desired endpoint and call all needed setter (e.g. to set context) from with in constructor or in an init method.
Sometimes i create a method that uses getContext().getEndpoint("name", ClazzOfEndpoint.class) within the route builder.
But how to do this with MasterEndpoint (preferable without using string literals/constants)?
The problem with extending MasterEndpoint is the unusual constructor it uses. The problem with using getEndpoint is: how to connect the returned master endpoint to the FileEndpoint?
You cannot really do this as that master component is not designed for being build programmatically. You get the endpoint via configuring it using a string uri. This is also the recommended way in Camel to setup and define endpoints. Don't program them manually.
I found a way that suits my needs:
First create the master endpoint together with it's child:
masterEndpoint = context.getEndpoint("master:fileLock:file:" + rootFolder, MasterEndpoint.class);
To programmatically configure the child endpoint (in my case FileEndpoint) obtain it from master and configure it:
fileEndpoint = (FileEndpoint) masterEndpoint.getEndpoint();
fileEndpoint.setAutoCreate(false);
fileEndpoint.setAntInclude(ANT_INCLUDE);
fileEndpoint.setMove(doneFolder);
fileEndpoint.setMoveFailed(errorFolder);
It would be extreme cumbersome (and error prone) to configure it with strings.
Does anybody knows why BlockData class doesn't directly implement IContent?
I know that during BlockData is being retrieve from database, proxy created by Castle implements IContent.
If StackOverflow isn't suitable place for this kind of a question, please move it.
Johan Björnfot at EPiServer explains some of the details in this post.
Excerpt:
"In previous versions of CMS was pages (PageData) the only content type that the content repository (traditionally DataFactory) handled. In CMS7 this has changed so now content repository (IContentRepository) handles IContent instances. This means that the requirement for a .NET type to be possible to save/load from content repository is that it implements the interface EPiServer.Core.IContent.
There are some implementations of IContent built into CMS like PageData and ContentFolder (used to group shared block instances) and it is also possible to register custom IContent implementations.If you look at BlockData though you will notice that it doesn’t implement IContent, how is then shared block instances handled?
The answer is that during runtime when a shared block instance is created (e.g. through a call to IContentRepository.GetDefault where T is a type inheriting from BlockData) the CMS will create a new .NET type inheriting T using a technic called mixin where the new generated subclass will implement some extra interfaces (including IContent)."
BlockData does implement IContent as it is intended to work both when added to another content item such as a PageData instance (a.k.a. Local Block), and as a standalone instance (a.k.a.Shared Block). In latter case the interface is added by using a mix-in though Castle Windsor so that it can be referenced.
The decision for this construct was based on wanting to be able to use the same rendering templates regardless if a block is local or shared. Therefor the choice stood between having a large number of empty properties on local blocks or the current solution using mixins. Both options were tested and mixins was selected as the preferred solution even though it's not a perfect one.
BlockData "does implement IContent", just do:
var myContent = (IContent)myBlock;
But, if you're by any chance handling a Block which itself is a property (not a ContentReference), that cast will throw an exception.
This will be true for 100% of all cases (... using Math.Round).
I've been researching ways to store global settings for my Android application and so far the best way seems to extend the Application class and store the shared data inside it, as described here. I've discovered that instead of using (CustomApplicationClass)getApplicationContext().getSomething() i can do the same thing by referencing directly to the static method inside the class like this: CustomApplicationClass.getSomething() and both ways work just fine.
Here's a piece from CustomApplicationClass:
public class CustomApplicationClass extends Application {
private static boolean something;
#Override
public void onCreate() {
[...]
}
public static boolean isSomething() {
return something;
}
public static void setSomething(boolean something) {
this.something = something;
}
}
Now, if i want to retrieve value of "something" variable somewhere in my code, say, from my application Activity, is there a difference between:
boolean var1 = ((CustomApplicationClass)getApplicationContext()).isSomething();
and
boolean var1 = CustomApplicationClass.isSomething();
? When running the application, both work fine. Is the second way safe to use, or is it inadvisable?
I've been researching ways to store global settings for my Android application and so far the best way seems to extend the Application class and store the shared data inside it, as described here.
Except that you're not doing that.
I've discovered that instead of using (CustomApplicationClass)getApplicationContext().getSomething() i can do the same thing by referencing directly to the static method inside the class like this: CustomApplicationClass.getSomething() and both ways work just fine.
Of course. You could just as easily had CustomApplicationClass extend Object, then executed CustomApplicationClass.getSomething(). You are gaining nothing by your current approach versus just using an ordinary singleton pattern in Java, and you are losing flexibility, as an application can only have one custom subclass of Application.
Is the second way safe to use, or is it inadvisable?
The first way is pointless, since your data member and methods are static.
Either:
Make your stuff in CustomApplicationClass not be static, and then use getApplicationContext().
Refactor CustomApplicationClass to not extend Application, and then use the static data member and/or accessor methods, or switch more formally to the Java singleton pattern.
Personally, I would go with option #2.
If you check the api of android.app.Application (http://developer.android.com/reference/android/app/Application.html) then you will find on Class Overview as following:
Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's tag, which will cause that class to be instantiated for you when the process for your application/package is created.
There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.
As I have posted before also,I am developing a site in two languages done in CakePHP.
Now the latest problem I am facing in my application is that the application is not sharing the Cache values between the Main Domain and the Subdomain.Please help me out of this mess...!!!
Thanks in advance.
There are 3 problems connected to this.
Data you're caching manually by using Cache::read() and Cache::write()
Just use a prefix for each subdomain when using the methods.
Element caching
you can solve this "almost" elegantly by following these steps:
Create my_view.php (or whatever) in app/views
Content:
class MyView extends View {
}
Search for view.php in the Cake Core and copy the element() method to your newly created class. Add your subdomain prefix in the part where the caching happens
In your AppController::beforeFilter() write
$this->view = 'MyView';
Now you have control over the CakePHP view layer. You have just overridden the element method.
Alternatively to this approach (if your codebase isn't already using elements extensively) you could just create a helper with a method, that takes the same arguments as the View::element() method, add the subdomain key to the cache options and call the orginal element() method.
Full Page Caching
This is a tricky one. The full page caching happens in the dispatch() method before you have any possibility to modify the behavior. The second problem is, that CakePHP uses the relative URL of the page to cache it. The relative URLs are most likely identical under your different subdomains.
I think the simplest approach here is to create a Dispatcher class, which extends the original dispatcher. Override the cached() method and implement your desired behavior, like the prefixes. Then in your app/webroot/index.php you need to change this line
$Dispatcher = new Dispatcher();
...to your new class name.