Re: ‘MapStack’ weirdness.

2018-07-26 Thread Scott Gray
I looked back through an old copy of the pre-ASF repo and found that the
"context" references were added in 2006 and it had something to do with
making MapStack a LocalizedMap for screen/form widget internalization
rendering.  The commit message and a small explanation in the mailing lists
didn't explain that specific addition unfortunately.  Could be that it
isn't used there anymore, at the time freemarker macros weren't used for
widget rendering, so it's possible that a fix in the freemarker render
could remove the need for it.

Regards
Scott

On 21 July 2018 at 17:12, Mathieu Lirzin  wrote:

> Hello Scott,
>
> Scott Gray  writes:
>
> > I think it relates to the "context" variable that is frequently used in
> > groovy data prep scripts for the script output.
> >
> > I'm not in front of a computer, but looking at it in that light may help.
>
> As shown by this snippet from ‘GroovyUtil.java’, the “context” binding
> is added explicitly so it doesn't require the ‘MapStack’ special case
> for the "context" key.  In fact since the context is copied to an
> ‘HashMap’ before being passed to Groovy, the ‘MapStack’ implementation
> is not used at all from Groovy.
>
> --8<---cut here---start->8---
> public static Binding getBinding(Map context, String
> expression) {
> Map vars = new HashMap<>();
> if (context != null) {
> vars.putAll(context);
> if (UtilValidate.isNotEmpty(expression)) {
>   ...;
> }
> vars.put("context", context);
> ...;
> }
> return new Binding(vars);
> }
>
> public static Object runScriptAtLocation(String location, String
> methodName, Map context) throws GeneralException {
> Script script = InvokerHelper.createScript(
> getScriptClassFromLocation(location), getBinding(context));
> Object result = null;
> if (UtilValidate.isEmpty(methodName)) {
> result = script.run();
> } else {
> result = script.invokeMethod(methodName, new Object[] {
> context });
> }
> return result;
> }
> --8<---cut here---end--->8---
>
> What is nice is that the ‘getBinding’ method has a javadoc explaining
> why the “context” binding is added explicitly.  Thanks to Adrian Crum
> (RIP) for providing it.
>
> --8<---cut here---start->8---
> The ‘context’ Map is added to the ‘Binding’ as a variable called
> "context" so that variables can be passed back to the caller.
> --8<---cut here---end--->8---
>
> Thanks for your input.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>


Re: svn commit: r1813640 - in /ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity: GenericDelegator.java GenericEntity.java GenericPK.java GenericValue.java

2018-07-26 Thread Scott Gray
FYI, I think this commit accidentally introduced a weird import into
GenericPK:
import org.apache.sis.internal.jdk7.Objects

probably intended to be java.util.Objects

Regards
Scott

On 28 October 2017 at 15:19,  wrote:

> Author: mbrohl
> Date: Sat Oct 28 15:19:56 2017
> New Revision: 1813640
>
> URL: http://svn.apache.org/viewvc?rev=1813640=rev
> Log:
> Improved: Fixing defects reported by FindBugs, package
> org.apache.ofbiz.entity.
> (OFBIZ-9716)
>
> I modified the patch slightly.
>
> Thanks Julian Leichert for reporting and providing the patch.
>
> Modified:
> ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericDelegator.java
> ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericEntity.java
> ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericPK.java
> ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericValue.java
>
> Modified: ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericDelegator.java
> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
> framework/entity/src/main/java/org/apache/ofbiz/entity/
> GenericDelegator.java?rev=1813640=1813639=1813640=diff
> 
> ==
> --- ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericDelegator.java (original)
> +++ ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericDelegator.java Sat Oct 28 15:19:56
> 2017
> @@ -114,9 +114,9 @@ public class GenericDelegator implements
>  protected EntityCrypto crypto = null;
>
>  /** A ThreadLocal variable to allow other methods to specify a user
> identifier (usually the userLoginId, though technically the Entity Engine
> doesn't know anything about the UserLogin entity) */
> -protected static ThreadLocal> userIdentifierStack = new
> ThreadLocal>();
> +private static final ThreadLocal> userIdentifierStack =
> new ThreadLocal>();
>  /** A ThreadLocal variable to allow other methods to specify a
> session identifier (usually the visitId, though technically the Entity
> Engine doesn't know anything about the Visit entity) */
> -protected static ThreadLocal> sessionIdentifierStack =
> new ThreadLocal>();
> +private static final ThreadLocal> sessionIdentifierStack
> = new ThreadLocal>();
>
>  private boolean testMode = false;
>  private boolean testRollbackInProgress = false;
> @@ -786,7 +786,7 @@ public class GenericDelegator implements
>  value.setDelegator(this);
>
>  // if audit log on for any fields, save new value with no old
> value because it's a create
> -if (value != null && 
> value.getModelEntity().getHasFieldWithAuditLog())
> {
> +if (value.getModelEntity().getHasFieldWithAuditLog()) {
>  createEntityAuditLogAll(value, false, false);
>  }
>
> @@ -796,7 +796,7 @@ public class GenericDelegator implements
>  if (testMode) {
>  storeForTestRollback(new 
> TestOperation(OperationType.INSERT,
> value));
>  }
> -} catch (GenericEntityException e) {
> +} catch (IllegalStateException | GenericEntityException e) {
>  // see if this was caused by an existing record before
> resetting the sequencer and trying again
>  // NOTE: use the helper directly so ECA rules, etc won't
> be run
>
> @@ -843,7 +843,7 @@ public class GenericDelegator implements
>
>  TransactionUtil.commit(beganTransaction);
>  return value;
> -} catch (Exception e) {
> +} catch (GenericEntityException e) {
>  String entityName = value != null ? value.getEntityName() :
> "invalid Generic Value";
>  String errMsg = "Failure in createSetNextSeqId operation for
> entity [" + entityName + "]: " + e.toString() + ". Rolling back
> transaction.";
>  Debug.logError(e, errMsg, module);
> @@ -877,7 +877,7 @@ public class GenericDelegator implements
>  value.setDelegator(this);
>
>  // if audit log on for any fields, save new value with no old
> value because it's a create
> -if (value != null && 
> value.getModelEntity().getHasFieldWithAuditLog())
> {
> +if (value.getModelEntity().getHasFieldWithAuditLog()) {
>  createEntityAuditLogAll(value, false, false);
>  }
>
> @@ -900,7 +900,7 @@ public class GenericDelegator implements
>
>  TransactionUtil.commit(beganTransaction);
>  return value;
> -} catch (Exception e) {
> +} catch (IllegalStateException | GenericEntityException e) {
>  String errMsg = "Failure in create operation for entity [" +
> (value != null ? 

Re: Gradle ‘gretty’ Plugin

2018-07-26 Thread Mathieu Lirzin
Hello James,

James Yong  writes:

> Have you looked into http://dcevm.github.io/ ?
>
> No comment about gretty as I haven't tried.

I didn't know about it.  I will take a look.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37


Re: Gradle ‘gretty’ Plugin

2018-07-26 Thread James Yong
Hi Mathieu,

Have you looked into http://dcevm.github.io/ ?

No comment about gretty as I haven't tried.

Regards,
James Yong

On 2018/07/26 09:08:44, Mathieu Lirzin  wrote: 
> Hello,
> 
> Being a bit frustrated by the slowness of having to stop/compile/restart
> OFBiz manually each time a java file is changed, I have been searching
> for a way to make Java code hot-deployable, meaning recompiling and
> redeploying Java classes each time a ‘.java’ file is saved.
> 
> The ‘gretty’ Gradle plugin seems to provide such feature [1][2].
> 
> I would like to know if somebody has already tried to integrate it in
> OFBiz build system? and if there is any OFBiz singularitiy preventing
> its use?
> 
> Thanks.
> 
> [1] https://guides.gradle.org/building-java-web-applications/
> [2] https://akhikhl.github.io/gretty-doc/Hot-deployment.html
> 
> -- 
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
> 


Re: Gradle ‘gretty’ Plugin

2018-07-26 Thread Taher Alkhateeb
Yes agreed Michael. This is a "someday" to do item.

On Thu, Jul 26, 2018, 1:53 PM Michael Brohl 
wrote:

> Hi Pradhan, Taher,
>
> I think this would be a huge undertaking and I am not sure if this would
> be a project goal for the near future.
>
> We have many fields of action which should have more focus like UI,
> functionality, documentation etc..
>
> So yes, nice goal but more on the long view...
>
> Regrds,
>
> Michael
>
>
> Am 26.07.18 um 11:27 schrieb Yash Sharma:
> > Hello Mathieu,
> >
> > I have tried jRebel link: https://zeroturnaround.com/software/jrebel/
> >   with IntelliJ.
> >
> > +1 Taher for the change in architecture from a single huge monolithic to
> > some microservice hot swap (dynamic loading) flexible architecture.
> >
> >
> > Thanks & Regards,
> > Pradhan Yash Sharma
> >
> > On Thu, Jul 26, 2018 at 2:38 PM, Mathieu Lirzin <
> mathieu.lir...@nereide.fr>
> > wrote:
> >
> >> Hello,
> >>
> >> Being a bit frustrated by the slowness of having to stop/compile/restart
> >> OFBiz manually each time a java file is changed, I have been searching
> >> for a way to make Java code hot-deployable, meaning recompiling and
> >> redeploying Java classes each time a ‘.java’ file is saved.
> >>
> >> The ‘gretty’ Gradle plugin seems to provide such feature [1][2].
> >>
> >> I would like to know if somebody has already tried to integrate it in
> >> OFBiz build system? and if there is any OFBiz singularitiy preventing
> >> its use?
> >>
> >> Thanks.
> >>
> >> [1] https://guides.gradle.org/building-java-web-applications/
> >> [2] https://akhikhl.github.io/gretty-doc/Hot-deployment.html
> >>
> >> --
> >> Mathieu Lirzin
> >> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
> >>
>
>
>


Re: Gradle ‘gretty’ Plugin

2018-07-26 Thread Michael Brohl

Hi Pradhan, Taher,

I think this would be a huge undertaking and I am not sure if this would 
be a project goal for the near future.


We have many fields of action which should have more focus like UI, 
functionality, documentation etc..


So yes, nice goal but more on the long view...

Regrds,

Michael


Am 26.07.18 um 11:27 schrieb Yash Sharma:

Hello Mathieu,

I have tried jRebel link: https://zeroturnaround.com/software/jrebel/
  with IntelliJ.

+1 Taher for the change in architecture from a single huge monolithic to
some microservice hot swap (dynamic loading) flexible architecture.


Thanks & Regards,
Pradhan Yash Sharma

On Thu, Jul 26, 2018 at 2:38 PM, Mathieu Lirzin 
wrote:


Hello,

Being a bit frustrated by the slowness of having to stop/compile/restart
OFBiz manually each time a java file is changed, I have been searching
for a way to make Java code hot-deployable, meaning recompiling and
redeploying Java classes each time a ‘.java’ file is saved.

The ‘gretty’ Gradle plugin seems to provide such feature [1][2].

I would like to know if somebody has already tried to integrate it in
OFBiz build system? and if there is any OFBiz singularitiy preventing
its use?

Thanks.

[1] https://guides.gradle.org/building-java-web-applications/
[2] https://akhikhl.github.io/gretty-doc/Hot-deployment.html

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Gradle ‘gretty’ Plugin

2018-07-26 Thread Michael Brohl

Hi Mathieu,

hot code replacement works fine in Eclipse if you have updated the 
Eclipse classpath through ./gradlew eclipse.


You can run/debug OFBiz in Eclipse without problems mostly. Sometimes 
you have to restart, depending of the changes.


For me this is working sufficiently.

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 26.07.18 um 11:08 schrieb Mathieu Lirzin:

Hello,

Being a bit frustrated by the slowness of having to stop/compile/restart
OFBiz manually each time a java file is changed, I have been searching
for a way to make Java code hot-deployable, meaning recompiling and
redeploying Java classes each time a ‘.java’ file is saved.

The ‘gretty’ Gradle plugin seems to provide such feature [1][2].

I would like to know if somebody has already tried to integrate it in
OFBiz build system? and if there is any OFBiz singularitiy preventing
its use?

Thanks.

[1] https://guides.gradle.org/building-java-web-applications/
[2] https://akhikhl.github.io/gretty-doc/Hot-deployment.html






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Gradle ‘gretty’ Plugin

2018-07-26 Thread Yash Sharma
Hello Mathieu,

I have tried jRebel link: https://zeroturnaround.com/software/jrebel/
 with IntelliJ.

+1 Taher for the change in architecture from a single huge monolithic to
some microservice hot swap (dynamic loading) flexible architecture.


Thanks & Regards,
Pradhan Yash Sharma

On Thu, Jul 26, 2018 at 2:38 PM, Mathieu Lirzin 
wrote:

> Hello,
>
> Being a bit frustrated by the slowness of having to stop/compile/restart
> OFBiz manually each time a java file is changed, I have been searching
> for a way to make Java code hot-deployable, meaning recompiling and
> redeploying Java classes each time a ‘.java’ file is saved.
>
> The ‘gretty’ Gradle plugin seems to provide such feature [1][2].
>
> I would like to know if somebody has already tried to integrate it in
> OFBiz build system? and if there is any OFBiz singularitiy preventing
> its use?
>
> Thanks.
>
> [1] https://guides.gradle.org/building-java-web-applications/
> [2] https://akhikhl.github.io/gretty-doc/Hot-deployment.html
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>


Re: Gradle ‘gretty’ Plugin

2018-07-26 Thread Taher Alkhateeb
Hmm, at a quick glance, I think this will not work.

The problem is that OFBiz is currently designed as a "collection" of
webapps each loaded separately but housed in one jar file that also
includes an embedded web server. So you have to alter the Catalina
Container or something like that to perhaps be able to incorporate hot
plugging.

If you like a suggestion, I would say we probably need to re-visit the
architecture of the whole web deployment style we currently have (The
Servlet Container, the Servlets, The Webapps, Tomcat, the whole
thing). We need to make a more flexible architecture that can easily
deploy as a stand-alone webapp that you can put on any servlet
container. Then all such plugins and tools would be easier to use.

On Thu, Jul 26, 2018 at 12:08 PM, Mathieu Lirzin
 wrote:
> Hello,
>
> Being a bit frustrated by the slowness of having to stop/compile/restart
> OFBiz manually each time a java file is changed, I have been searching
> for a way to make Java code hot-deployable, meaning recompiling and
> redeploying Java classes each time a ‘.java’ file is saved.
>
> The ‘gretty’ Gradle plugin seems to provide such feature [1][2].
>
> I would like to know if somebody has already tried to integrate it in
> OFBiz build system? and if there is any OFBiz singularitiy preventing
> its use?
>
> Thanks.
>
> [1] https://guides.gradle.org/building-java-web-applications/
> [2] https://akhikhl.github.io/gretty-doc/Hot-deployment.html
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37


Gradle ‘gretty’ Plugin

2018-07-26 Thread Mathieu Lirzin
Hello,

Being a bit frustrated by the slowness of having to stop/compile/restart
OFBiz manually each time a java file is changed, I have been searching
for a way to make Java code hot-deployable, meaning recompiling and
redeploying Java classes each time a ‘.java’ file is saved.

The ‘gretty’ Gradle plugin seems to provide such feature [1][2].

I would like to know if somebody has already tried to integrate it in
OFBiz build system? and if there is any OFBiz singularitiy preventing
its use?

Thanks.

[1] https://guides.gradle.org/building-java-web-applications/
[2] https://akhikhl.github.io/gretty-doc/Hot-deployment.html

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37