[jira] [Commented] (OFBIZ-4341) GenericDelegator.findOne cache not working for not-found values (cached not-found treated like cache miss)
[
https://issues.apache.org/jira/browse/OFBIZ-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114561#comment-13114561
]
Martin Kreidenweis commented on OFBIZ-4341:
---
Hi Dimitri,
your patch causes the public {{Delegator.getFromPrimaryKeyCache()}} method to
return {{GenericValue.NULL_VALUE}}. I don't know if that's a good idea. The
NULL_VALUE looks like an internal thing to me that the cache uses because it
doesn't want to store {{null}} directly. (It would have the same problem that
cache misses and null-hits are harder to distinguish.) So maybe we don't want
to return that value from the Delegator.
But as I can't currently find any other uses of the {{getFromPrimaryKeyCache}}
method in OFBiz code, I guess your patch is fine as well.
Does somebody still know how the {{GenericValue.NULL_VALUE}} was originally
intended to be used?
Martin
> GenericDelegator.findOne cache not working for not-found values (cached
> not-found treated like cache miss)
> --
>
> Key: OFBIZ-4341
> URL: https://issues.apache.org/jira/browse/OFBIZ-4341
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
>Assignee: Jacques Le Roux
> Attachments: OFBIZ-4341-findOne-cache-fix.patch, OFBIZ-4341.patch
>
>
> {{GenericDelegator.findOne}} doesn't handle the cache consistently.
> When it doesn't find anything, it puts {{GenericValue.NULL_VALUE}} in the
> cache. When trying to read from the cache it uses the
> {{getFromPrimaryKeyCache}} method, which returns null when
> {{GenericValue.NULL_VALUE}} was stored in the cache, just like for cache
> misses. So a not-found value in the cache is treated like a cache miss and
> the cache isn't actually used.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4335) Delegator creation fails with new ExecutionPool on trunk
[ https://issues.apache.org/jira/browse/OFBIZ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114523#comment-13114523 ] Martin Kreidenweis commented on OFBIZ-4335: --- Just checking up on the ticket status... :-) Do you need more info or did you just not get around to applying the patch yet? I still would suggest just disabling the pre-starting of the ofbiz-config threads. The code then behaves the same regardless whether the UtilPropertiesResourceCache timeout is set or not. I don't think the ThreadWithClassLoader that Adam suggested is necessary. > Delegator creation fails with new ExecutionPool on trunk > > > Key: OFBIZ-4335 > URL: https://issues.apache.org/jira/browse/OFBIZ-4335 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Alexander Reelsen >Assignee: Adam Heath > Attachments: FixExecutionPoolThreadClassLoader.patch > > > he creation of the delegator done in GenericDelegator fails for me, when > starting ofbiz or running run-install-exttest. This is the exception I am > getting for each delegator > [java] 2011-07-08 10:15:17,691 (ofbiz-config-2) [ > GenericHelperFactory:62 :WARN ] > [java] exception report > -- > [java] Exception: java.lang.ClassNotFoundException > [java] Message: org.ofbiz.entity.datasource.GenericHelperDAO > [java] stack trace > --- > [java] java.lang.ClassNotFoundException: > org.ofbiz.entity.datasource.GenericHelperDAO > [java] java.net.URLClassLoader$1.run(URLClassLoader.java:202) > [java] java.security.AccessController.doPrivileged(Native Method) > [java] java.net.URLClassLoader.findClass(URLClassLoader.java:190) > [java] java.lang.ClassLoader.loadClass(ClassLoader.java:307) > [java] java.lang.ClassLoader.loadClass(ClassLoader.java:248) > [java] > org.ofbiz.entity.datasource.GenericHelperFactory.getHelper(GenericHelperFactory.java:60) > [java] > org.ofbiz.entity.GenericDelegator.initializeOneGenericHelper(GenericDelegator.java:268) > [java] > org.ofbiz.entity.GenericDelegator.access$000(GenericDelegator.java:89) > [java] org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:287) > [java] org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:285) > [java] java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > [java] java.util.concurrent.FutureTask.run(FutureTask.java:138) > [java] > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) > [java] > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) > [java] > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > [java] > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > [java] java.lang.Thread.run(Thread.java:680) > [java] > > When removing the ExecutionPool specific code which returns the Callable > stuff from the GenericDelegator everything gets back to work, so there might > be some problem. > Reply from doogie: > It's the Thread.currentThread().getContextClassLoader() call in > GenericHelperFactory that is broken. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4341) GenericDelegator.findOne cache not working for not-found values (cached not-found treated like cache miss)
[
https://issues.apache.org/jira/browse/OFBIZ-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114520#comment-13114520
]
Martin Kreidenweis commented on OFBIZ-4341:
---
Just checking up on the ticket status... :-)
Do you need more info or did you just not get around to applying the patch yet?
One thing we might want to be careful about: Some code might actually depend on
the buggy behavior and expect that the cache is not used for not-found primary
key values. Still, the intention of the original code seems to me like it
wanted to use that cache and it just didn't work. So I think we should fix this.
We found the issue while profiling a service in our application.
> GenericDelegator.findOne cache not working for not-found values (cached
> not-found treated like cache miss)
> --
>
> Key: OFBIZ-4341
> URL: https://issues.apache.org/jira/browse/OFBIZ-4341
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
> Attachments: OFBIZ-4341-findOne-cache-fix.patch
>
>
> {{GenericDelegator.findOne}} doesn't handle the cache consistently.
> When it doesn't find anything, it puts {{GenericValue.NULL_VALUE}} in the
> cache. When trying to read from the cache it uses the
> {{getFromPrimaryKeyCache}} method, which returns null when
> {{GenericValue.NULL_VALUE}} was stored in the cache, just like for cache
> misses. So a not-found value in the cache is treated like a cache miss and
> the cache isn't actually used.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4295) Deserialization of arrays with UtilObject.getObject() throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/OFBIZ-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114519#comment-13114519
]
Martin Kreidenweis commented on OFBIZ-4295:
---
Just checking up on the ticket status... :-)
Do you need more info or did you just not get around to applying the patch yet?
> Deserialization of arrays with UtilObject.getObject() throws
> ClassNotFoundException
> ---
>
> Key: OFBIZ-4295
> URL: https://issues.apache.org/jira/browse/OFBIZ-4295
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
> Attachments: OFBIZ-4295-classloader.patch
>
>
> Deserialization of arrays with {{UtilObject.getObject()}} throws a
> {{ClassNotFoundException}}. This happened to us when we enabled the
> distributed cache clear feature and it was sending arrays of {{EntityExpr}}
> objects to other OFBiz instances.
> The reason is, that the {{org.ofbiz.base.util.ObjectInputStream}} calls
> {{classLoader.loadClass(name)}} directly instead of using
> {{Class.forName(name, init, classLoader)}}.
> According to java bug
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446627
> {{ClassLoader.loadClass()}} is not intended to being used this way and
> doesn't support loading arrays.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4345) voided payments are auto-applied to new order invoices
[
https://issues.apache.org/jira/browse/OFBIZ-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13076089#comment-13076089
]
Martin Kreidenweis commented on OFBIZ-4345:
---
Hi Bilgin, thanks for looking into this.
I don't see any issue with also filtering out cancelled
OrderPaymentPreferences. This would work for us.
Martin
> voided payments are auto-applied to new order invoices
> --
>
> Key: OFBIZ-4345
> URL: https://issues.apache.org/jira/browse/OFBIZ-4345
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
>Assignee: Bilgin Ibryam
> Attachments: OFBIZ-4345-voidedAutoApply.patch
>
>
> {{InvoiceServices.createInvoiceForOrder}} automatically creates
> {{PaymentApplication}} records when unapplied payments exist for the order.
> Unfortunately this doesn't consider the {{Payment.statusId}}.
> So when a user accidentally enters a wrong payment and voids it right away,
> it is still automatically applied to the invoice on invoice creation. The GUI
> then provides no way to un-apply the payment, because it assumes that for
> voided payments no payment applications can exist any more.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4335) Delegator creation fails with new ExecutionPool on trunk
[
https://issues.apache.org/jira/browse/OFBIZ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068936#comment-13068936
]
Martin Kreidenweis commented on OFBIZ-4335:
---
I have an alternate, very simple patch:
{code}
Index: framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java
===
--- framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java
(Revision 1144132)
+++ framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java
(Arbeitskopie)
@@ -39,7 +39,7 @@
@SourceMonitored
public final class ExecutionPool {
public static final String module = ExecutionPool.class.getName();
-public static final ScheduledExecutorService GLOBAL_EXECUTOR =
getExecutor(null, "ofbiz-config", -1, true);
+public static final ScheduledExecutorService GLOBAL_EXECUTOR =
getExecutor(null, "ofbiz-config", -1, false);
protected static class ExecutionPoolThreadFactory implements ThreadFactory
{
private final ThreadGroup group;
{code}
The problem is indeed that the wrong class loader is used for the
"ofbiz-config-*" threads ({{NativeLibClassLoader}} instead of
{{CachedClassLoader}}). This happens when the threads are created by the static
code in {{ExecutionPool.java}} when it is executed before the
{{ClassLoaderContainer.init()}} initializes the {{CachedClassLoader}}.
This also causes other problems like: The local resolution of XML Schema files
won't work any more because it's also using the wrong classloader, which can't
find the XSD files:
{code}
[java] 2011-07-21 12:21:45,333 (ofbiz-config-0) [
UtilXml:1022:WARN ] [UtilXml.LocalResolver.resolveEntity] could not find LOCAL
DTD/Schema with publicId [null] and the file/resource is [service-eca.xsd]
{code}
You can trigger this behavior in current ofbiz trunk by setting an expire time
for the properties cache in {{cache.properties}}
{code}
properties.UtilPropertiesResourceCache.expireTime=1
{code}
The {{Debug.log()}} statements in the {{ContainerLoader}} then load the logging
configuration properties file and cache it. If an expire time is set, the
{{ExecutionPool}} is used and creates the "ofbiz-config-*" threads too early.
By not pre-starting the "ofbiz-config-*" threads in the static code (patch
above), the threads are then created later on, when the "main" thread
classloader has become the {{CachedClassLoader}} and everythings starts working
again. :-)
> Delegator creation fails with new ExecutionPool on trunk
>
>
> Key: OFBIZ-4335
> URL: https://issues.apache.org/jira/browse/OFBIZ-4335
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Alexander Reelsen
>Assignee: Adam Heath
> Attachments: FixExecutionPoolThreadClassLoader.patch
>
>
> he creation of the delegator done in GenericDelegator fails for me, when
> starting ofbiz or running run-install-exttest. This is the exception I am
> getting for each delegator
> [java] 2011-07-08 10:15:17,691 (ofbiz-config-2) [
> GenericHelperFactory:62 :WARN ]
> [java] exception report
> --
> [java] Exception: java.lang.ClassNotFoundException
> [java] Message: org.ofbiz.entity.datasource.GenericHelperDAO
> [java] stack trace
> ---
> [java] java.lang.ClassNotFoundException:
> org.ofbiz.entity.datasource.GenericHelperDAO
> [java] java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> [java] java.security.AccessController.doPrivileged(Native Method)
> [java] java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> [java] java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> [java] java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> [java]
> org.ofbiz.entity.datasource.GenericHelperFactory.getHelper(GenericHelperFactory.java:60)
> [java]
> org.ofbiz.entity.GenericDelegator.initializeOneGenericHelper(GenericDelegator.java:268)
> [java]
> org.ofbiz.entity.GenericDelegator.access$000(GenericDelegator.java:89)
> [java] org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:287)
> [java] org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:285)
> [java] java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> [java] java.util.concurrent.FutureTask.run(FutureTask.java:138)
> [java]
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
> [java]
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
> [java]
> java.util.
[jira] [Updated] (OFBIZ-4345) voided payments are auto-applied to new order invoices
[
https://issues.apache.org/jira/browse/OFBIZ-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kreidenweis updated OFBIZ-4345:
--
Attachment: OFBIZ-4345-voidedAutoApply.patch
Patch resolves the issue by not creating payment applications if the payment is
in the PMNT_VOID or PMNT_CANCELLED status.
> voided payments are auto-applied to new order invoices
> --
>
> Key: OFBIZ-4345
> URL: https://issues.apache.org/jira/browse/OFBIZ-4345
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
> Attachments: OFBIZ-4345-voidedAutoApply.patch
>
>
> {{InvoiceServices.createInvoiceForOrder}} automatically creates
> {{PaymentApplication}} records when unapplied payments exist for the order.
> Unfortunately this doesn't consider the {{Payment.statusId}}.
> So when a user accidentally enters a wrong payment and voids it right away,
> it is still automatically applied to the invoice on invoice creation. The GUI
> then provides no way to un-apply the payment, because it assumes that for
> voided payments no payment applications can exist any more.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4345) voided payments are auto-applied to new order invoices
voided payments are auto-applied to new order invoices
--
Key: OFBIZ-4345
URL: https://issues.apache.org/jira/browse/OFBIZ-4345
Project: OFBiz
Issue Type: Bug
Components: accounting
Affects Versions: SVN trunk
Reporter: Martin Kreidenweis
{{InvoiceServices.createInvoiceForOrder}} automatically creates
{{PaymentApplication}} records when unapplied payments exist for the order.
Unfortunately this doesn't consider the {{Payment.statusId}}.
So when a user accidentally enters a wrong payment and voids it right away, it
is still automatically applied to the invoice on invoice creation. The GUI then
provides no way to un-apply the payment, because it assumes that for voided
payments no payment applications can exist any more.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4341) GenericDelegator.findOne cache not working for not-found values (cached not-found treated like cache miss)
[
https://issues.apache.org/jira/browse/OFBIZ-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kreidenweis updated OFBIZ-4341:
--
Attachment: OFBIZ-4341-findOne-cache-fix.patch
patch fixing the findOne cache issue for not-found values
> GenericDelegator.findOne cache not working for not-found values (cached
> not-found treated like cache miss)
> --
>
> Key: OFBIZ-4341
> URL: https://issues.apache.org/jira/browse/OFBIZ-4341
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
> Attachments: OFBIZ-4341-findOne-cache-fix.patch
>
>
> {{GenericDelegator.findOne}} doesn't handle the cache consistently.
> When it doesn't find anything, it puts {{GenericValue.NULL_VALUE}} in the
> cache. When trying to read from the cache it uses the
> {{getFromPrimaryKeyCache}} method, which returns null when
> {{GenericValue.NULL_VALUE}} was stored in the cache, just like for cache
> misses. So a not-found value in the cache is treated like a cache miss and
> the cache isn't actually used.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4341) GenericDelegator.findOne cache not working for not-found values (cached not-found treated like cache miss)
GenericDelegator.findOne cache not working for not-found values (cached
not-found treated like cache miss)
--
Key: OFBIZ-4341
URL: https://issues.apache.org/jira/browse/OFBIZ-4341
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Martin Kreidenweis
{{GenericDelegator.findOne}} doesn't handle the cache consistently.
When it doesn't find anything, it puts {{GenericValue.NULL_VALUE}} in the
cache. When trying to read from the cache it uses the
{{getFromPrimaryKeyCache}} method, which returns null when
{{GenericValue.NULL_VALUE}} was stored in the cache, just like for cache
misses. So a not-found value in the cache is treated like a cache miss and the
cache isn't actually used.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039660#comment-13039660
]
Martin Kreidenweis commented on OFBIZ-4296:
---
Another thing we noticed when we looked at the problem: Prior to
[r1090952|https://fisheye6.atlassian.com/changelog/ofbiz?cs=1090952] the DCC
was initialized before the ECA handlers. Now it is the other way round. Don't
know it this was intended and/or could be a problem.
> JmsTopicListener started twice when distributed-cache-clear is active
> -
>
> Key: OFBIZ-4296
> URL: https://issues.apache.org/jira/browse/OFBIZ-4296
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
>Assignee: Jacques Le Roux
>
> This is a follow up issue of OFBIZ-3987 and OFBIZ-4202. Apparently the
> problem was not properly fixed. The infinite loop during startup went away,
> but there still are other side effects.
> Log output excerpt:
> {code}
> 2011-05-26 09:43:56,336 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
> JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
> ...
> 2011-05-26 09:44:00,499 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
> JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
> 2011-05-26 09:44:01,076 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
> JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on
> [activemq]...
> 2011-05-26 09:44:01,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
> JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on
> [activemq]...
> ...
> 2011-05-26 09:44:21,081 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
> JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All
> listeners connected.
> 2011-05-26 09:44:21,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
> JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All
> listeners connected.
> {code}
> What happens is this:
> {{DelegatorFactory.getDelegator("default")}} is called during startup
> (CatalinaContainer init). After creating the delegator and putting it in the
> cache it calls {{delegator.initEntityEcaHandler()}}. Somewhere inside it
> tries to get a dispatcher, so the first ServiceDispatcher instance is
> initialized. Inside the constructor code the JobManager wants to access the
> database and somewhere inside the {{EntityExpr}} another call to
> {{DelegatorFactory.getDelegator("default")}} is done. As the ECAHandler is
> already initialized it now initializes the DCC using
> {{EntityCacheServices.setDelegator()}}. This creates the second
> {{ServiceDispatcher}} instance and starts up the first {{JmsListenerFactory}}
> thread. Further up the call stack, a little later the "outer"
> {{ServiceDispatcher}} now also creates a {{JmsListenerFactory}} thread. So we
> have two listeners and every JMS message is handled twice.
> As a workaround we broke the recursion in the {{ServiceDispatcher}}
> constructor by doing a lazy initialization of the dispatcher in
> {{EntityCacheServices}}: We moved the call to
> {{EntityServiceFactory.getLocalDispatcher(delegator)}} out from the
> {{setDelegator}} method to when it is first needed.
> This doesn't seem like the proper solution, though. Maybe someone with more
> insight on how all the initialization of the dispatcher and delegator works
> can contribute a proper fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
JmsTopicListener started twice when distributed-cache-clear is active
-
Key: OFBIZ-4296
URL: https://issues.apache.org/jira/browse/OFBIZ-4296
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Martin Kreidenweis
This is a follow up issue of OFBIZ-3987 and OFBIZ-4202. Apparently the problem
was not properly fixed. The infinite loop during startup went away, but there
still are other side effects.
Log output excerpt:
{code}
2011-05-26 09:43:56,336 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
...
2011-05-26 09:44:00,499 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
2011-05-26 09:44:01,076 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on
[activemq]...
2011-05-26 09:44:01,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on
[activemq]...
...
2011-05-26 09:44:21,081 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All
listeners connected.
2011-05-26 09:44:21,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All
listeners connected.
{code}
What happens is this:
{{DelegatorFactory.getDelegator("default")}} is called during startup
(CatalinaContainer init). After creating the delegator and putting it in the
cache it calls {{delegator.initEntityEcaHandler()}}. Somewhere inside it tries
to get a dispatcher, so the first ServiceDispatcher instance is initialized.
Inside the constructor code the JobManager wants to access the database and
somewhere inside the {{EntityExpr}} another call to
{{DelegatorFactory.getDelegator("default")}} is done. As the ECAHandler is
already initialized it now initializes the DCC using
{{EntityCacheServices.setDelegator()}}. This creates the second
{{ServiceDispatcher}} instance and starts up the first {{JmsListenerFactory}}
thread. Further up the call stack, a little later the "outer"
{{ServiceDispatcher}} now also creates a {{JmsListenerFactory}} thread. So we
have two listeners and every JMS message is handled twice.
As a workaround we broke the recursion in the {{ServiceDispatcher}} constructor
by doing a lazy initialization of the dispatcher in {{EntityCacheServices}}: We
moved the call to {{EntityServiceFactory.getLocalDispatcher(delegator)}} out
from the {{setDelegator}} method to when it is first needed.
This doesn't seem like the proper solution, though. Maybe someone with more
insight on how all the initialization of the dispatcher and delegator works can
contribute a proper fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4295) Deserialization of arrays with UtilObject.getObject() throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/OFBIZ-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kreidenweis updated OFBIZ-4295:
--
Attachment: OFBIZ-4295-classloader.patch
This patch fixes the array deserialization issue in for UtilIO and UtilObject
by using {{Class.forName()}}.
> Deserialization of arrays with UtilObject.getObject() throws
> ClassNotFoundException
> ---
>
> Key: OFBIZ-4295
> URL: https://issues.apache.org/jira/browse/OFBIZ-4295
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
> Attachments: OFBIZ-4295-classloader.patch
>
>
> Deserialization of arrays with {{UtilObject.getObject()}} throws a
> {{ClassNotFoundException}}. This happened to us when we enabled the
> distributed cache clear feature and it was sending arrays of {{EntityExpr}}
> objects to other OFBiz instances.
> The reason is, that the {{org.ofbiz.base.util.ObjectInputStream}} calls
> {{classLoader.loadClass(name)}} directly instead of using
> {{Class.forName(name, init, classLoader)}}.
> According to java bug
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446627
> {{ClassLoader.loadClass()}} is not intended to being used this way and
> doesn't support loading arrays.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4295) Deserialization of arrays with UtilObject.getObject() throws ClassNotFoundException
Deserialization of arrays with UtilObject.getObject() throws
ClassNotFoundException
---
Key: OFBIZ-4295
URL: https://issues.apache.org/jira/browse/OFBIZ-4295
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Martin Kreidenweis
Deserialization of arrays with {{UtilObject.getObject()}} throws a
{{ClassNotFoundException}}. This happened to us when we enabled the distributed
cache clear feature and it was sending arrays of {{EntityExpr}} objects to
other OFBiz instances.
The reason is, that the {{org.ofbiz.base.util.ObjectInputStream}} calls
{{classLoader.loadClass(name)}} directly instead of using {{Class.forName(name,
init, classLoader)}}.
According to java bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446627
{{ClassLoader.loadClass()}} is not intended to being used this way and doesn't
support loading arrays.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4284) NullPointerException in GenericDelegator during testMode rollback
[
https://issues.apache.org/jira/browse/OFBIZ-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kreidenweis updated OFBIZ-4284:
--
Attachment: OFBIZ-4284.patch
patch fixing both described issues
> NullPointerException in GenericDelegator during testMode rollback
> -
>
> Key: OFBIZ-4284
> URL: https://issues.apache.org/jira/browse/OFBIZ-4284
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
> Attachments: OFBIZ-4284.patch
>
>
> Test mode rollback doesn't work right in {{GenericDelegator}} for calls to
> {{removeByPrimary()}} key and {{removeByValue()}} when the row to be deleted
> didn't exist in the first place. It creates a {{TestOperation}} with a null
> value and subsequently fails to create that during rollback.
> First, the TestOperation shouldn't be created at all. Second, if {{null}} is
> passed to {{GenericDelegator.create()}} it tries to handle this, but fails
> with a NullPointerException.
> Patch to come.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4284) NullPointerException in GenericDelegator during testMode rollback
NullPointerException in GenericDelegator during testMode rollback
-
Key: OFBIZ-4284
URL: https://issues.apache.org/jira/browse/OFBIZ-4284
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Martin Kreidenweis
Test mode rollback doesn't work right in {{GenericDelegator}} for calls to
{{removeByPrimary()}} key and {{removeByValue()}} when the row to be deleted
didn't exist in the first place. It creates a {{TestOperation}} with a null
value and subsequently fails to create that during rollback.
First, the TestOperation shouldn't be created at all. Second, if {{null}} is
passed to {{GenericDelegator.create()}} it tries to handle this, but fails with
a NullPointerException.
Patch to come.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-4202) Distributed Cache Clear is broken in current versions of OFBiz
[
https://issues.apache.org/jira/browse/OFBIZ-4202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000301#comment-13000301
]
Martin Kreidenweis commented on OFBIZ-4202:
---
Hi,
Sascha, I guess you actually reported the same issue in OFBIZ-3987. So this bug
is a duplicate.
I did not try reverting changeset 921990 and did not check why it causes the
issue. I just found out that this is where it broke while doing a dumb binary
search on the version history to narrow it down.
So I guess we should review Sascha's changes in OFBIZ-3987 to see if they're a
good fix. During our tests, as a workaround, we added lazy initialization in
{{EntityCacheServices}}: we wouldn't call
{{EntityServiceFactory.getLocalDispatcher(delegator)}} right away, but only
when it's first needed.
It's not a high priority issue for us currently. Still, it would be nice if it
worked again out of the box in OFBiz.
Martin
> Distributed Cache Clear is broken in current versions of OFBiz
> --
>
> Key: OFBIZ-4202
> URL: https://issues.apache.org/jira/browse/OFBIZ-4202
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Release Branch 10.04, SVN trunk
>Reporter: Martin Kreidenweis
>
> Setting distributed-cache-clear-enabled="true" for the delegator in
> entityengine.xml doesn't work any more: OFBiz goes into an infinite loop
> during startup. (Only for regular startup, not e.g. for {{ant run-install}}
> startup).
> I think I already tracked down where it broke: [Changeset
> 921990|https://fisheye6.atlassian.com/changelog/ofbiz?cs=921990] on
> 2010-03-11 in OFBiz trunk. Before this change OFBiz still starts up, after
> this change you get the infinite loop. This means Release 10.04 is already
> broken.
> Unfortunately I don't have time currently to investigate further, maybe at a
> later time.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OFBIZ-4202) Distributed Cache Clear is broken in current versions of OFBiz
Distributed Cache Clear is broken in current versions of OFBiz
--
Key: OFBIZ-4202
URL: https://issues.apache.org/jira/browse/OFBIZ-4202
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 10.04, SVN trunk
Reporter: Martin Kreidenweis
Setting distributed-cache-clear-enabled="true" for the delegator in
entityengine.xml doesn't work any more: OFBiz goes into an infinite loop during
startup. (Only for regular startup, not e.g. for {{ant run-install}} startup).
I think I already tracked down where it broke: [Changeset
921990|https://fisheye6.atlassian.com/changelog/ofbiz?cs=921990] on 2010-03-11
in OFBiz trunk. Before this change OFBiz still starts up, after this change you
get the infinite loop. This means Release 10.04 is already broken.
Unfortunately I don't have time currently to investigate further, maybe at a
later time.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OFBIZ-4196) Non-existing image (new image management system) returns 500 error instead of 404
Non-existing image (new image management system) returns 500 error instead of 404 - Key: OFBIZ-4196 URL: https://issues.apache.org/jira/browse/OFBIZ-4196 Project: OFBiz Issue Type: Bug Components: content Affects Versions: SVN trunk Reporter: Martin Kreidenweis The new ImageUrlServlet throws an IndexOutOfBoundsException or NullPointerException when called with invalid paths: https://demo-trunk.ofbiz.apache.org/catalog/images/foo.jpg https://demo-trunk.ofbiz.apache.org/catalog/images/foo/bar.jpg This causes Tomcat to show a stacktrace with HTTP status code 500. It should return a 404 Not Found error instead. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-4178) New Custom Method order ID generation implementation in OFBIZ-3765 broke backwards compatiblity
[ https://issues.apache.org/jira/browse/OFBIZ-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kreidenweis updated OFBIZ-4178: -- Attachment: OFBIZ-4178.patch fixes order id generation backwards compatiblity > New Custom Method order ID generation implementation in OFBIZ-3765 broke > backwards compatiblity > --- > > Key: OFBIZ-4178 > URL: https://issues.apache.org/jira/browse/OFBIZ-4178 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Martin Kreidenweis > Attachments: OFBIZ-4178.patch > > > Due to missed col-name attributes for the deprecated field names (old* > fields) and a typo in the minilang code in the original patch (OFBIZ-3765), > the backwards compatibility with the old enum IDs broke. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OFBIZ-4178) New Custom Method order ID generation implementation in OFBIZ-3765 broke backwards compatiblity
New Custom Method order ID generation implementation in OFBIZ-3765 broke backwards compatiblity --- Key: OFBIZ-4178 URL: https://issues.apache.org/jira/browse/OFBIZ-4178 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: SVN trunk Reporter: Martin Kreidenweis Due to missed col-name attributes for the deprecated field names (old* fields) and a typo in the minilang code in the original patch (OFBIZ-3765), the backwards compatibility with the old enum IDs broke. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-4176) savePaymentGatewayResponse throws exceptions due to foreign key constraints
[ https://issues.apache.org/jira/browse/OFBIZ-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kreidenweis updated OFBIZ-4176: -- Attachment: OFBIZ-4176.patch Fix for the issue: we created a new savePaymentGatewayResponseAndMessages service, that takes both the Response and the ResponseMessages and writes them to the database in the right order. > savePaymentGatewayResponse throws exceptions due to foreign key constraints > --- > > Key: OFBIZ-4176 > URL: https://issues.apache.org/jira/browse/OFBIZ-4176 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Martin Kreidenweis > Attachments: OFBIZ-4176.patch > > > If you use a CC payment service provider that actually wants to save not only > PaymentGatewayResponses, but also PaymentGatewayResponseMessages, saving > these to the database actually might fail because they are created in the > wrong order. The response and the messages are scheduled as separate async > rollback services in processCreditResult. So it's not guaranteed the Response > is there before OFBiz tries to add the ResponseMessages. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OFBIZ-4176) savePaymentGatewayResponse throws exceptions due to foreign key constraints
savePaymentGatewayResponse throws exceptions due to foreign key constraints --- Key: OFBIZ-4176 URL: https://issues.apache.org/jira/browse/OFBIZ-4176 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: SVN trunk Reporter: Martin Kreidenweis If you use a CC payment service provider that actually wants to save not only PaymentGatewayResponses, but also PaymentGatewayResponseMessages, saving these to the database actually might fail because they are created in the wrong order. The response and the messages are scheduled as separate async rollback services in processCreditResult. So it's not guaranteed the Response is there before OFBiz tries to add the ResponseMessages. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-4079) Adding content in CMS using add long text (right mouse click) doesn't work
[ https://issues.apache.org/jira/browse/OFBIZ-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kreidenweis updated OFBIZ-4079: -- Attachment: OFBIZ-4079_cmsEditorFixes.svn.patch Hi Sascha, I re-created the patch using subversion. Maybe you have more luck applying this one. Martin > Adding content in CMS using add long text (right mouse click) doesn't work > -- > > Key: OFBIZ-4079 > URL: https://issues.apache.org/jira/browse/OFBIZ-4079 > Project: OFBiz > Issue Type: Sub-task > Components: content >Affects Versions: SVN trunk >Reporter: Willem Janssen >Assignee: Jacques Le Roux > Attachments: 2010-12-28_2329.png, OFBIZ-4079_cmsEditorFixes.patch, > OFBIZ-4079_cmsEditorFixes.svn.patch > > > When using the add long text function in the menu that shows when using the > right mouse click the existing content is shown, not an empty form. > Now it's not possible to add content in the CMS because only existing content > is shown in the forms. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4079) Adding content in CMS using add long text (right mouse click) doesn't work
[ https://issues.apache.org/jira/browse/OFBIZ-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980647#action_12980647 ] Martin Kreidenweis commented on OFBIZ-4079: --- I'm not sure my patch fixes all the jQuery related issues with the CMS. Some more testing is necessary there. Creating new long and short texts works as expected now, though. > Adding content in CMS using add long text (right mouse click) doesn't work > -- > > Key: OFBIZ-4079 > URL: https://issues.apache.org/jira/browse/OFBIZ-4079 > Project: OFBiz > Issue Type: Sub-task > Components: content >Affects Versions: SVN trunk >Reporter: Willem Janssen >Assignee: Jacques Le Roux > Attachments: 2010-12-28_2329.png, OFBIZ-4079_cmsEditorFixes.patch > > > When using the add long text function in the menu that shows when using the > right mouse click the existing content is shown, not an empty form. > Now it's not possible to add content in the CMS because only existing content > is shown in the forms. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4079) Adding content in CMS using add long text (right mouse click) doesn't work
[ https://issues.apache.org/jira/browse/OFBIZ-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kreidenweis updated OFBIZ-4079: -- Attachment: OFBIZ-4079_cmsEditorFixes.patch fixing some bugs in CMS introduced in svn r1036195 when migrating from dojo to jQuery: * reverted accidental logic change in callDocument() that broke the "new ..." context menu items (OFBiz bug OFBIZ-4079) * making elRTE "save" toolbar button work: same behavior as the regular "Save" button * using regular form submit instead of ajax for new content for now ** ajaxSubmitForm() can't handle new content, it won't reload the form because it doesn't know the new contentId *** some controller changes would probably be necessary to make that work (return new contentId as JSON) ** nav tree is not updated with ajax submit currently * now always creating editor if corresponsing html element exists ** editor was not initialized when WebSiteCMSContent screen was loaded by non-ajax call > Adding content in CMS using add long text (right mouse click) doesn't work > -- > > Key: OFBIZ-4079 > URL: https://issues.apache.org/jira/browse/OFBIZ-4079 > Project: OFBiz > Issue Type: Sub-task > Components: content >Affects Versions: SVN trunk >Reporter: Willem Janssen >Assignee: Jacques Le Roux > Attachments: 2010-12-28_2329.png, OFBIZ-4079_cmsEditorFixes.patch > > > When using the add long text function in the menu that shows when using the > right mouse click the existing content is shown, not an empty form. > Now it's not possible to add content in the CMS because only existing content > is shown in the forms. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4108) Links to Path Alias and Meta Tags in CMS don't work any more
[ https://issues.apache.org/jira/browse/OFBIZ-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kreidenweis updated OFBIZ-4108: -- Attachment: OFBIZ-4108_CMS_link_fix.patch patch removes calls to non-existing destroyEditor() javascript function, fixes the url to the path alias, and adds the missing screenlets to the path alias and meta tags screens > Links to Path Alias and Meta Tags in CMS don't work any more > > > Key: OFBIZ-4108 > URL: https://issues.apache.org/jira/browse/OFBIZ-4108 > Project: OFBiz > Issue Type: Sub-task > Components: content >Affects Versions: SVN trunk >Reporter: Martin Kreidenweis > Attachments: OFBIZ-4108_CMS_link_fix.patch > > > * Go to > https://demo-trunk.ofbiz.apache.org/content/control/WebSiteCms?webSiteId=WebStore > * Select some content, e.g. "Store Policies" > * Try to click the "Path Alias" or "Meta Tags" links at the top. They cause > a JavaScript error: "destroyEditor is not defined" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4108) Links to Path Alias and Meta Tags in CMS don't work any more
Links to Path Alias and Meta Tags in CMS don't work any more Key: OFBIZ-4108 URL: https://issues.apache.org/jira/browse/OFBIZ-4108 Project: OFBiz Issue Type: Sub-task Components: content Affects Versions: SVN trunk Reporter: Martin Kreidenweis * Go to https://demo-trunk.ofbiz.apache.org/content/control/WebSiteCms?webSiteId=WebStore * Select some content, e.g. "Store Policies" * Try to click the "Path Alias" or "Meta Tags" links at the top. They cause a JavaScript error: "destroyEditor is not defined" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4107) if-regexp conditions in Minilang and Screens not thread safe
[ https://issues.apache.org/jira/browse/OFBIZ-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kreidenweis updated OFBIZ-4107: -- Attachment: OFBIZ-4107-partial-fix.patch OFBIZ-4107-test.patch Test to reproduce the issue and our fix for org.ofbiz.minilang.method.ifops.IfRegexp > if-regexp conditions in Minilang and Screens not thread safe > > > Key: OFBIZ-4107 > URL: https://issues.apache.org/jira/browse/OFBIZ-4107 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Martin Kreidenweis > Attachments: OFBIZ-4107-partial-fix.patch, OFBIZ-4107-test.patch > > > The Perl5Matcher Perl5Compiler are not thread safe, as mentioned in their > documentation: > http://jakarta.apache.org/oro/api/org/apache/oro/text/regex/Perl5Compiler.html > A separate instance should be used per thread. > The concrete issue occurred in our system in the > createCommContentDataResource service. The service tries to save emails to > the database after they have been sent. It failed because of the described > issue. This caused the whole email service (sendMailFromScreen) to be > rescheduled. So customers got emails twice. > The Perl5Matcher and Perl5Compiler instances are assigned to static fields in > the org.ofbiz.minilang.method.ifops.IfRegexp class. So every thread will use > the same instance. No synchronization is done currently. Changing the fields > to be non-static will not work either, as SimpleMethods are cached. So all > calls to the same simple method use the same IfRegexp instance. > We fixed the problem by moving the instantiation of the Perl5Matcher and > Perl5Compiler to the exec() method in IfRegexp. > Other classes are most likely affected, too: > org.ofbiz.entity.condition.EntityComparisonOperator, > org.ofbiz.minilang.method.conditional.RegexpCondition, > org.ofbiz.minilang.operation.Regexp, > org.ofbiz.widget.menu.ModelMenuCondition$IfRegexp, > org.ofbiz.widget.screen.ModelScreenCondition$IfRegexp, > org.ofbiz.widget.tree.ModelTreeCondition$IfRegexp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4107) if-regexp conditions in Minilang and Screens not thread safe
if-regexp conditions in Minilang and Screens not thread safe Key: OFBIZ-4107 URL: https://issues.apache.org/jira/browse/OFBIZ-4107 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Martin Kreidenweis The Perl5Matcher Perl5Compiler are not thread safe, as mentioned in their documentation: http://jakarta.apache.org/oro/api/org/apache/oro/text/regex/Perl5Compiler.html A separate instance should be used per thread. The concrete issue occurred in our system in the createCommContentDataResource service. The service tries to save emails to the database after they have been sent. It failed because of the described issue. This caused the whole email service (sendMailFromScreen) to be rescheduled. So customers got emails twice. The Perl5Matcher and Perl5Compiler instances are assigned to static fields in the org.ofbiz.minilang.method.ifops.IfRegexp class. So every thread will use the same instance. No synchronization is done currently. Changing the fields to be non-static will not work either, as SimpleMethods are cached. So all calls to the same simple method use the same IfRegexp instance. We fixed the problem by moving the instantiation of the Perl5Matcher and Perl5Compiler to the exec() method in IfRegexp. Other classes are most likely affected, too: org.ofbiz.entity.condition.EntityComparisonOperator, org.ofbiz.minilang.method.conditional.RegexpCondition, org.ofbiz.minilang.operation.Regexp, org.ofbiz.widget.menu.ModelMenuCondition$IfRegexp, org.ofbiz.widget.screen.ModelScreenCondition$IfRegexp, org.ofbiz.widget.tree.ModelTreeCondition$IfRegexp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3910) Sending multiple emails simultaneously to new party does not work properly
Sending multiple emails simultaneously to new party does not work properly
--
Key: OFBIZ-3910
URL: https://issues.apache.org/jira/browse/OFBIZ-3910
Project: OFBiz
Issue Type: Bug
Components: party
Affects Versions: Release Branch 10.04
Reporter: Martin Kreidenweis
Sending more than one email at once to a party that never has received an email
using the sendMailFromScreen service fails.
Creating the communication event for the email in this case triggers the
createPartyRole service. So two threads apparently try to insert the same party
role. This results in the following error:
{code}
java.lang.Exception: Failure in create operation for entity [PartyRole]:
org.ofbiz.entity.GenericEntityException: Error while inserting:
[GenericEntity:PartyRole][createdStamp,2010-08-30
10:44:41.144(java.sql.Timestamp)][createdTxStamp,2010-08-30
10:44:26.709(java.sql.Timestamp)][lastUpdatedStamp,2010-08-30
10:44:41.144(java.sql.Timestamp)][lastUpdatedTxStamp,2010-08-30
10:44:26.709(java.sql.Timestamp)][partyId,RegisteredMerchantCompany(java.lang.String)][roleTypeId,ADDRESSEE(java.lang.String)]
(SQL Exception while executing the following:INSERT INTO ofbiz.PARTY_ROLE
(PARTY_ID, ROLE_TYPE_ID, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP,
CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?) (ERROR: duplicate
key value violates unique constraint »pk_party_role«)). Rolling back
transaction.
{code}
This happens only after the actual emails are sent. OFBiz now rolls back the
transaction, thinks the email sending failed, and tries to send the emails
again later.
Workaround:
Create a PartyRole ADDRESSE for the party before trying to send emails.
We did not find a good solution for the actual problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3883) Customer's Shipment Address Not Assigned to Dropship Purchase Orders
Customer's Shipment Address Not Assigned to Dropship Purchase Orders Key: OFBIZ-3883 URL: https://issues.apache.org/jira/browse/OFBIZ-3883 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Release Branch 10.04, SVN trunk Environment: demo-trunk.ofbiz.apache.org Reporter: Martin Kreidenweis When buying drop ship products from the demo store the customer's shipping address is not saved with the purchase order, so the shipping address cannot be provided to the drop ship supplier. Steps to Reproduce: * From the DropShip Category add "DropShip from BigSupplier" and "DropShip from DemoSupplier" to your cart. * Login as admin * Use the one page checkout to order the products Resulting Order: https://demo-trunk.ofbiz.apache.org:8443/ordermgr/control/orderview?orderId=WSCO10002 The purchase orders WS10003 and WS10004 are associated correctly with the order items, but as the shipping groups don't have addresses, the purchase orders don't have either. Expectation: All Shipment groups should have the shipping address assigned. Actual: Only the first shipment group has the shipping address assigned. Possibly offending line of Code: ShoppingCart.java line 2235: this.setShippingContactMechId(0, shippingContactMechId); Should probably not add the contactMechId only to the first CartShipInfo. When we tried to change that, though, drop shipping broke somehow completely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1151) Passwords are not seeded
[ https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895313#action_12895313 ] Martin Kreidenweis commented on OFBIZ-1151: --- Adam, great news about the patch. Where can I get it? :) Thanks Martin > Passwords are not seeded > > > Key: OFBIZ-1151 > URL: https://issues.apache.org/jira/browse/OFBIZ-1151 > Project: OFBiz > Issue Type: Sub-task > Components: party >Affects Versions: Release Branch 4.0, SVN trunk >Reporter: Wickersheimer Jeremy >Assignee: Jacques Le Roux >Priority: Minor > > Password are currently hashed but not seeded which may be a security issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method
[
https://issues.apache.org/jira/browse/OFBIZ-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kreidenweis updated OFBIZ-3847:
--
Attachment: GenericDelegator.java.diff
This should fix the issue in GenericDelegator. We can't see why not all the
fields should be passed down to store().
> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
> Attachments: GenericDelegator.java.diff
>
>
> The conditions don't work when updating (not creating) entities using the
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
>
> value="N"/>
> value-attr="productInstance"/>
>
> {code}
> The indexProductKeywords service is called anyway when the product is updated
> and the autoCreateKeywords was "N" and stays "N". It works correctly for
> newly created products.
> The problem is in the method GenericDelegator.storeAll(), where unchanged
> field values are not passed down to the store() method. The store method
> calls the ECA engine, which does not receive the unchanged values at all and
> thus cannot evaluate the EECA conditions correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method
Entity ECAs not triggered correctly when using Delegator.storeAll() method
--
Key: OFBIZ-3847
URL: https://issues.apache.org/jira/browse/OFBIZ-3847
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 10.04
Reporter: Martin Kreidenweis
The conditions don't work when updating (not creating) entities using the
Delegator.storeAll() method. E.g. the following condition does not work:
{code}
{code}
The indexProductKeywords service is called anyway when the product is updated
and the autoCreateKeywords was "N" and stays "N". It works correctly for newly
created products.
The problem is in the method GenericDelegator.storeAll(), where unchanged field
values are not passed down to the store() method. The store method calls the
ECA engine, which does not receive the unchanged values at all and thus cannot
evaluate the EECA conditions correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
