Re: Unit testing for a custom module

[Carsten Schinzer]

Hello Gaetan,


Apologies for the late reply. No, the issue is not solved.
I shall have time towards end of this week to set you access up and let you
know.

Thanks a mill to offer help.
Warm regards


Carsten


---


Dr. Carsten Schinzer

*Inhaber*


t +49 89 88569642 | f +49 89 99964059 | m +49 159 05269462

DCS Verkaufssysteme

Gerner Str. 27 | 80638 München | Germany


Gaetan  schrieb am Do. 4. Juli 2024 um 09:55:

> Hi Carsten, did you manage to solve your problem ?
>
> Regards, Gaetan
>
> On 6/21/24 14:45, Gaetan wrote:
> > Hi,
> >
> > I created a public gitlab account account so that i can help you, with
> > this address : (mr.plop.p...@netcourrier.com)
> > If you feel confortable with it, you can share with me the repo link
> > (read only, of course).
> >
> > Best regards
> > Gaetan
> >
> > PS: i don't know if there are any community rules for this kind of
> > cases ?
> >
> > On 6/21/24 11:17, Carsten Schinzer wrote:
> >> Hi Gaetan,
> >>
> >> Thanks to get back to me. I see no change - all the things you
> >> applied I already did.
> >> I also added your test case to the code and ran that locally - the
> >> test is obviously not found.
> >>
> >> It might have to do with the fact that I prefer JUnit 5 because of
> >> its advanced parametrized testing features?
> >> I can give you access to the code repo if you have a Gitlab account.
> >>
> >> When running tests locally, I do not see any test reports for my
> >> classes, so this is the indicator I am using.
> >> Also, I have test cases that should fail with the current code state.
> >>
> >> So situation is unchanged unfortunately.
> >> Warm regards
> >>
> >>
> >> Carsten
> >>
> >>> Am 20.06.2024 um 16:58 schrieb Gaetan :
> >>>
> >>> Hi Carsten, do you have any updates on your case ?
> >>>
> >>> Regards,
> >>>
> >>> Gaetan
> >>>
> >>> On 6/11/24 09:58, Gaetan wrote:
> >>>> Hello Carsten.
> >>>>
> >>>> I set up a very small example plugin that i tested myself localy.
> >>>> Could you please reproduce the steps below ?
> >>>>
> >>>> - get ofbiz framework from apache repo
> >>>> (https://github.com/apache/ofbiz-framework)
> >>>>
> >>>> - checkout trunk on ofbiz framework
> >>>>
> >>>> - get example plugin and set it up inside plugins
> >>>> (https://github.com/gtchaboussie/ofbiz-demo-test-plugin)
> >>>>
> >>>> at the ofbiz root location, run `./gradlew test`. The build should
> >>>> fail (this means the test in the plugin is runned) with this error:
> >>>>
> >>>> ```
> >>>>
> >>>> org.test.TestClass > test FAILED
> >>>>  java.lang.AssertionError at TestClass.java:9
> >>>>
> >>>> ```
> >>>>
> >>>> This gives you a template or example of a unit test.
> >>>>
> >>>> As you can see, you should not have to update anything on the base
> >>>> framework for your tests yo be runned.
> >>>>
> >>>> Also, could you share your OS and OFBiz version ?
> >>>>
> >>>> Regards,
> >>>>
> >>>> Gaetan
> >>>>
> >>>> On 6/10/24 19:13, Carsten Schinzer wrote:
> >>>>> Hello Gaetan,
> >>>>>
> >>>>>
> >>>>> I do all this as you describe, source path for tests is as
> >>>>> required and
> >>>>> tests are properly annotated.
> >>>>> The main difference is that this is not a unit test out of a
> >>>>> framework, but
> >>>>> unit tests sitting in a plugin component.
> >>>>>
> >>>>> I so not see any traces of the framework stepping into my test
> >>>>> directories
> >>>>> when executing test (I ran .gradlew test —info to get more info).
> >>>>>
> >>>>> IMO something is probably missing in my build.gradle:
> >>>>>
> >>>>> /*…*/
> >>>>>
> >>>>> dependencies {
> >>>>>   // information: the ofbiz:release22.01 is on
> >>>>> jakarta.ws.rs:jakarta.ws.rs-api:2.1.6
> >>>&

Re: Unit testing for a custom module

[Carsten Schinzer]

Hi Gaetan,

Thanks to get back to me. I see no change - all the things you applied I 
already did.
I also added your test case to the code and ran that locally - the test is 
obviously not found.

It might have to do with the fact that I prefer JUnit 5 because of its advanced 
parametrized testing features?
I can give you access to the code repo if you have a Gitlab account.

When running tests locally, I do not see any test reports for my classes, so 
this is the indicator I am using.
Also, I have test cases that should fail with the current code state.

So situation is unchanged unfortunately.
Warm regards


Carsten

> Am 20.06.2024 um 16:58 schrieb Gaetan :
> 
> Hi Carsten, do you have any updates on your case ?
> 
> Regards,
> 
> Gaetan
> 
> On 6/11/24 09:58, Gaetan wrote:
>> Hello Carsten.
>> 
>> I set up a very small example plugin that i tested myself localy. Could you 
>> please reproduce the steps below ?
>> 
>> - get ofbiz framework from apache repo 
>> (https://github.com/apache/ofbiz-framework)
>> 
>>- checkout trunk on ofbiz framework
>> 
>> - get example plugin and set it up inside plugins 
>> (https://github.com/gtchaboussie/ofbiz-demo-test-plugin)
>> 
>> at the ofbiz root location, run `./gradlew test`. The build should fail 
>> (this means the test in the plugin is runned) with this error:
>> 
>> ```
>> 
>> org.test.TestClass > test FAILED
>> java.lang.AssertionError at TestClass.java:9
>> 
>> ```
>> 
>> This gives you a template or example of a unit test.
>> 
>> As you can see, you should not have to update anything on the base framework 
>> for your tests yo be runned.
>> 
>> Also, could you share your OS and OFBiz version ?
>> 
>> Regards,
>> 
>> Gaetan
>> 
>> On 6/10/24 19:13, Carsten Schinzer wrote:
>>> Hello Gaetan,
>>> 
>>> 
>>> I do all this as you describe, source path for tests is as required and
>>> tests are properly annotated.
>>> The main difference is that this is not a unit test out of a framework, but
>>> unit tests sitting in a plugin component.
>>> 
>>> I so not see any traces of the framework stepping into my test directories
>>> when executing test (I ran .gradlew test —info to get more info).
>>> 
>>> IMO something is probably missing in my build.gradle:
>>> 
>>> /*…*/
>>> 
>>> dependencies {
>>>  // information: the ofbiz:release22.01 is on
>>> jakarta.ws.rs:jakarta.ws.rs-api:2.1.6
>>>  pluginLibsCompile 'org.glassfish.jersey.inject:jersey-hk2:2.31'
>>>  pluginLibsCompile
>>> 'org.glassfish.jersey.containers:jersey-container-servlet:2.31'
>>>  pluginLibsCompile
>>> 'org.glassfish.jersey.media:jersey-media-json-jackson:2.31'
>>>  pluginLibsCompile 'javax.json:javax.json-api:1.1.4'
>>>  pluginLibsCompile 'jakarta.inject:jakarta.inject-api:2.0.1'
>>>  pluginLibsCompile 'jakarta.ws.rs:jakarta.ws.rs-api:2.1.6'
>>>  pluginLibsCompile 
>>> 'com.fasterxml.jackson.core:jackson-annotations:2.16.1'
>>>  pluginLibsCompile 'com.fasterxml.jackson.core:jackson-core:2.16.1'
>>>  pluginLibsCompile 'com.fasterxml.jackson.core:jackson-databind:2.16.1'
>>>  pluginLibsCompile
>>> 'com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.16.1'
>>>  // Swagger Annotations for OpenAPI
>>>  pluginLibsCompile 'io.swagger.core.v3:swagger-annotations:2.2.20'
>>>  // Swagger JAX-RS Integration for OpenAPI
>>>  pluginLibsCompile 'io.swagger.core.v3:swagger-jaxrs2:2.2.20'
>>>  // Swagger UI
>>>  pluginLibsCompile 'org.webjars:swagger-ui:4.1.3'
>>>  // Junit core, api and parameterization
>>>  pluginLibsCompile 'org.junit.jupiter:junit-jupiter:5.10.0'
>>>  pluginLibsCompile 'org.junit.jupiter:junit-jupiter-api:5.10.0'
>>>  pluginLibsCompile 'org.junit.jupiter:junit-jupiter-params:5.10.0'
>>> }
>>> 
>>> task install {
>>>  doLast {
>>>  // Install logic for this plugin
>>>  }
>>> }
>>> 
>>> task uninstall {
>>>  doLast {
>>>  // uninstall logic for this plugin
>>>  }
>>> }
>>> 
>>> 
>>> I have dependencies on JUnit 5 since I want to use the ParameterizedTest
>>> feature available there. Maybe that is the issue. I also cannot find a
>>> passing build when stating these dependencies as pluginCompileOnly either.

Re: Unit testing for a custom module

[Carsten Schinzer]

Hello Gaetan


Thanks indeed for your efforts!This is what I am doing except the the XML 
Schema here https://ofbiz.apache.org/dtds/test-suite.xsd
Complains when I do not add test-case elements, which I did. But even without 
them that does not change the picture.

I am running on MacOS 14.5 (Sonoma) and observe the same in GitLab Travis CI 
runs (openjdk:17-jdk image).
OfBiz release22.01 (not trunk).
Locally I have sym-linked the plugin code into the plugins folder. In gitlab-ci 
I copy the plugin files into the OfBiz plugins directory.

I am going to play bit with you plugin to see whether in principle this works 
on my machine this evening.
I shall then let you know.

Warm regards & thanks again!


Carsten


> Am 11.06.2024 um 09:58 schrieb Gaetan :
> 
> ld you share your OS and OFBiz vers

Re: Unit testing for a custom module

[Carsten Schinzer]

Hello Gaetan,


I do all this as you describe, source path for tests is as required and
tests are properly annotated.
The main difference is that this is not a unit test out of a framework, but
unit tests sitting in a plugin component.

I so not see any traces of the framework stepping into my test directories
when executing test (I ran .gradlew test —info to get more info).

IMO something is probably missing in my build.gradle:

/*…*/

dependencies {
// information: the ofbiz:release22.01 is on
jakarta.ws.rs:jakarta.ws.rs-api:2.1.6
pluginLibsCompile 'org.glassfish.jersey.inject:jersey-hk2:2.31'
pluginLibsCompile
'org.glassfish.jersey.containers:jersey-container-servlet:2.31'
pluginLibsCompile
'org.glassfish.jersey.media:jersey-media-json-jackson:2.31'
pluginLibsCompile 'javax.json:javax.json-api:1.1.4'
pluginLibsCompile 'jakarta.inject:jakarta.inject-api:2.0.1'
pluginLibsCompile 'jakarta.ws.rs:jakarta.ws.rs-api:2.1.6'
pluginLibsCompile 'com.fasterxml.jackson.core:jackson-annotations:2.16.1'
pluginLibsCompile 'com.fasterxml.jackson.core:jackson-core:2.16.1'
pluginLibsCompile 'com.fasterxml.jackson.core:jackson-databind:2.16.1'
pluginLibsCompile
'com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.16.1'
// Swagger Annotations for OpenAPI
pluginLibsCompile 'io.swagger.core.v3:swagger-annotations:2.2.20'
// Swagger JAX-RS Integration for OpenAPI
pluginLibsCompile 'io.swagger.core.v3:swagger-jaxrs2:2.2.20'
// Swagger UI
pluginLibsCompile 'org.webjars:swagger-ui:4.1.3'
// Junit core, api and parameterization
pluginLibsCompile 'org.junit.jupiter:junit-jupiter:5.10.0'
pluginLibsCompile 'org.junit.jupiter:junit-jupiter-api:5.10.0'
pluginLibsCompile 'org.junit.jupiter:junit-jupiter-params:5.10.0'
}

task install {
doLast {
// Install logic for this plugin
}
}

task uninstall {
doLast {
// uninstall logic for this plugin
}
}


I have dependencies on JUnit 5 since I want to use the ParameterizedTest
feature available there. Maybe that is the issue. I also cannot find a
passing build when stating these dependencies as pluginCompileOnly either.

So almost certainly this is rather a hook into the test executionon grade
side, WDYT?

Thanks for your comments so far!
Warm regards


Carsten


Am 10.06.2024 um 17:54 schrieb Gaetan :

Hi again,

After some research, it seems you should follow this kind of structure for
your unit tests :

https://github.com/apache/ofbiz-framework/blob/7c2487bc3f1a6ec472585c27d7ceb5ca19471387/build.gradle#L259

So you should setup your tests at the right package (either groovy or java
according to build instructions) and add the test decorator like this
example

https://github.com/apache/ofbiz-framework/blob/7c2487bc3f1a6ec472585c27d7ceb5ca19471387/framework/base/src/test/java/org/apache/ofbiz/base/container/ComponentContainerTest.java#L63

Please let me know if you encounter any more trouble !

Regards

Gaetan

On 6/10/24 16:55, Carsten Schinzer wrote:

… and after some more assertions, I can add:
I have verified the paths to all my test suites to point to the correct
Java classes.
I do not find any error in the test logs.
I do find the classes in the build/classes/java/test directory.
I do not find related test results at all.

An hint you can give me is appreciated!
Warm regards


Carsten

Am 10.06.2024 um 15:47 schrieb Carsten Schinzer <
cars...@dcs-verkaufssysteme.de>:

Hello,


You mean like this:

Re: Unit testing for a custom module

[Carsten Schinzer]

… and after some more assertions, I can add:
I have verified the paths to all my test suites to point to the correct Java 
classes.
I do not find any error in the test logs.
I do find the classes in the build/classes/java/test directory.
I do not find related test results at all.

An hint you can give me is appreciated!
Warm regards


Carsten

> Am 10.06.2024 um 15:47 schrieb Carsten Schinzer 
> :
> 
> Hello,
> 
> 
> You mean like this:
> 
> 

Re: Unit testing for a custom module

[Carsten Schinzer]

Hello,


You mean like this:

Unit testing for a custom module

[Carsten Schinzer]

Hello all,


I am looking for a reference to integrate my plugin unit tests into the test 
run of OfBiz, i.e. when I run

> ./gradlew test

My defined test suite should be included and executed.

I did browse the official plugin repository and found no reference.

First issue: how to define the hook into the test task in build.gradle.
Second: Ho to make sure, the build.gradle dependencies on JUnit are only loaded 
for test and not packaged.

Does anyone have an example possibly how to do this.

Thanks & warm regards


Carsten

Re: Docker Image build from Release 22.01 does not start up - JAVA_HOME issues?

[Carsten Schinzer]

Thanks for your reply, Eugen,


I am still investigating and come to understand that this might be a 
side-effect of gitlab-ci deciding too early to move ahead; when switching on 
full logs I still see startup sequence running on the container when gitlab 
already executes the tests I wrote.

So I tend to believe this is nothing to do with the image as such as things 
stand now.

I would have written an update later (and will do once I am clearer), but 
wanted to react to your post to avoid others spending too much time on what 
right now does not look like a case for OfBiz.

On your remark towards u...@ofbiz.apache.org: Point taken - I was not sure 
myself and hope to catch the experts with deeper insights rather here.

Thanks again and warm regards


Carsten 

> Am 05.01.2024 um 20:47 schrieb Eugen Stan :
> 
> Hi Carsten,
> 
> I tried the following and it worked:
> 
> git checkout release22.01
> DOCKER_BUILDKIT=1 docker build --tag ofbiz-docker . --load
> docker run -it -p 8443:8443 ofbiz-docker
> 
> Please try the commands locally, and if it does not work, post the full list 
> of commands.
> There is a large set of options in the document.
> 
> I am on
> 
> commit 4fa1b5c4a229eae4456275aaf4e6447a8d215b88 (HEAD -> release22.01, 
> origin/release22.01)
> Author: Jacques Le Roux  <mailto:jacques.le.r...@les7arts.com>>
> Date:   Thu Jan 4 12:12:42 2024 +0100
> 
>Fixed: Replace SvnCheckout in Gradle (OFBIZ-12868)
> 
> I believe the question should be on u...@ofbiz.apache.org 
> <mailto:u...@ofbiz.apache.org>.
> 
> Regards,
> Eugen
> 
> 
> La 05.01.2024 17:45, Carsten Schinzer a scris:
>> Hello all and Happy New Year,
>> During my CI/CD pipeline run I do build a docker image as per the official 
>> document here:
>> ofbiz-framework.png
>> ofbiz-framework/DOCKER.md at release22.01 · apache/ofbiz-framework 
>> <https://github.com/apache/ofbiz-framework/blob/release22.01/DOCKER.md>
>> github.com <http://github.com/> 
>> <https://github.com/apache/ofbiz-framework/blob/release22.01/DOCKER.md>
>> <https://github.com/apache/ofbiz-framework/blob/release22.01/DOCKER.md>
>> I do not manipulate any config or code from the framework repo. My pipeline 
>> job clones it (release 22.01), deploys my custom component and then runs the 
>> docker build command.
>> Now when attempting to run as a sidecar on a later stage in the pipeline in 
>> order to test some REST API that my custom component exposes, the container 
>> does not start up properly.
>> When I download and run the container locally using the exact command given 
>> on the document above, it runs through preliminary steps but then exits with 
>> the following error:
>> -
>> (…)
>> + /ofbiz/bin/ofbiz --load-data readers=seed,seed-initial
>> ERROR: JAVA_HOME is set to an invalid directory: /opt/java/openjdk
>> Please set the JAVA_HOME variable in your environment to match the
>> location of your Java installation.
>> -
>> I wonder why that is the case, as the JAVA_HOME should be the default path 
>> taken from the parent image (eclipse-temurin). On the image’s PATH variable, 
>> the java binary path is correctly added:
>> /opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
>> Any advice that anyone has on this matter will be highly appreciated.
>> Warm regards
>> Carsten
> 
> -- 
> Eugen Stan
> 
> +40770 941 271  / https://www.netdava.com <https://www.netdava.com/>

OfBiz developer guideline to set up version control and dev environment for plugin development

[Carsten Schinzer]

Hi all,



While I have understood the OfBiz createPlugin Gradle task I fail to see how I 
would separate concerns in order to achieve version control for my plugin code 
vs the ofbiz framework version control.

Namely I have difficulty to configure a proper development environment where I 
would work on the plugin standalone.

My current workaround is to manage git version control in a separate project 
and include that project code via symlink into a clone of ofbiz framework 
within the plugins folder.

I think, the dev guide does not address this practical issue.

Is there any practice you can recommend? Maybe documented? Else is it possibly 
worth to document a common and recommended practice on the Confluence space?

Interested in your views!
Warm regards


Carsten

Re: I'm working on an OFBiz helm chart for kubernetes

[Carsten Schinzer]

Hello Eugen and all,


I like the initiative and I am convinced this is a forward-looking approach.

As you have read in the comment from Pierre the hurdle to overcome is the
external dependency injection of e.g. database connectivity as
configuration maps at runtime. In my company in Kubernetes stacks we are
solving that by maintaining a config map of RDBMS connectivity per
application stage and region and deploy that. The app then reads the config
information at container startup.

When taking the regular OFBiz approach, though, you would need to know at
build time to which stage (Staging, production, Development) and which
region you are going to deploy, which will be a bit of an overkill if you
want to leverage the full flexibility of a cloud-based deployment which
typically comes with variance on DB connection strings.

Alternatively, you would need to unpackage certain release artifacts and
rewrite them as part of the deployment process, which might be an
antipattern on Helm.

Could that be overcome and dynamic DB connection string be used somehow?
Warm regards


Carsten

---


Dr. Carsten Schinzer

*Inhaber*


t +49 89 88569642 | f +49 89 99964059 | m +49 159 05269462

DCS Verkaufssysteme

Gerner Str. 27 | 80638 München | Germany


Am Do., 1. Juli 2021 um 10:57 Uhr schrieb Pierre Smits <
pierre.sm...@gmail.com>:

> Hi Ioan,
>
> My apologies for the late reaction.
>
> IMO we can forget about the Derby route for this. Derby is not production
> grade, and often adopters/implementers already have their preferred RDBMS
> for production in play or decided upon.  Configuration of such is the
> entityengine.xml file, and deployment of such for the various
> environments/instances like UAT or PROD can easily managed and deployed via
> VCS.
>
> Best regards,
> Pierre Smits
>
>
> On Sun, May 9, 2021 at 9:13 PM Eugen Stan  wrote:
>
> >
> >
> > Hello,
> >
> > NOTE: I previously sent this email from an un-subscribed email address,
> > please ignore that one.
> >
> > I'm working on a Helm chart for OFBiz
> > https://github.com/ieugen/charts/tree/main/ofbiz .
> >
> > The goal is to have OFBiz running in Kubernetes.
> >
> > Right now it's a rough start: it starts OFBiz with Derby and that's
> > about it.
> >
> > I'll keep pushing updates as soon as I have them.
> >
> > I'm interested in your feedback.
> > If you plan on testing it and using it let me know.
> > I do accept and encourage collaboration.
> >
> > If this is interesting I might push it upstream but it uses the binary
> > build of OFBiz in Docker.
> >
> >
> > I'm using docker images built from trunk on jdk-11.
> > There are amd64 and arm64 (Raspberry PI4) images.
> >
> > Some issues that need solving are the many configuration files that
> > OFBiz has.
> >
> > This details creates a lot of configuration when deploying in Docker /
> > Kubernetes as they need to be mounted in a volume with many entries or
> > multiple volumes.
> >
> > There are many potential solutions to this but it boils down to:
> > * It would be nice to load max 1-2 or 3 configuration file with multiple
> > sections instead of the currently many configs split over the code base.
> > * It would be nice to support configuration (overwrite) via ENV vars for
> > some things like DB connection.
> >
> >
> > Regards.
> > Eugen
> >
>

Re: Behavior of Groovy vs JUnit tests with test data

[Carsten Schinzer]

Hello Jacques,


Thanks for the pointer.

My issue is that I find the XML test cases not good enough as e.g. the 
updateCustRequest service has special behaviors when cancelling or adding 
stories to a custRequest which are currently not covered by the test in XML.
Similar for the transitions between custRequestStatusIds some are forbidden and 
some are not and the test cases did not cover either.

The issue is really that in Groovy when starting from a given data load, the 
data is not refreshed/reset after a test case is run and hence I decided to do 
the testing of services in full and plain JUnit. Others apparently have decided 
the same.

In the subtasks you pointed me to, the problem is circumvented by creating the 
data in a common method before running a test against it. So the data load does 
not occur via the tested location. I wanted to re-use existing test data for 
custRequest.

If you tell me that the intent is to also get rid of the test data defined in 
the tested, then I would be on the wrong track and need to change my code to be 
like the one you pointed me to. Is there any decision made to also get rid of 
the test data loads when migrating minilang to groovy?

Warm regards


Carsten

PS: I also find it a pity that the JIRA tickets that are distributed are 
already subtasks in Stories instead of Stories in Epics. It disallows me to 
track the work done in sufficient detail other than commenting on the subtask. 
Do you know why that has been done like this? I should possibly rather discuss 
with Pierre Smits I guess?


> Am 08.09.2020 um 11:54 schrieb Jacques Le Roux :
> 
> Hi Carsten,
> 
> Did you have a look at the WIP under 
> https://issues.apache.org/jira/browse/OFBIZ-11232 and how it's done in 
> subtasks?
> 
> Jacques
> 
> Le 03/09/2020 à 13:43, Carsten Schinzer a écrit :
>> Hi all,
>> 
>> 
>> I did find and try the following from google search:
>> 
>> - wrap all the tests in a class
>> - tag the class with @RunWith(SpringRunner.class)
>> - tag every method that manipulates the entity data with 
>> @DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
>> 
>> This has NOT been successful, hence a strong indication that running the 
>> cases in Groovy will make entity data manipulations to be sticky and not 
>> reverted for the subsequent test case run.
>> I am going to rework my cases to run as JUnit test cases in a Java class.
>> 
>> Warm regards
>> 
>> 
>> Carsten
>> 
>>> Am 03.09.2020 um 13:13 schrieb Carsten Schinzer 
>>> :
>>> 
>>> Hi everyone,
>>> 
>>> 
>>> Recently, I did find that test cases actually are much easier to write in 
>>> Groovy and hence I started doing that, but now I stumble across the fact 
>>> that some of the Groovy tests seem to find changes applied to entities from 
>>> previous tests. The behavior is the following:
>>> 
>>> - I load the test data with instructions given in the tested XML
>>> - I manipulate data in the first test data, e.g. a status on an entity
>>> - when I run the next test case I do not get the originally loaded entity 
>>> but the manipulated one from the previous test
>>> 
>>> This is different from JUnit in Java where the entities seem to exist as 
>>> loaded from the testdata XML with every new test case.
>>> It would obviously mean that I we need to implement my testing in JUnit 
>>> (Java) rather when we want extensive testing of the services and need to 
>>> start from the loaded data every time.
>>> 
>>> Can anyone confirm this behavior of Groovy over JUnit?
>>> Warm regards
>>> 
>>> 
>>> Carsten
>>> 

Re: Behavior of Groovy vs JUnit tests with test data

[Carsten Schinzer]

Hi all,


I did find and try the following from google search:

- wrap all the tests in a class
- tag the class with @RunWith(SpringRunner.class)
- tag every method that manipulates the entity data with 
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)

This has NOT been successful, hence a strong indication that running the cases 
in Groovy will make entity data manipulations to be sticky and not reverted for 
the subsequent test case run.
I am going to rework my cases to run as JUnit test cases in a Java class.

Warm regards


Carsten

> Am 03.09.2020 um 13:13 schrieb Carsten Schinzer 
> :
> 
> Hi everyone,
> 
> 
> Recently, I did find that test cases actually are much easier to write in 
> Groovy and hence I started doing that, but now I stumble across the fact that 
> some of the Groovy tests seem to find changes applied to entities from 
> previous tests. The behavior is the following:
> 
> - I load the test data with instructions given in the tested XML
> - I manipulate data in the first test data, e.g. a status on an entity
> - when I run the next test case I do not get the originally loaded entity but 
> the manipulated one from the previous test
> 
> This is different from JUnit in Java where the entities seem to exist as 
> loaded from the testdata XML with every new test case.
> It would obviously mean that I we need to implement my testing in JUnit 
> (Java) rather when we want extensive testing of the services and need to 
> start from the loaded data every time. 
> 
> Can anyone confirm this behavior of Groovy over JUnit?
> Warm regards
> 
> 
> Carsten
> 

Behavior of Groovy vs JUnit tests with test data

[Carsten Schinzer]

Hi everyone,


Recently, I did find that test cases actually are much easier to write in 
Groovy and hence I started doing that, but now I stumble across the fact that 
some of the Groovy tests seem to find changes applied to entities from previous 
tests. The behavior is the following:

- I load the test data with instructions given in the tested XML
- I manipulate data in the first test data, e.g. a status on an entity
- when I run the next test case I do not get the originally loaded entity but 
the manipulated one from the previous test

This is different from JUnit in Java where the entities seem to exist as loaded 
from the testdata XML with every new test case.
It would obviously mean that I we need to implement my testing in JUnit (Java) 
rather when we want extensive testing of the services and need to start from 
the loaded data every time. 

Can anyone confirm this behavior of Groovy over JUnit?
Warm regards


Carsten

Re: REST implementation

[Carsten Schinzer]

Hi Girish,

Thanks to clarify :)
What caught me on the OpenAPI integration is the snippet quoted below and I 
realize I should have read it in context. Actually then it is aligned with my 
view.

Warm regards

Carsten

> Initial implementation does not contain OpenApi integration yet. And

Re: REST implementation

[Carsten Schinzer]

Hello Giresh, 


Thanks for the example, it makes clearer what you want to achieve.

General considerations on RESTful or not:
If you want to stop a productionRun, why do you use PATCH and not DELETE? Well, 
I know the connotation of Delete is „dismantle“ rather than „stop“, but PATCH 
also considers and exposes config/data changes, not only status changes

PATCH /rest/productionruns/{productionRunId}?action=cancel
… would probably be the best

Here is how an Annotation based implementation would achieve this:

@Route /productionrun/{productionRunId}, requirement={productionRunid, \d+}
@ApiDoc(title=„A service to patch MRP Production Runs“, description="It allows 
to change the run configuration and status“)
public patchProductionRunAction(int productionRunId, string[] urlParameters)
{
...
if urlParameters[‚action‘] == ‚cancel‘:
call service cancelProductionRun(productionRunId)
...
}

Forgive this pseudo-code, but I think you get what I mean.

It would not avoid that some matching layer of code is reuqired in-between the 
exposed REST API methods like patchProductionRunAction and the actual service 
call, but this layer would remain code instead of being in XML or somewhere 
else that requires a context switch.

In my other application (the PHP) the classes are clearly separated by 
responsibility, i.e. Repository classes interact wit the persistence layer, 
Service classes are manipulating things and RestController classes are wrapping 
up the REST API methods and properly annotated with the Routes and validation 
constraints. The important point is that it is all coded in the same language 
and therefore the context is exposed to the IDE I am working with. No lookups 
to be made into an XML file to understand parameters and return types of 
services etc. That is quite an advantage IMO.

IMO that is the complexity in the current way of dealing with this in OFBiz and 
that’s why I believe the OpenAPI integration should be going along with REST 
implementation.

Warm regards


Carsten


> Am 17.06.2020 um 08:38 schrieb Girish Vasmatkar 
> :
> 
> Hi Carsten -
> 
> Your points make a lot of sense and that's the general consensus of the
> community as well. However, I believe we want to have the option of
> exposing the services via "REST". The existing frameworks services
> obviously are not named, thinking them as Resources and in the REST work
> resources are perceived as nouns.
> 
> This is obviously not a complete implementation and we would obviously like
> to tie up entities and services with resources. For example - consider the
> service cancelProductionRun.
> 
> If we expose it under services resource (considering services as
> resources), we could do it like this -
> PATCH /rest/services/cancelProductionRun
> {
>"productionRunId": 1234
> }
> 
> While this may not sound RESTFul, but this in a way adds capability for
> OFBiz to expose the services via a "REST" interface. A truly RESTFul
> approach that I am working on might do something like this -
> 
> PATCH /rest/productionruns/{productionRunId}
> 
> Internally it will hook up the service cancelProductionRun with this
> resource URL. This obviously has to be configured somewhere in XML and such
> details can be chalked out.
> 
> Best,
> Girish
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Jun 16, 2020 at 12:45 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> 
>> Thanks Girish,
>> 
>> I did not have time to look into details yet but your README is very
>> promising :)
>> 
>> Jacques
>> 
>> Le 15/06/2020 à 17:59, Girish Vasmatkar a écrit :
>>> Hi All
>>> 
>>> I have tried to implement a draft proposal here -
>>> https://github.com/girishvasmatkar/ofbiz-rest-impl.git
>>> The readme contains details.
>>> 
>>> In order to support the changes, I have made a corresponding change in
>> the
>>> service definition to include a new attribute named "verb". This can also
>>> be named "method". These changes are in my forked ofbiz repo (it is very
>>> much in sync with ofbiz trunk):
>>> 
>> https://github.com/girishvasmatkar/ofbiz-framework/tree/feature/add-service-verb
>>> 
>>> Initial implementation does not contain OpenApi integration yet. And yes,
>>> we should be fine doing both JSON and YAML.
>>> 
>>> Please take a look at it and let me know what you think of this. I am
>> open
>>> to suggestions, improvements, discussions.
>>> 
>>> Best Regards,
>>> Girish
>>> 
>>> 
>>> On Mon, Jun 15, 2020 at 7:02 PM Pritam Kute <
>> pritam.k...@hotwaxsystems.com>
>>> wrote:
>>> 
 Hello Girish,
 
 +1 for having REST implementation using Jersey as a separate plugin and
>> not
 to disturb the OFBiz default Control servlets and filters.
 
 IMO we should also think about the end-point security implementations
 alongside as it is one of the crucial things that users look into while
 adopting any framework.
 
 Kind Regards,
 --
 Pritam Kute
 
 
 On Fri, Jun 12, 2020 

Re: Add CHANGELOG.md file

[Carsten Schinzer]

+1 for a CHANGELOG.md

Would this be maintained for all official release branches + trunk, right? Or 
official release branches only.
Regards

Carsten

Re: REST implementation

[Carsten Schinzer]

Hello,


Certainly +1 for a REST API Implementation including JWT.

I am implementing a REST API for internal use in my job based upon PHP and 
Symfony framework (FOS REST and NELMIO Bundle just in case someone is 
interested) and find VERY cool that the NELMIO API Doc Bundle comes with an 
adopted Swagger documentation done through Annotations on the documentation 
comment for the very method implementation, i.e. avoiding the various different 
files to define the invocation, URI endpoint, implementation.

A good REST API design usually obsoletes the need to include the CRUD action 
into service naming (createXService, updateYService, ...). I liked the 
following article most and have implemented along this guidelines on my 
internal tool mentioned above: 
https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api 
.

It is a bit trickier to keep a good overview of verbs & methods on such APIs, 
but that can easily be handled by warnings/errors at Integration time. And the 
generated API documentation is always your friend, too!

I would therefore prefer to combine a REST API implementation with OpenAPI 
integration right away. Maybe worth a dedicated discussion and kick-off in the 
upcoming Community Days in August? Could be worth a dedicated team / slack 
channel that aligns on major concepts and side-by-side options of Service 
Engine vs. OpenAPI and gets a first implementation going.


If we decide to take that path, there will be interference with the Service 
Engine view and the Swagger Documentation will replace it on the long run I 
would expect. We would also need to consider cross-effects onto the 
Minilang-to-GroovyDSL migration. Design and Architecture decisions made could 
mean a change of direction on that activity.

Hope my 0.02 EUR make sense.
Warm regards


Carsten


> Am 15.06.2020 um 17:59 schrieb Girish Vasmatkar 
> :
> 
> Hi All
> 
> I have tried to implement a draft proposal here -
> https://github.com/girishvasmatkar/ofbiz-rest-impl.git
> The readme contains details.
> 
> In order to support the changes, I have made a corresponding change in the
> service definition to include a new attribute named "verb". This can also
> be named "method". These changes are in my forked ofbiz repo (it is very
> much in sync with ofbiz trunk):
> https://github.com/girishvasmatkar/ofbiz-framework/tree/feature/add-service-verb
> 
> Initial implementation does not contain OpenApi integration yet. And yes,
> we should be fine doing both JSON and YAML.
> 
> Please take a look at it and let me know what you think of this. I am open
> to suggestions, improvements, discussions.
> 
> Best Regards,
> Girish
> 
> 
> On Mon, Jun 15, 2020 at 7:02 PM Pritam Kute 
> wrote:
> 
>> Hello Girish,
>> 
>> +1 for having REST implementation using Jersey as a separate plugin and not
>> to disturb the OFBiz default Control servlets and filters.
>> 
>> IMO we should also think about the end-point security implementations
>> alongside as it is one of the crucial things that users look into while
>> adopting any framework.
>> 
>> Kind Regards,
>> --
>> Pritam Kute
>> 
>> 
>> On Fri, Jun 12, 2020 at 2:58 PM Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>> 
>>> 
>>> Hi Girish,
>>> 
>>> Inline...
>>> 
>>> Le 10/06/2020 à 17:42, Girish Vasmatkar a écrit :
 Hi All
 
 I am again bringing up this discussion on having a REST implementation
>>> for
 OFBiz. I know we have had discussions before and I was looking at some
>> of
 the past discussions about this topic and seems we are not there quite
>>> yet
 (correct me if I am wrong).
 
 I had developed a POC plug-in based on Jersey (that I am currently
 enhancing) and recently started evaluating Apache Juneau as well. I
>>> wanted
 to bring everybody on the same page as far as REST implementation is
 concerned so I had initiated a discussion on slack today. I am listing
>>> down
 a few points below that can be perceived as
>>> comment/question/understanding
 based on my general understanding of the matter and today's slack
 discussion.
 
- Anything we start on can be part of a plug-in for the start and
>>> later
can become part of the framework (as separate plug-in) once it is
developed. A dedicated API application will allow it to be
>>> lightweight in
terms of request processing. Should have separate auth mechanism
>>> bypassing
ControlerServlet/ContextFiler/ControlFilter. I opine we do not need
>>> the API
request to go through these three. Please correct me.
>>> 
>>> Though I did not look at the code (is it already somewhere?) I tend to
>>> agree on that.
>>> REST is something else and should not be hampered by those, if it's the
>>> case.
>>> 
>>> 
- We want to have mechanism to expose services (export=true) to be
available as a REST resources. Possibly extending 

OFBiz Coding Conventions

[Carsten Schinzer]

Hello all,


Like many of you, I am currently working on a piece to move services from 
minilang to Groovy DSL.
When looking around in the Wiki I found that the Coding Conventions 
(https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions 
) do have 
a foreseen section for „Service Definitions“, yet it is entirely empty.

As I also observe some deviations across the various file types and names 
involved with service definition and also inconsistencies with file locations 
in packages (Groovy-based test cases belong to non-test packages) I wondered 
where it is possibly a good time — now that plenty of us are working on the 
Mining to Groovy DSL migration — to align on conventions related to:
* Services Naming
* Context Definitions, e.g. sequence of IN vs OUT variables in seca definitions
* location of service implementations vs test implementations
* ...

I am sure there are already plenty mutually agreed conventions being „gate 
kept“ by the committers, yet I would prefer to make them explicit and document 
them for everyone’s benefit.

Note sure how to track this further … I can propose to consolidate replies to 
this mail thread and update the page as well as monitoring the page itself 
where you might leave comments or add updates to the section yourselves.

What do you think?

Warm regards from rainy Munich


Carsten

Re: Parameterized Unit Tests?

[Carsten Schinzer]

Hi,

I admit, I did fail on the rather „quick“ attempt and decided to rather 
focus on getting the minilang migration lifted forward with a set of 8 
dedicated tests, non-parameterized.
So I created a story to investigate this test feature in depth some time in the 
future:

https://issues.apache.org/jira/browse/OFBIZ-11744 
<https://issues.apache.org/jira/browse/OFBIZ-11744>

Warm regards

Carsten


> Am 25.05.2020 um 17:24 schrieb Carsten Schinzer 
> :
> 
> Thanks for the hint, Dan!
> 
> Also, I just came across this one:
> https://stackoverflow.com/questions/3361239/excluding-a-non-param-test-in-parameterized-test-class
>  
> <https://stackoverflow.com/questions/3361239/excluding-a-non-param-test-in-parameterized-test-class>
> 
> I certainly support running each of the parameter sets as an individual test, 
> i.e. test counters go up per set executed.
> I will try both suggestions, the one you suggested and the one from the link 
> above.
> 
> Warm regards
> 
> 
> Carsten
> 
> 
>> Am 25.05.2020 um 17:21 schrieb Daniel Watford > <mailto:d...@foomoo.co.uk>>:
>> 
>> Hi Carsten,
>> 
>> I don't know if there were any reasons historically that precluded use of
>> the parameterized test pattern, but I think it can be quite useful if you
>> are able to make use of it.
>> 
>> Another test class that could benefit is FlexibleStringExpanderTests where
>> the parameterized test pattern appears to have been implemented without
>> test library support.
>> 
>> A benefit of converting FlexibleStringExpanderTests would be that all the
>> various parameterized tests would contribute to the overall test count of a
>> build, rather than being rolled up as part of the public testParsing(),
>> testWithVerbosity() and testQuietly() methods.
>> 
>> Thanks,
>> 
>> Dan.
>> 
>> On Mon, 25 May 2020 at 15:43, Carsten Schinzer <
>> cars...@dcs-verkaufssysteme.de <mailto:cars...@dcs-verkaufssysteme.de>> 
>> wrote:
>> 
>>> Hello all,
>>> 
>>> 
>>> I find no other reference to org.junit.Parameterized in the code stack on
>>> trunk which indicates that no-one else has committed parameterized unit
>>> tests. I am asking because I have a test case where I would need that (I
>>> want to run all options for the CustRequestStatusType against the status
>>> check service an be sure it return the expected result) and when
>>> implementing I find that my IDE hints that „There is no default constructor
>>> available in class ‚org.apache.ofbiz.service.testtools.OFBizTestCase‘“.
>>> 
>>> 
>>> package org.apache.ofbiz.order
>>> 
>>> import org.apache.ofbiz.service.ServiceUtil
>>> import org.apache.ofbiz.service.testtools.OFBizTestCase
>>> import org.junit.Test
>>> import org.junit.runner.RunWith
>>> import org.junit.runners.Parameterized
>>> import org.junit.runners.Parameterized.Parameters
>>> 
>>> @RunWith(Parameterized)
>>> class CustRequestStatusTests extends OFBizTestCase {
>>>private String status
>>>private String expect
>>>private String scenario
>>> 
>>>@Parameters static scenarios() {[
>>>['CRQ_DRAFT', 'PASS', 'CustRequest status Draft expected to
>>> PASS'],
>>>['CRQ_SUBMITTED', 'PASS', 'CustRequest status Submitted expected
>>> to PASS'],
>>>['CRQ_ACCEPTED',  'PASS', 'CustRequest status Accepted expected to
>>> PASS'],
>>>['CRQ_REVIEWED',  'PASS', 'CustRequest status Reviewed expected to
>>> PASS'],
>>>['CRQ_PENDING',   'PASS', 'CustRequest status Pending expected to
>>> PASS'],
>>>['CRQ_COMPLETED', 'FAIL', 'CustRequest status Completed expected
>>> to FAIL'],
>>>['CRQ_REJECTED',  'PASS', 'CustRequest status Rejected expected to
>>> PASS'],
>>>['CRQ_CANCELLED', 'FAIL', 'CustRequest status Cancelled expected
>>> to FAIL'],
>>>]*.toArray()}
>>> 
>>>public CustRequestStatusTests(String name, String status, String
>>> expect, String scenario) {
>>>this.expect   = expect
>>>this.scenario = scenario
>>>this.status   = status
>>>super(name)
>>>}
>>> 
>>>/* Testing custRequestStatusCheck Service Implementation
>>>*
>>>* available test data:
>>>* (...)
>>>*   >> fromPartyId="DemoCustomer" priority="9&quo

Re: Help required - calling Minilang Experts

[Carsten Schinzer]

Hi Scott,


Thanks for your comment. I understand … and I don’t.
See, this is the message sequence in the two cases:

Case 1
updateCustRequest
==> calls checkStatusCustRequest
   (Will fail the check if not in an in-progress status)
<== returns to calling simple service
… do the updateCustRequest stuff

Test result: FAIL.


Case 2
createCustRequestItemNote
==> calls checkStatusCustRequest
   (Will fail the check if not in an in-progress status)
<== returns to calling simple service
… create the CustRequestItemNote

Test result: PASS.


The checkStatusCustRequest is a read-only method, only reason to run it is a 
failure message being raised when the referenced custRequest does not have an 
allowed status. Yet, it will in the background already read the custRequest 
object from the Entity store.

I tried:
- putting the copy-step first in the method before calling the StatusCheck 
(test expects the updateCustRequest.oldStatusId
 to be returned in the OUT map
- renaming the local variable in the StatusCheck method to avoid interference 
with the calling method’s context
- not returning a success message from the StatusCheck method to avoid any 
„pollution“ of the calling method’s context

Still I see the same error in all these attempts as mentioned below, namely 
that test expects the presence updateCustReuqest.oldStatusId as a return value 
of the updateCustRequest method. I do hence not seem to get it right. Any ideas?

Warm regards


Carsten



> Am 28.05.2020 um 03:11 schrieb Scott Gray :
> 
> Hi Carsten,
> 
> call-simple-method executes in the same manner as if you copied the code
> from the method being called directly into your code, i.e. it has the same
> variable scope as the method it's being called from.  So the "custRequest"
> variable from checkStatusCustRequest was available to updateCustRequest.
> Now that the implementation is a service, you'd need to explicitly return
> that value from the service in order to be able to use it.
> 
> Regards
> Scott
> 
> On Thu, 28 May 2020 at 04:52, Carsten Schinzer <
> cars...@dcs-verkaufssysteme.de> wrote:
> 
>> Hello MiniLang Experts,
>> 
>> 
>> I am migrating the checkStatusCustRequest service to Groovy (OFBIZ-11692 <
>> https://issues.apache.org/jira/browse/OFBIZ-11692>), part of our May
>> CommunityDays scope and sprint.
>> In the finalization I now notice that the original Minilang service
>> „checkStatusCustRequest“ is called by two other services as an inline
>> call-simple-method statement:
>> 
>> Source is /applications/order/minilang/request/CustRequestServices.xml:
>> 
>> #121
>> Was:
>> 
>>
>>
>>> from-field="parameters.custRequestId"/>
>>
>>
>>> in-map-name="crqCheck">
>>
>>
>>
>> 
>> And the second service in the same minilang file
>> 
>> #237
>> Was:
>> > short-description="Create Customer RequestItem Note">
>>
>>
>> 
>> Changed to:
>> > short-description="Create Customer RequestItem Note">
>>> field="crqCheck.custRequestId"/>
>>
>>
>>> in-map-name="crqCheck"/>
>>
>> 
>> While the latter passes testing now, the first does not, complaining that:
>> 
>>  > name="custrequest-tests.testCreateNewRequest" time="0.101">
>>  > type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError:
>> ERROR: Could not complete the update a request
>> [file:/Users/carsten/github/ofbiz-framework/applications/order/minilang/test/CustRequestTests.xml#inlineUpdateRequest]
>> process [problem invoking the [updateCustRequest] service with the map
>> named [updateRequestMap] containing
>> [{userLogin=[GenericEntity:UserLogin][createdStamp,2020-05-25
>> 09:59:39.293(java.sql.Timestamp)][createdTxStamp,2020-05-25
>> 09:59:39.167(java.sql.Timestamp)][currentPassword,null()][disabledBy,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2020-05-25
>> 09:59:41.161(java.sql.Timestamp)][lastUpdatedTxStamp,2020-05-25
>> 09:59:41.121(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
>> custRequestName=New Test Customer request, fromPartyId=admin,
>> statusId=CRQ_ACCEPTED, custRequestId=10530, custRequestTypeI

Help required - calling Minilang Experts

[Carsten Schinzer]

Hello MiniLang Experts,


I am migrating the checkStatusCustRequest service to Groovy (OFBIZ-11692 
), part of our May 
CommunityDays scope and sprint.
In the finalization I now notice that the original Minilang service 
„checkStatusCustRequest“ is called by two other services as an inline 
call-simple-method statement:

Source is /applications/order/minilang/request/CustRequestServices.xml:

#121
Was:











And the second service in the same minilang file

#237
Was:




Changed to:







While the latter passes testing now, the first does not, complaining that:

  
  junit.framework.AssertionFailedError:
 ERROR: Could not complete the update a request 
[file:/Users/carsten/github/ofbiz-framework/applications/order/minilang/test/CustRequestTests.xml#inlineUpdateRequest]
 process [problem invoking the [updateCustRequest] service with the map named 
[updateRequestMap] containing 
[{userLogin=[GenericEntity:UserLogin][createdStamp,2020-05-25 
09:59:39.293(java.sql.Timestamp)][createdTxStamp,2020-05-25 
09:59:39.167(java.sql.Timestamp)][currentPassword,null()][disabledBy,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2020-05-25
 09:59:41.161(java.sql.Timestamp)][lastUpdatedTxStamp,2020-05-25 
09:59:41.121(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
 custRequestName=New Test Customer request, fromPartyId=admin, 
statusId=CRQ_ACCEPTED, custRequestId=10530, custRequestTypeId=RF_INFO, 
priority=2, locale=en}]: Outgoing result (in runSync : updateCustRequest) does 
not match expected requirements (The following required parameter is missing: 
[OUT] [updateCustRequest.oldStatusId])]
   at org.apache.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:91)
   at 
org.apache.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:90)
   at 
org.apache.ofbiz.base.container.ContainerLoader.startLoadedContainers(ContainerLoader.java:156)
   at 
org.apache.ofbiz.base.container.ContainerLoader.load(ContainerLoader.java:78)
   at 
org.apache.ofbiz.base.start.StartupControlPanel.loadContainers(StartupControlPanel.java:151)
   at 
org.apache.ofbiz.base.start.StartupControlPanel.start(StartupControlPanel.java:71)
   at org.apache.ofbiz.base.start.Start.main(Start.java:90)
  
So something in my checkStatusCustRequest call is not digesting the response 
from the sub-service properly I suspect as the test complains that the 
subsequent line originally in line #123 which maps the oldStatusId is not 
executed as that field is missing in the response.

Now I am not an expert at all with these cross-service calls, what would you 
suggest here?

Also, a tactical option could be to extend the story to port all three to 
Groovy knowing that the other two are not called as nested call-simple-method 
statements by other services, but always as call-service statements which 
assumedly makes it fairly easy to port (but will cause scope slippage).

Thanks for any views and hints.
Warm regards


Carsten

Re: Parameterized Unit Tests?

[Carsten Schinzer]

Sorry, misunderstanding here:

I will try both suggestions from Stackoverflow and decide for one option.

Regarding your suggestion, Dan, I guess that is a new JIRA Improvement once I 
validated the parametrized testing with my test case, right?


> Am 25.05.2020 um 17:24 schrieb Carsten Schinzer 
> :
> 
> Thanks for the hint, Dan!
> 
> Also, I just came across this one:
> https://stackoverflow.com/questions/3361239/excluding-a-non-param-test-in-parameterized-test-class
>  
> <https://stackoverflow.com/questions/3361239/excluding-a-non-param-test-in-parameterized-test-class>
> 
> I certainly support running each of the parameter sets as an individual test, 
> i.e. test counters go up per set executed.
> I will try both suggestions, the one you suggested and the one from the link 
> above.
> 
> Warm regards
> 
> 
> Carsten
> 
> 
>> Am 25.05.2020 um 17:21 schrieb Daniel Watford > <mailto:d...@foomoo.co.uk>>:
>> 
>> Hi Carsten,
>> 
>> I don't know if there were any reasons historically that precluded use of
>> the parameterized test pattern, but I think it can be quite useful if you
>> are able to make use of it.
>> 
>> Another test class that could benefit is FlexibleStringExpanderTests where
>> the parameterized test pattern appears to have been implemented without
>> test library support.
>> 
>> A benefit of converting FlexibleStringExpanderTests would be that all the
>> various parameterized tests would contribute to the overall test count of a
>> build, rather than being rolled up as part of the public testParsing(),
>> testWithVerbosity() and testQuietly() methods.
>> 
>> Thanks,
>> 
>> Dan.
>> 
>> On Mon, 25 May 2020 at 15:43, Carsten Schinzer <
>> cars...@dcs-verkaufssysteme.de <mailto:cars...@dcs-verkaufssysteme.de>> 
>> wrote:
>> 
>>> Hello all,
>>> 
>>> 
>>> I find no other reference to org.junit.Parameterized in the code stack on
>>> trunk which indicates that no-one else has committed parameterized unit
>>> tests. I am asking because I have a test case where I would need that (I
>>> want to run all options for the CustRequestStatusType against the status
>>> check service an be sure it return the expected result) and when
>>> implementing I find that my IDE hints that „There is no default constructor
>>> available in class ‚org.apache.ofbiz.service.testtools.OFBizTestCase‘“.
>>> 
>>> 
>>> package org.apache.ofbiz.order
>>> 
>>> import org.apache.ofbiz.service.ServiceUtil
>>> import org.apache.ofbiz.service.testtools.OFBizTestCase
>>> import org.junit.Test
>>> import org.junit.runner.RunWith
>>> import org.junit.runners.Parameterized
>>> import org.junit.runners.Parameterized.Parameters
>>> 
>>> @RunWith(Parameterized)
>>> class CustRequestStatusTests extends OFBizTestCase {
>>>private String status
>>>private String expect
>>>private String scenario
>>> 
>>>@Parameters static scenarios() {[
>>>['CRQ_DRAFT', 'PASS', 'CustRequest status Draft expected to
>>> PASS'],
>>>['CRQ_SUBMITTED', 'PASS', 'CustRequest status Submitted expected
>>> to PASS'],
>>>['CRQ_ACCEPTED',  'PASS', 'CustRequest status Accepted expected to
>>> PASS'],
>>>['CRQ_REVIEWED',  'PASS', 'CustRequest status Reviewed expected to
>>> PASS'],
>>>['CRQ_PENDING',   'PASS', 'CustRequest status Pending expected to
>>> PASS'],
>>>['CRQ_COMPLETED', 'FAIL', 'CustRequest status Completed expected
>>> to FAIL'],
>>>['CRQ_REJECTED',  'PASS', 'CustRequest status Rejected expected to
>>> PASS'],
>>>['CRQ_CANCELLED', 'FAIL', 'CustRequest status Cancelled expected
>>> to FAIL'],
>>>]*.toArray()}
>>> 
>>>public CustRequestStatusTests(String name, String status, String
>>> expect, String scenario) {
>>>this.expect   = expect
>>>this.scenario = scenario
>>>this.status   = status
>>>super(name)
>>>}
>>> 
>>>/* Testing custRequestStatusCheck Service Implementation
>>>*
>>>* available test data:
>>>* (...)
>>>*   >> fromPartyId="DemoCustomer" priority="9" custRequestName="Customer Request
>>> Usage" description="Demo CustRequest" productStoreId="9000"/>
>>>*   >

Re: Parameterized Unit Tests?

[Carsten Schinzer]

Thanks for the hint, Dan!

Also, I just came across this one:
https://stackoverflow.com/questions/3361239/excluding-a-non-param-test-in-parameterized-test-class
 
<https://stackoverflow.com/questions/3361239/excluding-a-non-param-test-in-parameterized-test-class>

I certainly support running each of the parameter sets as an individual test, 
i.e. test counters go up per set executed.
I will try both suggestions, the one you suggested and the one from the link 
above.

Warm regards


Carsten


> Am 25.05.2020 um 17:21 schrieb Daniel Watford :
> 
> Hi Carsten,
> 
> I don't know if there were any reasons historically that precluded use of
> the parameterized test pattern, but I think it can be quite useful if you
> are able to make use of it.
> 
> Another test class that could benefit is FlexibleStringExpanderTests where
> the parameterized test pattern appears to have been implemented without
> test library support.
> 
> A benefit of converting FlexibleStringExpanderTests would be that all the
> various parameterized tests would contribute to the overall test count of a
> build, rather than being rolled up as part of the public testParsing(),
> testWithVerbosity() and testQuietly() methods.
> 
> Thanks,
> 
> Dan.
> 
> On Mon, 25 May 2020 at 15:43, Carsten Schinzer <
> cars...@dcs-verkaufssysteme.de> wrote:
> 
>> Hello all,
>> 
>> 
>> I find no other reference to org.junit.Parameterized in the code stack on
>> trunk which indicates that no-one else has committed parameterized unit
>> tests. I am asking because I have a test case where I would need that (I
>> want to run all options for the CustRequestStatusType against the status
>> check service an be sure it return the expected result) and when
>> implementing I find that my IDE hints that „There is no default constructor
>> available in class ‚org.apache.ofbiz.service.testtools.OFBizTestCase‘“.
>> 
>> 
>> package org.apache.ofbiz.order
>> 
>> import org.apache.ofbiz.service.ServiceUtil
>> import org.apache.ofbiz.service.testtools.OFBizTestCase
>> import org.junit.Test
>> import org.junit.runner.RunWith
>> import org.junit.runners.Parameterized
>> import org.junit.runners.Parameterized.Parameters
>> 
>> @RunWith(Parameterized)
>> class CustRequestStatusTests extends OFBizTestCase {
>>private String status
>>private String expect
>>private String scenario
>> 
>>@Parameters static scenarios() {[
>>['CRQ_DRAFT', 'PASS', 'CustRequest status Draft expected to
>> PASS'],
>>['CRQ_SUBMITTED', 'PASS', 'CustRequest status Submitted expected
>> to PASS'],
>>['CRQ_ACCEPTED',  'PASS', 'CustRequest status Accepted expected to
>> PASS'],
>>['CRQ_REVIEWED',  'PASS', 'CustRequest status Reviewed expected to
>> PASS'],
>>['CRQ_PENDING',   'PASS', 'CustRequest status Pending expected to
>> PASS'],
>>['CRQ_COMPLETED', 'FAIL', 'CustRequest status Completed expected
>> to FAIL'],
>>['CRQ_REJECTED',  'PASS', 'CustRequest status Rejected expected to
>> PASS'],
>>['CRQ_CANCELLED', 'FAIL', 'CustRequest status Cancelled expected
>> to FAIL'],
>>]*.toArray()}
>> 
>>public CustRequestStatusTests(String name, String status, String
>> expect, String scenario) {
>>this.expect   = expect
>>this.scenario = scenario
>>this.status   = status
>>super(name)
>>}
>> 
>>/* Testing custRequestStatusCheck Service Implementation
>>*
>>* available test data:
>>* (...)
>>*   > fromPartyId="DemoCustomer" priority="9" custRequestName="Customer Request
>> Usage" description="Demo CustRequest" productStoreId="9000"/>
>>*   > custRequestItemSeqId="1" productId="GZ-1001" story="This can be the
>> longer story of an item on the customer request."/>
>>*
>>*  */
>>@Test void testCustRequestStatusCheckEmpty() {
>>Map input = [
>>custRequestId: '9001',
>>]
>>Map result = dispatcher.runSync('checkStatusCustRequest', input)
>>assert ServiceUtil.isError(result)
>>// assert error message refers to certain text element
>>}
>> 
>>@Test void testCustRequestStatusCheckWrongStatus() {
>>Map input = [
>>custRequestId: '9000',
>>statusId: this.status,
>>]
>>Map result = dispatcher.runSync('chec

Re: LineLength for checkstyle

[Carsten Schinzer]

+1 for setting the max lines rule

> Am 25.05.2020 um 17:05 schrieb Daniel Watford :
> 
> Hi Jacques,
> 
> I would vote for setting an explicit rule to have the max line length set
> at 2000 lines and then work on refactoring those offending source files
> where possible.
> 
> If we find some files cannot be split up then I think we can add exceptions
> to prevent the max line length rule from being applied to them. But that
> should be done on a file by file basis.
> 
> I still have OFBIZ-11456 on my todo list to refactor MacroFormRenderer.
> Work has been progressing slowly but development has slowed during the
> pandemic. I hope to get back on top of this soon.
> 
> Thanks,
> 
> Dan.
> 
> On Mon, 25 May 2020 at 15:43, Jacques Le Roux 
> wrote:
> 
>> Hi All,
>> 
>> Suraj rightly mentioned that we have no FileLength checkstyle rule and the
>> max default is 2000 lines:
>> https://checkstyle.sourceforge.io/config_sizes.html#FileLength
>> 
>> We have some very large Java files in trunk and few (19) are longer than
>> 2000 lines.
>> The question is should we increase FileLength checkstyle rule to hide the
>> issue or try to split those files?
>> 
>> I have created https://issues.apache.org/jira/browse/OFBIZ-11740 for that
>> 
>> Jacques
>> 
>> https://checkstyle.sourceforge.io/config_sizes.html#FileLength
>> 
>> Le 25/05/2020 à 15:09, Suraj Khurana a écrit :
>>> This is done in rev # d6ebef619349f809062641d1b558cacdec3da208
>>> 
>>> --
>>> Best Regards,
>>> Suraj Khurana
>>> Senior Technical Consultant
>>> 
>>> 
>>> On Mon, May 25, 2020 at 2:16 PM Suraj Khurana 
>>> wrote:
>>> 
 Thanks everyone,
 
 Here[1] is the ticket to track this improvement.
 
 [1]: https://issues.apache.org/jira/browse/OFBIZ-11737
 
 --
 Best Regards,
 Suraj Khurana
 Senior Technical Consultant
 
 
 On Sun, May 24, 2020 at 1:58 PM Olivier Heintz <
 holivier.li...@ofbizextra.org> wrote:
 
> +1
> 
> Le 23/05/2020 à 17:29, Suraj Khurana a écrit :
>> Hello Devs,
>> 
>> Recently we are facing some checkstyle issues and one cause of it is
>> LineLength property.
>> Currently we have set it to 120, I think we should make it to 150
> instead.
>> It is pretty visible in 13/14 font sizes as well.
>> 
>> Please share your thoughts on this.
>> 
>> --
>> Best Regards,
>> Suraj Khurana
>> Senior Technical Consultant
>> 
>> 
> 
> 
> -- 
> Daniel Watford

Parameterized Unit Tests?

[Carsten Schinzer]

Hello all,


I find no other reference to org.junit.Parameterized in the code stack on trunk 
which indicates that no-one else has committed parameterized unit tests. I am 
asking because I have a test case where I would need that (I want to run all 
options for the CustRequestStatusType against the status check service an be 
sure it return the expected result) and when implementing I find that my IDE 
hints that „There is no default constructor available in class 
‚org.apache.ofbiz.service.testtools.OFBizTestCase‘“.


package org.apache.ofbiz.order

import org.apache.ofbiz.service.ServiceUtil
import org.apache.ofbiz.service.testtools.OFBizTestCase
import org.junit.Test
import org.junit.runner.RunWith
import org.junit.runners.Parameterized
import org.junit.runners.Parameterized.Parameters

@RunWith(Parameterized)
class CustRequestStatusTests extends OFBizTestCase {
private String status
private String expect
private String scenario

@Parameters static scenarios() {[
['CRQ_DRAFT', 'PASS', 'CustRequest status Draft expected to PASS'],
['CRQ_SUBMITTED', 'PASS', 'CustRequest status Submitted expected to 
PASS'],
['CRQ_ACCEPTED',  'PASS', 'CustRequest status Accepted expected to 
PASS'],
['CRQ_REVIEWED',  'PASS', 'CustRequest status Reviewed expected to 
PASS'],
['CRQ_PENDING',   'PASS', 'CustRequest status Pending expected to 
PASS'],
['CRQ_COMPLETED', 'FAIL', 'CustRequest status Completed expected to 
FAIL'],
['CRQ_REJECTED',  'PASS', 'CustRequest status Rejected expected to 
PASS'],
['CRQ_CANCELLED', 'FAIL', 'CustRequest status Cancelled expected to 
FAIL'],
]*.toArray()}

public CustRequestStatusTests(String name, String status, String expect, 
String scenario) {
this.expect   = expect
this.scenario = scenario
this.status   = status
super(name)
}

/* Testing custRequestStatusCheck Service Implementation
*
* available test data:
* (...)
*   
*   
*
*  */
@Test void testCustRequestStatusCheckEmpty() {
Map input = [
custRequestId: '9001',
]
Map result = dispatcher.runSync('checkStatusCustRequest', input)
assert ServiceUtil.isError(result)
// assert error message refers to certain text element
}

@Test void testCustRequestStatusCheckWrongStatus() {
Map input = [
custRequestId: '9000',
statusId: this.status,
]
Map result = dispatcher.runSync('checkStatusCustRequest', input)
if(this.expect == 'PASS') {
assert ServiceUtil.isSuccess(result)
} else {
assert ServiceUtil.isFailure(result)
}
}
}



This hint certainly has to do with the implementation I need to do for such 
test cases using annotations to mark the class as @Parameterized, define the 
@Parameters and then mark the @Test that uses the parameters.

Before I dive too much into web search:
- has anyone attempted this for OFBiz unit Testing? (And hence the reason why 
no implementation is avail)

Thanks for a hint :)
Warm regards


Carsten

Re: Difficulties to support the Community Days

[Carsten Schinzer]

https://issues.apache.org/jira/browse/OFBIZ-11738

:)


> Am 25.05.2020 um 11:43 schrieb Pierre Smits :
> 
> Ahh. Yes, there is also Fisheye (another Atlassian product,  and still in
> play). That aspect of our tooling hasn't been adjusted yet (showing (links
> to) commits in Github.
> 
> Please be so kind to raise an issue regarding this, so that it can be
> followed through.
> 
> 
> Met vriendelijke groet,
> 
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz  since
> 2008 (without privileges)
> 
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> Apache Steve , committer
> 
> 
>> 

Re: Difficulties to support the Community Days

[Carsten Schinzer]

Hi,


Thanks indeed - #2 explains and is valid practice, just needed to know.

Ad 1 - The following is what I get, when I click on the commits link on any 
JIRA ticket with existing commits a popup dialog opens (I use that inside my 
work evironment to investigate on the code level). Example:
OFBIZ-11715: 1 unique commit
Authenticate to see related commits

Please log in to approve this application: fisheye 
<https://issues.apache.org/jira/plugins/servlet/applinks/oauth/login-dance/authorize?applicationLinkID=3b515deb-9c05-3575-992e-07c19ddeb26f>



That is how I came to ask about Fisheye …

Maybe this is an unwanted side effect on the tooling side?
Warm regards


Carsten



> Am 25.05.2020 um 11:23 schrieb Pierre Smits :
> 
> Hi Carsten,
> 
> Welcome back.
> 
> re: 1
> Indeed things has changes. Yet there is no dependency on Fishbowl. In fact
> there is no mention at all in any of our mailing lists regarding an
> integration with fishbowl. The tools still in use by the project: Jira (for
> issue management, release management, etc), GitHub (public repos, pull
> requests from forks and local clones), Confluence for documentation.
> 
> re: 2
> The consensus within the community is that feature/bug branches exist in
> the local clones (from forks or directly from the public repos) until
> maturity. After that proposed changes are handled though pull requests.
> This enables community members to collaborate on feature/bug branch (by
> forking/cloning from the community member's repo, while at the same time
> avoiding a cluttered and confusing public repo).  the See [1] and [2].
> 
> There is also a page in our wiki regarding this. see [3]
> 
> 
> [1] https://github.com/apache/ofbiz-framework/pulls
> [2] https://github.com/apache/ofbiz-plugins/pulls
> [3]
> https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github+-+WIP
> 
> 
> Met vriendelijke groet,
> 
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
> 2008 (without privileges)
> 
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> Apache Steve <https://steve.apache.org>, committer
> 
> 
> On Mon, May 25, 2020 at 11:06 AM Carsten Schinzer <
> cars...@dcs-verkaufssysteme.de> wrote:
> 
>> Hello all,
>> 
>> 
>> Admittedly I have been away for a very long time and things have changed.
>> I seem to be having difficulties to contribute to the Community Days, but
>> maybe simply rookie issues, so any helping hand is appreciated.
>> 
>> I have this status:
>> * OFBiz code bases (framework and plugins) cloned from git
>> * local framework testing completed
>> * JIRA Access working - I can see and follow the current sprint
>> * Confluence Access working - surprising after almost 9 years of silence;
>> that’s what I call continuity :)
>> 
>> I am stuck here:
>> 1) While I can see Jira tickets, when I want to investigate commits, I
>> need to log on to Fishbowl, but that appears to be a new account. Who can
>> grant me access?
>> 
>> 2) I do see the three main branches on git, but I fail to see any (feature
>> or bug) branches with ongoing development. Are you working with local
>> branching and limiting the main branch interactions to pull requests? Am I
>> just missing permission?
>> 
>> Thanks for helping me to get up to speed.
>> Warm regards
>> 
>> 
>> Carsten
>> 
>> 

Difficulties to support the Community Days

[Carsten Schinzer]

Hello all,


Admittedly I have been away for a very long time and things have changed.
I seem to be having difficulties to contribute to the Community Days, but maybe 
simply rookie issues, so any helping hand is appreciated.

I have this status:
* OFBiz code bases (framework and plugins) cloned from git
* local framework testing completed
* JIRA Access working - I can see and follow the current sprint
* Confluence Access working - surprising after almost 9 years of silence; 
that’s what I call continuity :)

I am stuck here:
1) While I can see Jira tickets, when I want to investigate commits, I need to 
log on to Fishbowl, but that appears to be a new account. Who can grant me 
access?

2) I do see the three main branches on git, but I fail to see any (feature or 
bug) branches with ongoing development. Are you working with local branching 
and limiting the main branch interactions to pull requests? Am I just missing 
permission?

Thanks for helping me to get up to speed.
Warm regards


Carsten

Re: Ideas about OFBiz servlet filters

[Carsten Schinzer]

Great proposal, I had quite some headaches with this 2-3 years ago when I
was diving deep into the multitenancy with several (mini) shops and content
sites for different tenants.. ContextFilter handles it well, but the others
don't for the reasons you mention. I was hesitating to propose anything
because I did not feel safe enough with my .. .well ... workarounds. They
were likely not generic and robust enough under different circumstances
(more traffic, concurrent traffic to different sites).

Good to have a documented guideline now.

Thanks & regards

Carsten

2016-09-09 10:07 GMT+02:00 Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com>:

> A web application, in order to leverage the OFBiz framework, requires that
> a series of objects are in its contexts (servlet context, session and
> request) such as "delegator", "delegatorName", "dispatcher", "security"
> etc. etc...
> This setup is performed by the logic contained in the servlet filter
> implemented by the following class:
>
> org.apache.ofbiz.webapp.control.ContextFilter
>
> The execution of this logic is required for the application to run
> properly.
> However, this filter is deployed in most but not all the web application in
> the OFBiz codebase: there are few exceptions due to the fact that a few web
> applications require the execution of other filters (e.g. CatalogUrlFilter,
> etc...).
>
> Unfortunately the way these filters have been implemented have issues
> including:
> * some of them extend the ContextFilter and override its behavior by
> copying some logic and adding new one; in these cases the ContextFilter is
> also deployed but after the execution of the extended filter
> * some of them have been copied from ContextFilter and then adapted,
> introducing a lot of redundant code difficult to maintain; in these cases
> the ContextFilter is not deployed
>
> There is now a chance for the community to help cleaning up these classes
> and I am proposing the following guidelines:
>
> 1) servlet filters should be chained (rather than extended or replaced)
> 2) ContextFilter should always be used and should always be the first
> (OFBiz) filter in the chain
> 3) if some of the behavior/logic of ContextFilter conflicts with the ones
> of other filters, then ContextFilter should be enhanced to prevent that
> (e.g. we can improve the code, move some of its logic in a separate filter
> that can be executed after etc...)
> 4) the other filters should work well after the ContextFilter and add
> behavior rather than overriding behavior or duplicating behavior
>
> As a beneficial side effect of this effort, we will get a cleaner picture
> (documented by the logic of ContextFilter) of all the context objects
> required by OFBiz web applications.
>
> I hope it helps
>
> Jacopo
>

Re: Duplicate webapp loads by birt component

[Carsten Schinzer]

Compromise proposal:

Option 1) You guys keep trunk as is and anyone who wants to avoid the log
message disables the birt component locally (I've just done so) until it is
officially released.
Option 2) You guys diasble birt in trunk by default and activate it for
testing when needed.

I guess Option 1 is what most prefer as in trunk you will not want to do
extra things before being able to test .. ?

My 2 cents
Regards

Carsten


2014-05-19 8:33 GMT+02:00 Taher Alkhateeb slidingfilame...@gmail.com:

 Hi Jacopo,

 I think we had a similar discussion in the past but if you disable the
 component then you will not be able to run the tests which means further
 marginalizing the special purpose components. This also means that any
 changes to the framework might result in an incompatibility with this
 component because it will not be kept up to date.

 To me personally birt is the most important component that I use on a daily
 basis.

 Taher Alkhateeb
 On May 19, 2014 9:25 AM, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:

  IMO the birt component in the trunk should be set as disabled to prevent
  this from happening.
 
  Jacopo
 
  On May 19, 2014, at 8:24 AM, Jacopo Cappellato 
  jacopo.cappell...@hotwaxmedia.com wrote:
 
   This is the intended behavior: when a component redefines an existing
  webapp the previous one is not loaded and an info message is printed.
  
   Jacopo
  
   On May 18, 2014, at 9:04 PM, Jacques Le Roux 
  jacques.le.r...@les7arts.com wrote:
  
   Just spotted the lines
  
   [java] 2014-05-18 20:55:57,869 (main) [
 CatalinaContainer.java:567:INFO
  ] createContext(ar)
   [java] 2014-05-18 20:55:57,869 (main) [
 CatalinaContainer.java:770:INFO
  ] Duplicate webapp mount; not loading : accounting /
  C:/projectsASF/ofbizVirgin/applications/accounting/webapp/accounting
   [java] 2014-05-18 20:55:57,869 (main) [
 CatalinaContainer.java:567:INFO
  ] createContext(manufacturing)
   [java] 2014-05-18 20:55:57,869 (main) [
 CatalinaContainer.java:770:INFO
  ] Duplicate webapp mount; not loading : facility /
  C:/projectsASF/ofbizVirgin/applications/product/webapp/facility
   [java] 2014-05-18 20:55:57,869 (main) [
 CatalinaContainer.java:567:INFO
  ] createContext(catalog)
   [java] 2014-05-18 20:55:57,869 (main) [
 CatalinaContainer.java:567:INFO
  ] createContext(ical)
   [java] 2014-05-18 20:55:57,870 (main) [
 CatalinaContainer.java:567:INFO
  ] createContext(workeffort)
   [java] 2014-05-18 20:55:57,870 (main) [
 CatalinaContainer.java:770:INFO
  ] Duplicate webapp mount; not loading : content /
  C:/projectsASF/ofbizVirgin/applications/content/webapp/content
  
   Not sure what to do with those, Jacopo?
  
   Jacques
  
   Le 18/05/2014 20:11, Carsten Schinzer a écrit :
   Thanks for the info,
   I comfirm it is harmless.
   Just wanted to be sure.
   Regards
  
   Carsten
  
  
   2014-05-18 14:27 GMT+02:00 Jacques Le Roux 
  jacques.le.r...@les7arts.com:
  
   Jacopo introduced a change to be able to move the Birt component
 from
   framework to specialpupose
   So yes it's an intended change but I see no problems with it using
  trunk.
   Those are loaded and used for Birt reports which are in those
  components
  
   Jacques
  
   Le 15/05/2014 18:18, c.schin...@gmail.com a écrit :
  
   All,
  
   I did an update from trunk and realize in the sniff test that logs
  show
   that birt's ofbiz-component.xml redefines three existing webapp
  mounts:
   accounting, facility and ordermgr. Embedded Tomcat does
 consequently
  not
   load these.
  
   Is this expected behavior? Am I missing a config change for my
  runtime?
   Or is this an issue?
   If so, is there a JIRA open or does it merit one?
  
   Thanks for letting me know.
   Regards
  
  
   Carsten
  
  
   Gesendet von unterwegs mit BlackBerry® Webmail.
  
  
  
   --
  
  
   --
  
 
 

Re: Duplicate webapp loads by birt component

[Carsten Schinzer]

Thanks for the info,
I comfirm it is harmless.
Just wanted to be sure.
Regards

Carsten


2014-05-18 14:27 GMT+02:00 Jacques Le Roux jacques.le.r...@les7arts.com:

 Jacopo introduced a change to be able to move the Birt component from
 framework to specialpupose
 So yes it's an intended change but I see no problems with it using trunk.
 Those are loaded and used for Birt reports which are in those components

 Jacques

 Le 15/05/2014 18:18, c.schin...@gmail.com a écrit :

  All,


 I did an update from trunk and realize in the sniff test that logs show
 that birt's ofbiz-component.xml redefines three existing webapp mounts:
 accounting, facility and ordermgr. Embedded Tomcat does consequently not
 load these.

 Is this expected behavior? Am I missing a config change for my runtime?
 Or is this an issue?
 If so, is there a JIRA open or does it merit one?

 Thanks for letting me know.
 Regards


 Carsten


 Gesendet von unterwegs mit BlackBerry® Webmail.



 --

[jira] [Updated] (OFBIZ-5298) iDEAL Configuration and Documentation

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5298:


Attachment: OFBIZ-5298_iDEAL_Configuration_and_Documentation.patch

This patch will fix the reported issue. A summary of the discussions held on 
the mailing list:

(1) all parties agree that this fix does not help the fact that the interface 
is out of date and likely no longer supported by ING as is. Development work 
will be required to make this work again.
(2) most parties agreed that this is likely an implementation specific to ING's 
iDEAL service, hence the package has been renamed -- and keys in the properties 
files as well -- to reflect this as being a thirdparty.ideal.ing payment method.

The README file on the package has been updated to give improved reading and 
subject introduction.

Hope this finds acceptance with everyone.
Regards

Carsten

 iDEAL Configuration and Documentation
 -

 Key: OFBIZ-5298
 URL: https://issues.apache.org/jira/browse/OFBIZ-5298
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting
Affects Versions: SVN trunk
 Environment: --
Reporter: Carsten Schinzer
Priority: Minor
  Labels: payment-gateway
 Fix For: SVN trunk

 Attachments: OFBIZ-5298_iDEAL_Configuration_and_Documentation.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 From dev mailing list, Jacques Leroux:
 Hi Hans,
 Would it be possible to translate the iDEAL Configuration from Dutch to 
 English?
 See payment.properties and paymentTest.properties
 Also in IdealPaymentServiceTest.java, please use rather a properties for 
 merchantReturnURL than harcoded value.
 Maybe clean the 
 applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/readme file 
 (some †chars)
 Thanks
 I am opening this JIRA on behalf of the dutch crew: Hans Bakker, Eric  
 Heidi de Haes. Contributions from Eric Dehaes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5298) iDEAL Configuration and Documentation

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5298:
---

 Summary: iDEAL Configuration and Documentation
 Key: OFBIZ-5298
 URL: https://issues.apache.org/jira/browse/OFBIZ-5298
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting
Affects Versions: SVN trunk
 Environment: --
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk


From dev mailing list, Jacques Leroux:

Hi Hans,

Would it be possible to translate the iDEAL Configuration from Dutch to English?
See payment.properties and paymentTest.properties

Also in IdealPaymentServiceTest.java, please use rather a properties for 
merchantReturnURL than harcoded value.

Maybe clean the 
applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/readme file 
(some †chars)

Thanks

I am opening this JIRA on behalf of the dutch crew: Hans Bakker, Eric  Heidi 
de Haes. Contributions from Eric Dehaes.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Question: Product Screens, Suppliers, SupplierPrefOrderId

[Carsten Schinzer]

Hello Product Screen experts

There are questions i have regarding the values of attribute
SupplierPrefOrderId:

1) While from the name I would expect a free form text field to be filled,
it shows a drop down that allows to select Main Supplier or Alt
Supplier.
So why is this a select element and not a text field?

2)I find the values on select field useful as well to describe the role of
the supplier for a specific product in more detail, however, that attribute
should rather be a SupplierSubRole or similar attribute, no?

Anyone with knowledge whether this is a mistake or has a deeper sense that
I do not catch, please elucidate me.

Thanks and kind regards


Carsten

[jira] [Commented] (OFBIZ-5218) MRF Landing Page as Portal Page with some Portlet proposals

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692815#comment-13692815
 ] 

Carsten Schinzer commented on OFBIZ-5218:
-

Hello Julien,


thanks for that input. On your Sellers dashboards, I do have comments:
- Production status for an order -- is that better to put in a dashboard on 
the ordermgr? (sort of MyMrfOrders or similar). It might make sense to offer 
the Portlet on both entry screens and finally the idea i anyways to personalize 
the portlets.
- Delivery status: Clearly not in scope of the MRF, but rather the related 
Order and Facility views.

What do you think?

Regards


Carsten

 MRF Landing Page as Portal Page with some Portlet proposals
 ---

 Key: OFBIZ-5218
 URL: https://issues.apache.org/jira/browse/OFBIZ-5218
 Project: OFBiz
  Issue Type: Improvement
  Components: manufacturing
Affects Versions: SVN trunk
 Environment: any
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk

   Original Estimate: 120h
  Remaining Estimate: 120h

 I would like to introduce a portal page when landing into the manufacturing 
 component after login. Just as we have already on e.g. ordermgr.
 Ideas for portlets to be displayed are currently:
 - stats on configuration data (how many routings/routing tasks/boms/... are 
 configured)
 - stats on runtime data (how many production runs by status ...)
 - top ten list of runs by status or duration
 More ideas are welcome, of course.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5218) MRF Landing Page as Portal Page with some Portlet proposals

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5218:


Description: 
I would like to introduce a portal page when landing into the manufacturing 
component after login. Just as we have already on e.g. ordermgr.

Ideas for portlets to be displayed are currently:
- stats on configuration data (how many routings/routing tasks/boms/... are 
configured)
- stats on runtime data (how many production runs by status ...)
- top ten list of runs by status or duration

More ideas are welcome, of course !

My plan is to collect the requirements into a design document/sheet per portlet 
that I would attach here before moving on to implementation. For personal 
reasons I will not be able to start with the implementation design before ca. 
end July 2013.

Any other portlet ideas for MRP/MRF are appreciated until that deadline. Then I 
would like to close the scoping and start writing designs.

  was:
I would like to introduce a portal page when landing into the manufacturing 
component after login. Just as we have already on e.g. ordermgr.

Ideas for portlets to be displayed are currently:
- stats on configuration data (how many routings/routing tasks/boms/... are 
configured)
- stats on runtime data (how many production runs by status ...)
- top ten list of runs by status or duration

More ideas are welcome, of course.



 MRF Landing Page as Portal Page with some Portlet proposals
 ---

 Key: OFBIZ-5218
 URL: https://issues.apache.org/jira/browse/OFBIZ-5218
 Project: OFBiz
  Issue Type: Improvement
  Components: manufacturing
Affects Versions: SVN trunk
 Environment: any
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk

   Original Estimate: 120h
  Remaining Estimate: 120h

 I would like to introduce a portal page when landing into the manufacturing 
 component after login. Just as we have already on e.g. ordermgr.
 Ideas for portlets to be displayed are currently:
 - stats on configuration data (how many routings/routing tasks/boms/... are 
 configured)
 - stats on runtime data (how many production runs by status ...)
 - top ten list of runs by status or duration
 More ideas are welcome, of course !
 My plan is to collect the requirements into a design document/sheet per 
 portlet that I would attach here before moving on to implementation. For 
 personal reasons I will not be able to start with the implementation design 
 before ca. end July 2013.
 Any other portlet ideas for MRP/MRF are appreciated until that deadline. Then 
 I would like to close the scoping and start writing designs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Report formatting - Locale dependant ?

[Carsten Schinzer]

Hello all,


 A question for all non-US devs of OFBiz out there, possible with similar
problems than I have ... ideally Multitenant experience

I am getting into phases where my customers want me to print reports on DIN
A4 paper (German / European norm, 21 x 29.7 cm).
Moreover, I want to customize the layout of official PDF documents to
country habits or customer habits.

Is there a way to customize e.g. InvoicePDF laytout without touching the
report template in the accounting component?
Is there a way to handle this per Party / PartyGroup or at least (in
Multitenancy mode) per Tenant?

I am thinking of a Locale-dependant report template in the first place.

Anyone out there who did similar tweaking? Any hint that I have missed a
well-known on-board feature?

Thanks for your comments !


Carsten

Re: Report formatting - Locale dependant ?

[Carsten Schinzer]

Thanks. Will do.

Regards

Carsten


2013/6/13 Adrian Crum adrian.c...@sandglass-software.com

 There are A4 page masters in the common component.

 Look at the GlobalFoDecorator widget in CommonScreens.xml, and the related
 FreeMarker templates.

 -Adrian


 On 6/13/2013 3:22 PM, Carsten Schinzer wrote:

 Hello all,


  A question for all non-US devs of OFBiz out there, possible with similar

 problems than I have ... ideally Multitenant experience

 I am getting into phases where my customers want me to print reports on
 DIN
 A4 paper (German / European norm, 21 x 29.7 cm).
 Moreover, I want to customize the layout of official PDF documents to
 country habits or customer habits.

 Is there a way to customize e.g. InvoicePDF laytout without touching the
 report template in the accounting component?
 Is there a way to handle this per Party / PartyGroup or at least (in
 Multitenancy mode) per Tenant?

 I am thinking of a Locale-dependant report template in the first place.

 Anyone out there who did similar tweaking? Any hint that I have missed a
 well-known on-board feature?

 Thanks for your comments !


 Carsten

[jira] [Created] (OFBIZ-5218) MRF Landing Page as Portal Page with some Portlet proposals

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5218:
---

 Summary: MRF Landing Page as Portal Page with some Portlet 
proposals
 Key: OFBIZ-5218
 URL: https://issues.apache.org/jira/browse/OFBIZ-5218
 Project: OFBiz
  Issue Type: Improvement
  Components: manufacturing
Affects Versions: SVN trunk
 Environment: any
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk


I would like to introduce a portal page when landing into the manufacturing 
component after login. Just as we have already on e.g. ordermgr.

Ideas for portlets to be displayed are currently:
- stats on configuration data (how many routings/routing tasks/boms/... are 
configured)
- stats on runtime data (how many production runs by status ...)
- top ten list of runs by status or duration

More ideas are welcome, of course.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5208) Missing UI Labels for Product Comparison

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5208:


Remaining Estimate: 0.5h
 Original Estimate: 0.5h

 Missing UI Labels for Product Comparison
 

 Key: OFBIZ-5208
 URL: https://issues.apache.org/jira/browse/OFBIZ-5208
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: SVN trunk
 Environment: xml conifguration file   
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 UI Labels for Product COmparison screenlet are not available in de Locale

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5208) Missing UI Labels for Product Comparison

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5208:
---

 Summary: Missing UI Labels for Product Comparison
 Key: OFBIZ-5208
 URL: https://issues.apache.org/jira/browse/OFBIZ-5208
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: SVN trunk
 Environment: xml conifguration file
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk


UI Labels for Product COmparison screenlet are not available in de Locale

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5208) Missing de UI Labels for Product Comparison

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5208:


Summary: Missing de UI Labels for Product Comparison  (was: Missing UI 
Labels for Product Comparison)

 Missing de UI Labels for Product Comparison
 ---

 Key: OFBIZ-5208
 URL: https://issues.apache.org/jira/browse/OFBIZ-5208
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: SVN trunk
 Environment: xml conifguration file   
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 UI Labels for Product COmparison screenlet are not available in de Locale

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5190) Missing UI Label translations to de Locale for Tags

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5190:
---

 Summary: Missing UI Label translations to de Locale for Tags
 Key: OFBIZ-5190
 URL: https://issues.apache.org/jira/browse/OFBIZ-5190
 Project: OFBiz
  Issue Type: Improvement
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
 Environment: xml config
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk


UI Label translations are missing for the PriductTag UI elements on the 
EcommerceUiLabels.xml for Locale de.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5190) Missing UI Label translations to de Locale for Tags

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5190:


Remaining Estimate: 0.5h
 Original Estimate: 0.5h

 Missing UI Label translations to de Locale for Tags
 ---

 Key: OFBIZ-5190
 URL: https://issues.apache.org/jira/browse/OFBIZ-5190
 Project: OFBiz
  Issue Type: Improvement
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
 Environment: xml config
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 UI Label translations are missing for the PriductTag UI elements on the 
 EcommerceUiLabels.xml for Locale de.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5190) Missing UI Label translations to de Locale for Tags

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5190:


Attachment: 
OFBIZ-5190_Missing_UI_Label_translations_to_de_Locale_for_Tags.patch

 Missing UI Label translations to de Locale for Tags
 ---

 Key: OFBIZ-5190
 URL: https://issues.apache.org/jira/browse/OFBIZ-5190
 Project: OFBiz
  Issue Type: Improvement
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
 Environment: xml config
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

 Attachments: 
 OFBIZ-5190_Missing_UI_Label_translations_to_de_Locale_for_Tags.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 UI Label translations are missing for the PriductTag UI elements on the 
 EcommerceUiLabels.xml for Locale de.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Commented] (OFBIZ-5179) checkExternalPayment returns payflowpro instead of paypal

[Carsten Schinzer]

Hello Mirko,


The Java class works OK. It is the integration with the checkout process
that is the culprit here.

I understand the following at present:

- PayPal Express Checkout allows/demands to register the current party with
PayPal before any shipment address or use details are even captured through
a UI
- PayPal payment (party and shipment details already captured) flow is
initiated before the Order is created, ie. all order details are still on
the ShoppingCart

When studying the Java class, I found that there are context objects read
(or better attempted to be read) which are not present a checkout time, but
only once the order is confirmed.

Similar to googlecheckout component, I would like to see a paypalcheckout
component here which will fulfill the requirements of a two phase commit on
checkout, which is also enforced by PayPal ie:
- preregister the order with PayPal; at this time on the OFBiz side only a
session with a ShoppingCart exists -- setPayPalCheckout, retrieve PayPal
Token
- optionally retrieve the customer's data from PayPal (when using
ExpressCheckout; this avoids lenghty registration forms on the shop's side)
-- getPayPalCheckout
- create the order once customer confirms order -- doPayPalCheckout

If the customer changes anyting later on the order (e.g. cancels it), then
updatePayPalCheckout method will be used to communicate that to PayPal.

From your comment, I assume you create the Order before even contacting
PayPal. Is that correct?

Also, I see there are more methods defined on the PayPal NVP API, I assume
those are use on the accounting side to do CRUD operations on the PayPal
account / it's reflection in OFBiz accounting.

Let me know whether this clarifies, please, or whether I am completely
wrong.
I've spent quite some effort to get things straight for the 2-phase-commit
on checkout and also segregated the PayPalServices.java into three:
PaypalUtil.java, PayPalServices.java and PayPalCheckout.java.

Kind regards


Carsten

PS: I also hope this is concrete enough for your purpose?


2013/5/1 Mirko Vogelsmeier (JIRA) j...@apache.org


 [
 https://issues.apache.org/jira/browse/OFBIZ-5179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13646204#comment-13646204]

 Mirko Vogelsmeier commented on OFBIZ-5179:
 --

 Hello Carsten,
 i did reviewed the function of the paypal interface just some months ago
 and it worked fine for me.
 PayPal contiditions are met is a little to abstract to exactly point out
 a bug there might be.

 About simple methods: I rather guess that the interface integration is not
 designed to use the OFBiz Simple-Methods (which to be honest im pretty glad
 about :D ). Or did i missinterpret the problem?

 CheckOutEvents#checkExternalPayment checks the defined OrderPaymentPref
 for the currently definied paymentMethod. Maybe your issue is while
 creating / working with the order?

 It would be helpfull if you create tickets for concrete problems (eg.
 inconsistent ways to get a locale) and refere to the users mailinglist for
 configuration issues with payment-regarding issues.

 Greetings,
 Mirko


  checkExternalPayment returns payflowpro instead of paypal
  -
 
  Key: OFBIZ-5179
  URL: https://issues.apache.org/jira/browse/OFBIZ-5179
  Project: OFBiz
   Issue Type: Bug
   Components: accounting
 Affects Versions: SVN trunk
  Environment: independant
 Reporter: Carsten Schinzer
  Fix For: SVN trunk
 
Original Estimate: 1h
   Remaining Estimate: 1h
 
  The following method contains a false return value:
  org.ofbiz.order.schoppingcart.CheckOutEvents#checkExternalPayment
  It verifies a Paypal payment method is defined for the ProductStore, but
 then returns a value 'payflowpro' in return which is clearly false as
 PayFlowPro is a separate external payment method.
  The patch/fix will allow to check for both, PayPal and PayFlowPro as
 external payment methods.

 --
 This message is automatically generated by JIRA.
 If you think it was sent incorrectly, please contact your JIRA
 administrators
 For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5181) missing de UI Labels in Accounting

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5181:


Attachment: OFBIZ-5181_missing_de_UI_Labels_in_Accounting.patch

better patch now :-/

 missing de UI Labels in Accounting
 --

 Key: OFBIZ-5181
 URL: https://issues.apache.org/jira/browse/OFBIZ-5181
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting
Affects Versions: SVN trunk
 Environment: XML configuration files, independant
Reporter: Carsten Schinzer
Assignee: Christian Geisert
Priority: Minor
 Fix For: SVN trunk

 Attachments: mylyn-context.zip, 
 OFBIZ-5181_missing_de_UI_Labels_in_Accounting.patch, 
 OFBIZ-5181_missing_de_UI_Labels_in_Accounting.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Mainly labels in the context of PayPal payment services utilisation in 
 accounting have been extended by UI labels for de language

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5181) missing de UI Labels in Accounting

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5181:


Attachment: (was: mylyn-context.zip)

 missing de UI Labels in Accounting
 --

 Key: OFBIZ-5181
 URL: https://issues.apache.org/jira/browse/OFBIZ-5181
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting
Affects Versions: SVN trunk
 Environment: XML configuration files, independant
Reporter: Carsten Schinzer
Assignee: Christian Geisert
Priority: Minor
 Fix For: SVN trunk

 Attachments: OFBIZ-5181_missing_de_UI_Labels_in_Accounting.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Mainly labels in the context of PayPal payment services utilisation in 
 accounting have been extended by UI labels for de language

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5181) missing de UI Labels in Accounting

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5181:


Attachment: (was: OFBIZ-5181_missing_de_UI_Labels_in_Accounting.patch)

 missing de UI Labels in Accounting
 --

 Key: OFBIZ-5181
 URL: https://issues.apache.org/jira/browse/OFBIZ-5181
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting
Affects Versions: SVN trunk
 Environment: XML configuration files, independant
Reporter: Carsten Schinzer
Assignee: Christian Geisert
Priority: Minor
 Fix For: SVN trunk

 Attachments: OFBIZ-5181_missing_de_UI_Labels_in_Accounting.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Mainly labels in the context of PayPal payment services utilisation in 
 accounting have been extended by UI labels for de language

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5182) LoginServices.userLogin add info to fail message

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5182:


Attachment: OFBIZ-5182_LoginServices.userLogin_add_info.patch

better patch file

 LoginServices.userLogin add info to fail message
 

 Key: OFBIZ-5182
 URL: https://issues.apache.org/jira/browse/OFBIZ-5182
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
 Environment: java class
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

 Attachments: OFBIZ-5182_LoginServices.userLogin_add_info.patch, 
 OFBIZ-5182_LoginServices.userLogin_add_info.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 The LoginServices only specify that a user was not found, but it is of 
 interest which user was not found.
 I added that to the log message in the error case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5182) LoginServices.userLogin add info to fail message

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5182:


Attachment: (was: OFBIZ-5182_LoginServices.userLogin_add_info.patch)

 LoginServices.userLogin add info to fail message
 

 Key: OFBIZ-5182
 URL: https://issues.apache.org/jira/browse/OFBIZ-5182
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
 Environment: java class
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

 Attachments: OFBIZ-5182_LoginServices.userLogin_add_info.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 The LoginServices only specify that a user was not found, but it is of 
 interest which user was not found.
 I added that to the log message in the error case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Commented] (OFBIZ-5181) missing de UI Labels in Accounting

[Carsten Schinzer]

I'll create a new one.
That is an issue with Eclipse on Mac.


2013/4/20 Christian Geisert (JIRA) j...@apache.org


 [
 https://issues.apache.org/jira/browse/OFBIZ-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13637366#comment-13637366]

 Christian Geisert commented on OFBIZ-5181:
 --

 The patch file looks wrong (no new DE labels, rather removal of all
 labels...)

  missing de UI Labels in Accounting
  --
 
  Key: OFBIZ-5181
  URL: https://issues.apache.org/jira/browse/OFBIZ-5181
  Project: OFBiz
   Issue Type: Improvement
   Components: accounting
 Affects Versions: SVN trunk
  Environment: XML configuration files, independant
 Reporter: Carsten Schinzer
 Assignee: Christian Geisert
 Priority: Minor
  Fix For: SVN trunk
 
  Attachments: mylyn-context.zip,
 OFBIZ-5181_missing_de_UI_Labels_in_Accounting.patch
 
Original Estimate: 1h
   Remaining Estimate: 1h
 
  Mainly labels in the context of PayPal payment services utilisation in
 accounting have been extended by UI labels for de language

 --
 This message is automatically generated by JIRA.
 If you think it was sent incorrectly, please contact your JIRA
 administrators
 For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5182) LoginServices.userLogin add info to fail message

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5182:


Remaining Estimate: 0.5h
 Original Estimate: 0.5h

 LoginServices.userLogin add info to fail message
 

 Key: OFBIZ-5182
 URL: https://issues.apache.org/jira/browse/OFBIZ-5182
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
 Environment: java class
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 The LoginServices only specify that a user was not found, but it is of 
 interest which user was not found.
 I added that to the log message in the error case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5182) LoginServices.userLogin add info to fail message

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5182:
---

 Summary: LoginServices.userLogin add info to fail message
 Key: OFBIZ-5182
 URL: https://issues.apache.org/jira/browse/OFBIZ-5182
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
 Environment: java class
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk


The LoginServices only specify that a user was not found, but it is of interest 
which user was not found.
I added that to the log message in the error case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5182) LoginServices.userLogin add info to fail message

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5182:


Attachment: OFBIZ-5182_LoginServices.userLogin_add_info.patch

 LoginServices.userLogin add info to fail message
 

 Key: OFBIZ-5182
 URL: https://issues.apache.org/jira/browse/OFBIZ-5182
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
 Environment: java class
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

 Attachments: OFBIZ-5182_LoginServices.userLogin_add_info.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 The LoginServices only specify that a user was not found, but it is of 
 interest which user was not found.
 I added that to the log message in the error case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5182) LoginServices.userLogin add info to fail message

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13636178#comment-13636178
 ] 

Carsten Schinzer commented on OFBIZ-5182:
-

patching the log at line 412

 LoginServices.userLogin add info to fail message
 

 Key: OFBIZ-5182
 URL: https://issues.apache.org/jira/browse/OFBIZ-5182
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
 Environment: java class
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

 Attachments: OFBIZ-5182_LoginServices.userLogin_add_info.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 The LoginServices only specify that a user was not found, but it is of 
 interest which user was not found.
 I added that to the log message in the error case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

ref. OFBIZ-5179 -- Paypal Checkout

[Carsten Schinzer]

Guys,


after 3 days of reserach and trying to make this work, I conclude that the
PayPal services are not usable ootb. Any comments?

The following is missing from my PoV:

- services incomplete / wrong interface services defined
- PayPalServices.java is not efficiently using context and existing Workers
(for Cart and Store)
- documentation outdated (PayPal calls the PROD environment 'live', not
'PROD')
- redirect screen definitions for PayPal checkout also missing
- ...

Either I am entirely on the wrong path here, or the suggestive Just add
your paypal configuraiton and it will work on the OFBiz Business Setup
guide is a joke.

Otherwise I propose to make it work in my webapp and contribute all missing
items to the abovementioned JIRA.

Also I noticed for GoogleCheckout there is an entire component in
specialpurpose.
Does it make sense to externalize the PayPal checkout in a similar way?
Is the integration made in Accounting eventually limited to PayPal payments
checking and not for ECommerce Store payments?

Can anyone please comment who recently added PayPal services to their
webapp?

Regards


Carsten

Re: ref. OFBIZ-5179 -- Paypal Checkout

[Carsten Schinzer]

Hello and thanks for the tip. And apologies for the wording. Last
functional change on the services classes in accounting.payment.thirdparty
seems to date from early 2010.
It seems really really outdated.
Either no-one is using PayPal any more, at least not recently, or people
have their secrets ;-)

I'll open a new JIRA to describe issue and the solution I have in mind and
make the above JIRA a dependant child of it to avoid confusion.

Regards

Carsten


2013/4/19 Adrian Crum adrian.c...@sandglass-software.com

 One thing I usually include in my research is the commit history for the
 files being analyzed. If there hasn't been any commit activity lately, then
 most likely the code has become out-of-date.

 So, the instructions in the Business Setup Guide might be outdated, but
 they were never a joke.

 -Adrian


 On 4/19/2013 9:40 AM, Carsten Schinzer wrote:

 Guys,


 after 3 days of reserach and trying to make this work, I conclude that the
 PayPal services are not usable ootb. Any comments?

 The following is missing from my PoV:

 - services incomplete / wrong interface services defined
 - PayPalServices.java is not efficiently using context and existing
 Workers
 (for Cart and Store)
 - documentation outdated (PayPal calls the PROD environment 'live', not
 'PROD')
 - redirect screen definitions for PayPal checkout also missing
 - ...

 Either I am entirely on the wrong path here, or the suggestive Just add
 your paypal configuraiton and it will work on the OFBiz Business Setup
 guide is a joke.

 Otherwise I propose to make it work in my webapp and contribute all
 missing
 items to the abovementioned JIRA.

 Also I noticed for GoogleCheckout there is an entire component in
 specialpurpose.
 Does it make sense to externalize the PayPal checkout in a similar way?
 Is the integration made in Accounting eventually limited to PayPal
 payments
 checking and not for ECommerce Store payments?

 Can anyone please comment who recently added PayPal services to their
 webapp?

 Regards


 Carsten

[jira] [Created] (OFBIZ-5181) missing de UI Labels in Accounting

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5181:
---

 Summary: missing de UI Labels in Accounting
 Key: OFBIZ-5181
 URL: https://issues.apache.org/jira/browse/OFBIZ-5181
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting
Affects Versions: SVN trunk
 Environment: XML configuration files, independant
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk


Mainly labels in the context of PayPal payment services utilisation in 
accounting have been extended by UI labels for de language

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5181) missing de UI Labels in Accounting

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5181:


Remaining Estimate: 1h
 Original Estimate: 1h

 missing de UI Labels in Accounting
 --

 Key: OFBIZ-5181
 URL: https://issues.apache.org/jira/browse/OFBIZ-5181
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting
Affects Versions: SVN trunk
 Environment: XML configuration files, independant
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk

   Original Estimate: 1h
  Remaining Estimate: 1h

 Mainly labels in the context of PayPal payment services utilisation in 
 accounting have been extended by UI labels for de language

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5179) checkExternalPayment returns payflowpro instead of paypal

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5179:


Summary: checkExternalPayment returns payflowpro instead of paypal  (was: 
cehckExternalPayment returns payflowpro instead of paypal)

 checkExternalPayment returns payflowpro instead of paypal
 -

 Key: OFBIZ-5179
 URL: https://issues.apache.org/jira/browse/OFBIZ-5179
 Project: OFBiz
  Issue Type: Bug
  Components: accounting
Affects Versions: SVN trunk
 Environment: independant
Reporter: Carsten Schinzer
 Fix For: SVN trunk

   Original Estimate: 1h
  Remaining Estimate: 1h

 The following method contains a false return value:
 org.ofbiz.order.schoppingcart.CheckOutEvents#checkExternalPayment
 It verifies a Paypal payment method is defined for the ProductStore, but then 
 returns a value 'payflowpro' in return which is clearly false as PayFlowPro 
 is a separate external payment method.
 The patch/fix will allow to check for both, PayPal and PayFlowPro as external 
 payment methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5179) checkExternalPayment returns payflowpro instead of paypal

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13634171#comment-13634171
 ] 

Carsten Schinzer commented on OFBIZ-5179:
-

The scope of this creeps unfortunately. It turns out that PayPal services are 
apparently not ootb usable, the following seem to be missing before they will 
work:

- checkExternalPayment returns the wrong value when PayPal contiditions are met
- although PayPaylServices.java is there and respective java servicedef is also 
in place, the mapping of context parameters for service execution is entirely 
missing, ie
-- Simple Method Map Processings are missing
-- Simple Method Events are missing
-- Simple Method Services are missing
- IN map parameters also need to be reviewed as the interface methods only 
partially define the required parameters that are used and accessed in 
PayPalServices.java
- some review might be required for consistent parameter use on 
PayPalServices.java as well (I already found eg. the Locale being accessed 
through the cart and directly on context)

On top of that, the de translations on the payPalEvents are also missing. (I 
got the full pacakge here :D) that will be tracked on a separate JIRA though, 
since it is only mutually related to this one.

I have reviewed the estimated effort and upped it to 4 hrs.


 checkExternalPayment returns payflowpro instead of paypal
 -

 Key: OFBIZ-5179
 URL: https://issues.apache.org/jira/browse/OFBIZ-5179
 Project: OFBiz
  Issue Type: Bug
  Components: accounting
Affects Versions: SVN trunk
 Environment: independant
Reporter: Carsten Schinzer
 Fix For: SVN trunk

   Original Estimate: 1h
  Remaining Estimate: 1h

 The following method contains a false return value:
 org.ofbiz.order.schoppingcart.CheckOutEvents#checkExternalPayment
 It verifies a Paypal payment method is defined for the ProductStore, but then 
 returns a value 'payflowpro' in return which is clearly false as PayFlowPro 
 is a separate external payment method.
 The patch/fix will allow to check for both, PayPal and PayFlowPro as external 
 payment methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5181) missing de UI Labels in Accounting

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5181:


Attachment: OFBIZ-5181_missing_de_UI_Labels_in_Accounting.patch

 missing de UI Labels in Accounting
 --

 Key: OFBIZ-5181
 URL: https://issues.apache.org/jira/browse/OFBIZ-5181
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting
Affects Versions: SVN trunk
 Environment: XML configuration files, independant
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk

 Attachments: mylyn-context.zip, 
 OFBIZ-5181_missing_de_UI_Labels_in_Accounting.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Mainly labels in the context of PayPal payment services utilisation in 
 accounting have been extended by UI labels for de language

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5181) missing de UI Labels in Accounting

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5181:


Attachment: mylyn-context.zip

 missing de UI Labels in Accounting
 --

 Key: OFBIZ-5181
 URL: https://issues.apache.org/jira/browse/OFBIZ-5181
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting
Affects Versions: SVN trunk
 Environment: XML configuration files, independant
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk

 Attachments: mylyn-context.zip, 
 OFBIZ-5181_missing_de_UI_Labels_in_Accounting.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Mainly labels in the context of PayPal payment services utilisation in 
 accounting have been extended by UI labels for de language

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5179) cehckExternalPayment returns payflowpro instead of paypal

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5179:
---

 Summary: cehckExternalPayment returns payflowpro instead of paypal
 Key: OFBIZ-5179
 URL: https://issues.apache.org/jira/browse/OFBIZ-5179
 Project: OFBiz
  Issue Type: Bug
  Components: accounting
Affects Versions: SVN trunk
 Environment: independant
Reporter: Carsten Schinzer
 Fix For: SVN trunk


The following method contains a false return value:

org.ofbiz.order.schoppingcart.CheckOutEvents#checkExternalPayment

It verifies a Paypal payment method is defined for the ProductStore, but then 
returns a value 'payflowpro' in return which is clearly false as PayFlowPro is 
a separate external payment method.
The patch/fix will allow to check for both, PayPal and PayFlowPro as external 
payment methods.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5179) cehckExternalPayment returns payflowpro instead of paypal

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5179:


Remaining Estimate: 1h
 Original Estimate: 1h

 cehckExternalPayment returns payflowpro instead of paypal
 -

 Key: OFBIZ-5179
 URL: https://issues.apache.org/jira/browse/OFBIZ-5179
 Project: OFBiz
  Issue Type: Bug
  Components: accounting
Affects Versions: SVN trunk
 Environment: independant
Reporter: Carsten Schinzer
 Fix For: SVN trunk

   Original Estimate: 1h
  Remaining Estimate: 1h

 The following method contains a false return value:
 org.ofbiz.order.schoppingcart.CheckOutEvents#checkExternalPayment
 It verifies a Paypal payment method is defined for the ProductStore, but then 
 returns a value 'payflowpro' in return which is clearly false as PayFlowPro 
 is a separate external payment method.
 The patch/fix will allow to check for both, PayPal and PayFlowPro as external 
 payment methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: PAYPAL vs PAYFLOWPRO

[Carsten Schinzer]

After some more study on code and datamodel I have now opened: OFBIZ-5179.


2013/4/15 Carsten Schinzer c.schin...@gmail.com

 All,


 I realize that PAYPAL vs. PAYFLOWPRO payment gateways are not the same and
 actually

 org.ofbiz.order.shoppingcart.CheckOutEvents.java#checkExternalCheckout
 only returns paypal when actually the related paymentGatewayConfigTypeId
 is PAYFLOWPRO.

 How can I use simple Paypal Express checkout defined on my (separate)
 PaymentGateway cofnig with paymentGatewayConfigTypeId = PAYPAL ?

 Bug, Jira etc: ? Or is the intention to deprecate PAYPAL and go for
 PAYFLOWPRO rather than allow two different Paypal gateways ?

 Thanks for a quick hint!
 Regards


 Carsten

PAYPAL vs PAYFLOWPRO

[Carsten Schinzer]

All,


I realize that PAYPAL vs. PAYFLOWPRO payment gateways are not the same and
actually

org.ofbiz.order.shoppingcart.CheckOutEvents.java#checkExternalCheckout
only returns paypal when actually the related paymentGatewayConfigTypeId
is PAYFLOWPRO.

How can I use simple Paypal Express checkout defined on my (separate)
PaymentGateway cofnig with paymentGatewayConfigTypeId = PAYPAL ?

Bug, Jira etc: ? Or is the intention to deprecate PAYPAL and go for
PAYFLOWPRO rather than allow two different Paypal gateways ?

Thanks for a quick hint!
Regards


Carsten

[jira] [Created] (OFBIZ-5131) Review ServletFilter architecture and Servlet vs Session vs Request objects

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5131:
---

 Summary: Review ServletFilter architecture and Servlet vs Session 
vs Request objects
 Key: OFBIZ-5131
 URL: https://issues.apache.org/jira/browse/OFBIZ-5131
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Carsten Schinzer


Diving deep into the framework and how it has implemented the basic web 
framework artifacts such as: ControlServlet, Filters etc. there are multiple 
inconsistencies discovered which require improvement in order to apply (JEE) 
Standard Techniques to implement features such as the handling of objects 
required at rendering time (request objects), within a session (Session 
Objects) or outside (default Servlet Configuration).
Further to this, often code artifacts are found that manipulate the 
ServletContext during lifetime while this really should not happend as it 
causes inconsistent behaviour of the Servlet outside the foreseen 
customizations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5100) Delegator name is expected to be always default which is not the right approac

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13574404#comment-13574404
 ] 

Carsten Schinzer commented on OFBIZ-5100:
-

Webapp delegators:
AFAIK the (default) delegatorName is specified on each and every ServletContext 
(ie. each web.xml contains the respectve init-parameter). If there was 
consistent handling of ServletContext (eg. no overwrite of it's init-parameters 
and attributes), there would be no situation where the use of a hardcoded 
delegatorname is necessary: The ServletContext would always contain the 
(user-defined) delegator name as an init-parameter and -- once the Servlet is 
initialized -- the ServletContext would also contain a proper attribute that 
holds respective the delegator object.

I am going to propose this solution on OFBIZ-5131 as part of the overall rework 
of the Servlet and Filter objects.

How would a similar mechanism work for Engine delegators:


 Delegator name is expected to be always default which is not the right 
 approac
 

 Key: OFBIZ-5100
 URL: https://issues.apache.org/jira/browse/OFBIZ-5100
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release 10.04
 Environment: All Environments
Reporter: Tarun Kumar
  Labels: entity-condition, entityengine

 h4. Problem
 For the below delegator configuration with a delegator.find call to a view 
 Entity Engine is throwing error due wrong code in EntityExpr class
 {code:xml}
 delegator name=newName entity-model-reader=main 
 entity-group-reader=main
 group-map group-name=pegasus datasource-name=pegasus/
 group-map group-name=Bookstore datasource-name=bookstore/
 /delegator
 {code:xml}
 The code in EntityExpr.java
 {code:java}
   if (delegator == null) {
 // this will be the common case for now as the delegator isn't 
 available where we want to do this
 // we'll cheat a little here and assume the default delegator
 delegator = DelegatorFactory.getDelegator(default);
 }
 {code}
 assumes the delegator name is default, instead it should use the delegator 
 name kept in xml configuration.
 h4. How to reproduce?
 1. Change the delegator name to something else from default
 2. Keep a view in entitymodel.xml
 {code:xml}
 view-entity entity-name=simpleView
  package-name=org.ofbiz.entity.dummy
  title=Dummy
 member-entity entity-alias=cl entity-name=c1/
 member-entity entity-alias=ac entity-name=a1/
 alias-all entity-alias=ac name=id /
 alias-all entity-alias=cl name=id/
 alias-all entity-alias=cl name=firstName/
 alias-all entity-alias=cl name=sponsor/
 alias-all entity-alias=ac name=title/
 view-link entity-alias=ac rel-entity-alias=cl
key-map field-name=id rel-field-name=id/
 /view-link
 relation type=one title=one rel-entity-name=cl
 key-map field-name=id /
 /relation
 /view-entity
 {code}
 3. Use this like below,
 {code:java}
 Delegator delegator = DelegatorFactory.getDelegator(newName);
 ListEntityExpr 
 expr=UtilMisc.toList(EntityCondition.makeCondition(sponsor,EntityOperator.EQUALS,
  Long.valueOf(1)));
 EntityListIterator listIterator=delegator.find(simpleView, 
 EntityCondition.makeCondition(expr, EntityOperator.OR), null,fieldToSelct, 
 UtilMisc.toList(id), null);
 {code}
 It will throw GenericEntityException due to default is hard coded in 
 EntityExpr.java
 Please let me know if I can submit a patch for this to avoid hard coded 
 delegator name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5100) Delegator name is expected to be always default which is not the right approac

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13574480#comment-13574480
 ] 

Carsten Schinzer commented on OFBIZ-5100:
-

My last sentence should end with a question mark ? not a colon:.

 Delegator name is expected to be always default which is not the right 
 approac
 

 Key: OFBIZ-5100
 URL: https://issues.apache.org/jira/browse/OFBIZ-5100
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release 10.04
 Environment: All Environments
Reporter: Tarun Kumar
  Labels: entity-condition, entityengine

 h4. Problem
 For the below delegator configuration with a delegator.find call to a view 
 Entity Engine is throwing error due wrong code in EntityExpr class
 {code:xml}
 delegator name=newName entity-model-reader=main 
 entity-group-reader=main
 group-map group-name=pegasus datasource-name=pegasus/
 group-map group-name=Bookstore datasource-name=bookstore/
 /delegator
 {code:xml}
 The code in EntityExpr.java
 {code:java}
   if (delegator == null) {
 // this will be the common case for now as the delegator isn't 
 available where we want to do this
 // we'll cheat a little here and assume the default delegator
 delegator = DelegatorFactory.getDelegator(default);
 }
 {code}
 assumes the delegator name is default, instead it should use the delegator 
 name kept in xml configuration.
 h4. How to reproduce?
 1. Change the delegator name to something else from default
 2. Keep a view in entitymodel.xml
 {code:xml}
 view-entity entity-name=simpleView
  package-name=org.ofbiz.entity.dummy
  title=Dummy
 member-entity entity-alias=cl entity-name=c1/
 member-entity entity-alias=ac entity-name=a1/
 alias-all entity-alias=ac name=id /
 alias-all entity-alias=cl name=id/
 alias-all entity-alias=cl name=firstName/
 alias-all entity-alias=cl name=sponsor/
 alias-all entity-alias=ac name=title/
 view-link entity-alias=ac rel-entity-alias=cl
key-map field-name=id rel-field-name=id/
 /view-link
 relation type=one title=one rel-entity-name=cl
 key-map field-name=id /
 /relation
 /view-entity
 {code}
 3. Use this like below,
 {code:java}
 Delegator delegator = DelegatorFactory.getDelegator(newName);
 ListEntityExpr 
 expr=UtilMisc.toList(EntityCondition.makeCondition(sponsor,EntityOperator.EQUALS,
  Long.valueOf(1)));
 EntityListIterator listIterator=delegator.find(simpleView, 
 EntityCondition.makeCondition(expr, EntityOperator.OR), null,fieldToSelct, 
 UtilMisc.toList(id), null);
 {code}
 It will throw GenericEntityException due to default is hard coded in 
 EntityExpr.java
 Please let me know if I can submit a patch for this to avoid hard coded 
 delegator name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5100) Delegator name is expected to be always default which is not the right approac

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558269#comment-13558269
 ] 

Carsten Schinzer commented on OFBIZ-5100:
-

Indeed ... I must have been very sleepy ... apologies and thanks Jacques for 
the clarification.

 Delegator name is expected to be always default which is not the right 
 approac
 

 Key: OFBIZ-5100
 URL: https://issues.apache.org/jira/browse/OFBIZ-5100
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release 10.04
 Environment: All Environments
Reporter: Tarun Kumar
  Labels: entity-condition, entityengine

 h4. Problem
 For the below delegator configuration with a delegator.find call to a view 
 Entity Engine is throwing error due wrong code in EntityExpr class
 {code:xml}
 delegator name=newName entity-model-reader=main 
 entity-group-reader=main
 group-map group-name=pegasus datasource-name=pegasus/
 group-map group-name=Bookstore datasource-name=bookstore/
 /delegator
 {code:xml}
 The code in EntityExpr.java
 {code:java}
   if (delegator == null) {
 // this will be the common case for now as the delegator isn't 
 available where we want to do this
 // we'll cheat a little here and assume the default delegator
 delegator = DelegatorFactory.getDelegator(default);
 }
 {code}
 assumes the delegator name is default, instead it should use the delegator 
 name kept in xml configuration.
 h4. How to reproduce?
 1. Change the delegator name to something else from default
 2. Keep a view in entitymodel.xml
 {code:xml}
 view-entity entity-name=simpleView
  package-name=org.ofbiz.entity.dummy
  title=Dummy
 member-entity entity-alias=cl entity-name=c1/
 member-entity entity-alias=ac entity-name=a1/
 alias-all entity-alias=ac name=id /
 alias-all entity-alias=cl name=id/
 alias-all entity-alias=cl name=firstName/
 alias-all entity-alias=cl name=sponsor/
 alias-all entity-alias=ac name=title/
 view-link entity-alias=ac rel-entity-alias=cl
key-map field-name=id rel-field-name=id/
 /view-link
 relation type=one title=one rel-entity-name=cl
 key-map field-name=id /
 /relation
 /view-entity
 {code}
 3. Use this like below,
 {code:java}
 Delegator delegator = DelegatorFactory.getDelegator(newName);
 ListEntityExpr 
 expr=UtilMisc.toList(EntityCondition.makeCondition(sponsor,EntityOperator.EQUALS,
  Long.valueOf(1)));
 EntityListIterator listIterator=delegator.find(simpleView, 
 EntityCondition.makeCondition(expr, EntityOperator.OR), null,fieldToSelct, 
 UtilMisc.toList(id), null);
 {code}
 It will throw GenericEntityException due to default is hard coded in 
 EntityExpr.java
 Please let me know if I can submit a patch for this to avoid hard coded 
 delegator name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5019) Multitenant delegator assignment not working correctly

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558277#comment-13558277
 ] 

Carsten Schinzer commented on OFBIZ-5019:
-

Meanwhile I did some research in the codebase regarding the question where the 
various code bits to lookup a delegator parameter. Search for 
'.getAttribute(delegator) in any java file of hte code base results 
basically as follows:
- ContextFilter and LoginWorker do lookup such attributes from Session, Visit 
and HttpRequest
while
- any other java class does this lookup from HttpRequest

Yet, I do not find any hint how the basic delegator lookup for backoffice 
applications work except the following:
- when excluding the rewrite of delegatorName in the ServletContext from 
ContextFilter, the backoffice apps do not show tenant data.
- when explicitly rewriting the ServletContex's attribute called delegator, 
then the backoffice applications do show tenant data

I am looking for any hint that would show how (or where) the backoffice 
applications lookup the delegator to use.


 Multitenant delegator assignment not working  correctly
 ---

 Key: OFBIZ-5019
 URL: https://issues.apache.org/jira/browse/OFBIZ-5019
 Project: OFBiz
  Issue Type: Bug
  Components: ALL APPLICATIONS, framework
Affects Versions: SVN trunk
 Environment: multitenantuse = Y
 Tenant with no Domain setting or Tenant using different domain for backend 
 applications
Reporter: Carsten Schinzer
  Labels: authentication, context, multitenancy, security
 Attachments: 
 OFBIZ-5019_Multitenant_delegator_assignment_not_working_correctly.patch

   Original Estimate: 168h
  Remaining Estimate: 168h

 This issue arises when Multitenancy is in use. It arises only on backend 
 applications (as typically the frontend store applications will use a context 
 variable defined in web.xml to determin the delegator to be used (ie. the 
 database to use for data lookups etc).
 The issue manifests as follows:
 * the wrong data is read for standard backoffice displays (e.g. orders, 
 accounts, etc.); it is the dataa from the default datasource, not the 
 tenant´s data source
 * in the backend apps certain functions require authentication (checked 
 dynamically) and this will fail when the default delegator is used since the 
 tenant's user accounts will differ (if not in name then in password hashes) 
 from the default datasource -- this leads to authentication warnings all over 
 the place
 * one will not be able to mainpulate data of course, either

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Commented] (OFBIZ-5019) Multitenant delegator assignment not working correctly

[Carsten Schinzer]

All,


I really need help on this -- I know multitenant is not very popular in
use. Yet, if someone could find time to look at this, would be a great help!

I have modified ContextFilter and LoginWorker now as follows in my local
environment:

LoginWorker:
- identifies the correct tenant delegator and places it in Session Context

ContextFilter:
- assure the tenant delegator is in SessionContext and places it in the
HttpRequest
- does no longer overwrite the ServletContext delegator with the
tenantDelegator (this is bad practice IMHO)

Since this change the logins work perfectly fine however the data I am
seeing in backoffice applications are not the tenant data but the data on
the main ofbiz instance.

So the backoffice application pages seem to be always using the delegator
in the ServletContext and not the Visit's or the HttpRequest's or the
SessionContext's.

Can someone confirm this statement and please point me where in the
framework I would change that behaviour?
IMHO the current, official implementation on the trunk which overwrites the
ServletContext parameter is bad practice and moreover is not robust enough
to support concurrent use of apps by different tenants.

Thanks for your support!
Regards


Carsten

[jira] [Created] (OFBIZ-5120) Two minor typos on OrderUILabels, lang=de

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5120:
---

 Summary: Two minor typos on OrderUILabels, lang=de
 Key: OFBIZ-5120
 URL: https://issues.apache.org/jira/browse/OFBIZ-5120
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: SVN trunk
 Environment: xml configuaration
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk


Two typos on the german OrderUILabels:

- property key=OrderOrderItems: fix to plural wording
- property key=OrderSalesOrderLookupFailed: typo on verb


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5120) Two minor typos on OrderUILabels, lang=de

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5120:


Attachment: OFBIZ-5120_Two_minor_typos_on_OrderUILabels_lang_de.patch

 Two minor typos on OrderUILabels, lang=de
 -

 Key: OFBIZ-5120
 URL: https://issues.apache.org/jira/browse/OFBIZ-5120
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: SVN trunk
 Environment: xml configuaration
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

 Attachments: OFBIZ-5120_Two_minor_typos_on_OrderUILabels_lang_de.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 Two typos on the german OrderUILabels:
 - property key=OrderOrderItems: fix to plural wording
 - property key=OrderSalesOrderLookupFailed: typo on verb

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5106) non facet valide method name in OrderServices.xml#orderSequence-enforced

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5106:
---

 Summary: non facet valide method name in 
OrderServices.xml#orderSequence-enforced
 Key: OFBIZ-5106
 URL: https://issues.apache.org/jira/browse/OFBIZ-5106
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: SVN trunk
 Environment: irrelevant, minilang service
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk


Error message in the error.log is as follows:
XmlFileLoader: File 
file:/usr/local/ofbiz-tr-mt12.5/applications/order/script/org/ofbiz/order/order/OrderServices.xml
 process error. Line: 530. Error message: cvc-pattern-valid: Value 
'orderSequence-enforced' is not facet-valid with respect to pattern 
'[a-zA-Z_]{1}[a-zA-Z0-9_$.]+' for type 'javaClassName'.

I am going to change all occurrencies of 'orderSequence-enforced' to 
'orderSequence_enforced' as only underscore dashed are allowed by the cvc 
pattern.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5107) XML Validation error on CustomerServices.xml

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5107:
---

 Summary: XML Validation error on CustomerServices.xml
 Key: OFBIZ-5107
 URL: https://issues.apache.org/jira/browse/OFBIZ-5107
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
 Environment: irrelevant, minilang service
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk


Error message in the error.log is as follows:
2012-12-19 08:38:09,223 (http-bio-0.0.0.0-8080-exec-145) [
UtilXml.java:1062:ERROR] XmlFileLoader: File 
file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
 process error. Line: 813. Error message: cvc-enumeration-valid: Value 'debug' 
is not facet-valid with respect to enumeration '[info, verbose, timing, 
important, warning, error, fatal, always]'. It must be a value from the 
enumeration.
2012-12-19 08:38:09,224 (http-bio-0.0.0.0-8080-exec-145) [
UtilXml.java:1062:ERROR] XmlFileLoader: File 
file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
 process error. Line: 813. Error message: cvc-attribute.3: The value 'debug' of 
attribute 'level' on element 'log' is not valid with respect to its type, 
'null'.
2012-12-19 08:38:09,226 (http-bio-0.0.0.0-8080-exec-145) [
UtilXml.java:1062:ERROR] XmlFileLoader: File 
file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
 process error. Line: 823. Error message: cvc-enumeration-valid: Value 'debug' 
is not facet-valid with respect to enumeration '[info, verbose, timing, 
important, warning, error, fatal, always]'. It must be a value from the 
enumeration.
2012-12-19 08:38:09,227 (http-bio-0.0.0.0-8080-exec-145) [
UtilXml.java:1062:ERROR] XmlFileLoader: File 
file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
 process error. Line: 823. Error message: cvc-attribute.3: The value 'debug' of 
attribute 'level' on element 'log' is not valid with respect to its type, 
'null'.

This was introduced with the patch for OFBIZ-5102 where I was adding these two 
log lines. The loging works yet fine, however it is preferrable to avoid such 
silly items filling our error logs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5107) XML Validation error on CustomerServices.xml

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5107:


Attachment: OFBIZ-5107_XML_Validation_error_on_CustomerServices.xml.patch

the patch for this tiny one

 XML Validation error on CustomerServices.xml
 

 Key: OFBIZ-5107
 URL: https://issues.apache.org/jira/browse/OFBIZ-5107
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
 Environment: irrelevant, minilang service
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

 Attachments: 
 OFBIZ-5107_XML_Validation_error_on_CustomerServices.xml.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Error message in the error.log is as follows:
 2012-12-19 08:38:09,223 (http-bio-0.0.0.0-8080-exec-145) [
 UtilXml.java:1062:ERROR] XmlFileLoader: File 
 file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
  process error. Line: 813. Error message: cvc-enumeration-valid: Value 
 'debug' is not facet-valid with respect to enumeration '[info, verbose, 
 timing, important, warning, error, fatal, always]'. It must be a value from 
 the enumeration.
 2012-12-19 08:38:09,224 (http-bio-0.0.0.0-8080-exec-145) [
 UtilXml.java:1062:ERROR] XmlFileLoader: File 
 file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
  process error. Line: 813. Error message: cvc-attribute.3: The value 'debug' 
 of attribute 'level' on element 'log' is not valid with respect to its type, 
 'null'.
 2012-12-19 08:38:09,226 (http-bio-0.0.0.0-8080-exec-145) [
 UtilXml.java:1062:ERROR] XmlFileLoader: File 
 file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
  process error. Line: 823. Error message: cvc-enumeration-valid: Value 
 'debug' is not facet-valid with respect to enumeration '[info, verbose, 
 timing, important, warning, error, fatal, always]'. It must be a value from 
 the enumeration.
 2012-12-19 08:38:09,227 (http-bio-0.0.0.0-8080-exec-145) [
 UtilXml.java:1062:ERROR] XmlFileLoader: File 
 file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
  process error. Line: 823. Error message: cvc-attribute.3: The value 'debug' 
 of attribute 'level' on element 'log' is not valid with respect to its type, 
 'null'.
 This was introduced with the patch for OFBIZ-5102 where I was adding these 
 two log lines. The loging works yet fine, however it is preferrable to avoid 
 such silly items filling our error logs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5106) non facet valide method name in OrderServices.xml#orderSequence-enforced

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5106:


Attachment: 
OFBIZ-5106_non_facet_valid_method_name_in_OrderServices.xml.patch

the patch for this one

 non facet valide method name in OrderServices.xml#orderSequence-enforced
 

 Key: OFBIZ-5106
 URL: https://issues.apache.org/jira/browse/OFBIZ-5106
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: SVN trunk
 Environment: irrelevant, minilang service
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk

 Attachments: 
 OFBIZ-5106_non_facet_valid_method_name_in_OrderServices.xml.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Error message in the error.log is as follows:
 XmlFileLoader: File 
 file:/usr/local/ofbiz-tr-mt12.5/applications/order/script/org/ofbiz/order/order/OrderServices.xml
  process error. Line: 530. Error message: cvc-pattern-valid: Value 
 'orderSequence-enforced' is not facet-valid with respect to pattern 
 '[a-zA-Z_]{1}[a-zA-Z0-9_$.]+' for type 'javaClassName'.
 I am going to change all occurrencies of 'orderSequence-enforced' to 
 'orderSequence_enforced' as only underscore dashed are allowed by the cvc 
 pattern.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5106) non facet valid method name in OrderServices.xml#orderSequence-enforced

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5106:


Summary: non facet valid method name in 
OrderServices.xml#orderSequence-enforced  (was: non facet valide method name in 
OrderServices.xml#orderSequence-enforced)

 non facet valid method name in OrderServices.xml#orderSequence-enforced
 ---

 Key: OFBIZ-5106
 URL: https://issues.apache.org/jira/browse/OFBIZ-5106
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: SVN trunk
 Environment: irrelevant, minilang service
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk

 Attachments: 
 OFBIZ-5106_non_facet_valid_method_name_in_OrderServices.xml.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Error message in the error.log is as follows:
 XmlFileLoader: File 
 file:/usr/local/ofbiz-tr-mt12.5/applications/order/script/org/ofbiz/order/order/OrderServices.xml
  process error. Line: 530. Error message: cvc-pattern-valid: Value 
 'orderSequence-enforced' is not facet-valid with respect to pattern 
 '[a-zA-Z_]{1}[a-zA-Z0-9_$.]+' for type 'javaClassName'.
 I am going to change all occurrencies of 'orderSequence-enforced' to 
 'orderSequence_enforced' as only underscore dashed are allowed by the cvc 
 pattern.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5107) XML Validation error on CustomerServices.xml

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13536440#comment-13536440
 ] 

Carsten Schinzer commented on OFBIZ-5107:
-

Hmm. Maybe a shortcoming on my side: I thought I did add the two lines that are 
in the patch. And if I had done soe, they would state wrong log level values 
('debug').
Apparently, you are right and these two lines are not in the current revision, 
so you might ignore this or read this ticket as: If you feel these two log 
statements are helpful when in a 'verbose' log mode, please add this patch to 
trunk.

Regards

Carsten

 XML Validation error on CustomerServices.xml
 

 Key: OFBIZ-5107
 URL: https://issues.apache.org/jira/browse/OFBIZ-5107
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
 Environment: irrelevant, minilang service
Reporter: Carsten Schinzer
Priority: Trivial
 Fix For: SVN trunk

 Attachments: 
 OFBIZ-5107_XML_Validation_error_on_CustomerServices.xml.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Error message in the error.log is as follows:
 2012-12-19 08:38:09,223 (http-bio-0.0.0.0-8080-exec-145) [
 UtilXml.java:1062:ERROR] XmlFileLoader: File 
 file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
  process error. Line: 813. Error message: cvc-enumeration-valid: Value 
 'debug' is not facet-valid with respect to enumeration '[info, verbose, 
 timing, important, warning, error, fatal, always]'. It must be a value from 
 the enumeration.
 2012-12-19 08:38:09,224 (http-bio-0.0.0.0-8080-exec-145) [
 UtilXml.java:1062:ERROR] XmlFileLoader: File 
 file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
  process error. Line: 813. Error message: cvc-attribute.3: The value 'debug' 
 of attribute 'level' on element 'log' is not valid with respect to its type, 
 'null'.
 2012-12-19 08:38:09,226 (http-bio-0.0.0.0-8080-exec-145) [
 UtilXml.java:1062:ERROR] XmlFileLoader: File 
 file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
  process error. Line: 823. Error message: cvc-enumeration-valid: Value 
 'debug' is not facet-valid with respect to enumeration '[info, verbose, 
 timing, important, warning, error, fatal, always]'. It must be a value from 
 the enumeration.
 2012-12-19 08:38:09,227 (http-bio-0.0.0.0-8080-exec-145) [
 UtilXml.java:1062:ERROR] XmlFileLoader: File 
 file:/usr/local/ofbiz-tr-mt12.5/specialpurpose/ecommerce/script/org/ofbiz/ecommerce/customer/CustomerEvents.xml
  process error. Line: 823. Error message: cvc-attribute.3: The value 'debug' 
 of attribute 'level' on element 'log' is not valid with respect to its type, 
 'null'.
 This was introduced with the patch for OFBIZ-5102 where I was adding these 
 two log lines. The loging works yet fine, however it is preferrable to avoid 
 such silly items filling our error logs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5102) CheckoutScrips not adapoted after ShoppingCart.setShipmentMethodTypdeId

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5102:
---

 Summary: CheckoutScrips not adapoted after 
ShoppingCart.setShipmentMethodTypdeId
 Key: OFBIZ-5102
 URL: https://issues.apache.org/jira/browse/OFBIZ-5102
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5102) CheckoutScripts not adapoted after ShoppingCart.setShipmentMethodTypdeId

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5102:


   Description: 
The CustomerEvent scripts do not yet account for the fact that the method takes 
two parameters after a code change on ShoppingCart:
- int shipGroupIndex and
- String shipmentMethodTypeId
instead of the latter String only in earlier versions.

I will have to research what the shipGroupIndex is supposed to carry and adopt 
code accordingly.

Remaining Estimate: 4h
 Original Estimate: 4h
   Summary: CheckoutScripts not adapoted after 
ShoppingCart.setShipmentMethodTypdeId  (was: CheckoutScrips not adapoted after 
ShoppingCart.setShipmentMethodTypdeId)

 CheckoutScripts not adapoted after ShoppingCart.setShipmentMethodTypdeId
 

 Key: OFBIZ-5102
 URL: https://issues.apache.org/jira/browse/OFBIZ-5102
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk

   Original Estimate: 4h
  Remaining Estimate: 4h

 The CustomerEvent scripts do not yet account for the fact that the method 
 takes two parameters after a code change on ShoppingCart:
 - int shipGroupIndex and
 - String shipmentMethodTypeId
 instead of the latter String only in earlier versions.
 I will have to research what the shipGroupIndex is supposed to carry and 
 adopt code accordingly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5102) CheckoutScripts not adapoted after ShoppingCart.setShipmentMethodTypdeId

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13533366#comment-13533366
 ] 

Carsten Schinzer commented on OFBIZ-5102:
-

Minilang Script calls to setShipmentMethodTypeId with a single String Parameter 
need to be changed.
They now must call setAllShipmentMethodTypeId. This method has been introduced 
with rev. 1407116.


 CheckoutScripts not adapoted after ShoppingCart.setShipmentMethodTypdeId
 

 Key: OFBIZ-5102
 URL: https://issues.apache.org/jira/browse/OFBIZ-5102
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk

   Original Estimate: 4h
  Remaining Estimate: 4h

 The CustomerEvent scripts do not yet account for the fact that the method 
 takes two parameters after a code change on ShoppingCart:
 - int shipGroupIndex and
 - String shipmentMethodTypeId
 instead of the latter String only in earlier versions.
 I will have to research what the shipGroupIndex is supposed to carry and 
 adopt code accordingly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5102) CheckoutScripts not adapoted after ShoppingCart.setShipmentMethodTypdeId

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13533369#comment-13533369
 ] 

Carsten Schinzer commented on OFBIZ-5102:
-

Also (potentially) affected:
- set[All]CarrierPartyId
- set[All]ProductStoreShipMethId
- set[All]GiftMessage
- set[All]IsGift
- set[All]MaySplit]
- set[All]ShippingInstructions

The patch shall cover all occurrencies of and changes to these method calls in 
the specialpurpose applications.

 CheckoutScripts not adapoted after ShoppingCart.setShipmentMethodTypdeId
 

 Key: OFBIZ-5102
 URL: https://issues.apache.org/jira/browse/OFBIZ-5102
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Carsten Schinzer
Priority: Minor
 Fix For: SVN trunk

   Original Estimate: 4h
  Remaining Estimate: 4h

 The CustomerEvent scripts do not yet account for the fact that the method 
 takes two parameters after a code change on ShoppingCart:
 - int shipGroupIndex and
 - String shipmentMethodTypeId
 instead of the latter String only in earlier versions.
 I will have to research what the shipGroupIndex is supposed to carry and 
 adopt code accordingly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5102) CheckoutScripts not adapoted after ShoppingCart.setShipmentMethodTypdeId

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5102:


Attachment: OFBIZ-5102_Checkout_scripts_not_adopted_for_rev1407116.patch

 CheckoutScripts not adapoted after ShoppingCart.setShipmentMethodTypdeId
 

 Key: OFBIZ-5102
 URL: https://issues.apache.org/jira/browse/OFBIZ-5102
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Carsten Schinzer
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: SVN trunk

 Attachments: 
 OFBIZ-5102_Checkout_scripts_not_adopted_for_rev1407116.patch

   Original Estimate: 4h
  Remaining Estimate: 4h

 The CustomerEvent scripts do not yet account for the fact that the method 
 takes two parameters after a code change on ShoppingCart:
 - int shipGroupIndex and
 - String shipmentMethodTypeId
 instead of the latter String only in earlier versions.
 I will have to research what the shipGroupIndex is supposed to carry and 
 adopt code accordingly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5102) CheckoutScripts not adopted after ShoppingCart.setShipmentMethodTypdeId

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5102:


Remaining Estimate: 2h  (was: 4h)
 Original Estimate: 2h  (was: 4h)
   Summary: CheckoutScripts not adopted after 
ShoppingCart.setShipmentMethodTypdeId  (was: CheckoutScripts not adapoted after 
ShoppingCart.setShipmentMethodTypdeId)

 CheckoutScripts not adopted after ShoppingCart.setShipmentMethodTypdeId
 ---

 Key: OFBIZ-5102
 URL: https://issues.apache.org/jira/browse/OFBIZ-5102
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Carsten Schinzer
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: SVN trunk

 Attachments: 
 OFBIZ-5102_Checkout_scripts_not_adopted_for_rev1407116.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The CustomerEvent scripts do not yet account for the fact that the method 
 takes two parameters after a code change on ShoppingCart:
 - int shipGroupIndex and
 - String shipmentMethodTypeId
 instead of the latter String only in earlier versions.
 I will have to research what the shipGroupIndex is supposed to carry and 
 adopt code accordingly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5102) CheckoutScripts not adopted after ShoppingCart.setShipmentMethodTypdeId

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5102:


Attachment: OFBIZ-5102_Checkout_scripts_not_adopted_for_rev1407116.patch

final version after testing

 CheckoutScripts not adopted after ShoppingCart.setShipmentMethodTypdeId
 ---

 Key: OFBIZ-5102
 URL: https://issues.apache.org/jira/browse/OFBIZ-5102
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Carsten Schinzer
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: SVN trunk

 Attachments: 
 OFBIZ-5102_Checkout_scripts_not_adopted_for_rev1407116.patch, 
 OFBIZ-5102_Checkout_scripts_not_adopted_for_rev1407116.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The CustomerEvent scripts do not yet account for the fact that the method 
 takes two parameters after a code change on ShoppingCart:
 - int shipGroupIndex and
 - String shipmentMethodTypeId
 instead of the latter String only in earlier versions.
 I will have to research what the shipGroupIndex is supposed to carry and 
 adopt code accordingly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5102) CheckoutScripts not adopted after ShoppingCart.setShipmentMethodTypdeId

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5102:


Attachment: (was: 
OFBIZ-5102_Checkout_scripts_not_adopted_for_rev1407116.patch)

 CheckoutScripts not adopted after ShoppingCart.setShipmentMethodTypdeId
 ---

 Key: OFBIZ-5102
 URL: https://issues.apache.org/jira/browse/OFBIZ-5102
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Carsten Schinzer
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: SVN trunk

 Attachments: 
 OFBIZ-5102_Checkout_scripts_not_adopted_for_rev1407116.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The CustomerEvent scripts do not yet account for the fact that the method 
 takes two parameters after a code change on ShoppingCart:
 - int shipGroupIndex and
 - String shipmentMethodTypeId
 instead of the latter String only in earlier versions.
 I will have to research what the shipGroupIndex is supposed to carry and 
 adopt code accordingly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5019) Multitenant delegator assignment not working correctly

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13527505#comment-13527505
 ] 

Carsten Schinzer commented on OFBIZ-5019:
-

More on this topic:

I would like to understand what the requirements are for the ContextFilter to 
place delegatorName in the various contexts. From what I read in code, this is 
where delegator information is placed in Contexts::

ServletContext
- delegator (e.g. definiton in web.xml
- dispatcher

SessionContext:
- delegator
- delegatorName
- dispatcher

Before I move on with this fix, I need to understand whether the following 
assumption is correct:
The ServletContext exists for the Servlet, not per instance. Write operations 
to it should thus be avoided in order to prevent inconsistencies. However, for 
Multitenant delegator, this occurs in current code.
The SessionContext exists for each Session and can thus contain 
Session-dependant items, such as Multitenant tenantId, delegator and dispatcher 
(and many more of course)

Based in these assumptions, I shall fix the Multitenant-part in the 
ContextFilter as follows:

(1) check if ServletContext has a Multitenant-delegator
-- if so: copy into Session Context, bail out
-- else:
(2) check if SessionContext has a Multitenant-delegator for the current tenantId
-- if so: the work is done, bail out
-- else:
(3) check if SessionContext has a tenantId parameter
-- if so: create the Multitenant-delegator using baseDelegatorName from 
ServletContext + # + tenantId
-- else: re-use existing code (but that is weak and should rather become an 
Exception case)

In order for this to run, I need confirmation that any invocation of a 
delegator will first check for a delegator in the SessionContext before falling 
back to the delegator in the ServletContext.

Could this assumption be confirmed by someone from the committers?


 Multitenant delegator assignment not working  correctly
 ---

 Key: OFBIZ-5019
 URL: https://issues.apache.org/jira/browse/OFBIZ-5019
 Project: OFBiz
  Issue Type: Bug
  Components: ALL APPLICATIONS, framework
Affects Versions: SVN trunk
 Environment: multitenantuse = Y
 Tenant with no Domain setting or Tenant using different domain for backend 
 applications
Reporter: Carsten Schinzer
  Labels: authentication, context, multitenancy, security
 Attachments: 
 OFBIZ-5019_Multitenant_delegator_assignment_not_working_correctly.patch

   Original Estimate: 168h
  Remaining Estimate: 168h

 This issue arises when Multitenancy is in use. It arises only on backend 
 applications (as typically the frontend store applications will use a context 
 variable defined in web.xml to determin the delegator to be used (ie. the 
 database to use for data lookups etc).
 The issue manifests as follows:
 * the wrong data is read for standard backoffice displays (e.g. orders, 
 accounts, etc.); it is the dataa from the default datasource, not the 
 tenant´s data source
 * in the backend apps certain functions require authentication (checked 
 dynamically) and this will fail when the default delegator is used since the 
 tenant's user accounts will differ (if not in name then in password hashes) 
 from the default datasource -- this leads to authentication warnings all over 
 the place
 * one will not be able to mainpulate data of course, either

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5019) Multitenant delegator assignment not working correctly

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13527509#comment-13527509
 ] 

Carsten Schinzer commented on OFBIZ-5019:
-

Further to this I do see a UtilityMethod on 
LoginWorker.setWebContextObjects(...) which takes care of placing information 
in the various contexts after login.

Firstly I think this very same method would be of use in the ContextFilter 
class as well (make it protected? is LoginWorker the correct place for this? 
should it not be part of ContexFilter and usable by LoginWorker?)

Secondly I can read in the implementation that this method just overwrites 
settings in the ServletContext ('just in case any of it has changed' as the 
method comment sais) which IMHO is not a good use of that context. The 
ServletContext should contain Session-independant, basic configurations and 
remain unchanged throughout the lifecycle of the Servlet ie. as long as the JVM 
is up.

Any Session-(ie. User-) dependant configuration should be added to the Session 
context.



 Multitenant delegator assignment not working  correctly
 ---

 Key: OFBIZ-5019
 URL: https://issues.apache.org/jira/browse/OFBIZ-5019
 Project: OFBiz
  Issue Type: Bug
  Components: ALL APPLICATIONS, framework
Affects Versions: SVN trunk
 Environment: multitenantuse = Y
 Tenant with no Domain setting or Tenant using different domain for backend 
 applications
Reporter: Carsten Schinzer
  Labels: authentication, context, multitenancy, security
 Attachments: 
 OFBIZ-5019_Multitenant_delegator_assignment_not_working_correctly.patch

   Original Estimate: 168h
  Remaining Estimate: 168h

 This issue arises when Multitenancy is in use. It arises only on backend 
 applications (as typically the frontend store applications will use a context 
 variable defined in web.xml to determin the delegator to be used (ie. the 
 database to use for data lookups etc).
 The issue manifests as follows:
 * the wrong data is read for standard backoffice displays (e.g. orders, 
 accounts, etc.); it is the dataa from the default datasource, not the 
 tenant´s data source
 * in the backend apps certain functions require authentication (checked 
 dynamically) and this will fail when the default delegator is used since the 
 tenant's user accounts will differ (if not in name then in password hashes) 
 from the default datasource -- this leads to authentication warnings all over 
 the place
 * one will not be able to mainpulate data of course, either

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5019) Multitenant delegator assignment not working correctly

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13511502#comment-13511502
 ] 

Carsten Schinzer commented on OFBIZ-5019:
-

This does still not work properly in my local environment. What I have done so 
far:

The adapted ContextFilter will ensure:
- new delegator is created when multitenant use is configured and tenantId is 
in the HttpRequest
- new delegator is created when multitenant use is configured and tenantId in 
HttpRequest does not match in the delegatorName (ie. current delegator is for a 
different tenant)
- attempt to create proper delegator for the first tenant in the list of 
tenants when no information is present in HttpRequest


I can also see that LoginWorker attempts to redefine the delegator (again?), 
but the ContextFilter should already have done that work. Anyone with a comment 
regarding this additional delegator fiddling? Is there any situation where 
LoginWorker is called and ContextFilter no being invoked beforehand?

Thanks for your comments.

Regards


Carsten

 Multitenant delegator assignment not working  correctly
 ---

 Key: OFBIZ-5019
 URL: https://issues.apache.org/jira/browse/OFBIZ-5019
 Project: OFBiz
  Issue Type: Bug
  Components: ALL APPLICATIONS, framework
Affects Versions: SVN trunk
 Environment: multitenantuse = Y
 Tenant with no Domain setting or Tenant using different domain for backend 
 applications
Reporter: Carsten Schinzer
  Labels: authentication, context, multitenancy, security
 Attachments: 
 OFBIZ-5019_Multitenant_delegator_assignment_not_working_correctly.patch

   Original Estimate: 168h
  Remaining Estimate: 168h

 This issue arises when Multitenancy is in use. It arises only on backend 
 applications (as typically the frontend store applications will use a context 
 variable defined in web.xml to determin the delegator to be used (ie. the 
 database to use for data lookups etc).
 The issue manifests as follows:
 * the wrong data is read for standard backoffice displays (e.g. orders, 
 accounts, etc.); it is the dataa from the default datasource, not the 
 tenant´s data source
 * in the backend apps certain functions require authentication (checked 
 dynamically) and this will fail when the default delegator is used since the 
 tenant's user accounts will differ (if not in name then in password hashes) 
 from the default datasource -- this leads to authentication warnings all over 
 the place
 * one will not be able to mainpulate data of course, either

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5090) Type in new party/entitymodel.xml

[Carsten Schinzer (JIRA)]

Carsten Schinzer created OFBIZ-5090:
---

 Summary: Type in new party/entitymodel.xml
 Key: OFBIZ-5090
 URL: https://issues.apache.org/jira/browse/OFBIZ-5090
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: SVN trunk
 Environment: XML
Reporter: Carsten Schinzer
 Fix For: SVN trunk


The entitymodel.xml for party contains a typo on agreement_facility_appl: it 
refers to faciliyId instead of facilityId.
this needs urgent fixing as otherwise any DB build done with the wrong 
definition will generate errors (as the reference is part of a constraint).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5090) Type in new party/entitymodel.xml

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5090:


Remaining Estimate: 0.25h
 Original Estimate: 0.25h

 Type in new party/entitymodel.xml
 -

 Key: OFBIZ-5090
 URL: https://issues.apache.org/jira/browse/OFBIZ-5090
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: SVN trunk
 Environment: XML
Reporter: Carsten Schinzer
 Fix For: SVN trunk

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 The entitymodel.xml for party contains a typo on agreement_facility_appl: it 
 refers to faciliyId instead of facilityId.
 this needs urgent fixing as otherwise any DB build done with the wrong 
 definition will generate errors (as the reference is part of a constraint).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5090) Typ0 in new party-entitymodel

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5090:


Summary: Typ0 in new party-entitymodel  (was: Type in new 
party/entitymodel.xml)

 Typ0 in new party-entitymodel
 -

 Key: OFBIZ-5090
 URL: https://issues.apache.org/jira/browse/OFBIZ-5090
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: SVN trunk
 Environment: XML
Reporter: Carsten Schinzer
 Fix For: SVN trunk

 Attachments: OFBIZ-5090_Typo in new party-entitymodel.patch

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 The entitymodel.xml for party contains a typo on agreement_facility_appl: it 
 refers to faciliyId instead of facilityId.
 this needs urgent fixing as otherwise any DB build done with the wrong 
 definition will generate errors (as the reference is part of a constraint).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5090) Typ0 in new party-entitymodel

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5090:


Attachment: OFBIZ-5090_Typo in new party-entitymodel.patch

 Typ0 in new party-entitymodel
 -

 Key: OFBIZ-5090
 URL: https://issues.apache.org/jira/browse/OFBIZ-5090
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: SVN trunk
 Environment: XML
Reporter: Carsten Schinzer
 Fix For: SVN trunk

 Attachments: OFBIZ-5090_Typo in new party-entitymodel.patch

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 The entitymodel.xml for party contains a typo on agreement_facility_appl: it 
 refers to faciliyId instead of facilityId.
 this needs urgent fixing as otherwise any DB build done with the wrong 
 definition will generate errors (as the reference is part of a constraint).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5090) Typ0 in new party-entitymodel

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508320#comment-13508320
 ] 

Carsten Schinzer commented on OFBIZ-5090:
-

the patch

 Typ0 in new party-entitymodel
 -

 Key: OFBIZ-5090
 URL: https://issues.apache.org/jira/browse/OFBIZ-5090
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: SVN trunk
 Environment: XML
Reporter: Carsten Schinzer
 Fix For: SVN trunk

 Attachments: OFBIZ-5090_Typo in new party-entitymodel.patch

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 The entitymodel.xml for party contains a typo on agreement_facility_appl: it 
 refers to faciliyId instead of facilityId.
 this needs urgent fixing as otherwise any DB build done with the wrong 
 definition will generate errors (as the reference is part of a constraint).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5090) Typ0 in new party-entitymodel

[Carsten Schinzer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Schinzer updated OFBIZ-5090:


Attachment: OFBIZ-5090_Typo in new party-entitymodel.patch

 Typ0 in new party-entitymodel
 -

 Key: OFBIZ-5090
 URL: https://issues.apache.org/jira/browse/OFBIZ-5090
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: SVN trunk
 Environment: XML
Reporter: Carsten Schinzer
 Fix For: SVN trunk

 Attachments: OFBIZ-5090_Typo in new party-entitymodel.patch, 
 OFBIZ-5090_Typo in new party-entitymodel.patch

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 The entitymodel.xml for party contains a typo on agreement_facility_appl: it 
 refers to faciliyId instead of facilityId.
 this needs urgent fixing as otherwise any DB build done with the wrong 
 definition will generate errors (as the reference is part of a constraint).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5090) Typ0 in new party-entitymodel

[Carsten Schinzer (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508321#comment-13508321
 ] 

Carsten Schinzer commented on OFBIZ-5090:
-

the patch

 Typ0 in new party-entitymodel
 -

 Key: OFBIZ-5090
 URL: https://issues.apache.org/jira/browse/OFBIZ-5090
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: SVN trunk
 Environment: XML
Reporter: Carsten Schinzer
 Fix For: SVN trunk

 Attachments: OFBIZ-5090_Typo in new party-entitymodel.patch, 
 OFBIZ-5090_Typo in new party-entitymodel.patch

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 The entitymodel.xml for party contains a typo on agreement_facility_appl: it 
 refers to faciliyId instead of facilityId.
 this needs urgent fixing as otherwise any DB build done with the wrong 
 definition will generate errors (as the reference is part of a constraint).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira