GithubHelp home page GithubHelp logo

orika's People

Watchers

 avatar

orika's Issues

Add customization of collection mapping.

I map Dto to hibernate entity. Orika recursively rebuild all associated 
collection, therefore every entity which has collection became dirty and 
hibernate updates DB. I need to registrate base smart collection merger. 
Such as:
Collection<BaseDto> dstDtos merge( Collection<BaseDto> srcDtos , 
Collection<BaseDto> dstEntities, Mapper mapper  ){
 //change existing collection instead of rebuild
}
more details see in attach

Original issue reported on code.google.com by [email protected] on 8 Jun 2012 at 9:47

Attachments:

Call a destination setter when the source getter is nil

I have a destination object that already exists with a value, I am using orika 
to copy over properties
from an object where null indicates that the property should have no value (in 
my case, it is an unanswered question, where someone wants to go from previous 
having answered a question to indicating they are
not answering the question).

Original issue reported on code.google.com by [email protected] on 23 Nov 2011 at 5:12

NoSuchElementException mapping empty lists

What steps will reproduce the problem?

MapperFactory mapperFactory = new DefaultMapperFactory.Builder().build();
mapperFactory.registerClassMap(ClassMapBuilder.map(Object.class,Object.class).by
Default().toClassMap());
List<Object> listA = new ArrayList<Object>();
mapperFactory.getMapperFacade().mapAsList(listA, Object.class);

What is the expected output? What do you see instead?
An empty array is expected but a NoSuchElementException is thrown

What version of the product are you using? On what operating system?
Orika 1.1.2 with JDK 1.6

Please provide any additional information below.


Original issue reported on code.google.com by [email protected] on 16 May 2012 at 12:20

Cleanup orika-core pom.xml

There are a couple of dependencies in the orika-core pom.xml that should not be 
there:

1) Test dependencies in compile scope (instead of test scope):
* junit
* easymock
* spring-test

2) Useless dependencies in compile scope
* dozer
* spring
* h2database

3) Dependency on slf4j-simple instead of slf4j-api

This pushes these dependencies onto the project using orika. Please clean up 
your pom. Thanks :)

Original issue reported on code.google.com by lighteater on 30 Jul 2012 at 12:50

exclude fields

I would like to be able to specify fields that need to be excluded from being 
mapped.

Original issue reported on code.google.com by [email protected] on 22 Feb 2012 at 10:57

The mapper create a child's instance instead of a parent's instance.

What steps will reproduce the problem?
1. Make inheritance child from parent.
2. Get a child bean from the MapperFacade.
3. Get a parent bean from the MapperFacade

What is the expected output? What do you see instead?
Parent's instance is expected. I see child's instance instead.

What version of the product are you using? On what operating system?
Orika 1.1.8

Please provide any additional information below.
see attached test

Original issue reported on code.google.com by [email protected] on 20 Jul 2012 at 6:43

Attachments:

NPE in IntrospectorPropertyResolver

There is a possibility of NPE in IntrospectorPropertyResolver in method "public 
NestedProperty getNestedProperty(java.lang.reflect.Type type, String p)" in 
current trunk (but it affects older versions too). In RuntimeException that may 
be thrown in that method a "property.getType()" is used, but property variable 
itself gets initialized only after first iteration. So if the first item in the 
mapping path is not correct, ugly NPE is thrown instead of RuntimeException 
with correct error message.

Original issue reported on code.google.com by [email protected] on 8 Aug 2012 at 3:56

Class-cast exception for mapped objects

What steps will reproduce the problem?
We run a very complex mapped object tree, with several levels of nested objects 
in lists, where each list can contain large amounts (thousands) of objects. 
Dozer handles this without a problem, but of course - very slowly. 
Orika's overhead is negligable to non-existant (we map objects that are about 
2-4 mb of binary data usually under 1 ms). so performance wise it's very good.
anyhow - it seems that from time to time an object from a different path in the 
object tree get's mapped to the wrong list:
i.e.
myObject.myList<FirstType>.nestedList<NestedType>
would get objects from
myObject.otherList<SecondType>

the really strange thing is that nested list would contain mostly NestedType an 
one instance of SecondType

reproduction is consistent when a large enough object tree (say 2-3 levels of 
nesting, thousands of objects in the lists) and enough executions of the mapper.
out of 800 mappings of the root object i consistently get 3-4 class cast 
exceptions while iterating on those lists.

This seems to happen only after the code has been compiled into byte code - 
that's my diagnosis based on the fact that it happens very intermittently, and 
far more frequently on "run" configuration rather than on "debug".
i would say that it was a race-condition but i am running on a single thread so 
 i don't see how that would be possible. but that might be all-together 
unrelated.

What version of the product are you using? On what operating system?
we're using the latest 1.2.0 version, but this goes back as at lest 1.1.5 which 
was the first version we tried. i check every release to see if it was resolved.


Original issue reported on code.google.com by [email protected] on 8 Sep 2012 at 10:26

File handle leak on Linux (Cent OS version 6)

Using the mapper on Linux results in leaked file handles. Once the number of 
open file handles exceeds the OS level limit, the mapper fails to work as the 
JavassistCompilerStrategy considers the type to be mapped in accessible as it 
is impossible to open an InputStream to check for existence.

This presents on Cent OS version 6 with Orika 1.0, the issue is not encountered 
on Windows 7 professional x64.

Based on my investigation, the symptom of the problem is also the cause - the 
assureTypeIsAccessible method in JavassistCompilerStrategy opens an InputStream 
to check for file existence but does not close it. After changing this to 
opening a URL to check for file existence we have not encountered the issue. 
I've attached a patch with this change for review and consideration.

Original issue reported on code.google.com by [email protected] on 20 Mar 2012 at 6:01

Attachments:

Conversion of BigDecimal to java.lang.Double is not working

What steps will reproduce the problem?

1. Class A containing field of type BigDecimal
2. Class B containing field of type java.lang.Double
3. Try to declare and perform conversion for such field

What is the expected output? What do you see instead?

Conversion works find if class B has field of primitive unboxed type "double". 
But it fails if it does have "java.lang.Double" with exception "exception while 
creating object factory for java.lang.Double" - with message "exception while 
creating object factory for java.lang.Double".

What version of the product are you using? On what operating system?

1.1.5 from maven repository.

Original issue reported on code.google.com by [email protected] on 9 Jul 2012 at 12:54

ClassLoader leak via "strategyKey" ThreadLocal

When running an application using Orika (v1.1.7) within container-managed 
threads it seems that Orika causes a ClassLoader leak by attaching a 
ThreadLocal 
(ma.glasnost.orika.impl.mapping.strategy.MappingStrategyKey#strategyKey) to 
container-managed threads, but never removing these.

In addition, MappingStrategyKey#toString() seems to happily throw NPEs when 
Tomcat complains about the ThreadLocal-leak (I guess
getRawSourceType returns null):

-- 8< --
Jul 09, 2012 4:10:57 PM org.apache.catalina.loader.WebappClassLoader 
clearThreadLocalMap
SEVERE: Unable to determine string representation of value of type 
[ma.glasnost.orika.impl.mapping.strategy.MappingStrategyKey]
java.lang.NullPointerException
        at ma.glasnost.orika.impl.mapping.strategy.MappingStrategyKey.toString(MappingStrategyKey.java:129)
        at org.apache.catalina.loader.WebappClassLoader.clearThreadLocalMap(WebappClassLoader.java:2433)
        at org.apache.catalina.loader.WebappClassLoader.clearReferencesThreadLocals(WebappClassLoader.java:2349)
        at org.apache.catalina.loader.WebappClassLoader.clearReferences(WebappClassLoader.java:1921)
        at org.apache.catalina.loader.WebappClassLoader.stop(WebappClassLoader.java:1833)
        at org.apache.catalina.loader.WebappLoader.stop(WebappLoader.java:740)
        at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4920)
        at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:936)
        at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1359)
        at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1330)
        at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:326)
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
        at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1098)
        at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1110)
        at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:468)
        at org.apache.catalina.core.StandardService.stop(StandardService.java:604)
        at org.apache.catalina.core.StandardServer.stop(StandardServer.java:788)
        at org.apache.catalina.startup.Catalina.stop(Catalina.java:662)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:629)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)

Jul 09, 2012 4:10:57 PM org.apache.catalina.loader.WebappClassLoader 
clearThreadLocalMap
SEVERE: The web application [/logging] created a ThreadLocal with key of type 
[ma.glasnost.orika.impl.mapping.strategy.MappingStrategyKey$1] (value 
[ma.glasnost.orika.impl.mapping.strategy.MappingStrategyKey$1@2c62e3ea]) and a 
value of type [ma.glasnost.orika.impl.mapping.strategy.MappingStrategyKey] 
(value [Unknown]) but failed to remove it when the web application was stopped. 
This is very likely to create a memory leak.
-- 8< --

Original issue reported on code.google.com by [email protected] on 10 Jul 2012 at 5:36

Exclude FieldMap in one direction

I'm trying to suppress a mapping of a field (no primitive type) in only one 
direction (MappingDirection.A_TO_B should be excluded)

My source code for this is:

ClassMapBuilder.map( A.class, B.class ).fieldMap( "anyField" 
).aToB().exclude().add();

The result is no mapping in both directions.

Another try is to explicitly add the mapping only for direction B_TO_A.

ClassMapBuilder.map( A.class, B.class ).fieldMap( "anyField" ).bToA().add();

This is working.


I'm using Orika 1.1.7

Best regards
Tom



Original issue reported on code.google.com by [email protected] on 2 Jul 2012 at 3:57

Inheritance mapping with customized mapper - custom mapper not fired for parent class

What steps will reproduce the problem?
1. Run the attached JUnit test

What is the expected output? What do you see instead?
The object should map flawlessly, yet the customized mapper for parent class is 
not fired.

What version of the product are you using? On what operating system?
orika-core 1.0, JDK 1.5

Please provide any additional information below.


Original issue reported on code.google.com by lighteater on 8 Mar 2012 at 11:01

Attachments:

Calendar as destination throwing exception

What steps will reproduce the problem?
1. if the destination object is Calendar(java.util.Calendar)
example:

Source:
class Product {

 private Date tempCal;

}

Destination:

class ProductDTO {

 private Calendar tempCal;

}


What is the expected output? What do you see instead?
 It should map without any error, Instead it throws an exception

"No concrete class mapping defined for source class"

What version of the product are you using? On what operating system?
1.1.1 windows 7

Please provide any additional information below.

1) It should not throw any exception for Calendar, XMLGregorianCalendar 


Original issue reported on code.google.com by [email protected] on 8 May 2012 at 3:33

Convenient way of declaring types as immutable

In the case of mapping immutable types, it should be safe to return the source.

Therefore, it'd be nice to have a shorthand way of doing this.

Initially, I tried the following:

public class ImmutableConverter<S> extends CustomConverter<S> {
    @Override
    public D convert(S source, Type<? extends D> destinationType) {
        return (D) source;
    }
}


However, this fails because the constructor for CustomConverter requires two 
generic parameters.

Therefore, I have to create subclasses for each immutable type.

Ie., I'd like:

factory.getConverterFactory().registerConverter(new 
ImmutableConverter<DateTime>());

Instead, I currently have the following:

factory.getConverterFactory().registerConverter(new DateTimeCopier());
class DateTimeCopier extends ImmutableConverter<DateTime,DateTime> {};

Not terrible by any means, but could be a little more elegant.

Thanks

Original issue reported on code.google.com by [email protected] on 22 Aug 2012 at 10:51

Exclusions are ignored when combined with used mappers

What steps will reproduce the problem?
Exclude fields from a mapping; define a child mapping that uses the 
already-defined mapping with exclusion of some fields.

What is the expected output? What do you see instead?
Expected to see those fields also excluded in the child mapping; instead, the 
child mapping does not honor the exclusion.

Original issue reported on code.google.com by [email protected] on 11 Sep 2012 at 8:52

Add support for java.util.Map

Currently, Orika has no built-in support for java.util.Map in it's mapping 
methods or auto-generated mappings by configuration.

This should be implemented as part of the 1.2.0 release.

Original issue reported on code.google.com by [email protected] on 9 May 2012 at 11:40

remove Hibernate-core and Eclipse-Core from Orika-core compile-time dependencies

Both of these dependencies are to support optional modules, and should not be 
part of the core if at all possible.

Hibernate-core is only necessary for HibernateUnenhanceStrategy, and the 
dependency can be replaced with reflection -- since Hibernate must be available 
on the class-path anyway to use it.

The Eclipse core dependencies are for supporting EclipseJdtCompilerStrategy 
which is mainly for step-through debugging of generated mapper code; this 
should be broken out so that it's only a transitive dependeny of the 
eclipse-tools module.

Original issue reported on code.google.com by [email protected] on 15 Mar 2012 at 6:02

Consistant Property Mapping Order

What steps will reproduce the problem?
1. Configure an object to map more than one property and log the order it was 
set
2. Run on a different JVM/OS (or in my experience restart the JVM)
3. Possibly see different output, possibly not depending on your luck

What is the expected output? What do you see instead?
Properties mapped in the same order across servers JVMs

What version of the product are you using? On what operating system?
1.2 snapshot on OS X and Windows

Please provide any additional information below.
This stems I believe from the properties being stored as sets which don't have 
an order and can change the order based upon implementation. I think a 
LinkedHashSet might meet the requirements. Also I would find it a nice bonus if 
I can explicitly specify the properties to be mapped first then call 
byDefault() to have add the remaining properties to happen afterwards.

Please let me know if I can provide any additional info

Original issue reported on code.google.com by [email protected] on 17 Aug 2012 at 10:28

DefaultMapper has dependency on org.hibernate.MappingException

There is an import in ma.glasnost.orika.impl.DefaultMapper that references 
"org.hibernate.MappingException"
This dependency causes classloading to fail, since it is not included in the 
transitive dependencies of the orika artifact.
Perhaps this should have been an import of "ma.glasnost.orika.MappingException" 
instead?

This is found in orica-core-1.0-SNAPSHOT


Original issue reported on code.google.com by [email protected] on 13 Oct 2011 at 5:48

Short.TYPE is not defined in ClassUtil

What steps will reproduce the problem?
1. Try to map a class containing a field of Short.
2.
3.

What is the expected output? What do you see instead?
Causes a class instantiation exception.

What version of the product are you using? On what operating system?
newest, Linux

Please provide any additional information below.
Same issue as Byte, which was added in r205.


Original issue reported on code.google.com by [email protected] on 14 Oct 2011 at 3:16

Occasionally the wrong Type is resolved for a class

In multi-threading scenarios, some times the incorrect Type<?> is returned for 
a given class.
this may show up in the logs as Foo is incompatible with Bar, but can only 
occasionally be seen; we had to set the build on continuous fire every 20 
minutes to unearth this, and it only happened maybe one in 10 times.

Most likely a multi-threading issue.

Original issue reported on code.google.com by [email protected] on 12 Jun 2012 at 8:39

XML file mapping

Even though mapping through a programmatic configuration does the job, I find 
my 6 or so Java mapper files are getting quite unreadable. It would be very 
nice if the MapperFactory could read an XML file, similar to what Dozer does.

Original issue reported on code.google.com by [email protected] on 10 Sep 2012 at 9:17

NPE when collection is changed.

What steps will reproduce the problem?
1. Create MapperFactory with HibernateUnenhanceStrategy
2. Load hibernate entity, and map to DTO
3. Add a element to association collection in DTO and map to the entity.
4. Remove same element from association collection in DTO and map to the entity.

What is the expected output? What do you see instead?
Changing of data is expected. I see NullPointerException instead.

What version of the product are you using? On what operating system?
orika 1.1.4 , windows 7, jsdk 7

More details are in attached archive.


Original issue reported on code.google.com by [email protected] on 29 May 2012 at 8:01

Attachments:

Remove compile-scope dependency to slf4j-simple

slf4j-simple is one implementation of slf4j-api.

As a library orika should log to slf4j (the simple logging facade for java), 
which adds a compile-scope dependency to slf4j-api.

However, it should be up to the user which implementation to use (such as, in 
my case, logback).

Original issue reported on code.google.com by [email protected] on 24 Jul 2012 at 7:51

Javassist compile error for primitive type mapping when respective converter is present.

What steps will reproduce the problem?
1. Register mapping between primitive double and BigDecimal
2. Register bidirectional converter between Double and BigDecimal
3. Run application

What is the expected output? What do you see instead?
Mapping facade building fails with message
compile error: invalid types for !=
    at javassist.compiler.CodeGen.badTypes(CodeGen.java:1255) ...

What version of the product are you using? On what operating system?
1.1.0 on Mac OS, Weblogic 12.1.1 Java 6

Please provide any additional information below.
When the convertor is not registered, facade building succeeds. Javassist 
prints the whole failing code where the critical part is retyping double and 
comparing it with null(in my opinion. names obfuscated):

if(((double)((xxx)((yyy)((zzz)source.getRequestBody()).aaa()).bbb()).getAmount()
) != null){
                destination.setAmount((java.math.BigDecimal) mapperFacade.convert(((double)((xxx)((yyy)((zzz)source.getRequestBody()).aaa()).bbb()).getAmount()), usedTypes[4], usedTypes[3], null));

            }

Original issue reported on code.google.com by [email protected] on 26 Apr 2012 at 5:22

lookupConcreteDestinationType should return the most specific type, not the first that is assignable

What steps will reproduce the problem?
1. Have a class A that maps to both B and BSuper where B is a subclass of BSuper
2. call lookupConcreteDestinationType with destination B
3. depending on set iteration order, B or BSuper is returned

What is the expected output? What do you see instead?

I would expect it to return the tightest match, rather than the first that is 
assignable.

What version of the product are you using? On what operating system?

1.2.0 on Ubuntu with Java(TM) SE Runtime Environment (build 1.6.0_26-b03)

Please provide any additional information below.

Attached a failing test, the troublesome code is here

        for (final Type<?> type : destinationSet) {
            if (destinationType.isAssignableFrom(type) && ClassUtil.isConcrete(type)) {
                return (Type<? extends D>) type;
            }
        }

if destinationSet has multiple types that are assignable, it should pick the 
one that is the tightest fit, rather than the first one that matches


Original issue reported on code.google.com by [email protected] on 7 Jun 2012 at 6:59

Attachments:

Mapping for Collection<String> --> String[] is not working

What steps will reproduce the problem?
1. Set up mapping between A and B where A has field "p" of type String[] 
(array) for example and B has the same, but in form or collection - 
Collection<String>
2. Register mapping between A and B.
3. Invoke map from instance of A to B.

What is the expected output? What do you see instead?
Exception: 
Exception in thread "main" ma.glasnost.orika.MappingException: No concrete 
class mapping defined for source class java.lang.String
        at ma.glasnost.orika.impl.MapperFacadeImpl.map(MapperFacadeImpl.java:200)
        at ma.glasnost.orika.impl.MapperFacadeImpl.mapAsCollection(MapperFacadeImpl.java:418)
        at ma.glasnost.orika.impl.MapperFacadeImpl.mapAsList(MapperFacadeImpl.java:290)
        at ma.glasnost.orika.impl.MapperFacadeImpl.mapAsList(MapperFacadeImpl.java:466)
        at ma.glasnost.orika.generated.OrikaBAMapper533000440.mapAtoB(OrikaBAMapper533000440.java)
        at ma.glasnost.orika.impl.MapperFacadeImpl.mapDeclaredProperties(MapperFacadeImpl.java:369)
        at ma.glasnost.orika.impl.MapperFacadeImpl.map(MapperFacadeImpl.java:220)
        at ma.glasnost.orika.impl.MapperFacadeImpl.map(MapperFacadeImpl.java:113)
        at ma.glasnost.orika.impl.MapperFacadeImpl.map(MapperFacadeImpl.java:442)

The mapping works for collections of registered user types, but not for 
primitives.

What version of the product are you using? On what operating system?

1.1.2, Linux x64.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 16 May 2012 at 8:53

Add flag to disable auto generation of mapper classes.

For security / paranoia reasons I would like to scope the mapping to classes 
that I have manually defined mappers for.  Basically the factory should refuse 
to generate a mapper in lookupmapper if one has not been defined already.  I've 
attached a patch built against 1.2.0 that shows the behavior I am trying to 
achieve.

Original issue reported on code.google.com by [email protected] on 31 May 2012 at 2:38

Attachments:

MappingException: cannot determine runtime type of destination collection

What steps will reproduce the problem?
1.Running the attached test case using orika version 1.1.6, then running using 
version 1.1.7

What is the expected output? What do you see instead?
Not to throw "MappingException: cannot determine runtime type of destination 
collection" on classes with generic types.

What version of the product are you using? On what operating system?
orika 1.1.7, Ubuntu 11.10, Sun JDK 7

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 6 Jul 2012 at 2:44

Attachments:

MappingException when enum toString() is overridden

What steps will reproduce the problem?
1.Create a enum and override toString method. 
2.Create a object with the enum field.
2.Map this object to another object with corresponding enum field.

What is the expected output? What do you see instead?
Filled object is  expected. I see MappingException instead.

What version of the product are you using? On what operating system?
Orika 1.2.0. Windows 7 and Ubuntu 12.0.4

Please provide any additional information below.
see attached test and log.

Original issue reported on code.google.com by [email protected] on 11 Sep 2012 at 12:13

Attachments:

StackOverflowError for nested Enum

What steps will reproduce the problem?

TypeFactory.valueOf some nested Enum throw StackOverflowError
due to an evantual bug in handling recursive Generics




Original issue reported on code.google.com by [email protected] on 22 Aug 2012 at 8:56

NPE when mapping null objects

NPE occurs when mapping null objects using the Class-based method signatures, 
due to calls to TypeFactory.valueOf(null) throwing an NPE.

Original issue reported on code.google.com by [email protected] on 15 May 2012 at 4:26

Boolean fields not mapped when using 'is' getter methods instead of 'get'

Steps to reproduce: Run the attached unit test.

From what I gather this is a bug in one of the JDK introspector classes - 
java.beans.PropertyDescriptor.getReadMethod - which in 1.5.0 recognizes 'is' 
getters only for boolean types (forgetting its big brother - Boolean).

It would be nice if Orika included some sort of workaround for this issue. 

Original issue reported on code.google.com by lighteater on 29 Mar 2012 at 1:20

Attachments:

Exception on collection mapping

What steps will reproduce the problem?
1.Create a object with a collection field.
2.Map this object to another object with corresponding collection field.

What is the expected output? What do you see instead?
Filled object is  expected. I see MappingException instead.

What version of the product are you using? On what operating system?
Orika 1.2.0. Windows 7 and Ubuntu 12.0.4

Please provide any additional information below.
see attach test and log.

Original issue reported on code.google.com by [email protected] on 11 Sep 2012 at 11:43

Attachments:

require orika to allow user to register their own immutable class.

What steps will reproduce the problem?
This is not a issue that runs in my code but instead I think we can add some 
enhancement for it in the future. 
Right now we use this kind of logic to tell whether a type is immutable or not
 return IMMUTABLES_TYPES.contains(clazz) || clazz.isEnum();

And the IMMUTABLES_TYPES are pre-defined the immutable classes in JDK in orika 
code. However maybe the orika user will define some their own immutable classes 
and they are the type of bean properties.  

What is the expected output? What do you see instead?

So maybe we need to provide interface to allow user to register their own 
immutable classes so that we can tell the mapping property type is immutable in 
code generation phrase. 

Anyway, i think this is not so urgent. I raise it here to notify other users in 
case some day we run into this trap.


What version of the product are you using? On what operating system?


Please provide any additional information below.


Original issue reported on code.google.com by [email protected] on 29 Aug 2012 at 6:22

MapperFacadeImpl - unenhancer when usage

In the MapperFacadeImpl#convert method unenhancer is always called, but the 
unenhanced class is only used when no converterId was specified. This could be 
easily fixed by moving the call into the 'if' body.

    public <S, D> D convert(S source, Type<S> sourceType, Type<D> destinationType, String converterId) {
        Converter<S, D> converter;
        ConverterFactory converterFactory = mapperFactory.getConverterFactory();
        if (converterId == null) {
        final Type<? extends Object> sourceClass = unenhanceStrategy.unenhanceType(source, sourceType);
            converter = (Converter<S, D>) converterFactory.getConverter(sourceClass, destinationType);
        } else {
            converter = (Converter<S, D>) converterFactory.getConverter(converterId);
        }

        return converter.convert(source, destinationType);
    }

This gives a small performance improvement when using named converters.

Original issue reported on code.google.com by lighteater on 17 Apr 2012 at 12:15

StackOverflowError mapping hibernate4 proxy.

What steps will reproduce the problem?
1. Create MapperFactory with HibernateUnenhanceStrategy
2. Load hibernate entity, and map to DTO
3. If entity is wrapped to proxy and have associations with proxy, then orika 
throw StackOverflowError

What is the expected output? What do you see instead?
DTO is expected. I have infinite recursion instead.

What version of the product are you using? On what operating system?
orika 1.1.2 and 1.1.1, windows 7, jsdk 7

More details are in attached archive.

Original issue reported on code.google.com by [email protected] on 25 May 2012 at 12:27

Attachments:

want to have option to not set target object property when property value in the source object is null

What steps will reproduce the problem?


I am working to replace the dozer bean mapping solution with orika solution for 
conversion performance purpose. I made a bridge to migrate the dozer mapping 
solution to orika with a minor existing dozer mapping configuration changes and 
hide the details for the business layer.  And I am almost there except one 
issue. Our old project was written with EJB and Hibernate. Most of the PO 
entities (persistent objects) contain nested type objects. For example:

public class BasCustomer extends AbstractBO
    @ManyToOne(fetch = FetchType.LAZY)
    private BasCantonInfo area;
   .....
}

public BasCantonInfo{
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO, generator = "BAS_CANTONINFO_SEQ")
    private Long id;
   .....
}

My mapping BasCustomerVO ----> BasCustomer 

            <field>
                <a>area.id</a>  <!-- BasCustomer  -->
                <b>areaId</b>   <!-- BasCustomerVO -->
            </field>
            <field type="one-way" >
                <a>area.name</a>   <!-- BasCustomer  -->
                <b>areaName</b>   <!-- BasCustomerVO -->
            </field>

In my generated class OrikaBasCustomerVoBasCustomerMapper1884032229682941, I 
see that, the code segment for BasCustomerVO.areaId  ---> BasCustomer.area.id 
is as bellow. 

if (((com.best.oasis.genidc.biz.base.model.BasCantonInfo) destination
                .getArea()) == null)
            destination
                    .setArea((com.best.oasis.genidc.biz.base.model.BasCantonInfo) mapperFacade
                            .newObject(source, usedTypes[0], mappingContext));

((com.best.oasis.genidc.biz.base.model.BasCantonInfo) destination
                .getArea()).setId(((java.lang.Long) source.getAreaId()));

So when the BasCustomerVO.areaId and BasCustomerVO.areaName property both null, 
I will get a  BasCustomer.area nested type object, but with all property null. 
To be more specifically, BasCustomer.area.id =null, BasCustomer.area.name =null 
and so on.  Then hibernate will take action to try to save the BasCantonInfo 
instance “area” because it thinks “area” should be a new entity object 
but it will be never successfully saved for it only contains null properties.

So for me, my expectation result of BasCustomer.area in this case is 
BasCustomer.area= null;

And if the generated code be

        if (source.getAreaId() != null) {
            if (((com.best.oasis.genidc.biz.base.model.BasCantonInfo) destination
                    .getArea()) == null)
                destination
                        .setArea((com.best.oasis.genidc.biz.base.model.BasCantonInfo) mapperFacade
                                .newObject(source, usedTypes[0], mappingContext));

            ((com.best.oasis.genidc.biz.base.model.BasCantonInfo) destination
                    .getArea()).setId(((java.lang.Long) source.getAreaId()));
        }

maybe also make sence. I don't know whether this will break the other use 
cases.  Or maybe we can make this behavior configurable for flexibility purpose.

And also for String type conversion, the generated code segment is 


What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.


Original issue reported on code.google.com by [email protected] on 17 Aug 2012 at 12:28

Write releas notes

Please provide release notes for new versions.
Really important to know whether to upgrade or not.

Gret work, btw!

Original issue reported on code.google.com by [email protected] on 7 Jun 2012 at 11:49

support public field without getter/setter

I hope to skip the getter/setter in DTO. 

Does orika support it?


Play2.0 doesn't have getter/setter in entity object now. i think it will be 
mainstream later.

Dozer can't suppor it by default, and not refactoring friendly. 

ModelMapper donesn't support Bi-directional mapping. 

So i hope orika will be the best solution.



Original issue reported on code.google.com by [email protected] on 7 Mar 2012 at 6:23

Allow converters for Lists (or other collections).

It would be nice to be able to do:

  public static class Product {
    private String name;
  }

  public static class Order {
    private List<Product> products;
  }

  public static class OrderDto {
    private List<String> productNames;
  }

.registerConverter("productToName", new CustomConverter<Product, String>() {

          @Override
          public String convert(Product source, Type<? extends String> destinationType) {
            return source.getName();
          }
        });

.registerClassMap(ClassMapBuilder.map(Order.class, 
OrderDto.class).fieldMap("products", 
"productNames").converter("productToName").add().toClassMap());

Currently this fails with a class cast exception because orika tries to convert 
the *list* to a string instead of the individual items.

The attached test case shows a work around (with converter from List<Product> 
to List<String>), but this is not desirable, because a converter would be 
needed for every list<type>.

Original issue reported on code.google.com by [email protected] on 29 Aug 2012 at 9:36

Attachments:

TypeVariableImpl cannot be cast to java.lang.Class

What steps will reproduce the problem?
1. Run attached class' main method

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
1.0

Please provide any additional information below.

Hi,

there is some problem with generic type collections. Is it possible to fix 
this? In case such generic types Orika tries to find class with generic name, 
and in case <P extends Person> parameter, there is no 'P' class.


Original issue reported on code.google.com by [email protected] on 13 Feb 2012 at 2:39

Attachments:

Copying objects works only first time.

What steps will reproduce the problem?
Check attachment.

What is the expected output? What do you see instead?
In short, when copying from object to object, it works properly only the first 
time. The test case provided shows this issue.

What version of the product are you using? On what operating system?
Orika 1.1.2



Original issue reported on code.google.com by [email protected] on 18 May 2012 at 8:25

Attachments:

resolveSourceType does not distinguish by destinationType

What steps will reproduce the problem?
Create a situation where a single source type is mapped to more than one 
destination type over a period of time.
If explicit mappings are not registered, then the resolved source type can be 
different depending on the order in which the auto-mappings are triggered.

What is the expected output? What do you see instead?
The same source type should be resolved regardless of the order in which 
auto-mappings are triggered.

Please use labels and text to provide additional information.


Original issue reported on code.google.com by [email protected] on 5 Sep 2012 at 11:01

require Orika support Jboss4.3

What steps will reproduce the problem?
1. use orika 1.1.5 execute a maven ear task to make a ejb ear build. 
2. Deoploy it to Jboss 4.3 GA
3. restart Jboss

What is the expected output? What do you see instead?
Jboss start without error
Jboss detect javassist conflict issue and stop launching. 


What version of the product are you using? On what operating system?
orika 1.1.5
Jboss 4.3 GA

Please provide any additional information below.
  Jboss4.3 is using javassit-3.8.0.GA.jar while rika 1.1.5 is using javassit-3.12.0.GA.jar. We need to downgrade it to javassit-3.8.0.GA and also to  change classPool.getCtClass() to classPool.get() in JavassistCompilerStrategy.


Original issue reported on code.google.com by [email protected] on 22 Aug 2012 at 7:43

Flexible field-name mapping is needed.

I have to define a global strategy which tell Orika how to find property from 
Entity for property from Dto and back. Orika suggests solution for a particular 
class only.
For example:

 public class UserExtendedInfo extends BaseDto {
    private String groupName;

     @myannotation.Field("group.name")   
     public String getGroupName() {
       return groupName;
     }
     ...
 }

public class User extends BaseEntity {
  private UserGroup group;
   ...
  }

Orika should generate code looks like:
userExtendedInfo.setGroupName(
   user.getGroup().getName();
)

One of case is to register similar DefaultFieldMapper:

defaultMapperFactoryBuilder.registerFieldStrategy(
 new FieldMapperStrategy() {
  /**
  *@param  destinationClass ( in this case UserExtendedInfo.class)
  *@param  sourceClass ( in this case User.class)
  *@param  destinationPropertyName ( in this case"groupName")
  *return propertyName (in this case "group.name:)
  **/
 public String suggestSourcePropertyName(String destinationPropertyName, Class destinationClass, Class sourceClass ) { 
      //Custom logic. It is desirable, that caching the result.  

   }
}
);

Original issue reported on code.google.com by [email protected] on 16 Jul 2012 at 7:47

StackoverflowException on recursively-defined type

What steps will reproduce the problem?

See the attached test case

What is the expected output? What do you see instead?
Mapping should be successful, stackoverflow instead.

Please use labels and text to provide additional information.


Original issue reported on code.google.com by [email protected] on 25 Jun 2012 at 4:39

Attachments:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.