Is it safe to implement a MIDlet class as a singleton? That is, after all, the Display class is acting like a singleton for each and every midlet so is the midlet itself a singleton by behaviour so that implementing it as such wouldn't break something?
In other words, it is not possible to have two instances of an app running, is it? I mean, the AMS wouldn't allow it, would it?
Thanks!
Normally Singleton classes have protected constructor, and this will cause a problem because the AMS needs the MIDlet class constructor to be public not protected nor private.
Related
The Service Fabric requires [DataContract] and [DataMember] attributes for all the classes that are used as input parameters for the Actor services.
Is there a way to override this default?
In our project we heavily use the read-only message classes, which have read-only properties and constructors. The serialization is handled by Newtonsoft JSON serializer, which works just great. Now, I want to send this messages in Service Fabric, so I need a way to override the default WCF-like serialization to something like JSON serializer.
I was able to make a workaround by implementing the serialization myself. Basically, this is how it works:
Define an actor (+ contract) which accepts and returns byte[] + type name, e.g.
Task<byte[]> DoWork(string typeName, byte[] message);
Deserialize byte[] to an instance of the specified type by using custom serializer (I used Newtonsoft JSON converter).
On the sending side, serialize object to byte[] using the same serializer.
I defined some base classes to wrap that, so I don't have to repeat it for every actor / client.
This feels a bit hacky though. Would be nice to get some opinion from the Service Fabric team. Would be even nicer to get the native extensibility point from the platform itself. DataContract feels a bit archaic, it's not used anywhere in our project anymore.
This approach is described in more details in my blog post.
I don't think this is possible at the minute unfortunately. From this article,
"Reliable Collections allow the serializer to be overridden, but
Reliable Actors currently do not."
So it might be worth mapping to new classes.
I need to call a method annotated with #Asynchronous in EJB from a ConversationScoped bean. Inside this method I create instances of some classes using #Inject to inject ConversationScoped beans.
Is it somehow possible to set the context of the asynchronous method to given Conversation?
I hope you can help me.
No, absolutely not. EJBs do per definition not run in web container, but in EJB container. In essence, having any web-related artifact/dependency (including javax.faces.* classes) inside an EJB class is a red alert. You're not supposed to inject/access any class from the client tier (the WAR) in the business tier (the EJB/EAR). Moreover, conversation scoped beans are tied to a HTTP request parameter and this information is nowhere available in an EJB container.
Whatever problem you're trying to solve and for which you incorrectly thought that this all would be the right solution, it has to be solved differently. As an educated guess, I think you just need to let the EJB fire a CDI event or take a callback argument.
See also:
JSF Service Layer
Is it possible to define, within XML, a standard Spring Integration bean as an abstract bean which can be overridden. The idea of course would be to minimize configuration.
For instance, say one needs several jms:message-driven-adapter beans, all which share some common properties. How could one define an abstract bean with those properties, and then override it with concrete beans which have just the parameters which are different between each instance?
Thanks
You cannot do it with the namespace; but the JMS message-driven adapter is a relatively simple component that you can define with normal <bean/> syntax. You would need to wire together a JmsMessageDrivenEndpoint which takes an AbstractMessageListenerContainer (DefaultMessageListenerContainer) and a ChannelPublishingJmsMessageListener in its constructor.
In general, taking a look at the namespace parser for each component will tell you what <bean/>s to define.
Another technique is to define a "mini" application context defining the endpoint with property placeholders and then create a new instance of the context each time, making the main context the parent.
The general technique is explored for outbound ftp endpoints in this sample. However, it does not make its contexts children (because it's not needed there). However, the README has a link to a forum thread that explains that mechanism, when used for dynamic inbound endpoints.
Actually I'm new to JSF and Facelets and enterprise apps despite i've been working on it the last 4 months, anyway, i'm developing a web page which has a login, an user administrator and a documents administrator (it has more but it doesn't matter) and i have to manage the acces and the content of pages according to each user permissions. Reading about security i've found out many ways of doing a login, but i have made my own with Stateful Beans in order to maintain the users data in the application for using them later so i can restrict the content. the question is... is this the correct way to manage the content according to users restrictions?
if not, which is the best and securest way of doing it?
this is my Stateful Bean (i did not include the Getters and Setters)
#ManagedBean
#Stateful
public class HandlerLogin implements Serializable{
#EJB
private LoginMethodsLocal loginMethods;
private String loginNickname;
private String loginPassword;
private String userData[];
//[0]=Nickname
//[1]=Name
//[2]=User Type
private boolean loguedIn= false;
public void check(){
System.out.println(this.loginNombre);
System.out.println(this.loginContrasena);
this.userData= loginMethods.Login(this.loginNickname, this.loginPassword);
//the method loginMethods.Login() queries in the database looking for
//"this.loginNickname" and "this.loginPassword"
if (this.userData!=null){
this.loguedIn=true;
}
else{
this.loguedIn= false;
FacesContext.getCurrentInstance().addMessage("mensajesLogin", new FacesMessage("Error, User Does not Exist"));
}
}
public void closeSession(){
this.userData=null;
}
}
so my logic to manage the content and navigation is to check what kind of user is and depending on it determine how the acces and rendering is going to be
The #Stateful annotation does nothing in a JSF #ManagedBean. That annotation is only really been used when the class is by itself injected as #EJB in another managed bean or EJB and even then, a brand new and completely different instance with all properties set to default would have been created and used. So the #Stateful annotation definitely doesn't do what you think it does. Remove it, it makes no sense in this context.
Whether the remaining code is the correct way or not depends on the concrete functional requirements. There are many ways which are equally good and secure (assuming that you understand what code you actually are writing). The question is more: how many of the wheel do you want to reinvent yourself? The builtin container managed authentication leaves very little room for finegrained control, but if it is sufficient for you, then just make use of it instead of homebrewing the authentication yourself.
Going through the following related answers should give some good ideas:
Performing user authentication in Java EE / JSF using j_security_check
JSF: How control access and rights in JSF?
How to check if is user logged in?
How to properly use isUserInRole(role)
JSF request scoped bean keeps recreating new Stateful session beans on every request?
I try to make a website with play with a member and a non member area. So i have controllers with member and non-member methods. But i can only make the whole controller secure [#With(Secure.class)].
Is it possibly to make only a few methods secure and access the others without a login?
Thanks
Yes, you can, although it will require some tweaking on the Secure class. If you check #Secure it has a method annotated with #Before. As per documentation you can indicate which methods the #Before is applied to and for which ones it is skipped.
#Before(unless="login")
So it would be a matter of not running #Before on the public methods. Be aware it may not work properly using #With and you may need to create your own #Before in the controller that manages the security (calling the proper methods in secure).
But it would be simpler to just have 2 controllers, one for secure users and one for public methods.
You can use the deadbolt module which is quite powerful: http://www.playframework.org/modules/deadbolt
Yes, you can to this. Remove #With annotation and use this method of Secure controller when you want restrict access to connected user :
Secure.checkAccess();
With this method, you can even use #Check annotation. Example :
#Check("member")
public static void restrictedAction() {
Secure.checkAccess();
...
}
No, there is no simple way to do this. You can check roles, but not connected user, visitor.
You would have to add #Before annotations and that is going to be a little complicated. Simply break up your controller into several controllers. It is by the way, functionnaly better to do it that way, rather than mix up public/private methods.