I created some lightweight cipher in Java Card language and now I want to integrate them into the Java Card API.I noticed the javacardx.crypto.Cipher as well as javacard.security.Key classes. But it seems to me that if I extends the Cipher class and implement all that methods I will still need a way to add my cipher constants into the internal framework for fully integrated the ciphers.Is there a good way to do this ?
No, there is no way to register new ciphers. But note that you normally generate object instances during installation time. So it shouldn't matter all that much if you create an object that extends Cipher and instantiate that instead.
So in general you should create your own XCipher class with your own getInstance methods and constants.
Algorithms are represented by byte constants in Java Card. If they would have a registry there is a chance of collisions. That's why the Java Card forum generally decides if new algorithms should be added.
Related
In my project, I used QHttpResponseHeader in Qt4.8.6, but it became obsolete and it is not
available anymore in Qt5. What is its equivalent class in Qt5?
There is an equivalent already available in Qt4.8 : look at the QNetworkReply class, particularly the header() and rawHeader() functions. It should be what you are looking for.
A bit of explanation : QNetworkAccessManager is the class which allows you to send and receive requests. It is much more flexible and not limited to a single protocol, in contrast to QHttp/QFtp. Before, you had to decide on the application level which protocol to use, and now you only pass an URL to the QNetworkAccessManager, it will manage the rest.
I will try explaining my confusion through the application I am currently developing.
My application (based on Qt5.1 + Qt Quick Controls) interacts with Facebook API to manage a Facebook Page. I am trying to keep the QML code (for UI) as separate as possible from the C++ core.
Now, an OAuth2 implementation is required to be able to interact with Facebook API. For that, I have a C++ OAuth2 class, the constructor of which has the following signature:
OAuth2::OAuth2(QString appId, QString redirectUrl, QStringList permissions);
Now, as the OAuth process requires a browser, I have also implemented an OAuthBrowser.qml, which uses OAuth2 to complete an authorization.
I have the following options to expose OAuth2 class to OAuth2Browser:
Instantiate OAuth2 and use setContextProperty() to expose the instance to OAuth2Browser. However, this means my C++ code has to deal with the UI code. The more baffling issue is that OAuth2Browser is a secondary window. When a user clicks on a "Authorize" window on the MainWindow, then an
AppController C++ object (connected to MainWindow) will launch the OAuth2Browser window. Thus, the instantiation code of OAuth2Browser would go deep down inside a AppController method. It would have been good if only main.cpp had to deal with the window creation.
Use qmlRegisterType(). In this case, I can't pass parameters to the constructor. So, I will have to implement an init() method that would initialize an OAuth2 object. Then, I would call this init() method in OAuth2Browser's Component.onCompleted() method.However, in this approach, I will have to expose QSettings to the UI code - QML window, so that the required parameters to init() method can be retrieved. I have huge skepticism on whether directly exposing application settings to QML UI is a good idea.
Implicitly use QSettings within the OAuth2 constructor. This way, I won't have to pass any parameters, and I would be able to use qmlRegisterType(). However, this means I am doing some magic stuff "behind the curtains". Instead of explicitly passing QSettings instance, I am using it wherever the hell I want to, thus hiding the initialization detail from public API.
An alternative based on the 3rd option was advised on IRC - use an initFromSettings() type of method to initialize an instance if no parameter is passed to the constructor. That way, the initialization is not hidden, and initFromSettings() can confidently use QSettings within itself. Now, I can happily use qmlRegisterType() to instantiate OAuth2 in QML.
So, what is the better approach?
Also,
Is exposing QSettings directly to QML UI a good idea?
I personally prefer qmlRegisterType() to setContextProperty() - that way, the lifetime of a registered class's instance is maintained solely by QML. However, the former is less likely to be used due to the lack of support of parameterized constructors, unless some form of init() is used
explicitly for initialization. Is that a good design?
I apologise in advance for an excruciatingly long post. But I thought it best to ask here.
It's difficult to fully follow your post since it's so long and information dense. Here are my suggestions for what they might be worth.
You want to know what is a good design but you don't specify your goals. You can't really rate something for how well it achieves goals unless you can enumerate the goals.
You're dealing with facebook's api. My crystal ball says change is something you will need to deal with. Therefore putting all the tools into qml may make you better able to respond to change. You can respond to change by rewriting javascript in a qml file instead of a recompile (hopefully). Use properties and the signal/slot design and it should be flexible enough to get the job done. Performance doesn't seem to be an issue.
I would create a settings object that exposes the stuff you want to store. Perhaps using the model/view architecture Qt provides already. The underlying storage, xml file, database, QSettings registry isn't important. You can offer a grid/list to allow users to update their settings if necessary.
Put together oauth and browser tools as objects that will let you script the behavior of the app in qml.
These tools to expose c++ objects might be something excellent to share with the community as well.
Good luck!
I have a solution with several projects (MyApp.Data, MyApp.BLL, MyApp.Web). I register types in Global.asax file in MyApp.Web (main web application):
builder.RegisterType<SomeService1>().As<ISomeService1>().InstancePerHttpRequest();
builder.RegisterType<SomeService2>().As<ISomeService2>().InstancePerHttpRequest();
//...etc
And I wonder whether it's a bad practice to register types and their scope using attributes in the other assemblies (for example, in MyApp.BLL). See below:
[Dependency(typeof(ISomeService1), ComponentLifeStyle.Transient)]
public class SomeService1 : ISomeService1
{
//methods and properties go here
}
Using local attributes or other ways to indicate wiring for a DI Container tightly couples the service to the DI Container, so I don't think that's a good idea.
Additionally, it may constrain your future options. If, for example, you specify the lifestyle scope, you can't reuse the service with a different scope.
In general, you should compose the application in a Composition Root (global.asax), which gives you a single location with a clearly defined responsibility where all classes are composed.
That would be much more manageable and maintainable that spreading the configuration data all over your classes.
As your question implies, it makes some sense to delegate responsibility for registration to the assembly that knows what needs to be registered. For example, if you
use the SolrNet library, it provides a method that performs component registration, to encapsulate the knowledge of what needs to be registered and to spare the library's consumer from having to learn all about the library before getting started.
However, there is a potential issue with this approach. Would your registration requirements change if you used the dependent assemblies in other applications? For example, would it make sense to register something as ComponentLifeStyle.HttpRequestScoped and then use it in a non-Web application? By delegating registration to the dependency, you are coupling the dependency to its consumer's registration requirements (and to its choice of IoC container).
Autofac (I can't speak for other IoC containers) provides a way round this. It enables you to override registrations so that the most recently registered component is used when a service is resolved. This means that you can call a library's registration method and then register your own services to override the defaults.
There is another problem with your proposed attribute-based registration - it doesn't enable you to specify a lambda expression as a component creator. How would you implement a registration like this with attributes?
builder.Register(c => new A(c.Resolve<B>()));
It might be preferable to define an IRegistrar interface, and then use reflection to search all loaded assemblies for implementations and invoke them. Perhaps something like this:
public interface IRegistrar
{
void RegisterComponents();
}
Preferablly with a simple example.
The spec can be found at: http://msdn.microsoft.com/en-us/library/ms972319.aspx
From http://en.wikipedia.org/wiki/Provider_model
The .NET extensible provider model allows a "component" to have multiple implementations using an abstract factory pattern approach. Providers are a subclass of the ProviderBase class and typically instantiated using a factory method.
An example would be membership providers. At runtime it works out which provider to use based on configuration settings. The provider must adhere to a specification (defined usually by an interface). It creates an instance of the type specified that can fulfill the requirements of the specification, and then calls methods on it to do the work.
This lets you augment and enhance default functionality to provide your own implementation (ie: custom authentication logic) using a standard interface.
Very similar to abstract factory and builder patterns.
I have an the following scenario:
// several classes that implement different interfaces
class A implements X,Y {}
class B implements Y,Z {}
class C implements X,Z {}
// other classes that contain collections of one of the interfaces(different objects)
class G {
Collection<X> mayContainAC;
}
class H {
Collection<Y> mayContainAB;
}
class I {
Collection<Z> mayContainBC;
}
How would I go about persisting this using JPA?
From what I can see JPA doesn't support Collections of interfaces. Is the correct?
JDO does support it but I am having difficulties getting JDO to place nicely with my Wicket app.
Thanks, Tom
How would I go about persisting this using JPA?
Not supported.
From what I can see JPA doesn't support Collections of interfaces. Is the correct?
If the interface has a single persistent implementer, then you can define it using the targetEntity.
If the interface has multiple implementers, it's not supported by standard JPA.
JDO does support it
Yes JDO does support persistent interfaces and we've been using them since 2007 in all of our designs because, you know, using interfaces in Java programming is like object oriented modeling 1.0.1. If your ORM doesn't support them then your so called 'transparent persistence' solution is actually not very transparent.
This and some other short comings have meant we have steered clear of the most popular JPA implementation and ended up using an ORM something slightly less popular but much more powerful and highly productive when it comes to object oriented modeling. We use DataNucleus/JDO where persistent interfaces work perfectly. I can't imagine building OO models without this support.
I'm not sure what the inherent architectural limitation is with the most popular JPA implementation that it can't support persistent interfaces.
As well as implementing the JDO standard DataNucleus also implements the JPA standard. There is a chance that DataNucleus/JPA does support persistent interfaces but I've only ever used DataNucleus with JDO so I don't know for sure.
but I am having difficulties getting JDO to place nicely with my Wicket app.
We have a massive (400+ persistent classes) web application/cloud platform deployed using JDO with the (most excellent) Wicket java UI framework and have never had a problem. We have created a couple of JDO specific IModel implementations that work with Wicket's model binding architecture. Let us know if you want to use these and we can open source them.