I am using JAXB javax.xml.bind.Marshaller to marshal XML and also doing XSD validation as a part of it.
My object to be marshal is of complex type like below
I have complex class like below
class A{
private B b;
private C c;
}
where B and C are other classes.
In case of XSD validation failure, I am getting proper error message in configured javax.xml.bind.ValidationEventHandler.
but the problem is, I am getting locator.object only either B or C where XSD validation fails.
[severity=FATAL_ERROR,message=cvc-maxLength-valid: Value 'test' with length = '4' is not facet-valid with respect to maxLength '1' for type '#AnonType_xxxxx'.,locator=[url=null,line=-1,column=-1,node=null,object=com.....C#1f4304be,field=null]]
Here, Is there any way that along with above message I can get always a full class object i.e. object=com.....A#1f4304be so that I can cast it and use for my futher business processing.
The challenge is Class B is the only class which contains unique identifier of users and hence whenever there is a failure for class C only, I am not able to find for which user, this failed as Class C does not have any unique information about user.
Seeking for advice and solution!
Related
as my post describes it, I'd like to create an UTIL class with a never_both function.
class
UTIL
create
default_create
feature -- could be in class BOOLEAN
double_implies, reversible_implies, never_both (a, b: BOOLEAN): BOOLEAN
-- Into boolean class with never_with
do
if a and b then
Result := False
else
Result := True
end
end
end
When I use it
invariant
never_both: {UTIL}.never_both (attached last_error, attached last_success_message)
the compiler complains about a VUNO error
never_both used in the non-object call is not a class feature.
I saw 2 notations about objects creating
- {UTIL}.never_both (a, b)
- ({UTIL}).never_both (a, b)
Whats the difference between them?
How to create an application wide (could be even world wide once if you want!) object for the use of this UTIL if possible in Eiffel?!
I know this is a TUPLE of questions so I put them in Bold
If you want to use a feature without creating the corresponding object, it should be marked as a class feature. This is done in the feature postcondition with the same keyword:
foo ...
do
...
ensure
instance_free: class
...
end
After that, the feature can be used in an objectless call {BAR}.foo ....
The notation ({BAR}).qux does not denote an objectless call. It is an object call on the target object of type TYPE [BAR]. The object describes the type BAR.
My model is as follows
abstract concept Address {
o String street
o String zip
o String city
o String country
}
participant Actor identified by userId {
o String userId
o String firstName
o String name
o Address address
}
When I POST a new Actor in composer rest server, I get the following error
"Cannot instantiate Abstract Type Address in namespace
io.mydomain.myapp",
What am I missing out on here ?
Abstract types are not meant to be instantiated so no wonder that it can't be created.
Read: https://hyperledger.github.io/composer/latest/reference/cto_language
Specifically this quote is of interest:
An optional 'abstract' declaration, to indicate that this type cannot
be created. Abstract resources can be used as a basis for other
classes to extend. Extensions of abstract classes do not inherit the
abstract status. For example, the asset Vehicle defined above should
never be created, as there should be more specific asset classes
defined to extend it.
Consider the Concepts subheading of the docs.
TL;DR: Read the documentation.
I am using Nomin for mapping tasks. As taken from the documentation of Nomin it should be able to map fields with the same name by itself in case automapping has been activated. When activating it, it causes an infinite loop exception.
I have the following:
mappingFor a: CoinsOnMarketPlace, b: Coin
// automap() // when deactivated it works fine, when activated infinite loop
a.coin.name = b.name
a.coin.rank = b.rank
a.priceUSD = b.priceUSD // Could be automapped
a.priceBTC = b.priceBTC // Could be automapped
...
Exception:
org.nomin.core.NominException: ./net/hemisoft/ccm/repository/coinmarketcap2coin.groovy: Recursive mapping rule a = b causes infinite loop!
One thing worth adding regarding your use case - this Recursive mapping rule a = b causes infinite loop! exception is thrown because you use groovy classes in your mapping rule. Nomin uses ReflectionIntrospector and what's important:
It performs getting/setting properties using accessor methods which are called through the Java reflection mechanism. ReflectionIntrospector uses supplied NamingPolicy instance to determine accessor methods. JbNamingPolicy is used by default, this implementation cerresponds the JavaBeans convention. Its InstanceCreator named ReflectionInstanceCreator instantiates objects using Class.newInstance().
Source: http://nomin.sourceforge.net/introspectors.html
A simple Groovy class like:
class Entity {
String name
String somethingElse
}
gets compiled to a Java class that implements GroovyObject providing following methods:
public interface GroovyObject {
Object invokeMethod(String var1, Object var2);
Object getProperty(String var1);
void setProperty(String var1, Object var2);
MetaClass getMetaClass();
void setMetaClass(MetaClass var1);
}
In this case ReflectionInstanceCreator combined with automap() resolves following mappings:
a.property = b.property
and
a = b
where a = b mapping comes from MetaClass getMetaClass() getter method I suppose, because there is no mapping like a.metaClass = b.metaClass resolved. a.property = b.property gets resolved because of Object getProperty(String var1) method.
Solution
This problem can be solved by specifying explicitly ExplodingIntrospector for your mapping script that:
It performs getting/setting properties using a class field immediately through through the Java reflection mechanism and may be useful in case when domain object don't provide accessors for their properties. Supplied instance creator is ReflectionInstanceCreator.
Source: http://nomin.sourceforge.net/introspectors.html
All you have to do is to add
introspector exploding
right below mappingFor a: ..., b: ... header. For example:
import mypackage.Entity
import mypackage.EntityDto
mappingFor a: Entity, b: EntityDto
introspector exploding
automap()
a.test2 = b.test1
Tested with two Groovy classes, worked like a charm. Hope it helps.
public class ABC
{
}
public class DEF : ABC
{
}
public class Class1
{
ABC abc = new DEF(); //No error
DEF def = new ABC(); //Compile time error
}
Can anyone explain to me this scenario.
and under what circumstances we might use it.
Its because as per the OOD rule you can assign child to parent but you cannot assign parent to child.
//this possible as you re assigning child to parent
ABC abc = new DEF(); //No error
//this is illegal as you are trying to assign child to parent directly
DEF def = new ABC(); //Compile time error
Reconsider your design again or if you want to convert parent object to child than you need method for that conversion directly its not possible to do it as per OOD rules.
Consider real time example relation of Customer and RetailCustomer or Corporatecustomer of bank. Where you can easily say RetailCustomer or CorporateCustomer is Customer, but you cannot say Customer is RetailCustomer or CorporateCustomer because customer can be of any type.
Same goes for relation between Parent Shape Class and Child Rectangle,Circle etc. class.
This is called as Ploymorphism .
As explained in MSDN
At run time, objects of a derived class may be treated as objects of a
base class in places such as method parameters and collections or
arrays. When this occurs, the object's declared type is no longer
identical to its run-time type.
Base classes may define and implement virtual methods, and derived
classes can override them, which means they provide their own
definition and implementation. At run-time, when client code calls the
method, the CLR looks up the run-time type of the object, and invokes
that override of the virtual method. Thus in your source code you can
call a method on a base class, and cause a derived class's version of
the method to be executed.
The answer of for this question is best explained here MSDN Polymorphism
Let's say ABC is Person, while DEF is Student (which is a subclass of Person). You can always treat a Student as a Person, so the assignment to abc (of type Person) of a Student is correct, but you cannot treat a generic Person as Student, so the assignment to def is wrong (for instance, you cannot get the student number of a person which is not a student)
In Groovy you can do surprising type conversions using either the as operator or the asType method. Examples include
Short s = new Integer(6) as Short
List collection = new HashSet().asType(List)
I'm surprised that I can convert from an Integer to a Short and from a Set to a List, because there is no "is a" relationship between these types, although they do share a common ancestor.
For example, the following code is equivalent to the Integer/Short example in terms of the
relationship between the types involved in the conversion
class Parent {}
class Child1 extends Parent {}
class Child2 extends Parent {}
def c = new Child1() as Child2
But of course this example fails. What exactly are the type conversion rules behind the as operator and the asType method?
I believe the default asType behaviour can be found in: org.codehaus.groovy.runtime.DefaultGroovyMethods.java
org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.java.
Starting from DefaultGroovyMethods it is quite easy to follow the behavior of asType for a specific object type and requested type combination.
According to what Ruben has already pointed out the end result of:
Set collection = new HashSet().asType(List)
is
Set collection = new ArrayList( new HashSet() )
The asType method recognizes you are wanting a List and being the fact HashSet is a Collection, it just uses ArrayList's constructor which takes a Collection.
As for the numbers one, it converts the Integer into a Number, then calls the shortValue method.
I didn't realize there was so much logic in converting references/values like this, my sincere gratitude to Ruben for pointing out the source, I'll be making quite a few blog posts over this topic.