Sorry for the slow reply Florin, this slipped past me until I saw your message 
to Jacques a moment ago.

Could you provide more details about what changes you've made to this checkout? 
 My first guess is that there's something wrong with the database connection 
since the problem appears during the first attempt to connect to it.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 25/01/2010, at 7:35 AM, Florin Popa wrote:

> Hello Scott,
> 
> Additionally, I just noticed that revision 902810 could not be started:
> 
>    [java] 2010-01-25 15:12:48,825 (main) [   
> ModelViewEntity.java:529:WARN ] Conversion for complex-alias needs to be 
> implemented for cache and in-memory eval stuff to work correctly, will not 
> work for alias: statusDelay of view-entity ExampleStatusDetail
> 
>     [java] 2010-01-25 15:12:48,933 (main) [   
> ModelViewEntity.java:529:WARN ] Conversion for complex-alias needs to be 
> implemented for cache and in-memory eval stuff to work correctly, will not 
> work for alias: quantityOrdered of view-entity 
> OrderItemQuantityReportGroupByItem
> 
>     [java] 2010-01-25 15:12:48,934 (main) [   
> ModelViewEntity.java:529:WARN ] Conversion for complex-alias needs to be 
> implemented for cache and in-memory eval stuff to work correctly, will not 
> work for alias: quantityOpen of view-entity OrderItemQuantityReportGroupByItem
> 
>     [java] 2010-01-25 15:12:48,934 (main) [   
> ModelViewEntity.java:529:WARN ] Conversion for complex-alias needs to be 
> implemented for cache and in-memory eval stuff to work correctly, will not 
> work for alias: quantityOrdered of view-entity 
> OrderItemQuantityReportGroupByProduct
> 
>     [java] 2010-01-25 15:12:48,934 (main) [   
> ModelViewEntity.java:529:WARN ] Conversion for complex-alias needs to be 
> implemented for cache and in-memory eval stuff to work correctly, will not 
> work for alias: quantityOpen of view-entity 
> OrderItemQuantityReportGroupByProduct
> 
>     [java] 2010-01-25 15:12:48,947 (main) [   
> ModelViewEntity.java:529:WARN ] Conversion for complex-alias needs to be 
> implemented for cache and in-memory eval stuff to work correctly, will not 
> work for alias: quantityOrdered of view-entity 
> OrderItemAndShipGrpInvResAndItemSum
> 
>     [java] 2010-01-25 15:12:48,947 (main) [   
> ModelViewEntity.java:529:WARN ] Conversion for complex-alias needs to be 
> implemented for cache and in-memory eval stuff to work correctly, will not 
> work for alias: totQuantityAvailable of view-entity 
> OrderItemAndShipGrpInvResAndItemSum
> 
>     [java] 2010-01-25 15:12:49,056 (main) [       
> ModelReader.java:389:INFO ] FINISHED LOADING ENTITIES - ALL FILES;
> 
> #Entities=839 #ViewEntities=263 #Fields=8747 #Relationships=2903
> 
> #AutoRelationships=2138
> 
>     [java] 2010-01-25 15:12:49,068 (main) [  
> GenericDelegator.java:232:INFO ] Doing entity definition check...
> 
>     [java] 2010-01-25 15:12:49,072 (main) [ ModelEntityChecker.java:501:INFO 
> ] [initReservedWords] array length=1023
> 
>     [java] Exception in thread "main" java.lang.NullPointerException
> 
>     [java]     at
> 
> org.ofbiz.entity.GenericDelegator.getEntityFieldType(GenericDelegator.java:484)
> 
>     [java]     at
> 
> org.ofbiz.entity.model.ModelEntityChecker.checkEntities(ModelEntityChecker.java:101)
> 
>     [java]     at
> 
> org.ofbiz.entity.GenericDelegator.<init>(GenericDelegator.java:233)
> 
>     [java]     at
> 
> org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:43)
> 
>     [java]     at
> 
> org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:25)
> 
>     [java]     at
> 
> org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:181)
> 
>     [java]     at
> 
> org.ofbiz.entity.DelegatorFactory.getDelegator(DelegatorFactory.java:31)
> 
>     [java]     at
> 
> org.ofbiz.entityext.data.EntityDataLoadContainer.start(EntityDataLoadContainer.java:229)
> 
>     [java]     at
> 
> org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:100)
> 
>     [java]     at
> 
> org.ofbiz.base.start.Start.startStartLoaders(Start.java:272)
> 
>     [java]     at org.ofbiz.base.start.Start.startServer(Start.java:322)
> 
>     [java]     at org.ofbiz.base.start.Start.start(Start.java:326)
> 
>     [java]     at org.ofbiz.base.start.Start.main(Start.java:411)
> 
>     [java] 2010-01-25 15:12:49,176 (OFBiz_Shutdown_Hook) [   
> ContainerLoader.java:113:INFO ] Shutting down containers
> 
>     [java] Java Result: 1
> 
> 
> BUILD SUCCESSFUL
> 
> Total time: 8 seconds
> 
> 
> 
> 
> Can you help please?
> 
> thanks,
> Flopa
>> Given the amount of changes required to back port you're probably better to 
>> upgrade to a newer revision, depending on how you've handled your custom 
>> code and what tests you have in place to verify your main areas of 
>> functionality, it should be relatively straightforward.
>> 
>> Regards
>> Scott
>> 
>> HotWax Media
>> http://www.hotwaxmedia.com
>> 
>> On 25/01/2010, at 7:01 AM, Florin Popa wrote:
>> 
>>  
>>> Hello all,
>>> 
>>> 
>>> We started to develop an e-commerce application based on Ofbiz framework 
>>> around 2 years ago.
>>> The version we started from is a revision 691692.
>>> 
>>> Main problem is that we already have few systems launched into production, 
>>> based on that revision.
>>> 
>>> Meanwhile, doing some mass tests, we encountered a lot of problems - mostly 
>>> related to transactions...
>>> We noticed the implementation of 
>>> /framework/entity/src/org/ofbiz/entity/transaction/TransactionUtil.java has 
>>> lots of problems from this point of view - maybe not thread safe.
>>> 
>>> We just checked out today revision 902810 and it seems someone really 
>>> improved a lot that source code from threads-safe point of view.
>>> Trying to upgrade only that class into our old version drove to upgrade for 
>>> more and more classes. We encountered lots of incompatibilities - the 
>>> source code has been in some places fully changed. Right now, having more 
>>> than 800 compilation errors I would not feel too optimist to integrate only 
>>> what I need from the newer version into the old one.
>>> 
>>> On the other hand, trying to get 902810 and then put over our work might 
>>> also cause same problems because the entity layer and conditions handling 
>>> seems to be changed.. I even expect to be worse that way because maybe web 
>>> templates are also changed.
>>> 
>>> Which way could someone suggest to proceed for a better version where all 
>>> database/entity layer/transaction later problems are fixed?
>>> 
>>> 
>>> Many thanks,
>>> Flopa
>>>    
>> 
>>  
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to