We have used cloud SDK(odata-generator-maven-plugin) and generated the VDM out of our EDMX(defined in xml) file. Now, want to refer some of the fields from VDM as a constant in our POJO class instead of re-defining as a constant in our class . I don’t find EDMX field/odataName declared as a variable with public specifier and the constant as well in VDM generated classes.
In the below example,
For example :
VDM snippet - ItemCDSViewForLineItem.java
#ODataField(odataName = "DraftUUID")
private UUID key_2;
public final static ItemCDSViewForLineItemField<UUID> KEY_2 = new ItemCDSViewForLineItemField <UUID>("DraftUUID");
Edmx snippet:
`<Property Name="DraftUUID" Type="Edm.Guid" sap:label="Key"/>`
Is there any way by which I can access or refer “DraftUUID” as a constant field in our own POJO class and reuse it ? Could you please suggest ?
Thanks
Surendra
You need to add Lombok as a dependency to your project to see the public Getters and Setters for these fields. More information can be obtained from the documentation.
To also see them in your IDE you probably need to have a plugin installed as described here.
The method EntityField#getFieldName should give you what you are looking for:
ItemCDSViewForLineItem.KEY_2.getFieldName() // returns "DraftUUID"
Related
I was using jooq3.9.2 when it was found that the code generator was just a layer of pojo's getters method that did not generate setters? I needed to use
Setters and the default constructor, and the generated package name I do not need to have a table, hope that is the same, com.tseng.dao not com.tseng.jooq.table.daos in the code generator how to achieve?
I have autowired a class as #Autowired(required=true) private CookieDao ewp;
I am trying to use the ewp to call a function ewp.getCookieEntry(id, name );
How do I access the contents of ewp. Since it is a object I get classname#hashcode but after .toString() , I just get the classname.
If ewp is autowired, then is it the same as CookieDao ewp = new CookieDao();? If not, then what is it called and how can I extract it's values?
I believe that you need to annotate your CookieDao with #Repository to the autowired work just fine, for more information have a looks into this answer : Understanding Spring #Autowired usage
I have ValidationMessages_en_US.properties as below
requiredFirstName=First name is required
requiredLastName=Last name is required
requiredEmailAddress=Email Address is required
...
...
What I would like to do is parameterize the field name in this. So something like this
requiredField={field} is required
So that there will be only one message and I can pass in the field name. I am using this in bean validations in the jsf environment.
This is where I want to use the values:
public class SomeBean implements Serializable
{
#NotNull(message="{requiredFirstName}" )
private String firstName;
......
.....
Is there a way to do this?
Thanks
There is no way to achieve this with the current Bean Validation specification or reference implementation (Hibernate Validator). You can interpolate the validated value and the constraint parameters and with Validator 5.1 you will also be able to add custom variables via HibernateConstraintValidatorContext (see also https://hibernate.atlassian.net/browse/HV-701). However, that does not help you yet to identify your fields and set the right 'field' value.
I am using the very excellent servicestack libaries and trying to generate a ASP.NET web-service reference (old style not WCF) from within VS2010 across my servicestack WSDL - Soap11. To nicely wrap the service WSDL.
The DTO's are in a seperate assembly/namespace (My.WS.DTO) from the AppHost/services and are following the request/response naming convention.. when I try to generate the reference through visual studio I get the following error in VS.
Custom tool error: Unable to import WebService/Schema. Unable to import binding 'BasicHttpBinding_ISyncReply' from namespace 'http://schemas.servicestack.net/types'. Unable to import operation 'GetMyDetails'. The element 'http://schemas.servicestack.net/types:GetMyDetails' is missing.
NOTE: GetMyDetails is just the first service that appears in the list - so I dont believe this is the problem.
I have tried adding the assembly namespace in the AppHost file using
EndpointHostConfig.Instance.WsdlServiceNamespace = "My.WS.DTO"; and this just causes the same generation error (as above) but with 'My.WS.DTO' instead of 'http://schemas.servicestack.net/types'.
I assume it is perhaps some sort of referencing problem but any guidance as to what I might be doing wrong would be great.
cheers
I don't know if this is still an issue for you but I had a similar problem and found that I had not decorated one of my DTOs with [DataContract] and [DataMember] attributes, as described on the SOAP Support wiki page. Once you have added these to your DTO it will be declared in the type section of the WSDL.
Have a look at using [DataContract (Namespace = "YOUR NAMESPACE")] on top of your DTO's. This is how my objects are referenced.
[DataContract(Namespace = "My.WS.DTO")]
public class Account{
}
I also use this in my service model. [System.ServiceModel.ServiceContract()] and [System.ServiceModel.OperationContract()]
[System.ServiceModel.ServiceContract()]
public class SendGetAccountResponseService : IService<SendGetAccountNotification>
{
#region IService implementation
[System.ServiceModel.OperationContract()]
public object Execute (SendGetAccountNotification request)
{
Console.WriteLine ("Reached");
return null;
}
#endregion
}
Hope this helps / solves your problem.
I know this is an old question, but I had to add SOAP support for a 3rd party that refused to support REST very recently to my ServiceStack implementation so it could still be relevant to other people still having this issue.
I had the same issue you were having:
Unable to import binding 'BasicHttpBinding_ISyncReply'...
And like mickfold previously answered I needed to add [DataContract] and [DataMember] to my class definitions and their properties.
But I also had to add the following to my AssemblyInfo.cs file before the error went away for me:
[assembly: ContractNamespace("http://schemas.servicestack.net/types", ClrNamespace = "My Type Namespace")]
I assume that you will need one of these lines for every single namespace where you have a type declared, which based upon the original question above would be My.WS.DTO.
I have a custom type converter that converts UTC DateTime properties to a company's local time (talked about here: Globally apply value resolver with AutoMapper).
I'd now like to only have this converter do its thing if the property on the view model is tagged with a custom DisplayInLocalTime attribute.
Inside the type converter, if I implement the raw ITypeConvert<TSource, TDestination> interface, I can check if the destination view model property being converted has the attribute:
public class LocalizedDateTimeConverter : ITypeConverter<DateTime, DateTime>
{
public DateTime Convert(ResolutionContext context)
{
var shouldConvert = context.Parent.DestinationType
.GetProperty(context.MemberName)
.GetCustomAttributes(false)[0].GetType() == typeof(DisplayInLocalTimeAttribute);
if (shouldConvert) {
// rest of the conversion logic...
}
}
}
So this code works just fine (obviously there's more error checking and variables in there for readability).
My questions:
Is this the correct way to go about this? I haven't found anything Googling around or spelunking through the AutoMapper code base.
How would I unit test this? I can set the parent destination type on the ResolutionContext being passed in with a bit of funkiness, but can't set the member name as all implementors of IMemberAccessor are internal to AutoMapper. This, and the fact that it's super ugly to setup, makes me this isn't really supported or I'm going about it all wrong.
I'm using the latest TeamCity build of AutoMapper, BTW.
Don't unit test this, use an integration test. Just write a mapping test that actually calls AutoMapper, verifying that whatever use case this type converter is there to support works from the outside.
As a general rule, unit tests on extension points of someone else's API don't have as much value to me. Instead, I try to go through the front door and make sure that I've configured the extension point correctly as well.