I'm struggling a bit with some of the base concepts of U2 Toolkit (and I've been quite successful with the previous version!).
First, I had to add using U2.Data.Client.UO; in order to reference UniSession or UniFile. This may just be general ignorance, but doesn't 'using U2.Data.Client' imply that I also want the .UO stuff under it?!?
Second - what (conceptually) are the differences between connecting via U2Connection's Open(), or UniSession's OpenSession()? Do each of them provide a different context in which to work?
Finally - while the examples provided in the doc and in Rajan's various articles are helpful, I'd like something a little more practical: how about a simple "here's how you read and write specific records in a Unidata file"?
Thanks!
Please see answer for the first and second questions
Regarding Namespace
If you want to develop application using ADO.NET ( SQL Access, UCI SERVER), you need one namespace (U2.Data.Client )
If you want to develop application using UO.NET ( Native Access, UO SERVER), you need two namespaces (U2.Data.Client and U2.Data.Client.UO)
U2.Data.Client namespace generally have Microsoft ADO.NET Specification Classes.
U2.Data.Client.UO namespace generally have UniObjects Native Specification Classes. As you have used in the past UODOTNET.DLL, you can feel all the Classes are there.
Regarding U2Connection/UniSession
This is by Design.
U2Connection.Open() calls UniSession.Open() when you use Accessmode=’Native’ in Connection String. You can verify from the LOG/TRACE File. In this case, basically, U2Connection and U2Session are same. U2Connection Class just passes connection string to UniSession Class and then UniSession Class uses this connection string and calls Open(). This is an improvement from the old way where you have used Static Class UniObjects(…) and there was no concept of standard connection string. Basically we replace Static Class UniObjects(…) to U2Connection Class and provided connection string capabilities.
U2Connection.Open() calls UCINET.Open() when you use Accessmode=’SQL’ in Connection String. You can verify from the LOG/TRACE File.
Is this clear()?
Related
is there an easy way to view the consumed states in the terminal with the CordaRPCOps interface? It seems that vaultQuery returns unconsumed states by default and I can't figure out how to use vaultQueryBy or anything with the criteria.
I know that there should be consumed states because I can see them with H2
Hi you could always write a short API to expose the states:
there is a sample for /asset in corda existing samples:
here is a code snippet api for your scenario:
#GET
#Path("asset")
#Produces(MediaType.APPLICATION_JSON)
fun getAssets(): List<StateAndRef<ContractState>> {
val consumedCriteria = QueryCriteria.VaultQueryCriteria(Vault.StateStatus.CONSUMED)
return services.vaultQueryBy<ContractState>(consumedCriteria).states
}
As Ricky says, you'll have to provide an API or write a client to speak to your CorDapp via RPC (e.g. https://github.com/corda/cordapp-example/blob/release-V1/kotlin-source/src/main/kotlin/com/example/client/ExampleClientRPC.kt).
In theory, run vaultQueryByCriteria contractStateType: com.example.state.IOUState, criteria: { Vault.StateStatus.CONSUMED } could work. However, in vaultQueryByCriteria, the criteria parameter is of type QueryCriteria, which is an abstract class. There is no way currently in the shell to specify which concrete subclass of QueryCriteria you wish to use.
I have raised an issue here: https://github.com/corda/corda/issues/2351.
In our framework we have an interface with this method in the public API:
JaxbConfiguration newJaxbConfiguration(Options xjcOpts);
In the implementation, we do something like this:
import com.sun.tools.xjc.ModelLoader;
import com.sun.tools.xjc.Options;
import com.sun.tools.xjc.model.Model;
...
public JaxbConfiguration newJaxbConfiguration(Options xjcOpts) {
Model model = ModelLoader.load(xjcOpts, ...);
...
}
However, both OSGi and Java 9's jigsaw don't like that we use com.sun.tools.xjc.Options, not in our implementation and especially not in our public API interface.
How can we get rid of it?
The JDeps website lists some of the JDK internal APIs and the recommended way to replace their usage. However, the use of ModelLoader.load() is not mentioned. My guess is that this use case has not come up enough to get the attention of the JDeps team.
My recommendation would be to refactor this method so that
you pass in the data you're using to construct the Options argument, instead of passing in the Options argument
use that data to construct your JaxbConfiguration object instead of converting from the internal Model.
You don't mention what JaxbConfiguration is or what library it's from so it's hard for me to say exactly how to construct it. Anyway, this answer is about how to remove the use of the internal API. How to construct a JaxbConfiguration is probably a different question.
I've been banging my head on this problem for a week, and now I'm starting to understand what's going on, but no idea why, or how to fix it.
Let me describe what I'm doing. I have an assortment of various objects in Java, and I have a native library. Java objects inform the library of their existence by calling NativeLibrary.AddObject(this). The native library has a container of jobjects where I store global references to the Java objects, obtained with env->NewGlobalRef(object). The native library uses these stored references to access the Java objects, and it does work fine.
And here's the crucial part that does NOT work. Obviously, I want to be able to delete Java objects, not only add them. So, when a Java object is no longer needed, it calls NativeLibrary.RemoveObject(this). The native library implements it by iterating the list of stored objects (which are all global references, as you may remember) and finding a match with env->IsSameObject(passedObject, storedObjectGlobalReference).
And here's where the problem is: it doesn't work as expected, the Java objects are not matched to their global references properly. When I started digging and logging all the calls with all the parameters, I noticed a weird thing: the jobject parameter of the native call (which is this of Java objects) has the same value for different objects! Moreover, this value changes between the ``NativeLibrary.AddObject(this)andNativeLibrary.RemoveObject(this)` calls for the same object!
So, what's going on, and how can I store, keep track of and delete the references to Java objects in native code? To reiterate: everything works fine as long as I only create and store global refs; the correct objects receive notifications via these refs, no problem. But as soon as I try deleting these references via env->DeleteGlobalRef, I find out that in the NativeLibrary.RemoveObject(this) implementation fails to match the stored reference to the passed jobject.
I was with the same problem. The root cause was that the added item NativeLibrary.AddObject(this) not was the same object when I called NativeLibrary.RemoveObject(this). I was using junit and this was causing the problem, because junit create multiples objects to run each test. I found the problem using System.out.println with the object in Java side. Before add function System.out.println("add object: " + sameObject); and before remove function System.out.println("remove object: " + sameObject);. Sorry for poor english, I hope this help someone.
Currently I am learning Domain Driven Design. Based on my understanding I have created a sample application which does some operations on country.
I have crated a class library named "MyTest.Country" which contains all commands-
--MyTest.Country (ProjectName)
-- Commands (Folder)
--CreateCountry (: ICommand)
--DeleteCountry (: ICommand)
I have another class library named "MyTest.CountryClient" which interacts with the database using EF.
--MyTest.CountryClient (Project)
--CountryClass (ClassFile)
--CreateCountry (Method)
--DeleteCountry (Method)
--GetAllCountryList (Method)
Yet another classlibrary for services named "MyTest.CountryServices" which contains the handler.
--MyTest.CountryServices (Project)
--CountryHandler : IHandleMessages<CreateCountry>
: IHandleMessages<DeleteCountry>
I have a web API which sends command to "MyTest.CountryServices" using NServiceBus for creating or Deleting the country. The message is handled by CountryHandler and then it invokes the respective method from "MyTestCountryClient".
I know that Country is an entity and cannot be defined as a domain. However, I am only trying to implement the DDD.
My question here is -
Am I following the proper DDD principles here?
If I want to get all country list, should I directly call MyTest.CountryClient? or I need to call services first even for the fetching operation?
In your case the CountryClient seems to be your Repository. If so, yes you can call it directly.
I suggest you start into DDD with the building blocks. And do not dig into Messages and Commands in the beggining.
I am very new to concept of IOC and I understand the fact that they help us resolve different classes in different contexts. Your calling class will just interact with Interface and Interface with decide which implementation to give you and it takes care of newing up the object.
Please do correct me if I am understanding is wrong because my question is based on that:
Now, I see this pattern very often in these projects:
private readonly IEmailService emailService;
private readonly ITemplateRenderer templateRenderer;
private readonly IHtmlToTextTransformer htmlToTextTransformer;
public TemplateEmailService(IEmailService emailService,
ITemplateRenderer templateRenderer,
IHtmlToTextTransformer htmlToTextTransformer)
{
this.emailService = emailService;
this.htmlToTextTransformer = htmlToTextTransformer;
this.templateRenderer = templateRenderer;
}
I understand that this helps using all the implementations of these classes without newing them up and also you don't have to decide WHICH implementaion to get, your IOC decides it for you, right?
but when I code like this, I do not even touch any IOC congiguration files. And again I am usin git for 2 days only but from all the tutorials that I have read, I was expecting my self to configure something which says "Resolve IParent to Child" class. But it works without me doing anything like it. Is it because there is only one implementaion of these interfaces? and If I do have more than one implementations then and then only I will have to configure resolved explicitly?
The code sample you have is a case of Constructor Injection.
In a traditional code, you would have a parameterless constructor, and in it you would "new-up" your objects like this:
IEmailService emailService = new EmailService();
So your code is explictly controlling which implementation gets assigned to the interface variable.
In IoC using constructor injection, control is inverted, meaning the container is "driving the bus" and is creating your TemplateEmailService object. When it is about to create it, the container looks at your constructor parameters (IEmailService , ITemplateRenderer , etc.) and feeds those objects to your class for use.
The IoC container can be configured so that interface A gets fulfilled by implementation B (or C) explicitly. Each one has a way to do it. Or it could do it by convention (IFoo fulfilled by Foo), or even attributes in classes, whatever.
So to answer your question-- you can explicitly define which implementations get used to fulfill certain interfaces. Got to read the IoC container docs for how to.
One more thing - "when you code like this", you technically don't have to be using an IoC container. In fact, your class should not have a direct reference to the container - it will maximize the reusability, and also allow easy testing. So you would wire-up interfaces to implementation classes elsewhere.