I changed log level from DEBUG to INFO on the Apex core for the same
reason a while ago.
Thank you,
Vlad
On 1/15/16 10:51, Chinmay Kolhatkar wrote:
Changing the subject line to have a focused discussion.
I understand that travis is fixing the issue.
But in the meanwhile, I was wondering if there is a better way of
approaching this rather than cutting down the output of tests.
For e.g., changing log level for tests to WARN?
Please share your thoughts.
Thanks,
Chinmay.
On Fri, Jan 15, 2016 at 10:18 PM, Timothy Farkas <[email protected]>
wrote:
Travis limits the log size. There is an issue open to allow overriding the
default but I guess the feature hasn't been added yet.
https://github.com/travis-ci/travis-ci/issues/3865
The only way to reduce the log size I can think of is to reduce the output
of tests. I'll try cutting down on the output of the tests I've added.
Maybe other people can pitch in trimming down their test output.
Thanks,
Tim
On Fri, Jan 15, 2016 at 5:58 AM, Chinmay Kolhatkar <
[email protected]>
wrote:
Hi All,
I've updated the ExpressionEvaluator interface as suggested. The pull
request is updated. Please review the pull request:
https://github.com/apache/incubator-apex-malhar/pull/170
But, the Travis build is failing for this pull request for unknown
reason.
I verified that the the command that is failing in travis is passing in
my
local machine:
This command is *mvn apache-rat:check verify -Dlicense.skip=false
-Pall-modules*
The last log line in Travis build is as follows:
"The log length has exceeded the limit of 4 Megabytes (this usually means
that test suite is raising the same exception over and over).
The build has been terminated."
I checked the Travis log and I could not see any test suite which was
raising any exception over and over.
Can you please suggest how to address Travis build failing issue?
Thanks,
Chinmay.
On Fri, Jan 15, 2016 at 12:15 PM, Tushar Gosavi <[email protected]>
wrote:
looks good, looking forward for an updated pull request
- Tushar.
On Fri, Jan 15, 2016 at 12:03 PM, Timothy Farkas <[email protected]>
wrote:
+1 looks good to me.
Thanks,
Tim
On Thu, Jan 14, 2016 at 10:06 AM, Chinmay Kolhatkar <
[email protected]
wrote:
Considering Tim's suggestiom, I'm thinking about modifying the
interface
in
following way:
So there will be 3 interfaces:
public interface Expression<O>
{
O execute(Object... obj);
}
public interface ExpressionEvaluator
{
<O> ExpressionEvaluator.Expression<O>
createExecutableFunction(String
expression, Class<?> returnType);
<O> ExpressionEvaluator.Expression<O>
createExecutableExpression(String
expression, Class<?> returnType);
void setExpressionParser(ExpressionParser parser);
}
public interface ExpressionParser
{
String convertToCompilableExpression(String expression, Class<?>
returnType, boolean containsReturnStatement);
}
Description of interfaces:
1. Expression interface is the final output which will have
executable
code
of expression.
2. ExpressionEvaluator interface will be implemented for specific
type
if
implementation. For eg. In this case the concrete implementation
will
be
JavaExpressionEvaluator which will evaluate quasi-Java expression
3. ExpressionParser interface will defined how expression need to
be
parsed
and can be plugin to ExpressionEvaluator interface via
setExpressionParser
method.
This way,
1. One can override parsing logic for specific evaluator.
2. Override the expression evaluation logic all together.
3. Sticking to a common interface of ExpressionEvaluator &
Expression
will
make the user code not to change even if parser or evaluator
changes.
Thoughts?
Thanks,
Chinmay.
On Thu, Jan 14, 2016 at 2:17 PM, Chinmay Kolhatkar <
[email protected]>
wrote:
I think think is doable.
I'll take a look.
Thanks,
Chinmay.
On Thu, Jan 14, 2016 at 1:59 PM, Timothy Farkas <
[email protected]
wrote:
Haven't gone though you're PR, so I'm not sure how this would
fit
in.
But
I
think introducing an interface like below, and allowing it to be
set
may
be
sufficient.
public interface ExpressionParser
{
public String convertToJavaExpression(String expression);
}
Thanks,
Tim
On Thu, Jan 14, 2016 at 12:19 AM, Chinmay Kolhatkar <
[email protected]
wrote:
Ah got it. That's a good point. Maybe its good to separate the
parsing
and
compilation part of the evaluation.
And let one override the parsing logic.
I'll see how to incorporate that, but if you have idea about
achieving
it,
please share it.
Thanks,
Chinmay.
On Thu, Jan 14, 2016 at 1:43 PM, Timothy Farkas <
[email protected]>
wrote:
Hey Chinmay,
It is possible the user may want to define a syntax
radically
different
from Java style syntax. I've proposed a syntax similar to
yours
to
one of
our users for expression evaluation but they didn't like it
because
the
syntax needs to be something easily validated by a UI. It
may
be
possible
that the user wants expressions to be sent to an operator as
json,
because
that is easy to parse and validate in javascript:
{"param":"myField1","operation":">","threshold":"1"}
If the syntax is pluggable then an implementation of this
syntax
could be
swapped with with an implementation of the syntax you've
already
provided
without changing operator code.
Thanks,
Tim
On Wed, Jan 13, 2016 at 11:34 PM, Chinmay Kolhatkar <
[email protected]
wrote:
Hi tim,
I agree with you. The expression here we're talking about
is
really
a
quasi-Java expression. One can do anything which java
does.
Only change with java syntax here is how variables are
accessed.
They're by default accessed as ${...}.
But this is also made configurable via a setter property
on
ExpressionEvaluator. The pull request has it.
If this is what you're talking about then this is taken
care
of.
Thanks,
Chinmay.
On Thu, Jan 14, 2016 at 1:00 PM, Timothy Farkas <
[email protected]>
wrote:
Hi Chinmay,
I think this is a very good first implementation. My
only
concern
is
that
people will get caught up in the details of the syntax
for
this
expression
language. I think a way to avoid that is to make the
syntax
pluggable.
For
example is there an interface for expression evaluation
which
can
be
implemented by different syntaxes? This would allow
operators
which
use
expression evaluation to have the syntax configured via
a
property.
That
way if someone discovers a limitation in the syntax down
the
line, a
new
syntax can be introduced without breaking backwards
compatibility
and
without requiring operator code to be changed.
Thanks,
Tim
On Wed, Jan 13, 2016 at 10:52 PM, Chinmay Kolhatkar <
[email protected]
wrote:
Hi All,
I'm working on APEXCORE-1972 which adds support for a
quasi-Java
Expression
Language and its expression evaluator.
All the detailed functionality and design details
along
with
examples
are
present in Jira.
I've summarized the ExpressionEvaluator feature &
Expression
language
below.
The pull request created for this at here:
https://github.com/apache/incubator-apex-malhar/pull/170
Please share your thought on this.
Thanks,
Chinmay.
*Summary of functionality of ExpressionEvaluator:*
1. Support quasi-Java Expression which defines a
single
line
executable
expression
2. Support for quasi-Java expression based function
code,
which
will
be
compiled on the fly and made available for
execution.
3. Should support accessing multiple fields from
multiples
input
POJOs
while addressing the conversion of private
variables
to
public
getter
method for all levels.
4. Should support nested field support
5. quasi-Java expressions should support operands
to
be
mentioned
in
following ways:
- ${input.fieldName}
- Access fieldName via a object name.
- ${fieldName}
- Accessing fieldName directly when a single
object
is
registered
for operation.
- ${input}
- Accessing object variable directly
- ${input.fieldName.internalField}
- Accessing nested fields
6. There should be some predefined function
provided
to
expression
writer which one can directly use in expression for
invoking
certain
functionality.
7. These are simple String based, Date time based
etc
functions.
8. On-need-basic one should be able to easily
update
Expression
Evaluator to easily add new predefined functions to
be
made
available
for
expression writer.
9. User of ExpressionEvaluator should be able to
add
a
custom
method
externally to be made available to in expression.
10. Though operands are defined, placeholder for
the
operand
in
expression should be allowed to be overridden. By
default,
expression
language should support bash type syntax for
operand
-
{…}
11. The library should not introduce any
serialization
related
issues.
12. All the java operators should be supported.
*The examples of quasi-Java Expression:*
- ${inp.field1}
- Will return value of field1 from registered
input
POJO.
- ${inp.field1} + ${inp.field2}
- Will return sum of field1 & field2 from given
POJO
- ${field1} + ${field2}
- Equivalent to above
- ${inpA.field1} > ${inpA.field2} ? ${inpA.field3}
:
${inpB.field3}
- Executes ternary expression and returns value
accordingly.
Works
on
2 POJOs. inpA & inpB are two placeholder
registered
for
given
POJO
with
ExpressionEvaluator library.
- pow(${inpA.field1}, ${inpB.field2})
- Executes pow function coming from
java.lang.Math
library.
This
and
other with lot other basic functions is
available
to
expression
writer out
of the box to use in expression.
- ${inpA.field1} > 0 ? ${inpB.innerPOJO.field3} :
${inpA.innerPOJO.field3}
- Shows how nested POJOs can be accessed in
expression.
The
variables
will evaluate to correct public getter method is
required.
- ${inp.firstname} + “ “ + ${inp.lastname}
- Generate the full name as per given expression
from
firstname
and
lastname field.
- long retVal=1; for (int i=0; ${inpF.value1}; i++)
{retVal =
retVal *
${inpF.value1}; } return retVal;
- This tells a complete method content to
ExpressionEvaluator.
The
library create an executable and compiled method
using
this
expression.
