[pkg-go] Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix

2024-05-11 Thread Eugen Stan

Hi,

I tried to configure podman to use crun-wasm and failed.

There seems to be 11 references in the org 
https://github.com/search?q=org%3Acontainers%20crun-wasm=code .


So the safer option would be to package crun-wasm IMO.

Asked for more information in the issue 
https://github.com/containers/crun/issues/1468 .


I would add the symlink. Other programs might look for the binary.
Looking at the references to crun-wasm I think having a crun-wasm 
package that:

- depends on crun and wasmedge
- creates a symlink to crun

does not sond so bad.
On the other hand, maintaining an extra package does not sound that nice 
either.



Regards,
Eugen

La 11.05.2024 12:55, Faidon Liambotis a scris:

Control: tags -1 confirmed

On Wed, May 08, 2024 at 03:10:40AM +0300, Eugen Stan wrote:

I followed the guide to run wasm images on my system and it failed with
errors.

I believe the issue is that podman looks for crun-wasm binary by default.
I failed to configure podman to use crun instead of crun-wasm.
I created a simbolic link named crun-wasm:

sudo ln -s /usr/bin/crun /usr/local/bin/crun-wasm


Ouch! You're right. This worked when I enabled WasmEdge in crun, but
was changed upstream at some point since.

Apparently Fedora/RedHat ship a "crun-wasm" package, which contains a) this
symlink, b) a dependency on WasmEdge.

In Debian, the main "crun" package has a Suggests on libwasmedge0.

I see three paths forward:
1) We do the same, creating a new (almost) empty package.
2) We ship a /usr/bin/crun-wasm symlink in the crun package.
3) We patch podman to use /usr/bin/crun instead of, or in addition to,
/usr/bin/crun-wasm.

I don't particularly love option (1). I'm split between options (2) and
(3), not loving either.

Thoughts?

Faidon


--
Eugen Stan

+40770 941 271  / https://www.netdava.com

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers


Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix

2024-05-11 Thread Eugen Stan

Hi,

I tried to configure podman to use crun-wasm and failed.

There seems to be 11 references in the org 
https://github.com/search?q=org%3Acontainers%20crun-wasm=code .


So the safer option would be to package crun-wasm IMO.

Asked for more information in the issue 
https://github.com/containers/crun/issues/1468 .


I would add the symlink. Other programs might look for the binary.
Looking at the references to crun-wasm I think having a crun-wasm 
package that:

- depends on crun and wasmedge
- creates a symlink to crun

does not sond so bad.
On the other hand, maintaining an extra package does not sound that nice 
either.



Regards,
Eugen

La 11.05.2024 12:55, Faidon Liambotis a scris:

Control: tags -1 confirmed

On Wed, May 08, 2024 at 03:10:40AM +0300, Eugen Stan wrote:

I followed the guide to run wasm images on my system and it failed with
errors.

I believe the issue is that podman looks for crun-wasm binary by default.
I failed to configure podman to use crun instead of crun-wasm.
I created a simbolic link named crun-wasm:

sudo ln -s /usr/bin/crun /usr/local/bin/crun-wasm


Ouch! You're right. This worked when I enabled WasmEdge in crun, but
was changed upstream at some point since.

Apparently Fedora/RedHat ship a "crun-wasm" package, which contains a) this
symlink, b) a dependency on WasmEdge.

In Debian, the main "crun" package has a Suggests on libwasmedge0.

I see three paths forward:
1) We do the same, creating a new (almost) empty package.
2) We ship a /usr/bin/crun-wasm symlink in the crun package.
3) We patch podman to use /usr/bin/crun instead of, or in addition to,
/usr/bin/crun-wasm.

I don't particularly love option (1). I'm split between options (2) and
(3), not loving either.

Thoughts?

Faidon


--
Eugen Stan

+40770 941 271  / https://www.netdava.com



[pkg-go] Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix

2024-05-07 Thread Eugen Stan

Package: podman
Version: 4.9.4+ds1-1
Severity: important

Dear Maintainer,

I followed the guide to run wasm images on my system and it failed with 
errors.


I believe the issue is that podman looks for crun-wasm binary by default.
I failed to configure podman to use crun instead of crun-wasm.
I created a simbolic link named crun-wasm:

sudo ln -s /usr/bin/crun /usr/local/bin/crun-wasm

More details bellow to reproduce:

This is the guide I followed 
https://news.opensuse.org/2024/01/19/podman-wasm-

support/

I installed podman, crun and wasmedge packages.
Created a rust package and image with this Containerfile

FROM scratch
COPY target/wasm32-wasi/debug/hello.wasm /
CMD ["/hello.wasm"]

When I ran the image I got this error

podman run --rm hello-wasm
WARNING: image platform (wasi/wasm) does not match the expected platform
(linux/amd64)
Error: requested OCI runtime crun-wasm is not available: invalid argument

After creating the crun-wasm symbolic link I got it working:

podman run --platform wasi/wasm --rm hello-wasm
Hello, world din wasm!

It might be that this bu is fixed by patching crun but I believe the 
issue is

happening with podman.

Thanks,
Eugen




-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=ro_RO.UTF8, LC_CTYPE=ro_RO.UTF8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages podman depends on:
ii  conmon   2.1.10+ds1-1+b1
ii  containerd.io [runc] 1.6.31-1
ii  crun 1.14.4-1
ii  golang-github-containers-common  0.57.4+ds1-2
ii  libc62.38-7
ii  libdevmapper1.02.1   2:1.02.196-1+b1
ii  libgpgme11t641.18.0-4.1+b1
ii  libseccomp2  2.5.5-1
ii  libsqlite3-0 3.45.3-1
ii  libsubid41:4.13+dfsg1-4

Versions of packages podman recommends:
ii  buildah1.33.7+ds1-1
ii  catatonit  0.1.7-1+b1
ii  dbus-user-session  1.14.10-4+b1
ii  passt  0.0~git20240426.d03c4e2-1
ii  slirp4netns1.2.1-1+b1
ii  uidmap 1:4.13+dfsg1-4

Versions of packages podman suggests:
ii  containers-storage  1.51.0+ds1-2
pn  docker-compose  
ii  iptables1.8.10-3

-- no debconf information

--
Eugen Stan

+40770 941 271  / https://www.netdava.com

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers


Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix

2024-05-07 Thread Eugen Stan

Package: podman
Version: 4.9.4+ds1-1
Severity: important

Dear Maintainer,

I followed the guide to run wasm images on my system and it failed with 
errors.


I believe the issue is that podman looks for crun-wasm binary by default.
I failed to configure podman to use crun instead of crun-wasm.
I created a simbolic link named crun-wasm:

sudo ln -s /usr/bin/crun /usr/local/bin/crun-wasm

More details bellow to reproduce:

This is the guide I followed 
https://news.opensuse.org/2024/01/19/podman-wasm-

support/

I installed podman, crun and wasmedge packages.
Created a rust package and image with this Containerfile

FROM scratch
COPY target/wasm32-wasi/debug/hello.wasm /
CMD ["/hello.wasm"]

When I ran the image I got this error

podman run --rm hello-wasm
WARNING: image platform (wasi/wasm) does not match the expected platform
(linux/amd64)
Error: requested OCI runtime crun-wasm is not available: invalid argument

After creating the crun-wasm symbolic link I got it working:

podman run --platform wasi/wasm --rm hello-wasm
Hello, world din wasm!

It might be that this bu is fixed by patching crun but I believe the 
issue is

happening with podman.

Thanks,
Eugen




-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=ro_RO.UTF8, LC_CTYPE=ro_RO.UTF8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages podman depends on:
ii  conmon   2.1.10+ds1-1+b1
ii  containerd.io [runc] 1.6.31-1
ii  crun 1.14.4-1
ii  golang-github-containers-common  0.57.4+ds1-2
ii  libc62.38-7
ii  libdevmapper1.02.1   2:1.02.196-1+b1
ii  libgpgme11t641.18.0-4.1+b1
ii  libseccomp2  2.5.5-1
ii  libsqlite3-0 3.45.3-1
ii  libsubid41:4.13+dfsg1-4

Versions of packages podman recommends:
ii  buildah1.33.7+ds1-1
ii  catatonit  0.1.7-1+b1
ii  dbus-user-session  1.14.10-4+b1
ii  passt  0.0~git20240426.d03c4e2-1
ii  slirp4netns1.2.1-1+b1
ii  uidmap 1:4.13+dfsg1-4

Versions of packages podman suggests:
ii  containers-storage  1.51.0+ds1-2
pn  docker-compose  
ii  iptables1.8.10-3

-- no debconf information

--
Eugen Stan

+40770 941 271  / https://www.netdava.com



Re: breaking ofbiz piece by piece - expose parts to outside

2024-03-22 Thread Eugen Stan

Hi Nicolas,

Thanks for the support. I do hope we get the ball roling at one point.

I won't be attending ApacheCon this year.
I think it's been 13 years since my last ApacheCon :).
Feel free to start merging changes.

Regards,
Eugen

La 22.03.2024 18:23, Nicolas Malin a scris:

Thanks both for your work and analyze !

I agree on the first point, we need to move forward to release the next 
OFBiz version and after we can breaking the wall :D


If the person are present at the eu apachecon it would be nice place to 
start a workshop on face to face ?


Nicolas


--
Eugen Stan

+40770 941 271  / https://www.netdava.com



Re: Call for vote: Apache James 0.8.11

2024-03-07 Thread Eugen Stan

+1 .

FYI I updated doap files with release information and made a PR for 
0.8.11 doap https://github.com/apache/james-mime4j/pull/99 .

Changes and PR are not mandatory for this release.


La 05.03.2024 17:42, Benoit TELLIER a scris:

Hi,

I would like to propose a new vote for 0.8.11 release of the Apache 
James MIME4J library.


You can find:

  - The maven release staged in repository.apache.org as the artifact 
#1082: 
https://repository.apache.org/content/repositories/orgapachejames-1082/

  - The changelog: https://github.com/apache/james-mime4j/pull/98
  - The site changes: https://github.com/apache/james-project/pull/2091

This is a minor release that addresses a regression of the 0.8.10 
release regarding invalid encoding usage in email headers.


Voting rules:
  - This is a majority approval: this release may not be vetoed.
  - A quorum of 3 binding votes is required
  - The vote starts at Tuesday 5th of March 2024, x4pmxx UTC+1
  - The vote ends at Tuesday 12th of March 2024, x4pmxx UTC+1

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org



--
Eugen Stan

+40770 941 271  / https://www.netdava.com


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org



Re: breaking ofbiz piece by piece - expose parts to outside

2024-02-27 Thread Eugen Stan
level wiki page to coordinate
refactoring efforts since that will help inform what refactoring tasks we
might want to see completed before creating the new release branch.


I have other refactoring topics I would like to discuss at some point -
such as considering whether we should bring plugins maintained by the
project into the ofbiz-framework repository, or whether we should set
cookies at site root to authenticate a user across all applications at once
- but the above seems enough to grapple with for the time being.

Thanks,

Dan.



On Sat, 17 Feb 2024 at 23:15, Eugen Stan  wrote:


Hi,

Did anyone have time to check out the PR?

I did rebase it on current trunk.
https://github.com/apache/ofbiz-framework/pull/678

Thanks,
Eugen

La 02.01.2024 14:50, Eugen Stan a scris:

Hello,

Happy new year!

I hope you had a great 2023.
Has anyone had time to look over the exploratory work?

If you have, please don't be shy, share your findings, good or bad.
It would be great if we can work on concrete examples.

I am still available to answer any questions and improve on the PR's to
make the changes part of OFBiz moving forward.

Let's make parts of OFBiz available as libraries so they can be used in
other projects (ofbiz tooling) / other ways of building OFBiz.

Regards,
Eugen

La 09.12.2023 01:04, Eugen Stan a scris:

Hi,

I pushed some changes that significantly reduce the number of lines
changed and also the possibility of breakage:
- merged back UtilValidateDateTime and UtilValidateEmpty into
UtilValidate
- moved some methods from *Runtime -> former class.

If you test the changes and find some issues please let me know.
I am willing to work to  fix those and make the PR mergeable.

I also did an exploratory work to see what would it take to have
entity engine as a library see
https://github.com/ieugen/ofbiz-framework/pull/3

On top of this PR, it adds only 670 lines and remove 370.
Very small price to pay IMO.
I have partial integration tests running.
I have added some comments related to the blockers (EntityEca, Tennant)
They should be doable, but I need more info / help.

To reiterate, please let me know of any issue you find and I will work
to fix it.

Regards,
Eugen

La 07.12.2023 20:55, Eugen Stan a scris:

Hi Michael,

Thank you for taking a look.
I will reply inline.

I did a demo project to support my case
https://github.com/ieugen/ofbiz-tooling-demo .

La 07.12.2023 12:53, Michael Brohl a scris:

Hi Eugen,

can you give us some explanations/examples why this is a useful

change?


What are the downsides?


I don't see any downsides.
There might be some breaking changes on upgrades.
We could work to mitigate them - will explain bellow.



I see a lot of changes in the base API like UtilValidate,
UtilProperties etc. which will brake almost every custom project out
there.


Have you tried it in your projects?
Do you know how many fail?

All the integrations tests pass.
Also we could do some work to mitigate those braking changes:
- copy those methods back to the classes they came from
- implement delegation: add a method with same signature that calls
on the class from base/util (UtilValidate calls UtilValidateEmpty).

IMO this should be a transition period until the code is cleaned up.
I did not do the mitigations because this is intendend as a POC to be
prepared once we decide it's a good direction.
Also - I don't have access to 'all the projects out there' to test.


The changes also need explanation. For example: why the split of
UtilValidate to UtilValidateEmpty etc.


Because of the cyclic dependency between classes.
There is a LOT of cyclic dependencies which IMO is a code smell.
UtilValidate depens on UtilProperties which depens on UtilValidate.
There are numerous cases for this.
If you run Intellij IDEA Analyze -> Analyze Cyclic dependencies you
will see them.
( I posted an image on gh issue)


https://github.com/apache/ofbiz-framework/pull/678#issuecomment-1845903198




I think we need to have very strong advantages to make those changes
and currently I do not see them.


We open OFBiz to be used as libraries.
Then developers can use things like entity-engine, datafile, bits to
build tooling as CLI or services that integrate with OFBiz.

- It opens a path forward to inovation
- It will make life of integrators MUCH more easy as it will provide
java API's for them to do integrations
- It exposes the dependencies by making them explicit (as gradle deps)
- Developers can focus on a smaller part of the code base: component
loading, XML parsing, entity engine without worrying about the rest
of the code.
- It will allow users to build tools and ofbiz components and package
them as jar files (component/datafile is a component as a jar file -
it depends on base/util and base/crypto - but nothing else from OFBiz).
- It will facilitate the developement of proper java API's - now
OFBiz is an implementation only - the API is the implementation.

I would like to build some import tooling that uses th

Re: breaking ofbiz piece by piece - expose parts to outside

2024-02-17 Thread Eugen Stan

Hi,

Did anyone have time to check out the PR?

I did rebase it on current trunk.
https://github.com/apache/ofbiz-framework/pull/678

Thanks,
Eugen

La 02.01.2024 14:50, Eugen Stan a scris:

Hello,

Happy new year!

I hope you had a great 2023.
Has anyone had time to look over the exploratory work?

If you have, please don't be shy, share your findings, good or bad.
It would be great if we can work on concrete examples.

I am still available to answer any questions and improve on the PR's to 
make the changes part of OFBiz moving forward.


Let's make parts of OFBiz available as libraries so they can be used in 
other projects (ofbiz tooling) / other ways of building OFBiz.


Regards,
Eugen

La 09.12.2023 01:04, Eugen Stan a scris:

Hi,

I pushed some changes that significantly reduce the number of lines 
changed and also the possibility of breakage:
- merged back UtilValidateDateTime and UtilValidateEmpty into 
UtilValidate

- moved some methods from *Runtime -> former class.

If you test the changes and find some issues please let me know.
I am willing to work to  fix those and make the PR mergeable.

I also did an exploratory work to see what would it take to have 
entity engine as a library see 
https://github.com/ieugen/ofbiz-framework/pull/3


On top of this PR, it adds only 670 lines and remove 370.
Very small price to pay IMO.
I have partial integration tests running.
I have added some comments related to the blockers (EntityEca, Tennant)
They should be doable, but I need more info / help.

To reiterate, please let me know of any issue you find and I will work 
to fix it.


Regards,
Eugen

La 07.12.2023 20:55, Eugen Stan a scris:

Hi Michael,

Thank you for taking a look.
I will reply inline.

I did a demo project to support my case 
https://github.com/ieugen/ofbiz-tooling-demo .


La 07.12.2023 12:53, Michael Brohl a scris:

Hi Eugen,

can you give us some explanations/examples why this is a useful change?

What are the downsides?


I don't see any downsides.
There might be some breaking changes on upgrades.
We could work to mitigate them - will explain bellow.



I see a lot of changes in the base API like UtilValidate, 
UtilProperties etc. which will brake almost every custom project out 
there.


Have you tried it in your projects?
Do you know how many fail?

All the integrations tests pass.
Also we could do some work to mitigate those braking changes:
- copy those methods back to the classes they came from
- implement delegation: add a method with same signature that calls 
on the class from base/util (UtilValidate calls UtilValidateEmpty).


IMO this should be a transition period until the code is cleaned up.
I did not do the mitigations because this is intendend as a POC to be 
prepared once we decide it's a good direction.

Also - I don't have access to 'all the projects out there' to test.

The changes also need explanation. For example: why the split of 
UtilValidate to UtilValidateEmpty etc.


Because of the cyclic dependency between classes.
There is a LOT of cyclic dependencies which IMO is a code smell.
UtilValidate depens on UtilProperties which depens on UtilValidate.
There are numerous cases for this.
If you run Intellij IDEA Analyze -> Analyze Cyclic dependencies you 
will see them.
( I posted an image on gh issue) 
https://github.com/apache/ofbiz-framework/pull/678#issuecomment-1845903198




I think we need to have very strong advantages to make those changes 
and currently I do not see them.


We open OFBiz to be used as libraries.
Then developers can use things like entity-engine, datafile, bits to 
build tooling as CLI or services that integrate with OFBiz.


- It opens a path forward to inovation
- It will make life of integrators MUCH more easy as it will provide 
java API's for them to do integrations

- It exposes the dependencies by making them explicit (as gradle deps)
- Developers can focus on a smaller part of the code base: component 
loading, XML parsing, entity engine without worrying about the rest 
of the code.
- It will allow users to build tools and ofbiz components and package 
them as jar files (component/datafile is a component as a jar file - 
it depends on base/util and base/crypto - but nothing else from OFBiz).
- It will facilitate the developement of proper java API's - now 
OFBiz is an implementation only - the API is the implementation.


I would like to build some import tooling that uses the OFBiz code 
(so I don't reinvent the weel).

Currently I don't see a way on how to do that.

See the https://github.com/ieugen/ofbiz-tooling-demo I just did for 
Crypto. It can help people migrate data from/to OFBiz by using the 
same crypto code and the same xml data processing code.
I do not need to bring whole OFBiz if all I want is to push / pull 
data from DB or to some files.
To my knowledge that is not possible with OFBiz right now (unlesss 
you reimplement the code). It will be possible once we publish 
libraries.


There is much more that th

Re: Vote to merge the Java 21 adoption for Apache James PR

2024-02-14 Thread Eugen Stan

La 14.02.2024 10:00, Jean Helou a scris:

Hello Eugen,

Libraries IMO should be released with support for older versions versions.

Not every project can use the latest and greatest JVM.
And I don't think low level libraries (mime4j) will benefit a lot from
new Java language features.



Just to clarify : what do you mean by libraries ? some of the modules in
the james-project reactor or only other projects such as mime4j ?
I don't think the switch is affecting mime4j, jsieve, jdkim or jspf as far
as I have seen, it's only for things in the james-project repo.

Given this are you fine with source 21 and target 21  ?

Jean



Hi,

Then you have my support for Java 21.

Thanks,
--
Eugen Stan

+40770 941 271  / https://www.netdava.com


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org



Re: Vote to merge the Java 21 adoption for Apache James PR

2024-02-07 Thread Eugen Stan

Hi Quan,

+1 for Java 21 for new James distribution version.

Libraries IMO should be released with support for older versions versions.
Not every project can use the latest and greatest JVM.
And I don't think low level libraries (mime4j) will benefit a lot from 
new Java language features.


Keep in mind, you can run a library built for Java 8 on JVM 21, but not 
the other way around.


IMO I will plan a switch to Java 21 some time after Java 22 is out (3-6 
months) after some JVM version reports are published.


Eugen

La 06.02.2024 15:32, Benoit TELLIER a scris:

Hi Quan

+1 on the principle.

However I have a few remarks:

1. Please be precise on James versions:
  - Java 21 will be used by Apache James for versions 3.9.0 onward
  - Java 11 will be used by Apache James for versions 3.7.x and 3.8.x. 
No backport of the Java 21 switch is planned.


2. Votes follow a more formal procedure within the ASF, and voting rules 
shall be clearly stated (voting time, voting threshold) cf 
https://www.apache.org/foundation/voting.html

In practice:
  - I propose the wording "lazy consensus"
  - for code changes we may remind that the vote may be vetoed
  - Provide an explicit voting time range specifying starting date and 
time and ending date.

    In practice a minimum of 3 days is recommended.

Regards

Benoit

On 06/02/2024 04:36, Quan tran hong wrote:

Hi everyone,

Following the Jira ticket
<https://issues.apache.org/jira/projects/JAMES/issues/JAMES-3961?filter=allissues>
and the previous mailing list discussion
<https://www.mail-archive.com/server-user@james.apache.org/msg16892.html>
regarding Java 21 adoption for James, I and Benoit put together an effort
to successfully get a green build on the Java 21 adoption PR
<https://github.com/apache/james-project/pull/1963>.

The idea is to have James migrated to Java 21 with minimal changes first,
and after that, we can leverage new Java features gradually.

Because this is a big change for James, James's community review, 
remarks,

and opinions on merging the Java 21 PR should be needed.

It would be good if the community could spend some time reviewing the PR,
or just upvote/downvote directly on this mail thread.

Thanks for reading.

Best regards,

Quan



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org



--
Eugen Stan

+40770 941 271  / https://www.netdava.com


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org



Going to FOSDEM, would like to meet

2024-02-01 Thread Eugen Stan

Hi,

I'm going to FOSDEM and would also like to attend 
https://fosdem.org/2024/schedule/event/fosdem-2024-1870--servers-apache-james-modular-email-server/ 
.


Regardless, I would like to meet some of the James devs / users that are 
there.


Ping me privately on email or on Mastodon: @ieu...@mas.to if you are 
around and would like to meet.


Otherwise I will try to catch who is available after the talk.

Regards,
--
Eugen Stan

+40770 941 271  / https://www.netdava.com

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org



Re: GOing to FOSDEM - any OFBiz devs/users that would like to meet?

2024-02-01 Thread Eugen Stan

La 01.02.2024 17:42, Sameer Alwosaby a scris:

،sorry, I am beginning what is mean FOSDEM


Hi Sameer,

Sorry for not being specific.
Here it is https://fosdem.org/2024/



؟


On Thu, Feb 1, 2024, 5:47 PM Eugen Stan  wrote:


Hello,

I'm going to FOSDEM. I would like to meet OFBiz users / devs if any are
in the area / participating to FOSDEM.

Please reply privatly to the email or via Mastodon: @ieu...@mas.to

Thanks,
--
Eugen Stan

+40770 941 271  / https://www.netdava.com





--
Eugen Stan

+40770 941 271  / https://www.netdava.com



GOing to FOSDEM - any OFBiz devs/users that would like to meet?

2024-02-01 Thread Eugen Stan

Hello,

I'm going to FOSDEM. I would like to meet OFBiz users / devs if any are 
in the area / participating to FOSDEM.


Please reply privatly to the email or via Mastodon: @ieu...@mas.to

Thanks,
--
Eugen Stan

+40770 941 271  / https://www.netdava.com


ofbiz used with USALI - Uniform System of Accounts for the Lodging Industry ?

2024-01-11 Thread Eugen Stan

Hello,

Does anyone know if OFBiz was used with USALI - Uniform System of 
Accounts for the Lodging Industry

https://usali.hftp.org/

Can you share anything related to the experience and what was required 
for OFBiz ?



Regards,
--
Eugen Stan

https://www.netdava.com


Re: All incoming email going to spam folder

2024-01-08 Thread Eugen Stan

Hello Jim,

First of all you are running a very old release of James and should 
consider upgrading since I don't know if it's "supported" .


I believe James 2.x uses log4j 1.x
So you could configure logging by placing a log4j.properties files as 
first as possible on the classpath.


See Step 4: Configure in https://james.apache.org/server/quick-start.html  .

Not all steps might apply for you since the release is old.

Regards,
Eugen


La 08.01.2024 21:19, Jim Smith a scris:


On 07/01/2024 11:18, Jim Smith wrote:

James server 2.3
My office email server was down over the holiday period, and on 
restarting it all incoming mail is now going to a spam folder on the 
server.
I use fetchmail to bring in mail from various sources to james and 
pop3 server to access the mail from james.
I have an smtp gateway configured pointing to the mail server for an 
externally hosted domain.
As far as I can see, all mail coming in through fetchmail is sent to 
spam.
There is almost nothing in the logs. Fetchmail processing seems to be 
normal.  The only anomaly I can see is in mailet.log
05/01/24 17:17:02 INFO  James.Mailet: RemoteDelivery: maxRetries is 
larger than total number of attempts specified. Increasing last 
delayTime with 19 attempts
05/01/24 17:17:02 INFO  James.Mailet: RemoteDelivery: Delay of 
2160 msecs is now attempted: 20 times
05/01/24 17:22:56 INFO  James.Mailet: ToRepository: Storing mail 
Mail1704475375634-0 in file://var/mail/spam/
The first 2 lines appear at startup, and the 3rd line is repeated for 
each incoming email.

Questions.
1 Any ideas what is going on?
2 How do I increase the logging level to help me work out what is 
going on.
3 Currently, I am accessing these emails by moving them into an inbox, 
and restarting james.   Is there any better way of doing this?




Thanks to Julian and Roy.   The problem was the spam blacklist.

For future reference, can someone tell me how to configure logging on 2.3?



-
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org




-
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org



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

2024-01-05 Thread 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 
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.

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 
<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



[jira] [Commented] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

2024-01-04 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803255#comment-17803255
 ] 

Ioan Eugen Stan commented on OFBIZ-12726:
-

I did a bit of research and found out that ./gradlew "ofbiz --test 
suitename=entitytests"  fails.

It might be the thing that fails the other tests.

I believe it's caused because xstream does not work with Java 17: 
[https://github.com/x-stream/xstream/issues/262] .

The recommended way to fix it is to do:
{color:#6aab73}'--add-opens=java.base/java.util=ALL-UNNAMED' 
{color}{color:#7a7e85}// OFBIZ-12726{color}
which we already do.

There does not seem to be a way around this other than replaxing xstream with 
something else.

So I believe this issue can be closed and we can move forward.

We could open a new issue, related to this where we can consider dropping 
xstream in place of something else.

But I guess we can do that at a later time.

No need to change if we have a workaround that seems ok so far.

cc [~jleroux] , [~pgil]  wdyt?

 

```
| |No converter available  Debugging information  message : No 
converter available type : java.util.Collections$UnmodifiableMap converter : 
com.thoughtworks.xstream.converters.reflection.ReflectionConverter message[1] : 
Unable to make field private static final long 
java.util.Collections$UnmodifiableMap.serialVersionUID accessible: module 
java.base does not "opens java.util" to unnamed module @75eeccf5 
--- 
 
```
{{com.thoughtworks.xstream.converters.ConversionException: No converter 
available}}
{{ Debugging information    
 }}
{{message : No converter available  
  }}
{{type: 
java.util.Collections$UnmodifiableMap}}
{{converter   : 
com.thoughtworks.xstream.converters.reflection.ReflectionConverter  
  }}
{{message[1]  : Unable to make field 
private static final long 
java.util.Collections$UnmodifiableMap.serialVersionUID accessible: 
module java.base does not "opens java.util" to unnamed module @75eeccf5 
   }}
```|

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Attachments: image-2023-12-05-16-52-38-822.png, 
> image-2023-12-12-18-10-16-016.png, image-2024-01-04-18-27-42-512.png, 
> image-2024-01-04-18-28-27-910.png
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

2024-01-04 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803239#comment-17803239
 ] 

Ioan Eugen Stan commented on OFBIZ-12726:
-

So I can confirm what [~pgil]  found.

Running test only a single component - that normally fails - makes the tests 
pass.

This is the result for running: ./gradlew cleanAll loadAll "ofbiz --test 
suitename=accountingtests"

As you can see the accountingtests pass.

!image-2024-01-04-18-27-42-512.png!

 

And this is the result for running: "./gradlew cleanAll loadAll 
testIntegration" .

As you can see the accountingtests fail.

 

!image-2024-01-04-18-28-27-910.png!

 

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Attachments: image-2023-12-05-16-52-38-822.png, 
> image-2023-12-12-18-10-16-016.png, image-2024-01-04-18-27-42-512.png, 
> image-2024-01-04-18-28-27-910.png
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

2024-01-04 Thread Ioan Eugen Stan (Jira)


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

Ioan Eugen Stan updated OFBIZ-12726:

Attachment: image-2024-01-04-18-28-27-910.png

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Attachments: image-2023-12-05-16-52-38-822.png, 
> image-2023-12-12-18-10-16-016.png, image-2024-01-04-18-27-42-512.png, 
> image-2024-01-04-18-28-27-910.png
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

2024-01-04 Thread Ioan Eugen Stan (Jira)


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

Ioan Eugen Stan updated OFBIZ-12726:

Attachment: image-2024-01-04-18-27-42-512.png

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Attachments: image-2023-12-05-16-52-38-822.png, 
> image-2023-12-12-18-10-16-016.png, image-2024-01-04-18-27-42-512.png
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OFBIZ-12722) Fix Java 17 two warning issues

2024-01-04 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803224#comment-17803224
 ] 

Ioan Eugen Stan commented on OFBIZ-12722:
-

[~jleroux] : Any idea why the code was done the way Daniel mentioned? 
> Resolving the deprecation of GroovyTestCase might be a bit complicated. 

> Groovy test suites test specifications are read in 
> _ModelTestSuite#parseTestElements:_

> Fix Java 17 two warning issues
> --
>
> Key: OFBIZ-12722
> URL: https://issues.apache.org/jira/browse/OFBIZ-12722
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: base, testtools
>Affects Versions: Upcoming Branch
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> AuthHelper.java:132: warning: [removal] AccessController in java.security has 
> been deprecated and marked for removal
> return AccessController.doPrivileged(
>^
> GroovyScriptTestCase.java:29: warning: [deprecation] GroovyTestCase in 
> groovy.util has been deprecated
> public class GroovyScriptTestCase extends GroovyTestCase {



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OFBIZ-12722) Fix Java 17 two warning issues

2024-01-04 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803221#comment-17803221
 ] 

Ioan Eugen Stan commented on OFBIZ-12722:
-

I took a look at fixing the groovy warning - no luck yet - the code there is 
pretty complex.

If we have a solution for AuthHelper, we should try it out.

Maybe we can get this done for 24.01 ?!

> Fix Java 17 two warning issues
> --
>
> Key: OFBIZ-12722
> URL: https://issues.apache.org/jira/browse/OFBIZ-12722
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: base, testtools
>Affects Versions: Upcoming Branch
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> AuthHelper.java:132: warning: [removal] AccessController in java.security has 
> been deprecated and marked for removal
> return AccessController.doPrivileged(
>^
> GroovyScriptTestCase.java:29: warning: [deprecation] GroovyTestCase in 
> groovy.util has been deprecated
> public class GroovyScriptTestCase extends GroovyTestCase {



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

2024-01-04 Thread Eugen Stan

Hi,

Inline:

La 04.01.2024 12:03, Jacques Le Roux a scris:


That is ok with me since I plan to use trunk anyway.
So I guess the sooner we have OFBiz 24.01 the better :D .
Are there otehr blockers for 24.01 besides the SVN issue?


There is OFBIZ-12726 
<https://issues.apache.org/jira/browse/OFBIZ-12726?src=confmacro> that I 
set as a blocker. I think we could continue with the workaround for now, 
the community to decide... 24.01 or such is now pressing...


I think the workaround woks fine for JDk-17 but won't work for JDK-21.
If we start splitting the modules we might make the testing part a bit 
more manageable.

I think testing should be done using standard junit tooling.
I might take a look at this once we start breaking up smaller parts.





This said I was reading 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
and stumbled upon 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md


Obviously some parts are obsolete since we rely now on Docker for 
demos. Could you please review and possibly amend?


Is this for me or for Daniel?
I assume it's for Daniel (as I read in your next emails).

Last but not least, I guess we will need very soon to change 
something in Docker config for demos ; since pullAllPluginsSource 
relies on soon not usable SvnCheckout plugin?


Yes indeed I confused, I finally handled Docker with the task 
https://issues.apache.org/jira/browse/OFBIZ-12876
For the READMEs it's more on my side than Daniel's. I'll clean the whole 
thing with https://issues.apache.org/jira/browse/OFBIZ-12863
For demos, we have now 
https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker




I did not know about ofbiz-tools :) .

Thanks,
--
Eugen Stan

+40770 941 271  / https://www.netdava.com



Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

2024-01-03 Thread Eugen Stan

Hi Jacques,

I missed this thread for some reason (was collapsed in TB) and only saw 
it now.


I read the thread.
Glad to see progress on fixing the SVN issue.

Also inline:

La 24.12.2023 13:05, Jacques Le Roux a scris:

Hi Eugen,

I tend to agree with your vision that sounds quite promising. I'm sorry 
I got no time to review your PR yet. I hope to do so during next year...


It's good that it gets some attention.
Even if the PR does not get merged as is but is used as example for the 
idea the PR is meant for.


Of course, this architecture will need to be discussed more and 
especially will not be part of the next release branch (24.01 ? 18.12 
becoming really old).


That is ok with me since I plan to use trunk anyway.
So I guess the sooner we have OFBiz 24.01 the better :D .
Are there otehr blockers for 24.01 besides the SVN issue?



This said I was reading 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
and stumbled upon 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md


Obviously some parts are obsolete since we rely now on Docker for demos. 
Could you please review and possibly amend?


Is this for me or for Daniel?
I assume it's for Daniel (as I read in your next emails).

Last but not least, I guess we will need very soon to change something 
in Docker config for demos ; since pullAllPluginsSource relies on soon 
not usable SvnCheckout plugin?


TIA

Jacques

Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :

Hi Jacques,

Regarding the plugin workflow, the PR that I posted can offer 
alternative ways to develop and consume plugins / components.
This would make plugin development by pulling sources in ofbiz 
optional / obsolete even (a choice).


If we move to have libraries that are published as jar files, then it 
would be possible to develop plugins by depending on the specific 
OFBiz bits.
It would also be possible to publish plugins / components as regular 
java jars and consume them the same way.

So, in the future a custom OFBiz build could look something like this:

build.gradle

dependencies {
  implementation 'org.apache.ofbiz:entity-engine:24.0'
  implementation 'org.apache.ofbiz:service:24.0'
  implementation 'org.apache.ofbiz:accounting:24.0'
  implementation 'com.example:my-plugin:1.2.3'
}




On 23.12.2023 17:06, Jacques Le Roux  
wrote:

It's ready for review before pushing and testing with GH and BB

TIA

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> Hi,
>
> I have created https://issues.apache.org/jira/browse/OFBIZ-12868 
for > that... WIP...

>
> HTH
>
> Jacques
>
> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>> Hi,
>>
>> As you may have noticed*, the SvnCheckout Gradle plugin will not 
be >> usable after January 8, 2024.

>>
>> So we need a replacement and it's clearly suggested by GitHub in 
the >> link below

>>
>> Jacques
>>
>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz





--
Eugen Stan

+40770 941 271  / https://www.netdava.com



[jira] [Commented] (OFBIZ-12868) Replace SvnCheckout in Gradle

2024-01-03 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802286#comment-17802286
 ] 

Ioan Eugen Stan commented on OFBIZ-12868:
-

[~jleroux] github might do a shallow clone : 
[https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/]

> Replace SvnCheckout in Gradle
> -
>
> Key: OFBIZ-12868
> URL: https://issues.apache.org/jira/browse/OFBIZ-12868
> Project: OFBiz
>  Issue Type: Task
>  Components: GitHub, Gradle
>Affects Versions: 22.01.01, Upcoming Branch, 18.12.10
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Fix For: 22.01.01, Upcoming Branch, 18.12.12, 22.01
>
> Attachments: OFBIZ-12868-README.patch, OFBIZ-12868-svncheckout.patch, 
> pullAllPluginsSource.bat, pullAllPluginsSource.sh, pullPluginSource.bat, 
> pullPluginSource.sh
>
>
> As mentionned in 
> https://lists.apache.org/thread/on7n6nsbj0w237sqgmw7bfmw31116wcy
> the SvnCheckout Gradle plugin will not be usable after January 8, 2024.
> So we need a replacement and it's clearly suggested by GitHub in the link 
> above



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: breaking ofbiz piece by piece - expose parts to outside

2024-01-02 Thread Eugen Stan

Hello,

Happy new year!

I hope you had a great 2023.
Has anyone had time to look over the exploratory work?

If you have, please don't be shy, share your findings, good or bad.
It would be great if we can work on concrete examples.

I am still available to answer any questions and improve on the PR's to 
make the changes part of OFBiz moving forward.


Let's make parts of OFBiz available as libraries so they can be used in 
other projects (ofbiz tooling) / other ways of building OFBiz.


Regards,
Eugen

La 09.12.2023 01:04, Eugen Stan a scris:

Hi,

I pushed some changes that significantly reduce the number of lines 
changed and also the possibility of breakage:

- merged back UtilValidateDateTime and UtilValidateEmpty into UtilValidate
- moved some methods from *Runtime -> former class.

If you test the changes and find some issues please let me know.
I am willing to work to  fix those and make the PR mergeable.

I also did an exploratory work to see what would it take to have entity 
engine as a library see https://github.com/ieugen/ofbiz-framework/pull/3


On top of this PR, it adds only 670 lines and remove 370.
Very small price to pay IMO.
I have partial integration tests running.
I have added some comments related to the blockers (EntityEca, Tennant)
They should be doable, but I need more info / help.

To reiterate, please let me know of any issue you find and I will work 
to fix it.


Regards,
Eugen

La 07.12.2023 20:55, Eugen Stan a scris:

Hi Michael,

Thank you for taking a look.
I will reply inline.

I did a demo project to support my case 
https://github.com/ieugen/ofbiz-tooling-demo .


La 07.12.2023 12:53, Michael Brohl a scris:

Hi Eugen,

can you give us some explanations/examples why this is a useful change?

What are the downsides?


I don't see any downsides.
There might be some breaking changes on upgrades.
We could work to mitigate them - will explain bellow.



I see a lot of changes in the base API like UtilValidate, 
UtilProperties etc. which will brake almost every custom project out 
there.


Have you tried it in your projects?
Do you know how many fail?

All the integrations tests pass.
Also we could do some work to mitigate those braking changes:
- copy those methods back to the classes they came from
- implement delegation: add a method with same signature that calls on 
the class from base/util (UtilValidate calls UtilValidateEmpty).


IMO this should be a transition period until the code is cleaned up.
I did not do the mitigations because this is intendend as a POC to be 
prepared once we decide it's a good direction.

Also - I don't have access to 'all the projects out there' to test.

The changes also need explanation. For example: why the split of 
UtilValidate to UtilValidateEmpty etc.


Because of the cyclic dependency between classes.
There is a LOT of cyclic dependencies which IMO is a code smell.
UtilValidate depens on UtilProperties which depens on UtilValidate.
There are numerous cases for this.
If you run Intellij IDEA Analyze -> Analyze Cyclic dependencies you 
will see them.
( I posted an image on gh issue) 
https://github.com/apache/ofbiz-framework/pull/678#issuecomment-1845903198




I think we need to have very strong advantages to make those changes 
and currently I do not see them.


We open OFBiz to be used as libraries.
Then developers can use things like entity-engine, datafile, bits to 
build tooling as CLI or services that integrate with OFBiz.


- It opens a path forward to inovation
- It will make life of integrators MUCH more easy as it will provide 
java API's for them to do integrations

- It exposes the dependencies by making them explicit (as gradle deps)
- Developers can focus on a smaller part of the code base: component 
loading, XML parsing, entity engine without worrying about the rest of 
the code.
- It will allow users to build tools and ofbiz components and package 
them as jar files (component/datafile is a component as a jar file - 
it depends on base/util and base/crypto - but nothing else from OFBiz).
- It will facilitate the developement of proper java API's - now OFBiz 
is an implementation only - the API is the implementation.


I would like to build some import tooling that uses the OFBiz code (so 
I don't reinvent the weel).

Currently I don't see a way on how to do that.

See the https://github.com/ieugen/ofbiz-tooling-demo I just did for 
Crypto. It can help people migrate data from/to OFBiz by using the 
same crypto code and the same xml data processing code.
I do not need to bring whole OFBiz if all I want is to push / pull 
data from DB or to some files.
To my knowledge that is not possible with OFBiz right now (unlesss you 
reimplement the code). It will be possible once we publish libraries.


There is much more that this can help with but we will see if OFBiz to 
accepts some changes.
And again, my changes don't break ANY integration test from the 780?! 
tests.


I am very excited of finding this way of breaking

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

2023-12-23 Thread eugen . stan

Hi Jacques,

Regarding the plugin workflow, the PR that I posted can offer alternative ways 
to develop and consume plugins / components.
This would make plugin development by pulling sources in ofbiz optional / 
obsolete even (a choice).

If we move to have libraries that are published as jar files, then it would be 
possible to develop plugins by depending on the specific OFBiz bits.
It would also be possible to publish plugins / components as regular java jars and consume them the same way. 


So, in the future a custom OFBiz build could look something like this:

build.gradle

dependencies {
  implementation 'org.apache.ofbiz:entity-engine:24.0'
  implementation 'org.apache.ofbiz:service:24.0'
  implementation 'org.apache.ofbiz:accounting:24.0'
  implementation 'com.example:my-plugin:1.2.3'
}




On 23.12.2023 17:06, Jacques Le Roux  wrote:

It's ready for review before pushing and testing with GH and BB

TIA

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> Hi,
>
> I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for 
> that... WIP...

>
> HTH
>
> Jacques
>
> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>> Hi,
>>
>> As you may have noticed*, the SvnCheckout Gradle plugin will not be 
>> usable after January 8, 2024.

>>
>> So we need a replacement and it's clearly suggested by GitHub in the 
>> link below

>>
>> Jacques
>>
>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz





[no subject]

2023-12-22 Thread Eugen Stan

Hi,


I wanted to ask if Syncope is / can be used to store linux group ID's .
We have some users and groups in Azure AD and I would like to have 
available for linux systems

- sync those users and groups
- generate the grup GID for linux (integer in high range - 9000 - 3)
- generate the UID for linux ( integer in high range - 9000 - 3)
- generate the linux group name ?!
- generate the linux user name (first part of email ?! )
- periodically sync the groups and users to all linux hosts - there is a 
project for this already that integrates with linux 
https://github.com/google/nsscache


Has anyone done something similar with Syncope?
Syncope seems to have most of the bits we need for this job. (edited)
Is there a better way of handling this?

--
Eugen


Re: how to upgrade ofbiz

2023-12-13 Thread Eugen Stan

Hi Nicolas,

Thank you for taking the time to look at this.
I am available for a call / chat on Slack as well.
I would really love to see this through.

The short term goal of the PR:
- show that we can have OFBiz parts as libraries that we can publish and 
reuse. No more mandatory rebase, but still an option.

- extract enough of OFBiz to allow splitinmg more as library

Medium term goal is entity engine library and service engine library.
Being able to use parts of OFBiz as librarries opens up a whole new 
world of posibilities: tooling and integrations that are hard / 
impossible to do.


Also having libraries - makes code more robust - forces out dependencies 
and is easier to reason about when making changes.
If I work on EntityEngine for example, I should not care about widget 
rendering or service layer that much since those should sit on top / be 
orthogonal to DB layer. Right now, every OFBiz change needs to take ALL 
of OFBiz into account, incluing private installations - since they might 
break.


Doing the refactoring exercise surfaced a lot of cyclic dependencies 
between OFBiz classes and parts.
Did you know entity engine code depends on widget rendering code or 
service execution code?
I find that to be peculiar since I would think the dependency should be 
the other way around. (Well the dependency is cyclcic unfortunatelly).


I think I will record the next session so people can watch it.
It makes explainig much easier to follow IMO.

Regards,
Eugen

La 13.12.2023 12:41, Nicolas Malin a scris:

Hi Eugen

Le 08/12/2023 à 19:05, Eugen Stan a écrit :

Thanks Nicolas,

Merging git / rebasing does not sound like a fun operation.
How does it go in practice?
How often do you encounter conflicts and how easy it is to deal with 
them.


Do you usually make changes to the ofbiz source code?
How do you add new components?
I live with it well :) because we don't touch the framework and try to 
work mostly on dedicate plugin.
The reason that we tried to improve OFBiz to support most extend cases 
through the plugin.


I am doing some research to support my PR 
https://github.com/apache/ofbiz-framework/pull/678 .

Yeah when we are on refactoring process I agree it's pain.


I believe publishing libraries will open up new deployment options.
Would love to hear your thoughs on that if you have time to check it out.
I started a review of your PR, I'll try to do a constructive return, the 
time that I understand well your goal.


Thanks for your work Eugen !
Nicolas


Regards,
Eugen

La 08.12.2023 15:25, Nicolas Malin a scris:

Hello Eugen,

 From our side, we have the ofbiz-framework dedicate on each project 
on our gitlab.
We add the official repo on available git remote, fetch and merge the 
wanted branch on the following local branch.

After rebase all depending branch to keep all up to date.

If you are not connected to git, I think the better way is retrieve 
the patch between two release tags.


Nicolas


Le 08/12/2023 à 14:12, Eugen Stan a écrit :

Hi,

How does one upgrade OFBiz from one release to the other?

Do you clone the repo and rebase your changes?


Regards,








--
Eugen Stan

+40770 941 271  / https://www.netdava.com



[jira] [Commented] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

2023-12-12 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795933#comment-17795933
 ] 

Ioan Eugen Stan commented on OFBIZ-12726:
-

Thank you [~pgil] ,  I have put a pause on this issue as I am waiting fro a 
review on [https://github.com/apache/ofbiz-framework/pull/678] .

I believe building libraries from ofbiz pieces can help with clarify 
dependencies and after some time improve the testing support - my moving the 
code to more standard testing practices.

Perhaps we could have an embedded in-memory ofbiz for testing - like we have 
now, but better defined in terms of dependencies.

I believe now it's an all or nothing scenario.

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Attachments: image-2023-12-05-16-52-38-822.png, 
> image-2023-12-12-18-10-16-016.png
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: breaking ofbiz piece by piece - expose parts to outside

2023-12-08 Thread Eugen Stan

Hi,

I pushed some changes that significantly reduce the number of lines 
changed and also the possibility of breakage:

- merged back UtilValidateDateTime and UtilValidateEmpty into UtilValidate
- moved some methods from *Runtime -> former class.

If you test the changes and find some issues please let me know.
I am willing to work to  fix those and make the PR mergeable.

I also did an exploratory work to see what would it take to have entity 
engine as a library see https://github.com/ieugen/ofbiz-framework/pull/3


On top of this PR, it adds only 670 lines and remove 370.
Very small price to pay IMO.
I have partial integration tests running.
I have added some comments related to the blockers (EntityEca, Tennant)
They should be doable, but I need more info / help.

To reiterate, please let me know of any issue you find and I will work 
to fix it.


Regards,
Eugen

La 07.12.2023 20:55, Eugen Stan a scris:

Hi Michael,

Thank you for taking a look.
I will reply inline.

I did a demo project to support my case 
https://github.com/ieugen/ofbiz-tooling-demo .


La 07.12.2023 12:53, Michael Brohl a scris:

Hi Eugen,

can you give us some explanations/examples why this is a useful change?

What are the downsides?


I don't see any downsides.
There might be some breaking changes on upgrades.
We could work to mitigate them - will explain bellow.



I see a lot of changes in the base API like UtilValidate, 
UtilProperties etc. which will brake almost every custom project out 
there.


Have you tried it in your projects?
Do you know how many fail?

All the integrations tests pass.
Also we could do some work to mitigate those braking changes:
- copy those methods back to the classes they came from
- implement delegation: add a method with same signature that calls on 
the class from base/util (UtilValidate calls UtilValidateEmpty).


IMO this should be a transition period until the code is cleaned up.
I did not do the mitigations because this is intendend as a POC to be 
prepared once we decide it's a good direction.

Also - I don't have access to 'all the projects out there' to test.

The changes also need explanation. For example: why the split of 
UtilValidate to UtilValidateEmpty etc.


Because of the cyclic dependency between classes.
There is a LOT of cyclic dependencies which IMO is a code smell.
UtilValidate depens on UtilProperties which depens on UtilValidate.
There are numerous cases for this.
If you run Intellij IDEA Analyze -> Analyze Cyclic dependencies you will 
see them.
( I posted an image on gh issue) 
https://github.com/apache/ofbiz-framework/pull/678#issuecomment-1845903198




I think we need to have very strong advantages to make those changes 
and currently I do not see them.


We open OFBiz to be used as libraries.
Then developers can use things like entity-engine, datafile, bits to 
build tooling as CLI or services that integrate with OFBiz.


- It opens a path forward to inovation
- It will make life of integrators MUCH more easy as it will provide 
java API's for them to do integrations

- It exposes the dependencies by making them explicit (as gradle deps)
- Developers can focus on a smaller part of the code base: component 
loading, XML parsing, entity engine without worrying about the rest of 
the code.
- It will allow users to build tools and ofbiz components and package 
them as jar files (component/datafile is a component as a jar file - it 
depends on base/util and base/crypto - but nothing else from OFBiz).
- It will facilitate the developement of proper java API's - now OFBiz 
is an implementation only - the API is the implementation.


I would like to build some import tooling that uses the OFBiz code (so I 
don't reinvent the weel).

Currently I don't see a way on how to do that.

See the https://github.com/ieugen/ofbiz-tooling-demo I just did for 
Crypto. It can help people migrate data from/to OFBiz by using the same 
crypto code and the same xml data processing code.
I do not need to bring whole OFBiz if all I want is to push / pull data 
from DB or to some files.
To my knowledge that is not possible with OFBiz right now (unlesss you 
reimplement the code). It will be possible once we publish libraries.


There is much more that this can help with but we will see if OFBiz to 
accepts some changes.
And again, my changes don't break ANY integration test from the 780?! 
tests.


I am very excited of finding this way of breaking OFBiz into smaller 
parts without breaking OFBiz runtime.
There will be work to be done to streamline the code as libs but I am 
optimistic.


Regards,


--
Eugen Stan

+40770 941 271  / https://www.netdava.com



Re: how to upgrade ofbiz

2023-12-08 Thread Eugen Stan

Thanks Nicolas,

Merging git / rebasing does not sound like a fun operation.
How does it go in practice?

How often do you encounter conflicts and how easy it is to deal with them.

Do you usually make changes to the ofbiz source code?
How do you add new components?

I am doing some research to support my PR 
https://github.com/apache/ofbiz-framework/pull/678 .


I believe publishing libraries will open up new deployment options.
Would love to hear your thoughs on that if you have time to check it out.

Regards,
Eugen

La 08.12.2023 15:25, Nicolas Malin a scris:

Hello Eugen,

 From our side, we have the ofbiz-framework dedicate on each project on 
our gitlab.
We add the official repo on available git remote, fetch and merge the 
wanted branch on the following local branch.

After rebase all depending branch to keep all up to date.

If you are not connected to git, I think the better way is retrieve the 
patch between two release tags.


Nicolas


Le 08/12/2023 à 14:12, Eugen Stan a écrit :

Hi,

How does one upgrade OFBiz from one release to the other?

Do you clone the repo and rebase your changes?


Regards,




--
Eugen Stan

+40770 941 271  / https://www.netdava.com



how to upgrade ofbiz

2023-12-08 Thread Eugen Stan

Hi,

How does one upgrade OFBiz from one release to the other?

Do you clone the repo and rebase your changes?


Regards,
--
Eugen Stan

+40770 941 271  / https://www.netdava.com


Re: breaking ofbiz piece by piece - expose parts to outside

2023-12-07 Thread Eugen Stan

Hi Michael,

Thank you for taking a look.
I will reply inline.

I did a demo project to support my case 
https://github.com/ieugen/ofbiz-tooling-demo .


La 07.12.2023 12:53, Michael Brohl a scris:

Hi Eugen,

can you give us some explanations/examples why this is a useful change?

What are the downsides?


I don't see any downsides.
There might be some breaking changes on upgrades.
We could work to mitigate them - will explain bellow.



I see a lot of changes in the base API like UtilValidate, UtilProperties 
etc. which will brake almost every custom project out there.


Have you tried it in your projects?
Do you know how many fail?

All the integrations tests pass.
Also we could do some work to mitigate those braking changes:
- copy those methods back to the classes they came from
- implement delegation: add a method with same signature that calls on 
the class from base/util (UtilValidate calls UtilValidateEmpty).


IMO this should be a transition period until the code is cleaned up.
I did not do the mitigations because this is intendend as a POC to be 
prepared once we decide it's a good direction.

Also - I don't have access to 'all the projects out there' to test.

The changes also need explanation. For example: why the split of 
UtilValidate to UtilValidateEmpty etc.


Because of the cyclic dependency between classes.
There is a LOT of cyclic dependencies which IMO is a code smell.
UtilValidate depens on UtilProperties which depens on UtilValidate.
There are numerous cases for this.
If you run Intellij IDEA Analyze -> Analyze Cyclic dependencies you will 
see them.
( I posted an image on gh issue) 
https://github.com/apache/ofbiz-framework/pull/678#issuecomment-1845903198




I think we need to have very strong advantages to make those changes and 
currently I do not see them.


We open OFBiz to be used as libraries.
Then developers can use things like entity-engine, datafile, bits to 
build tooling as CLI or services that integrate with OFBiz.


- It opens a path forward to inovation
- It will make life of integrators MUCH more easy as it will provide 
java API's for them to do integrations

- It exposes the dependencies by making them explicit (as gradle deps)
- Developers can focus on a smaller part of the code base: component 
loading, XML parsing, entity engine without worrying about the rest of 
the code.
- It will allow users to build tools and ofbiz components and package 
them as jar files (component/datafile is a component as a jar file - it 
depends on base/util and base/crypto - but nothing else from OFBiz).
- It will facilitate the developement of proper java API's - now OFBiz 
is an implementation only - the API is the implementation.


I would like to build some import tooling that uses the OFBiz code (so I 
don't reinvent the weel).

Currently I don't see a way on how to do that.

See the https://github.com/ieugen/ofbiz-tooling-demo I just did for 
Crypto. It can help people migrate data from/to OFBiz by using the same 
crypto code and the same xml data processing code.
I do not need to bring whole OFBiz if all I want is to push / pull data 
from DB or to some files.
To my knowledge that is not possible with OFBiz right now (unlesss you 
reimplement the code). It will be possible once we publish libraries.


There is much more that this can help with but we will see if OFBiz to 
accepts some changes.
And again, my changes don't break ANY integration test from the 780?! 
tests.


I am very excited of finding this way of breaking OFBiz into smaller 
parts without breaking OFBiz runtime.
There will be work to be done to streamline the code as libs but I am 
optimistic.


Regards,
--
Eugen Stan

+40770 941 271  / https://www.netdava.com



Re: breaking ofbiz piece by piece - expose parts to outside

2023-12-06 Thread Eugen Stan

Hi,

La 06.12.2023 18:01, Jacques Le Roux a scris:

Le 06/12/2023 à 15:32, Eugen Stan a écrit :
I need help with that one since I don't know how to run itests in IDE 
to debug


Hi Eugen,

I answered you at https://issues.apache.org/jira/browse/OFBIZ-12726



Merci Jacques :) .
It seems all integration tests are passing for my branch.

Please let me know your feedback and what will it take to have the PR 
merged.


Once that is done I would like to focus on fixing the tests for JDK17 
and see what will it take to get OFBiz on JDK21.


Once the datafile is published (being optimistic) I would like to work 
on some CLI tooling to import data in OFBIz. Alternative to current 
gradle / WebTools tooling.



--
Eugen Stan

+40770 941 271  / https://www.netdava.com



[jira] [Commented] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

2023-12-06 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793932#comment-17793932
 ] 

Ioan Eugen Stan commented on OFBIZ-12726:
-

Thank you.

I managed to run it in debug.

I am more used to right click inside test and select Run/Debug option.

Maybe we can make this happen in the future. 
It's a nicer experience.

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Attachments: image-2023-12-05-16-52-38-822.png
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OFBIZ-12308) Remove circular dependency between start and base components

2023-12-06 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793756#comment-17793756
 ] 

Ioan Eugen Stan commented on OFBIZ-12308:
-

A potential solution on how to approach this task is given in 
[https://github.com/apache/ofbiz-framework/pull/678]

> Remove circular dependency between start and base components
> 
>
> Key: OFBIZ-12308
> URL: https://issues.apache.org/jira/browse/OFBIZ-12308
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: base, start
>    Reporter: Ioan Eugen Stan
>Priority: Major
>
> Right now start and base components depend one on the other. 
> This should be resolved so that only 1 component should depend on the other.
> *Guidance needed.*
> Not sure right now if start should depend on base or the reverse. 
> This was discovered as part of exploratory branch  
> [https://github.com/apache/ofbiz-framework/pull/319] .
> I believe a logical dependency tree for components is needed. 
> This dependency tree will help guide people when needing to decide which 
> component should depend on which. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: breaking ofbiz piece by piece - expose parts to outside

2023-12-06 Thread Eugen Stan

Hi,

To support my proposal I have made the changes in this PR 
https://github.com/apache/ofbiz-framework/pull/678 .


The code above works:
- "./gradlew cleanAll loadAll testIntegration"  - gives me 1 failed test 
from 772 (I need help with that one since I don't know how to run itests 
in IDE to debug)
- "./gradlew cleanAll loadAll "ofbiz --start" " - works and I can see 
DataFile component


== How I got here

I introduced 3 gradle projects:

- base/util
- base/crypto (depends on base/util)
- components/datafile (depends on both the above)

I added dependencies to these projects to ofbiz/build.gradle via

   implementation project(':build/util') // ...

Using Intellij "Move class" refactoring I moved classes to one of those 
projects.


There where a lot of circular dependencies (for example: class 
UtilValidate is using UtilProperties that uses UtilValidate ).


To solve these I use the following technicues:
- Split some methods to a new class and moved that one in base/util: See 
UtilFormatOut -> UtilFormatOutBase for example and UtilValidate -> 
UtilValidateEmpty and UtilProperties -> UtilPropertiesRuntime


You can recognize these by *Base or *Runtime sufixes.

- Inline some methods - copy one method to a class - creates a small 
duplication but breaks dependency cycle.


A lot of time was spent fixing checkstyle errors.
Please please please adopt gradle spotless for automatic java formatting 
from gradle.
Using something like google java code formattter you can have the same 
formatter in IDE and in gradle cli

- https://github.com/diffplug/spotless/tree/main/plugin-gradle#java

== Where togo from here:

- I would like for us to merge this code ASAP and continue with the 
approach for other bits and pieces.
  IMO Focus should be on EntityEngine - but every reusable feature 
should be split.

- Work can be merged as is IMO (pending some testing)
- Dependencies are starting to be explicit for each project
- We can publish datafile and base/util, base/crypto to Maven repo so 
they can be reused in libraries / tooling.

- We need to breake up the cyclic dependencies between classes.
  This is A MUST if we want to make OFBiz more modular.
  Moving code to a project forces the dependencies to be explicit.
  IDE's also have some helpers to detect cyclic dependencies.


Waiting for feedback,
Eugen

La 06.12.2023 01:15, Eugen Stan a scris:

Hello OFBiz devs,

I had some time to check out OFBiz again and I would like to propose 
some improvements to OFBiz.


The purpose is to split some independent parts from ofbiz so they can be 
used by other projects that wish to interact with OFBiz.


The main beneficiaries will be ofbiz related tooling IMO.

I believe I have identified two initial candidates for splitting:

- datafile component = "framework/datafile" - split as a project / 
library - usefull for tooling
- base/crypto - 
framework/base/src/main/java/org/apache/ofbiz/base/crypto - to do crypto 
in tooling compatible with ofbiz
- base/util - framework/base/src/main/java/org/apache/ofbiz/base/util - 
this is used across both of the above stuff


== How the split should happen and how it will look like:


Use gradle subprojects feature to define 3 subprojects in the 
ofbiz-framework git repo:

- base/utils
- base/crypto
- components/datafile

The projects will be standalone gradle projects that can be built 
individually and have dependencies.

https://docs.gradle.org/current/userguide/declaring_dependencies_between_subprojects.html

Since these projects can build jar files, they can be published to maven 
to be consumed by other apps.
Since they are projects part of ofbiz-framework, they will participate 
as dependencies in the build.


I hope this can open the door to further refactoring and making OFBiz 
play nicer with outside developers.



After the change, the code should function the same with regards to 
normal OFBIz operations




It is somewhat related to https://issues.apache.org/jira/browse/OFBIZ-3500




--
Eugen Stan

+40770 941 271  / https://www.netdava.com



breaking ofbiz piece by piece - expose parts to outside

2023-12-05 Thread Eugen Stan

Hello OFBiz devs,

I had some time to check out OFBiz again and I would like to propose 
some improvements to OFBiz.


The purpose is to split some independent parts from ofbiz so they can be 
used by other projects that wish to interact with OFBiz.


The main beneficiaries will be ofbiz related tooling IMO.

I believe I have identified two initial candidates for splitting:

- datafile component = "framework/datafile" - split as a project / 
library - usefull for tooling
- base/crypto - 
framework/base/src/main/java/org/apache/ofbiz/base/crypto - to do crypto 
in tooling compatible with ofbiz
- base/util - framework/base/src/main/java/org/apache/ofbiz/base/util - 
this is used across both of the above stuff


== How the split should happen and how it will look like:


Use gradle subprojects feature to define 3 subprojects in the 
ofbiz-framework git repo:

- base/utils
- base/crypto
- components/datafile

The projects will be standalone gradle projects that can be built 
individually and have dependencies.
https://docs.gradle.org/current/userguide/declaring_dependencies_between_subprojects.html 



Since these projects can build jar files, they can be published to maven 
to be consumed by other apps.
Since they are projects part of ofbiz-framework, they will participate 
as dependencies in the build.


I hope this can open the door to further refactoring and making OFBiz 
play nicer with outside developers.



After the change, the code should function the same with regards to 
normal OFBIz operations




It is somewhat related to https://issues.apache.org/jira/browse/OFBIZ-3500


--
Eugen Stan

+40770 941 271  / https://www.netdava.com


[jira] [Created] (OFBIZ-12870) Remove DES encryption from ofbiz crypto - insecure algorithm

2023-12-05 Thread Ioan Eugen Stan (Jira)
Ioan Eugen Stan created OFBIZ-12870:
---

 Summary: Remove DES encryption from ofbiz crypto - insecure 
algorithm
 Key: OFBIZ-12870
 URL: https://issues.apache.org/jira/browse/OFBIZ-12870
 Project: OFBiz
  Issue Type: Bug
  Components: framework/base
Reporter: Ioan Eugen Stan


In my opinion OFBiz should remove or deprecate and remove the implementation 
for DES crypto - class org.apache.ofbiz.base.crypto.DesCrypt .

DES encryption is broken and insecure to my knowledge 

[https://en.wikipedia.org/wiki/Data_Encryption_Standard]

[https://www.techtarget.com/searchsecurity/tip/Expert-advice-Encryption-101-Triple-DES-explained]

[https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html]

In my opinion - it should be removed from the code in new releases.

If people have data encrypted with this they should migrate somehow.

Probably via an export-import?

 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

2023-12-05 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793365#comment-17793365
 ] 

Ioan Eugen Stan edited comment on OFBIZ-12726 at 12/5/23 5:19 PM:
--

I would like to know how to run the test from IDE as it's not very clear to me.

I have the this test failing 
|[accountingtests|http://localhost:63342/1_accountingtests.html]| 
[accounting-tests-data-load|http://localhost:63342/1_accountingtests.html#accounting-tests-data-load]|Error|

with the following error, but it does not tell me where in the code the test is 
failing. 
{noformat}
A transaction error occurred reading data
org.xml.sax.SAXException: A transaction error occurred 
reading data
org.apache.ofbiz.entity.transaction.GenericTransactionException: The 
current transaction is marked for rollback, not beginning a new 
transaction and aborting current operation; the rollbackOnly was caused 
by: Failure in create operation for entity [TestingCrypto]: 
java.lang.IllegalStateException: This object has been flagged as 
immutable (unchangeable), probably because it came from an Entity Engine
 cache. Cannot modify an immutable entity object. Use the clone method 
to create a mutable copy of this object.. Rolling back 
transaction.java.lang.IllegalStateException: This object has been 
flagged as immutable (unchangeable), probably because it came from an 
Entity Engine cache. Cannot modify an immutable entity object. Use the 
clone method to create a mutable copy of this object. (This object has 
been flagged as immutable (unchangeable), probably because it came from 
an Entity Engine cache. Cannot modify an immutable entity object. Use 
the clone method to create a mutable copy of this object.)
at 
org.apache.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:299)
at 
org.apache.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:261)
at 
org.apache.ofbiz.testtools.EntityXmlAssertTest.run(EntityXmlAssertTest.java:80)
at 
org.apache.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:90)
at 
org.apache.ofbiz.base.container.ContainerLoader.startLoadedContainers(ContainerLoader.java:153)
at 
org.apache.ofbiz.base.container.ContainerLoader.load(ContainerLoader.java:77)
at 
org.apache.ofbiz.base.start.StartupControlPanel.loadContainers(StartupControlPanel.java:146)
at 
org.apache.ofbiz.base.start.StartupControlPanel.start(StartupControlPanel.java:70)
at 
org.apache.ofbiz.base.start.Start.main(Start.java:89)
Caused by: 
org.apache.ofbiz.entity.transaction.GenericTransactionException: The 
current transaction is marked for rollback, not beginning a new 
transaction and aborting current operation; the rollbackOnly was caused 
by: Failure in create operation for entity [TestingCrypto]: 
java.lang.IllegalStateException: This object has been flagged as 
immutable (unchangeable), probably because it came from an Entity Engine
 cache. Cannot modify an immutable entity object. Use the clone method 
to create a mutable copy of this object.. Rolling back 
transaction.java.lang.IllegalStateException: This object has been 
flagged as immutable (unchangeable), probably because it came from an 
Entity Engine cache. Cannot modify an immutable entity object. Use the 
clone method to create a mutable copy of this object. (This object has 
been flagged as immutable (unchangeable), probably because it came from 
an Entity Engine cache. Cannot modify an immutable entity object. Use 
the clone method to create a mutable copy of this object.)
at 
org.apache.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:143)
at 
org.apache.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:277)
Caused by: java.lang.IllegalStateException: This
 object has been flagged as immutable (unchangeable), probably because 
it came from an Entity Engine cache. Cannot modify an immutable entity 
object. Use the clone method to create a mutable copy of this object.
at 
org.apache.ofbiz.entity.GenericEntity.assertIsMutable(GenericEntity.java:165)
at 
org.apache.ofbiz.entity.GenericEntity.setDelegator(GenericEntity.java:408)
at 
org.apache.ofbiz.entity.GenericDelegator.create(GenericDelegator.java:890)
at 
org.apache.ofbiz.entity.GenericDelegator.rollback(GenericDelegator.java:2715)
at 
org.apache.ofbiz.testtools.TestRunContainer.start

[jira] [Commented] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

2023-12-05 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793365#comment-17793365
 ] 

Ioan Eugen Stan commented on OFBIZ-12726:
-

I would like to know how to run the test from IDE as it's not very clear to me.

 

I have
{noformat}
A transaction error occurred reading data
org.xml.sax.SAXException: A transaction error occurred 
reading data
org.apache.ofbiz.entity.transaction.GenericTransactionException: The 
current transaction is marked for rollback, not beginning a new 
transaction and aborting current operation; the rollbackOnly was caused 
by: Failure in create operation for entity [TestingCrypto]: 
java.lang.IllegalStateException: This object has been flagged as 
immutable (unchangeable), probably because it came from an Entity Engine
 cache. Cannot modify an immutable entity object. Use the clone method 
to create a mutable copy of this object.. Rolling back 
transaction.java.lang.IllegalStateException: This object has been 
flagged as immutable (unchangeable), probably because it came from an 
Entity Engine cache. Cannot modify an immutable entity object. Use the 
clone method to create a mutable copy of this object. (This object has 
been flagged as immutable (unchangeable), probably because it came from 
an Entity Engine cache. Cannot modify an immutable entity object. Use 
the clone method to create a mutable copy of this object.)
at 
org.apache.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:299)
at 
org.apache.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:261)
at 
org.apache.ofbiz.testtools.EntityXmlAssertTest.run(EntityXmlAssertTest.java:80)
at 
org.apache.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:90)
at 
org.apache.ofbiz.base.container.ContainerLoader.startLoadedContainers(ContainerLoader.java:153)
at 
org.apache.ofbiz.base.container.ContainerLoader.load(ContainerLoader.java:77)
at 
org.apache.ofbiz.base.start.StartupControlPanel.loadContainers(StartupControlPanel.java:146)
at 
org.apache.ofbiz.base.start.StartupControlPanel.start(StartupControlPanel.java:70)
at 
org.apache.ofbiz.base.start.Start.main(Start.java:89)
Caused by: 
org.apache.ofbiz.entity.transaction.GenericTransactionException: The 
current transaction is marked for rollback, not beginning a new 
transaction and aborting current operation; the rollbackOnly was caused 
by: Failure in create operation for entity [TestingCrypto]: 
java.lang.IllegalStateException: This object has been flagged as 
immutable (unchangeable), probably because it came from an Entity Engine
 cache. Cannot modify an immutable entity object. Use the clone method 
to create a mutable copy of this object.. Rolling back 
transaction.java.lang.IllegalStateException: This object has been 
flagged as immutable (unchangeable), probably because it came from an 
Entity Engine cache. Cannot modify an immutable entity object. Use the 
clone method to create a mutable copy of this object. (This object has 
been flagged as immutable (unchangeable), probably because it came from 
an Entity Engine cache. Cannot modify an immutable entity object. Use 
the clone method to create a mutable copy of this object.)
at 
org.apache.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:143)
at 
org.apache.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:277)
Caused by: java.lang.IllegalStateException: This
 object has been flagged as immutable (unchangeable), probably because 
it came from an Entity Engine cache. Cannot modify an immutable entity 
object. Use the clone method to create a mutable copy of this object.
at 
org.apache.ofbiz.entity.GenericEntity.assertIsMutable(GenericEntity.java:165)
at 
org.apache.ofbiz.entity.GenericEntity.setDelegator(GenericEntity.java:408)
at 
org.apache.ofbiz.entity.GenericDelegator.create(GenericDelegator.java:890)
at 
org.apache.ofbiz.entity.GenericDelegator.rollback(GenericDelegator.java:2715)
at 
org.apache.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:92){noformat}

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
> 

[jira] [Commented] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

2023-12-05 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793313#comment-17793313
 ] 

Ioan Eugen Stan commented on OFBIZ-12726:
-

How can i see the tests failures? 

I ran

```

$ ./gradlew cleanAll loadAll testIntegration

```

and opened 
[http://localhost:63342/ofbiz/runtime/logs/test-results/html/index.html . 
|http://localhost:63342/ofbiz/runtime/logs/test-results/html/index.html?_ijt=ejmrh78bnvnoueqi03h7pqd2ut&_ij_reload=RELOAD_ON_SAVE]
I got

!image-2023-12-05-16-52-38-822.png!

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Attachments: image-2023-12-05-16-52-38-822.png
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

2023-12-05 Thread Ioan Eugen Stan (Jira)


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

Ioan Eugen Stan updated OFBIZ-12726:

Attachment: image-2023-12-05-16-52-38-822.png

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Attachments: image-2023-12-05-16-52-38-822.png
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OFBIZ-12721) Replace all occurrences of java.util.TimeZone by java.time.ZoneId

2023-12-03 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792605#comment-17792605
 ] 

Ioan Eugen Stan commented on OFBIZ-12721:
-

Provided a PR [~jleroux] . I think we can close this one finally.

> Replace all occurrences of java.util.TimeZone by java.time.ZoneId
> -
>
> Key: OFBIZ-12721
> URL: https://issues.apache.org/jira/browse/OFBIZ-12721
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Upcoming Branch
> Environment: Java 17
>Reporter: Jacques Le Roux
>    Assignee: Ioan Eugen Stan
>Priority: Major
>
> Using JDK 17, we have this issue:
> {noformat}
> 2022-12-06 19:04:30,689 |sse-nio-8443-exec-10 |FreeMarkerWorker  
> |E| null
> freemarker.core._TemplateModelException: Java method 
> "sun.util.calendar.ZoneInfo.useDaylightTime()" threw an exception when 
> invoked on sun.util.calendar.ZoneInfo object 
> "sun.util.calendar.ZoneInfo[id=\"Europe/Paris\",offset=360,dstSa
> vings=360,useDaylight=true,transitions=184,lastRule=java.util.SimpleTimeZone[id=Europe/Paris,offset=360,dstSavings=360,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=360,start
> TimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=360,endTimeMode=2]]";
>  see cause exception in the Java stack trace.
> 
> FTL stack trace ("~" means nesting-related):
> - Failed at: ${timeZone.getDisplayName(timeZone.us...  [in template 
> "component://helveticus/template/includes/Footer.ftl" at line 21, column 98]
> 
> at 
> freemarker.ext.beans._MethodUtil.newInvocationTemplateModelException(_MethodUtil.java:292)
>  ~[freemarker-2.3.31.jar:2.3.31]
> [...]
> Caused by: java.lang.IllegalAccessException: class 
> freemarker.ext.beans.BeansWrapper cannot access class 
> sun.util.calendar.ZoneInfo (in module java.base) because module java.base 
> does not export sun.util.calendar to unnamed module @1c852c0f
> at 
> jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
>  ~[?:?]
> at 
> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) 
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:560) ~[?:?]
> at 
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1552) 
> ~[freemarker-2.3.31.jar:2.3.31]
> at 
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:73) 
> ~[freemarker-2.3.31.jar:2.3.31]
> ... 85 more
> {noformat}
> [The var timeZone is accessible in screen 
> context|https://cwiki.apache.org/confluence/display/OFBIZ/Variables+always+available+in+screen+context].
>  The java.util.TimeZone class uses sun.util.calendar.ZoneInfo internally. 
> It's no longer supported by Java 17. We need to replace all occurrences of 
> java.util.TimeZone by java.time.ZoneId.
> An easy temporary solution is to set 
> {{--add-exports=java.base/sun.util.calendar=ALL-UNNAMED}} in build.gradle:
> : 
> ['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50','--add-exports=java.base/sun.util.calendar=ALL-UNNAMED']
> It has no impact with JDK 11.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OFBIZ-12721) Replace all occurrences of java.util.TimeZone by java.time.ZoneId

2023-12-03 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792603#comment-17792603
 ] 

Ioan Eugen Stan commented on OFBIZ-12721:
-

Apparently this works:
${timeZone.toZoneId().getDisplayName(Static["java.time.format.TextStyle"].FULL, 
locale)}

> Replace all occurrences of java.util.TimeZone by java.time.ZoneId
> -
>
> Key: OFBIZ-12721
> URL: https://issues.apache.org/jira/browse/OFBIZ-12721
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Upcoming Branch
> Environment: Java 17
>Reporter: Jacques Le Roux
>Assignee: Ioan Eugen Stan
>Priority: Major
>
> Using JDK 17, we have this issue:
> {noformat}
> 2022-12-06 19:04:30,689 |sse-nio-8443-exec-10 |FreeMarkerWorker  
> |E| null
> freemarker.core._TemplateModelException: Java method 
> "sun.util.calendar.ZoneInfo.useDaylightTime()" threw an exception when 
> invoked on sun.util.calendar.ZoneInfo object 
> "sun.util.calendar.ZoneInfo[id=\"Europe/Paris\",offset=360,dstSa
> vings=360,useDaylight=true,transitions=184,lastRule=java.util.SimpleTimeZone[id=Europe/Paris,offset=360,dstSavings=360,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=360,start
> TimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=360,endTimeMode=2]]";
>  see cause exception in the Java stack trace.
> 
> FTL stack trace ("~" means nesting-related):
> - Failed at: ${timeZone.getDisplayName(timeZone.us...  [in template 
> "component://helveticus/template/includes/Footer.ftl" at line 21, column 98]
> 
> at 
> freemarker.ext.beans._MethodUtil.newInvocationTemplateModelException(_MethodUtil.java:292)
>  ~[freemarker-2.3.31.jar:2.3.31]
> [...]
> Caused by: java.lang.IllegalAccessException: class 
> freemarker.ext.beans.BeansWrapper cannot access class 
> sun.util.calendar.ZoneInfo (in module java.base) because module java.base 
> does not export sun.util.calendar to unnamed module @1c852c0f
> at 
> jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
>  ~[?:?]
> at 
> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) 
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:560) ~[?:?]
> at 
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1552) 
> ~[freemarker-2.3.31.jar:2.3.31]
> at 
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:73) 
> ~[freemarker-2.3.31.jar:2.3.31]
> ... 85 more
> {noformat}
> [The var timeZone is accessible in screen 
> context|https://cwiki.apache.org/confluence/display/OFBIZ/Variables+always+available+in+screen+context].
>  The java.util.TimeZone class uses sun.util.calendar.ZoneInfo internally. 
> It's no longer supported by Java 17. We need to replace all occurrences of 
> java.util.TimeZone by java.time.ZoneId.
> An easy temporary solution is to set 
> {{--add-exports=java.base/sun.util.calendar=ALL-UNNAMED}} in build.gradle:
> : 
> ['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50','--add-exports=java.base/sun.util.calendar=ALL-UNNAMED']
> It has no impact with JDK 11.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OFBIZ-12721) Replace all occurrences of java.util.TimeZone by java.time.ZoneId

2023-12-03 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792602#comment-17792602
 ] 

Ioan Eugen Stan commented on OFBIZ-12721:
-

The issue here is with the call to `useDaylightTime` which calls an internal 
API: `sun.util.calendar.ZoneInfo` .

```

${timeZone.getDisplayName(timeZone.useDaylightTime(), 
Static["java.util.TimeZone"].LONG, locale)}

```

The call is used when getting the display name for the timezone.

We can get the display name for the timezone in other ways to avoid the call to 
useDaylightTime .

I used this code to convert to ZoneId which has an API for display name : 
[https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/ZoneId.html#getDisplayName(java.time.format.TextStyle,java.util.Locale)]
 .

```

${timeZone.toZoneId()}

```

However the API needs 
[https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/format/TextStyle.html]
 which I don't know how to use in FreeMarker :D .

Something like this ( I would setup a template helper method perhaps)

```

timeZone.toZoneId().getDisplayName(java.time.format.TextStyle.FULL, locale)

```

 

Running this code in jshell works
```

jshell> 
java.util.TimeZone.getDefault().toZoneId().getDisplayName(java.time.format.TextStyle.FULL,
 java.util.Locale.forLanguageTag("ro-RO"))
$2 ==> "Ora Europei de Est"

```

 

However, not going through the displayName is better IMO:

```

jshell> java.util.TimeZone.getDefault().toZoneId()
$1 ==> Europe/Bucharest

```

 

> Replace all occurrences of java.util.TimeZone by java.time.ZoneId
> -
>
> Key: OFBIZ-12721
> URL: https://issues.apache.org/jira/browse/OFBIZ-12721
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Upcoming Branch
> Environment: Java 17
>    Reporter: Jacques Le Roux
>Assignee: Ioan Eugen Stan
>Priority: Major
>
> Using JDK 17, we have this issue:
> {noformat}
> 2022-12-06 19:04:30,689 |sse-nio-8443-exec-10 |FreeMarkerWorker  
> |E| null
> freemarker.core._TemplateModelException: Java method 
> "sun.util.calendar.ZoneInfo.useDaylightTime()" threw an exception when 
> invoked on sun.util.calendar.ZoneInfo object 
> "sun.util.calendar.ZoneInfo[id=\"Europe/Paris\",offset=360,dstSa
> vings=360,useDaylight=true,transitions=184,lastRule=java.util.SimpleTimeZone[id=Europe/Paris,offset=360,dstSavings=360,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=360,start
> TimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=360,endTimeMode=2]]";
>  see cause exception in the Java stack trace.
> 
> FTL stack trace ("~" means nesting-related):
> - Failed at: ${timeZone.getDisplayName(timeZone.us...  [in template 
> "component://helveticus/template/includes/Footer.ftl" at line 21, column 98]
> 
> at 
> freemarker.ext.beans._MethodUtil.newInvocationTemplateModelException(_MethodUtil.java:292)
>  ~[freemarker-2.3.31.jar:2.3.31]
> [...]
> Caused by: java.lang.IllegalAccessException: class 
> freemarker.ext.beans.BeansWrapper cannot access class 
> sun.util.calendar.ZoneInfo (in module java.base) because module java.base 
> does not export sun.util.calendar to unnamed module @1c852c0f
> at 
> jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
>  ~[?:?]
> at 
> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) 
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:560) ~[?:?]
> at 
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1552) 
> ~[freemarker-2.3.31.jar:2.3.31]
> at 
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:73) 
> ~[freemarker-2.3.31.jar:2.3.31]
> ... 85 more
> {noformat}
> [The var timeZone is accessible in screen 
> context|https://cwiki.apache.org/confluence/display/OFBIZ/Variables+always+available+in+screen+context].
>  The java.util.TimeZone class uses sun.util.calendar.ZoneInfo internally. 
> It's no longer supported by Java 17. We need to replace all occurrences of 
> java.util.TimeZone by java.time.ZoneId.
> An easy temporary solution is to set 
> {{--add-exports=java.base/sun.util.calendar=ALL-UNNAMED}} in build.gradle:
> : 
> ['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50','--add-exports=java.base/sun.util.calendar=ALL-UNNAMED']
> It has no impact with JDK 11.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OFBIZ-12400) Upgrade to gradle 7.6 - support JDK 11 -> 17

2023-12-03 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792598#comment-17792598
 ] 

Ioan Eugen Stan commented on OFBIZ-12400:
-

Hi,

What is the holdup with this issue?

Java 21 is out so it's Java 17 is already old :) .

I might get some time to look at ofbiz and try to build some datasets for 
Romanian - so I can use it.

> Upgrade to gradle 7.6 - support JDK 11 -> 17
> 
>
> Key: OFBIZ-12400
> URL: https://issues.apache.org/jira/browse/OFBIZ-12400
> Project: OFBiz
>  Issue Type: Task
>    Reporter: Ioan Eugen Stan
>    Assignee: Ioan Eugen Stan
>Priority: Major
> Attachments: OFBIZ-12400-windows-binary.patch
>
>
> For working with Java 17, we need to upgrade to gradle 7.3 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: Re : Upgrade James to JDK17?

2023-11-06 Thread Eugen Stan

+1 for JDK 21

La 06.11.2023 07:42, Benoit TELLIER a scris:


+1 for JDK 21.

Thanks for the proposal.

--

Best regards,

Benoit TELLIER

General manager of Linagora VIETNAM.
Product owner for Team-Mail product.
Chairman of the Apache James project.

Mail: btell...@linagora.com
Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)


Le nov. 6, 2023 4:47 AM, de Rene Cordier Hello guys,

Well currently James is based on JDK 11. Should we think about upgrading
to at least the next LTS, JDK 17? (or why even not the current LTS,
which is the JDK 21?) I saw it being asked by a community member on a PR
a while ago (Antoine Duprat) and in our company, we would be glad for
such an upgrade as well.

Might need a bit of work but the project could definitely benefit from
it: records (finish the long verbose POJOs), pattern matching, better GC
handling, etc.

Would other people be interested about it too? Is it a problem for some
others in the community?

Rene.


-
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org







-
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org



Re: Lazy consensus: Host demo-trunk in a container.

2023-10-16 Thread Eugen Stan

+1

--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: Unsubscribe me

2023-09-01 Thread Eugen Stan

Have you also replied to the email to confirm unsubscribe?

You will receive an email with instructions.
Read and follow instructions.

La 01.08.2023 14:26, Krish K a scris:

Hi,

I also want to unsubscribe. I tried the below emails. It never worked.

  user-unsubscr...@ofbiz.apache.org
  dev-unsubscr...@ofbiz.apache.org
  commits-unsubscr...@ofbiz.apache.org
  notifications-unsubscr...@ofbiz.apache.org

Thanks,
Krish

On Tue, Aug 1, 2023 at 9:31 AM Eugen Stan  wrote:


You have to do that yourself:

https://ofbiz.apache.org/mailing-lists.html


  > Un-subscribing from our Mailing Lists

To unsubscribe from any of the following lists, please send an empty,
subjectless email to mailing list unsubscribe addresses.

  user-unsubscr...@ofbiz.apache.org
  dev-unsubscr...@ofbiz.apache.org
  commits-unsubscr...@ofbiz.apache.org
  notifications-unsubscr...@ofbiz.apache.org

Then, reply to the email from the mailing list manager program (EZMLM)
to confirm unsubscribe.




La 01.08.2023 08:11, Mayank Upadhyay a scris:

Please UnSubscribe my mail-id from all OfBiz mailer alias.

regards
Mayank Upadhyay



--
Eugen Stan

+40770 941 271  / https://www.netdava.com





--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: Demos down

2023-08-31 Thread eugen . stan

Hi,

It seems that some services have _restart: "no"_  and some are missing this 
option.
   
The docs for restart policy are here: https://docs.docker.com/compose/compose-file/compose-file-v2/#restart 

I did notice the compose version is 2.4. Any idea why not use version 3 (which is closer to swarm stack IMO)? 


https://github.com/apache/ofbiz-tools/blob/a20f9f3c750600164d08b54b80865093399a24de/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml#L9

On 31.08.2023 13:43, Jacques Le Roux  wrote:

Le 31/08/2023 à 11:25, Eugen Stan a écrit :
> La 30.08.2023 11:00, Jacques Le Roux a scris:
>> Hi,
>>
>> All demos are down (no processes running). I suspect a restart of the 
>> VM. I restart them all manually, wait 5 to 10 mins...

>>
>> Jacques
>>
>
> Hello Jacques,
>
> I presume you are talking about docker deployments.
> Can I take a look at how they are deployed ?
>
> I keep reading about them being down because of restarts or some other 
> reason.
> I believe I can help. Docker has options to restart automatically: 
> https://docs.docker.com/config/containers/start-containers-automatically/

>
> I think adding `unless-stopped` restart policy should do it.
> You can also go with `always`.
>
> docker run -d --restart unless-stopped redis
>
> Regards,

Hi Eugen,

Actually, this time at least, Docker is not concerned. When I said (no 
processes running) I meant no OFBiz process.
It happens from time to time. I guess this was due by a reported outage 
to Infra (even backup). Almost all VMs are externalised now.


For Docker, all the information is there: 
https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker


HTH

Jacques






Re: Demos down

2023-08-31 Thread Eugen Stan

La 30.08.2023 11:00, Jacques Le Roux a scris:

Hi,

All demos are down (no processes running). I suspect a restart of the 
VM. I restart them all manually, wait 5 to 10 mins...


Jacques



Hello Jacques,

I presume you are talking about docker deployments.
Can I take a look at how they are deployed ?

I keep reading about them being down because of restarts or some other 
reason.
I believe I can help. Docker has options to restart automatically: 
https://docs.docker.com/config/containers/start-containers-automatically/


I think adding `unless-stopped` restart policy should do it.
You can also go with `always`.

docker run -d --restart unless-stopped redis

Regards,
--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: Unsubscribe me

2023-08-01 Thread Eugen Stan

You have to do that yourself:

https://ofbiz.apache.org/mailing-lists.html


> Un-subscribing from our Mailing Lists

To unsubscribe from any of the following lists, please send an empty, 
subjectless email to mailing list unsubscribe addresses.


user-unsubscr...@ofbiz.apache.org
dev-unsubscr...@ofbiz.apache.org
commits-unsubscr...@ofbiz.apache.org
notifications-unsubscr...@ofbiz.apache.org

Then, reply to the email from the mailing list manager program (EZMLM) 
to confirm unsubscribe.





La 01.08.2023 08:11, Mayank Upadhyay a scris:

Please UnSubscribe my mail-id from all OfBiz mailer alias.

regards
Mayank Upadhyay



--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: Identifying cause of local package build

2023-05-25 Thread Eugen Stan

Hi,

I would also check the size of /tmp partition.
I build of iced-tea / openjdk was failing because it was running out of 
disk on /tmp.


guix-daemon builds packages in /tmp .
Some packages need a lot of disk to build.
In my case I had to increase /tmp to 7.5 GB until the build passed.
This was visible in the error log and the same issues was happening on 
substitute servers (build was failing with this issue).


Regards,
Eugen

On 25.05.2023 21:31, Simon Tournier wrote:

Hi,

On mer., 24 mai 2023 at 20:56, Skyler Ferris via  wrote:


the packages in my system configuration into a manifest and ran `guix weather`
against it, and it said that only 85% of packages have substitutes available.
I had assumed that substitutes should be available


Yeah, some process requires some improvements.  Hopefully, the CI and
tooling is improving daily. :-)


Cheers,
simon




--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



bug#50909: clojure-tools-cli outdated

2023-05-05 Thread Eugen Stan

Closing.
There is a new release, almost the latest.
https://packages.guix.gnu.org/packages/clojure-tools-cli/1.0.206/

--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



bug#50909: clojure-tools-cli outdated

2023-05-05 Thread Eugen Stan

Hi,

I believe this ticket can be closed.


https://packages.guix.gnu.org/packages/clojure-tools/1.11.1.1165/
https://packages.guix.gnu.org/packages/clojure-tools-cli/1.0.206/

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/clojure.scm#n552

Regards,
--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



bug#40067: clojure does not find namespace "clojure.set"

2023-05-05 Thread Eugen Stan

I can confirm solution from Alex ter Weele .

This issue can be closed.

--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



bug#48386: clojure tools.deps

2023-05-05 Thread Eugen Stan

I believe this can be fixed.

With latest release this seems to be working.

```
clojure -Sdescribe
{:version "1.11.1.1165"
 :config-files 
["/gnu/store/7ri29vlmg6j36civz8x7c6v8ihdvab3s-clojure-tools-1.11.1.1165/lib/clojure/deps.edn" 
"/home/ieugen/.clojure/deps.edn" "deps.edn" ]

 :config-user "/home/ieugen/.clojure/deps.edn"
 :config-project "deps.edn"
 :install-dir 
"/gnu/store/7ri29vlmg6j36civz8x7c6v8ihdvab3s-clojure-tools-1.11.1.1165/lib/clojure"

 :config-dir "/home/ieugen/.clojure"
 :cache-dir ".cpcache"
 :force false
 :repro false
 :main-aliases ""
 :repl-aliases ""}

```

--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



bug#48386: clojure tools.deps

2023-05-05 Thread Eugen Stan

(resend, forgot to add -done)

This is done, issue can be closed.

I use clojure with deps.edn projects.

https://packages.guix.gnu.org/packages/clojure/1.11.1/

clojure -Sdescribe
{:version "1.11.1.1165"
  :config-files 
["/gnu/store/7ri29vlmg6j36civz8x7c6v8ihdvab3s-clojure-tools-1.11.1.1165/lib/clojure/deps.edn" 
"/home/ieugen/.clojure/deps.edn" "deps.edn" ]

  :config-user "/home/ieugen/.clojure/deps.edn"
  :config-project "deps.edn"
  :install-dir 
"/gnu/store/7ri29vlmg6j36civz8x7c6v8ihdvab3s-clojure-tools-1.11.1.1165/lib/clojure"

  :config-dir "/home/ieugen/.clojure"
  :cache-dir ".cpcache"
  :force false
  :repro false
  :main-aliases ""
  :repl-aliases ""}


--
Eugenbegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



bug#48386: clojure tools.deps

2023-05-05 Thread Eugen Stan

This is done, issue can be closed.

I use clojure with deps.edn projects.

https://packages.guix.gnu.org/packages/clojure/1.11.1/

clojure -Sdescribe
{:version "1.11.1.1165"
 :config-files 
["/gnu/store/7ri29vlmg6j36civz8x7c6v8ihdvab3s-clojure-tools-1.11.1.1165/lib/clojure/deps.edn" 
"/home/ieugen/.clojure/deps.edn" "deps.edn" ]

 :config-user "/home/ieugen/.clojure/deps.edn"
 :config-project "deps.edn"
 :install-dir 
"/gnu/store/7ri29vlmg6j36civz8x7c6v8ihdvab3s-clojure-tools-1.11.1.1165/lib/clojure"

 :config-dir "/home/ieugen/.clojure"
 :cache-dir ".cpcache"
 :force false
 :repro false
 :main-aliases ""
 :repl-aliases ""}


--
Eugenbegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



org-mode export to html fails for unknown link types - telephone links

2023-04-22 Thread Eugen Stan

Hi,

I am building my wedding page with org mode. Yay!.
I tried to add telephone links so people can click on the link and it 
will do something useful.


I used this markup [[tel:(+40)55-555-555][(+40)55-555-555]] to produce 
something like (+40)55-555-555 .


However It failed because the tel: is not recognized link.
I believe the default behavior of failing to export when encountering an 
unknown link type is not ok.


IMO org-mode export should allow export for unknown links.
Support for tel: links might be added to org-mode by default since it is 
simple to add and quite useful, at least in HTML export .

See https://css-tricks.com/the-current-state-of-telephone-links/ .

It seems it might work in PDF exports as well 
https://community.adobe.com/t5/acrobat-reader-discussions/how-to-make-clickable-phone-numbers-in-pdfs/m-p/5822600 
.


Regardless, having the export fail is a bug IMO.


To build my website I followed a slightly updated version of 
https://systemcrafters.net/publishing-websites-with-org-mode/building-the-site/ 
.


I made it work with some customization but I do believe the default

(require 'ox-publish)
(require 'ol)

(org-link-set-parameters "tel"
 :export #'org-tel-export)

(defun org-tel-export (link description format _)
  "Export a tel link from Org files."
  (let ((path link)
(desc (or description link)))
(pcase format
  (`html (format "%s" 
path desc))

  (`latex (format "\\href{%s}{%s}" path desc))
  (`texinfo (format "@uref{%s,%s}" path desc))
  (`ascii (format "%s (%s)" desc path))
  (t path

(setq org-publish-project-alist
  `(("nunta-org-site"
 :recursive t
 .. )

(org-publish-all t)



status / plans for JDK-8275838 : java.net.http client does not work over unix domain sockets ?

2023-03-10 Thread Eugen Stan


Hello,

Can you help me / guide me find out any information regarding 
JDK-8275838 : java.net.http client does not work over unix domain sockets ?



Issue is: http client that comes with JDK does not work with UnixDomain 
sockets .
This should make it much easier to implement CLI tooling on linux - that 
makes extensive use of unix sockets.


Most prominent example is of course Docker Daemon.
Right now you can't write a docker daemon client with JDK only - even 
though most/all things are implemented.



I submitted it to OpenJDK bug tracker but I have no visibility there.
Or I don't know where to look.

Any help is appreciated :).

I saw the video about network enhancements 
https://www.youtube.com/watch?v=GPmeFv8t66E_channel=Java .



https://twitter.com/ieugen222/status/1603062524437757952

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8275838

Regards,
--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: Problems with Gnome Authenticator 2FA

2023-02-26 Thread Eugen Stan

On 23.02.2023 01:00, Wojtek Kosior via wrote:

guix show keepassxc


Hi,

keepassxc is quite nice.
I am using the Debian version, not the guix version.

Most services supporting TOTP conforming with RFC also have a plain text 
2FA setup code (besides the normal QR setup code) .


keepassxc also has a browser extension named keepassxc-browser 
https://github.com/keepassxreboot/keepassxc-browser .


It does not seem to be packaged in guix.


Good luck,
--
Eugen Stan
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



bug#51505: Request for official docker image on dockerhub

2023-02-11 Thread Eugen Stan

Hi,

I also think it would be a great idea to have guix running inside docker.

I tried to adopt guix as a package maanger in our CI/CD pipeline and I 
could not run it inside a debian Docker image.


It seems guix has issues when running inside docker.
I found prior work here: https://github.com/metacall/guix .

Thanks,
--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: Welcome to Daniel Watford as new PMC member

2023-02-03 Thread Eugen Stan

Congrats Daniel!

On 28.01.2023 12:57, Jacopo Cappellato wrote:

The OFBiz PMC has invited Daniel Watford as a new PMC member and we
are glad to announce that Daniel has accepted the nomination.

On behalf of the OFBiz PMC, welcome on board!


--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: traducerea actualizată a fișierului „debconf-glibc”.ro.po

2023-01-19 Thread Eugen Stan

Salut Remus-Gabriel,

Eu nu am nimic împotrivă să te alături echipei de traducere.

Tocmai ce am văzut că se apropie lansarea bookworm și e un prilej bun de 
îmbunătățit nivelul traducerilor în Română.


Nu prea am fost activ de ceva ani și nu mai sunt la curent cu procesul 
de traducere.

Dacă te pot ajuta cu ceva, te rog să îmi spui.

Cu drag,
Eugen

On 18.01.2023 20:00, Daniel wrote:

On Mon, 2023-01-16 at 13:23 +, remusgabriel.ch...@disroot.org wrote:

Salut, băieți veseli și năzdrăvani din echipa română a proiectului Debian!


Numele meu este, Remus-Gabriel Chelu, și sunt membru al echipei române 
din TP (https://translationproject.org/team/ro.html 
),
aș vrea, dacă sunteți de acord, să devin memru și al echipei române 
din Debian.


Am făcut actualizarea traducerii fișierului ro.po 
(debconf-glibc.ro.po) trimis de către Aurelien Jarno 
 pe lista de discuții de la

debian-l10n-romanian; și vi-l trimit spre analizare/revizare/cîrcotire ;)


Salutări Remus-Gabriel,

Am identificat următoarea problemă:

* Kernel version not supported
* Versiunea nucleului nu este acceptată
→ aici cred că se pierde înțelesul original prin folosirea lui 
„acceptată”. Dacă vrei să-l eviți pe „suportată” ai putea zice că nu 
este „compatibilă” (cu restul sistemului, bănuiesc)



O zi bună,
Daniel




Re: Question about RFC-2047 (utf-8 encoding in message headers)

2023-01-05 Thread Eugen Stan

Hi,

On 04.01.2023 09:33, Benoit TELLIER wrote:

Hello Firstie Lastie,

If doing so:

  - 1. do not come at a big performance price and
  - 2. do not compromise overall correctness

Then I do believe that such lenient behavoir contribution would be welcome.

Don't hesitate to open a pull request regarding this on github.

Regards,


Is this really necessary?
How often does this situation arise in practice?

I think this would complicate the parsing logic.
I personally am Ok with this if it's an OPT-IN strategy and is added 
with tests.


Even so, I am a bit reluctant to add more code to maintain unless there 
is a good reason.


Thanks,
Eugen


Re: Call for vote: Apache James 3.7.3

2023-01-01 Thread Eugen Stan

+1

On 30.12.2022 12:19, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 3.7.3 release of the Apache James 
server.


You can find:

  - The maven release staged in repository.apache.org as the artifact 
#1072: 
https://repository.apache.org/content/repositories/orgapachejames-1072/
  - Changelog entries and related documentation: 
https://github.com/apache/james-project/pull/1368

  - No specific upgrade instructions for this release.

This release:

  - Fixes logging for now legacy Spring packaging
  - Comprise some other bug fixes
  - Brings security related dependency updates

Voting rules:
  - This is a majority approval: this release may not be vetoed.
  - A quorum of 3 binding votes is required
  - The vote starts at Friday 30th of December 2022, 4pm UTC+7
  - The vote ends at Friday 6th of January 2022, 4pm UTC+7

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org



--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James MIME4J 0.8.9

2023-01-01 Thread Eugen Stan

+1
On 30.12.2022 09:19, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 0.8.9 release of the Apache James 
MIME4J library.


You can find:

  - The maven release staged in repository.apache.org as the artifact 
#1070: 
https://repository.apache.org/content/repositories/orgapachejames-1070/

  - The changelog for 0.8.9: https://github.com/apache/james-mime4j/pull/83
  - The blog post for this release: 
https://github.com/apache/james-project/pull/1370


This release comprise small bug fixes and enhancements.

Voting rules:
  - This is a majority approval: this release may not be vetoed.
  - A quorum of 3 binding votes is required
  - The vote starts at Friday 30th of December 2022, 3pm UTC+7
  - The vote ends at Friday 6th of January 2022, 3pm UTC+7

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org



--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James JSPF 1.0.3

2023-01-01 Thread Eugen Stan

+1
On 30.12.2022 09:23, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 1.0.3 release of the Apache James 
JSPF library.


You can find:

  - The maven release staged in repository.apache.org as the artifact 
#1071: 
https://repository.apache.org/content/repositories/orgapachejames-1071/
  - The blog post for this release: 
https://github.com/apache/james-project/pull/1369


This release fixes error handling for asynchronous JSPF executors.

Voting rules:
  - This is a majority approval: this release may not be vetoed.
  - A quorum of 3 binding votes is required
  - The vote starts at Friday 30th of December 2022, 3pm UTC+7
  - The vote ends at Friday 6th of January 2022, 3pm UTC+7

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org



--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

2022-12-21 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17650848#comment-17650848
 ] 

Ioan Eugen Stan commented on OFBIZ-12726:
-

I did not have time to work on 
https://issues.apache.org/jira/browse/OFBIZ-12721 .
I hope to get some time next week.

Would love to see OFBiz with jdk17

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Fix For: Upcoming Branch
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: Send Mail HOWTO

2022-12-14 Thread Eugen Stan

Hi,


You should be able to download the jars from Maven Central and put them 
on the classpath (next to the other jars).


https://search.maven.org/

Get the list of jars from the PR link Benoit shared.

Or one of:
* download a james snapshot build with the patch (if exists) and get 
jars from that binary


* clone the git repo, build the app and find the jars in the image.


On 14.12.2022 05:04, Benoit TELLIER wrote:

Hello Yishay Weiss,

For the logging issue, it has been reported and solved here: 
https://github.com/apache/james-project/pull/1335


Cheers,

Benoit


On 13/12/2022 19:35, Yishay Weiss wrote:

Hi,


I have just installed james-server-spring-app-3.7.2 on windows and am 
trying to send an email to my personal mail account. I am following 
the getting started guide [1] and in step 7 got the “250 2.6.0 Message 
received” message but I don’t see an email in my personal mailbox.




Any ideas what I could be doing wrong.



Also, I see no logs to debug this. I am, however, seeing the following 
message on startup.




C:\dev\james-server-spring-app-3.7.2\bin>run

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8

SLF4J: No SLF4J providers were found.



Thanks in advance,

Yishay

[1] Apache James Server 3.0 - Apache James Server 3 - Quick 
Start




-
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org




-
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org



[jira] [Commented] (OFBIZ-12721) Replace all occurrences of java.util.TimeZone by java.time.ZoneId

2022-12-08 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644691#comment-17644691
 ] 

Ioan Eugen Stan commented on OFBIZ-12721:
-

Freemarker added a special variablefor time zone since 2.3.31

> Added new special variable, time_zone (referred like .time_zone, like all 
> special variables), to retrieve the current value of the time_zone setting as 
> a string.

 

Should we use that ?

[https://freemarker.apache.org/docs/versions_2_3_31.html] .

> Replace all occurrences of java.util.TimeZone by java.time.ZoneId
> -
>
> Key: OFBIZ-12721
> URL: https://issues.apache.org/jira/browse/OFBIZ-12721
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Upcoming Branch
> Environment: Java 17
>Reporter: Jacques Le Roux
>Assignee: Ioan Eugen Stan
>Priority: Major
>
> Using JDK 17, we have this issue:
> {noformat}
> 2022-12-06 19:04:30,689 |sse-nio-8443-exec-10 |FreeMarkerWorker  
> |E| null
> freemarker.core._TemplateModelException: Java method 
> "sun.util.calendar.ZoneInfo.useDaylightTime()" threw an exception when 
> invoked on sun.util.calendar.ZoneInfo object 
> "sun.util.calendar.ZoneInfo[id=\"Europe/Paris\",offset=360,dstSa
> vings=360,useDaylight=true,transitions=184,lastRule=java.util.SimpleTimeZone[id=Europe/Paris,offset=360,dstSavings=360,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=360,start
> TimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=360,endTimeMode=2]]";
>  see cause exception in the Java stack trace.
> 
> FTL stack trace ("~" means nesting-related):
> - Failed at: ${timeZone.getDisplayName(timeZone.us...  [in template 
> "component://helveticus/template/includes/Footer.ftl" at line 21, column 98]
> 
> at 
> freemarker.ext.beans._MethodUtil.newInvocationTemplateModelException(_MethodUtil.java:292)
>  ~[freemarker-2.3.31.jar:2.3.31]
> [...]
> Caused by: java.lang.IllegalAccessException: class 
> freemarker.ext.beans.BeansWrapper cannot access class 
> sun.util.calendar.ZoneInfo (in module java.base) because module java.base 
> does not export sun.util.calendar to unnamed module @1c852c0f
> at 
> jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
>  ~[?:?]
> at 
> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) 
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:560) ~[?:?]
> at 
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1552) 
> ~[freemarker-2.3.31.jar:2.3.31]
> at 
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:73) 
> ~[freemarker-2.3.31.jar:2.3.31]
> ... 85 more
> {noformat}
> [The var timeZone is accessible in screen 
> context|https://cwiki.apache.org/confluence/display/OFBIZ/Variables+always+available+in+screen+context].
>  The java.util.TimeZone class uses sun.util.calendar.ZoneInfo internally. 
> It's no longer supported by Java 17. We need to replace all occurrences of 
> java.util.TimeZone by java.time.ZoneId.
> An easy temporary solution is to set 
> {{--add-exports=java.base/sun.util.calendar=ALL-UNNAMED}} in build.gradle:
> : 
> ['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50','--add-exports=java.base/sun.util.calendar=ALL-UNNAMED']
> It has no impact with JDK 11.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OFBIZ-12721) Replace all occurrences of java.util.TimeZone by java.time.ZoneId

2022-12-08 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644690#comment-17644690
 ] 

Ioan Eugen Stan commented on OFBIZ-12721:
-

I can take a look at this and prepare a PR.

Ok with that [~jleroux] ?

> Replace all occurrences of java.util.TimeZone by java.time.ZoneId
> -
>
> Key: OFBIZ-12721
> URL: https://issues.apache.org/jira/browse/OFBIZ-12721
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Upcoming Branch
> Environment: Java 17
>Reporter: Jacques Le Roux
>    Assignee: Ioan Eugen Stan
>Priority: Major
>
> Using JDK 17, we have this issue:
> {noformat}
> 2022-12-06 19:04:30,689 |sse-nio-8443-exec-10 |FreeMarkerWorker  
> |E| null
> freemarker.core._TemplateModelException: Java method 
> "sun.util.calendar.ZoneInfo.useDaylightTime()" threw an exception when 
> invoked on sun.util.calendar.ZoneInfo object 
> "sun.util.calendar.ZoneInfo[id=\"Europe/Paris\",offset=360,dstSa
> vings=360,useDaylight=true,transitions=184,lastRule=java.util.SimpleTimeZone[id=Europe/Paris,offset=360,dstSavings=360,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=360,start
> TimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=360,endTimeMode=2]]";
>  see cause exception in the Java stack trace.
> 
> FTL stack trace ("~" means nesting-related):
> - Failed at: ${timeZone.getDisplayName(timeZone.us...  [in template 
> "component://helveticus/template/includes/Footer.ftl" at line 21, column 98]
> 
> at 
> freemarker.ext.beans._MethodUtil.newInvocationTemplateModelException(_MethodUtil.java:292)
>  ~[freemarker-2.3.31.jar:2.3.31]
> [...]
> Caused by: java.lang.IllegalAccessException: class 
> freemarker.ext.beans.BeansWrapper cannot access class 
> sun.util.calendar.ZoneInfo (in module java.base) because module java.base 
> does not export sun.util.calendar to unnamed module @1c852c0f
> at 
> jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
>  ~[?:?]
> at 
> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) 
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:560) ~[?:?]
> at 
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1552) 
> ~[freemarker-2.3.31.jar:2.3.31]
> at 
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:73) 
> ~[freemarker-2.3.31.jar:2.3.31]
> ... 85 more
> {noformat}
> [The var timeZone is accessible in screen 
> context|https://cwiki.apache.org/confluence/display/OFBIZ/Variables+always+available+in+screen+context].
>  The java.util.TimeZone class uses sun.util.calendar.ZoneInfo internally. 
> It's no longer supported by Java 17. We need to replace all occurrences of 
> java.util.TimeZone by java.time.ZoneId.
> An easy temporary solution is to set 
> {{--add-exports=java.base/sun.util.calendar=ALL-UNNAMED}} in build.gradle:
> : 
> ['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50','--add-exports=java.base/sun.util.calendar=ALL-UNNAMED']
> It has no impact with JDK 11.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (OFBIZ-12721) Replace all occurrences of java.util.TimeZone by java.time.ZoneId

2022-12-08 Thread Ioan Eugen Stan (Jira)


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

Ioan Eugen Stan reassigned OFBIZ-12721:
---

Assignee: Ioan Eugen Stan

> Replace all occurrences of java.util.TimeZone by java.time.ZoneId
> -
>
> Key: OFBIZ-12721
> URL: https://issues.apache.org/jira/browse/OFBIZ-12721
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Upcoming Branch
> Environment: Java 17
>Reporter: Jacques Le Roux
>    Assignee: Ioan Eugen Stan
>Priority: Major
>
> Using JDK 17, we have this issue:
> {noformat}
> 2022-12-06 19:04:30,689 |sse-nio-8443-exec-10 |FreeMarkerWorker  
> |E| null
> freemarker.core._TemplateModelException: Java method 
> "sun.util.calendar.ZoneInfo.useDaylightTime()" threw an exception when 
> invoked on sun.util.calendar.ZoneInfo object 
> "sun.util.calendar.ZoneInfo[id=\"Europe/Paris\",offset=360,dstSa
> vings=360,useDaylight=true,transitions=184,lastRule=java.util.SimpleTimeZone[id=Europe/Paris,offset=360,dstSavings=360,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=360,start
> TimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=360,endTimeMode=2]]";
>  see cause exception in the Java stack trace.
> 
> FTL stack trace ("~" means nesting-related):
> - Failed at: ${timeZone.getDisplayName(timeZone.us...  [in template 
> "component://helveticus/template/includes/Footer.ftl" at line 21, column 98]
> 
> at 
> freemarker.ext.beans._MethodUtil.newInvocationTemplateModelException(_MethodUtil.java:292)
>  ~[freemarker-2.3.31.jar:2.3.31]
> [...]
> Caused by: java.lang.IllegalAccessException: class 
> freemarker.ext.beans.BeansWrapper cannot access class 
> sun.util.calendar.ZoneInfo (in module java.base) because module java.base 
> does not export sun.util.calendar to unnamed module @1c852c0f
> at 
> jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
>  ~[?:?]
> at 
> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) 
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:560) ~[?:?]
> at 
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1552) 
> ~[freemarker-2.3.31.jar:2.3.31]
> at 
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:73) 
> ~[freemarker-2.3.31.jar:2.3.31]
> ... 85 more
> {noformat}
> [The var timeZone is accessible in screen 
> context|https://cwiki.apache.org/confluence/display/OFBIZ/Variables+always+available+in+screen+context].
>  The java.util.TimeZone class uses sun.util.calendar.ZoneInfo internally. 
> It's no longer supported by Java 17. We need to replace all occurrences of 
> java.util.TimeZone by java.time.ZoneId.
> An easy temporary solution is to set 
> {{--add-exports=java.base/sun.util.calendar=ALL-UNNAMED}} in build.gradle:
> : 
> ['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50','--add-exports=java.base/sun.util.calendar=ALL-UNNAMED']
> It has no impact with JDK 11.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OFBIZ-12400) Upgrade to gradle 7.6 - support jdk 11 -> 17

2022-12-05 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643471#comment-17643471
 ] 

Ioan Eugen Stan commented on OFBIZ-12400:
-

[~jleroux] :


 > java.lang.IllegalArgumentException: Unsupported class file major version 61 

This might require a version upgrade for Jersey to a version that supports Java 
17 .
Jersey seems to repackage ASM for bytecode transformations.

The bundled version does not support Java 17 . 
An upgrade to jersey 2.37 should do the trick 
[https://github.com/eclipse-ee4j/jersey/releases/tag/2.37] .

 

> Upgrade to gradle 7.6 - support jdk 11 -> 17
> 
>
> Key: OFBIZ-12400
> URL: https://issues.apache.org/jira/browse/OFBIZ-12400
> Project: OFBiz
>  Issue Type: Sub-task
>    Reporter: Ioan Eugen Stan
>Assignee: Ioan Eugen Stan
>Priority: Major
> Attachments: OFBIZ-12400-windows.patch
>
>
> For working with Java 17, we need to upgrade to gradle 7.3 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: CI github failed : Java 11 or java 17

2022-12-02 Thread Eugen Stan

Hi Jaques,

Any luck on this?

I use sdkman to switch jdk's on linux.
https://sdkman.io/install

I noticed it has some Windows options as well, maybe they will work for 
you ?!



I try to stay away from customizations since most of the time they are 
not worth the effort.
If the build is slow it might also be an indication that we need to 
address the root cause instead of avoiding it.
Having personal build customization that avoid the issues will make the 
false believe the issue does not exist.


Also I don't imagine other people will use the same tricks so it will be 
harder to relate to their issues / experiences in running OFBiz.



If the CI is building and other people are also building the project the 
PR should be moved forward.

IMO, personal customization should not block the project moving forward.

I do hope you get to the bottom of this on your machine.
I don't use Windows myself, but I know a lot of people do and they 
should be able to run OFBiz.


Regards,
Eugen


On 30.11.2022 19:39, Jacques Le Roux wrote:
I found the cause. For performance reason, and especially in order to be 
able to quickly switch from a JDK version to another, I use a batch file 
to copy over JDKs to a RAM Disk. So java_home is always the same: this 
RAM Disk.


It has been working since Java 8, It now fails with JDK 17 (from what I 
have read I guess since one version of JDK 16).


When setting java_home to the initial location of JDK 17, instead of the 
RAM Disk, it works. I get only 2 warnings when compiling.


I'll have another look ASAP...


Le 30/11/2022 à 16:41, Jacques Le Roux a écrit :
After upgrading non-functional changes at OFBIZ-12400 (Java code, 
AsciiDoc versions, Groovy from 2.5.18 to 3.0.13), we can focus on 
Gradle and JDK version.


With last Java 17 and still Gradle 6.5,of of course the same error 
than before: "does not export com.sun.tools.javac.code to unnamed module"

With last Java 17 and Gradle 7.6, also the same error than before:

Execution failed for task ':compileJava'.
> Error while evaluating property 'javaVersion' of task ':compileJava'.
   > Cannot invoke "java.nio.file.Path.toString()" because the return 
value of "java.nio.file.Path.getFileName()" is null


I'll continue to dig starting from 
https://github.com/gradle/gradle/issues/20837 (notably last comment). 
It seems a not so obvious issue. I don't think it's related to my 
Windows version, but not sure...


Le 30/11/2022 à 13:24, Jacques Le Roux a écrit :

Hi Eugen,

As you know I'm still on Win7 and was able to manage all related 
issues so far (like the need to use npm 13.14.0 locally in build.gradle)


To simplify things I just committed the non functional Java changes 
unrelated to Gradle and JDK upgrades, not the same than your for 
CsrfUtil class.


I tried several mixed things w/o success so far. I'll continue and 
inform you here later.


Thanks

Jacques


Le 29/11/2022 à 12:12, Ioan Eugen Stan a écrit :

An update to this:

I've rebased the PR for gradle upgrade 
https://issues.apache.org/jira/browse/OFBIZ-12400

https://github.com/apache/ofbiz-framework/pull/354

I've bumped gradle to 7.6 .

I started ofbiz with temurin  jdk17 and it works (with warnings and 
some errors).

See screenshot in PR.
The CI build passes.

Can you please review @Jacques ?
I do hope this will help move things forward.

Eugen

On 2022/11/29 09:55:02 eugen.s...@netdava.com wrote:

Hi,

There are some open issues about this:

https://issues.apache.org/jira/browse/OFBIZ-10757  - jdk 11
https://issues.apache.org/jira/browse/OFBIZ-12399  - jdk 17
https://issues.apache.org/jira/browse/OFBIZ-12400  - gradle 7.x for 
jdk17


There is also a PR for gradle upgrade 
https://github.com/apache/ofbiz-framework/pull/354


Gradle upgrade is a pre-requisite for JDK upgrade.

I remember some issues with project not generating some docs as 
part of build on some system.

I think this should not be considered an upgrade blocker IMO.
Since we are using third party libraries that might not support all 
platforms.



I really hope this gets merged.

Regads,
Eugen



--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



[jira] [Commented] (OFBIZ-12399) Upgrade OFBiz to use Java JDK Version 17

2022-11-30 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641550#comment-17641550
 ] 

Ioan Eugen Stan commented on OFBIZ-12399:
-

Rebased on that commit.

> Upgrade OFBiz to use Java JDK Version 17
> 
>
> Key: OFBIZ-12399
> URL: https://issues.apache.org/jira/browse/OFBIZ-12399
> Project: OFBiz
>  Issue Type: Improvement
>        Reporter: Ioan Eugen Stan
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> We should have ofbiz owrking with JDK17. 
> This issue should track progress on making that happen.
> One think we need to do is upgrade gradle to 7.3 .



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: CI github failed : Java 11 or java 17

2022-11-29 Thread Ioan Eugen Stan
An update to this: 

I've rebased the PR for gradle upgrade 
https://issues.apache.org/jira/browse/OFBIZ-12400 
https://github.com/apache/ofbiz-framework/pull/354 

I've bumped gradle to 7.6 .

I started ofbiz with temurin  jdk17 and it works (with warnings and some 
errors). 
See screenshot in PR. 
The CI build passes. 

Can you please review @Jacques ? 
I do hope this will help move things forward. 

Eugen

On 2022/11/29 09:55:02 eugen.s...@netdava.com wrote:
> Hi,
> 
> There are some open issues about this:
> 
> https://issues.apache.org/jira/browse/OFBIZ-10757  - jdk 11
> https://issues.apache.org/jira/browse/OFBIZ-12399  - jdk 17
> https://issues.apache.org/jira/browse/OFBIZ-12400  - gradle 7.x for jdk17
> 
> There is also a PR for gradle upgrade 
> https://github.com/apache/ofbiz-framework/pull/354  
> 
> Gradle upgrade is a pre-requisite for JDK upgrade.
> 
> I remember some issues with project not generating some docs as part of build 
> on some system. 
> I think this should not be considered an upgrade blocker IMO. 
> Since we are using third party libraries that might not support all 
> platforms. 
> 
> 
> I really hope this gets merged. 
> 
> Regads,
> Eugen
> 


[jira] [Commented] (OFBIZ-10757) Upgrade OFBiz to use Java JDK Version 11

2022-11-29 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17640622#comment-17640622
 ] 

Ioan Eugen Stan commented on OFBIZ-10757:
-

I managed to start ofbiz locally (not without some errors and warnings) with 
JDK17 using the PR in https://issues.apache.org/jira/browse/OFBIZ-12400 .

As discussed on ML I think we can migrate to JDK17 and skip JDK 11 which was 
EOL'ed .

> Upgrade OFBiz to use Java JDK Version 11
> 
>
> Key: OFBIZ-10757
> URL: https://issues.apache.org/jira/browse/OFBIZ-10757
> Project: OFBiz
>  Issue Type: Improvement
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Taher Alkhateeb
>Priority: Minor
> Attachments: OFBIZ-10757-framework.patch, 
> OFBIZ-10757-framework.patch, OFBIZ-10757-framework.patch, 
> OFBIZ-10757-framework.patch, OFBIZ-10757-plugins.patch, 
> OFBIZ-10757-plugins.patch, OFBIZ-10757_Fix-javadoc-build-for-OpenJDK-11.patch
>
>
> To implement as per [Discussion 
> Thread|https://lists.apache.org/thread.html/71b8c1048f1dd4c5b3f104233c9af7b2cbc690863fe35b08ef91fcf5@%3Cdev.ofbiz.apache.org%3E]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OFBIZ-12400) Upgrade to gradle 7.6 - support jdk 8 -> 17

2022-11-29 Thread Ioan Eugen Stan (Jira)


[ 
https://issues.apache.org/jira/browse/OFBIZ-12400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17640620#comment-17640620
 ] 

Ioan Eugen Stan commented on OFBIZ-12400:
-

I've rebased my PR on latest trunk and bumped gradle to 7.6. 
I can start ofbiz locally with java 17 (see image in PR) 
[https://github.com/apache/ofbiz-framework/pull/354#issuecomment-1330424495] .

The build passed.

 

> Upgrade to gradle 7.6 - support jdk 8 -> 17
> ---
>
> Key: OFBIZ-12400
> URL: https://issues.apache.org/jira/browse/OFBIZ-12400
> Project: OFBiz
>  Issue Type: Sub-task
>    Reporter: Ioan Eugen Stan
>    Assignee: Ioan Eugen Stan
>Priority: Major
>
> For working with Java 17, we need to upgrade to gradle 7.3 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (OFBIZ-12400) Upgrade to gradle 7.6 - support jdk 8 -> 17

2022-11-29 Thread Ioan Eugen Stan (Jira)


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

Ioan Eugen Stan updated OFBIZ-12400:

Summary: Upgrade to gradle 7.6 - support jdk 8 -> 17  (was: Upgrade to 
gradle 7.3 - support jdk 8 -> 17)

> Upgrade to gradle 7.6 - support jdk 8 -> 17
> ---
>
> Key: OFBIZ-12400
> URL: https://issues.apache.org/jira/browse/OFBIZ-12400
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Ioan Eugen Stan
>    Assignee: Ioan Eugen Stan
>Priority: Major
>
> For working with Java 17, we need to upgrade to gradle 7.3 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: CI github failed : Java 11 or java 17

2022-11-29 Thread eugen . stan

Hi,

There are some open issues about this:

https://issues.apache.org/jira/browse/OFBIZ-10757  - jdk 11
https://issues.apache.org/jira/browse/OFBIZ-12399  - jdk 17
https://issues.apache.org/jira/browse/OFBIZ-12400  - gradle 7.x for jdk17

There is also a PR for gradle upgrade https://github.com/apache/ofbiz-framework/pull/354  


Gradle upgrade is a pre-requisite for JDK upgrade.

I remember some issues with project not generating some docs as part of build on some system. 
I think this should not be considered an upgrade blocker IMO. 
Since we are using third party libraries that might not support all platforms. 



I really hope this gets merged. 


Regads,
Eugen


Re: fuseki backup process / policy - similar capabilities to autopostgresqlbackup ?

2022-10-19 Thread Ioan Eugen Stan
Hello, 

So I took some time to implement a program to do backups following a policy. 
To implement such a program I think it would be helpful to add the database 
being backed up to the tasks JSON output.

Right now we get.

[ { 
"task" : "Backup" ,
"taskId" : "1" ,
"started" : "2022-10-11T16:25:47.083+00:00"
  }
]

>From this I don't know which DB is being backed up.
It is helpful if you have more tasks in progress to tell which one is done and 
which is in progress.

Regarding backup program, I was checking out how autopostgresql-backup works to 
implement something similar. 
autopostgresql-backup works synchronously. This makes the logic is simple for 
autopostgresql-backup.

On fuseki side, I need to know when the task is done. 
Since the tasks API is async my plan is to pool tasks api and check for db name.
I can also use DB name + date from json reply to form the file name instead of 
parsing it.

Let me know if you have other ideas on how this should be done. 


Re: Fuseki container is OOMKilled

2022-09-29 Thread Eugen Stan

For debugging, you need to do the following:

* pass JVM options to enable debugging
* expose docker port for JVM debug you chose

https://stackoverflow.com/questions/138511/what-are-java-command-line-options-to-set-to-allow-jvm-to-be-remotely-debugged

You should be able to do all this without changing the image: docker env 
variables and docker port option.


Once container is started and port is listening, open (confirm with 
docker ps) connect to it to debug.


Good luck,

On 29.09.2022 11:22, Martynas Jusevičius wrote:

On Thu, Sep 29, 2022 at 9:41 AM Lorenz Buehmann
 wrote:


You're working on an in-memory dataset?


No the datasets are TDB2-backed


Does it also happen with Jena 4.6.1?


Don't know :)

I wanted to run a profiler and tried connecting from VisualVM on
Windows to the Fuseki container but neither jstatd nor JMX connections
worked...
Now I want to run VisualVM inside the container itself but this
requires changing the Docker image in a way that I haven't figured out
yet.



On 28.09.22 20:23, Martynas Jusevičius wrote:

Hi,

We have a dockerized Fuseki 4.5.0 instance that is gradually running
out of memory over the course of a few hours.

3 datasets, none larger than 10 triples. The load is negligible
(maybe a few bursts x 10 simple queries per minute), no updates.

Dockerfile: https://github.com/AtomGraph/fuseki-docker/blob/master/Dockerfile
Memory settings:
mem_limit: 10240m
JAVA_OPTIONS=-Xmx7700m -Xms7700m

Any advice?

Martynas


--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: Fuseki container is OOMKilled

2022-09-29 Thread eugen . stan
We experienced fuseki crashes as well. 


For us we had LARGE data sets and had some reasoning rules.
Also lots of updates increase disk size as well. 


I hope it helps,
Eugen

On 29.09.2022 10:40, Lorenz Buehmann  wrote:
You're working on an in-memory dataset? Does it also happen with Jena 
4.6.1?


On 28.09.22 20:23, Martynas Jusevičius wrote:
> Hi,
>
> We have a dockerized Fuseki 4.5.0 instance that is gradually running
> out of memory over the course of a few hours.
>
> 3 datasets, none larger than 10 triples. The load is negligible
> (maybe a few bursts x 10 simple queries per minute), no updates.
>
> Dockerfile: 
> https://github.com/AtomGraph/fuseki-docker/blob/master/Dockerfile

> Memory settings:
> mem_limit: 10240m
> JAVA_OPTIONS=-Xmx7700m -Xms7700m
>
> Any advice?
>
> Martynas





Re: fuseki backup process / policy - similar capabilities to autopostgresqlbackup ?

2022-08-31 Thread Eugen Stan

Done https://github.com/apache/jena/issues/1500 .

Thanks.

Will see if I have time to contribute a solution.
But I am busy in the next week or so.
If anyone is interested in providing a fix, please let me know.

Regards,
Eugen

On 30.08.2022 17:13, Andy Seaborne wrote:



On 30/08/2022 12:17, Eugen Stan wrote:

Hi Andy,

Thanks for the feedback.
I think we are in agreement.
Nice touch with cleanup on server startup :).

Should I raise a JIRA issue for the server side bits?


Yes please, or a github issue (we use both)

https://github.com/apache/jena/issues

(The codebase already has some "safe write" code in IOX.safeWrite)

     Andy



I will setup the backup script as separate git repo.

Thanks,
Eugen

On 30.08.2022 13:02, Andy Seaborne wrote:

Hi Eugen,

Yes, the backup should be written then atomically moved (i.e. same 
directory). Cleanup would then be "delete" by pattern in the server 
startup script.


As to putting a process script around the functionality, it is an 
external script which needs access to the server file area (to know 
the state of backups). The file system state is the definitive state 
- not the jobs (that's a UI feature).


This would make a good independent project or contribution. Or 
published example as a starting point because the requirements will 
be depend on the deployment environment and it seems unlikely to me 
that there is a one size fits all.


Fuseki should make sure it has the right behaviours (like atomic write).

 Andy

autopostgresqlbackup itself is GPL.

On 29/08/2022 11:20, Eugen Stan wrote:

Hello,

We are using fuseki and we would like to implement a backup policy 
similar in capabilities to what [autopostgresqlbackup] has to offer.


Are there any existing solutions out there that can do all / part of 
these?


We would like to take:
* daily backups for a week
* weekly backups - 1 per week, last 4 weeks
* monthly backups - 1/ month, last 6 months


I believe this could be scripted with via the HTTP API + directory 
access.


The backup api in [fuseki-server-protocol] can trigger a backup and 
can also list existing backups.


Unfortunately in the current implementation, backup is not consistent.
In case of a server crash during backup, the file will remain there 
incomplete.
Also, since tasks are stored in memory and cleaned (periodically / 
on restart) there is no way to know for sure if the backup was 
successful or not.


In have encountered the above quite often in some workloads.

The in-consistency could be solved by writing the backup to 
temporary file name and on completion, renaming it to final file name.

Rename is usually atomic operation on POSIX file systems.

/backup-list API can list all backups or split backups in complete / 
incomplete. IMO for now, it can list all of them.


The in progress backup could be stored alongside the other backups 
with a file marker like: dataset_date.nq.gz.INCOMPLETE .

Once it's done it can be renamed to dataset_date.nq.gz .

Cleanup might be handled externally. In case of a crash, the file 
will remain INCOMPLETE until it is removed by system by checking a 
specific amount of time has passed since backup was started (1-2 days).


WDYT?


[autopostgresqlbackup] https://github.com/k0lter/autopostgresqlbackup
[fuseki-server-protocol] 
https://jena.apache.org/documentation/fuseki2/fuseki-server-protocol.html



Thanks,

z


--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: fuseki backup process / policy - similar capabilities to autopostgresqlbackup ?

2022-08-30 Thread Eugen Stan

Hi Andy,

Thanks for the feedback.
I think we are in agreement.
Nice touch with cleanup on server startup :).

Should I raise a JIRA issue for the server side bits?

I will setup the backup script as separate git repo.

Thanks,
Eugen

On 30.08.2022 13:02, Andy Seaborne wrote:

Hi Eugen,

Yes, the backup should be written then atomically moved (i.e. same 
directory). Cleanup would then be "delete" by pattern in the server 
startup script.


As to putting a process script around the functionality, it is an 
external script which needs access to the server file area (to know the 
state of backups). The file system state is the definitive state - not 
the jobs (that's a UI feature).


This would make a good independent project or contribution. Or published 
example as a starting point because the requirements will be depend on 
the deployment environment and it seems unlikely to me that there is a 
one size fits all.


Fuseki should make sure it has the right behaviours (like atomic write).

     Andy

autopostgresqlbackup itself is GPL.

On 29/08/2022 11:20, Eugen Stan wrote:

Hello,

We are using fuseki and we would like to implement a backup policy 
similar in capabilities to what [autopostgresqlbackup] has to offer.


Are there any existing solutions out there that can do all / part of 
these?


We would like to take:
* daily backups for a week
* weekly backups - 1 per week, last 4 weeks
* monthly backups - 1/ month, last 6 months


I believe this could be scripted with via the HTTP API + directory 
access.


The backup api in [fuseki-server-protocol] can trigger a backup and 
can also list existing backups.


Unfortunately in the current implementation, backup is not consistent.
In case of a server crash during backup, the file will remain there 
incomplete.
Also, since tasks are stored in memory and cleaned (periodically / on 
restart) there is no way to know for sure if the backup was successful 
or not.


In have encountered the above quite often in some workloads.

The in-consistency could be solved by writing the backup to temporary 
file name and on completion, renaming it to final file name.

Rename is usually atomic operation on POSIX file systems.

/backup-list API can list all backups or split backups in complete / 
incomplete. IMO for now, it can list all of them.


The in progress backup could be stored alongside the other backups 
with a file marker like: dataset_date.nq.gz.INCOMPLETE .

Once it's done it can be renamed to dataset_date.nq.gz .

Cleanup might be handled externally. In case of a crash, the file will 
remain INCOMPLETE until it is removed by system by checking a specific 
amount of time has passed since backup was started (1-2 days).


WDYT?


[autopostgresqlbackup] https://github.com/k0lter/autopostgresqlbackup
[fuseki-server-protocol] 
https://jena.apache.org/documentation/fuseki2/fuseki-server-protocol.html



Thanks,

z
--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



fuseki backup process / policy - similar capabilities to autopostgresqlbackup ?

2022-08-29 Thread Eugen Stan

Hello,

We are using fuseki and we would like to implement a backup policy 
similar in capabilities to what [autopostgresqlbackup] has to offer.


Are there any existing solutions out there that can do all / part of these?

We would like to take:
* daily backups for a week
* weekly backups - 1 per week, last 4 weeks
* monthly backups - 1/ month, last 6 months


I believe this could be scripted with via the HTTP API + directory access.

The backup api in [fuseki-server-protocol] can trigger a backup and can 
also list existing backups.


Unfortunately in the current implementation, backup is not consistent.
In case of a server crash during backup, the file will remain there 
incomplete.
Also, since tasks are stored in memory and cleaned (periodically / on 
restart) there is no way to know for sure if the backup was successful 
or not.


In have encountered the above quite often in some workloads.

The in-consistency could be solved by writing the backup to temporary 
file name and on completion, renaming it to final file name.

Rename is usually atomic operation on POSIX file systems.

/backup-list API can list all backups or split backups in complete / 
incomplete. IMO for now, it can list all of them.


The in progress backup could be stored alongside the other backups with 
a file marker like: dataset_date.nq.gz.INCOMPLETE .

Once it's done it can be renamed to dataset_date.nq.gz .

Cleanup might be handled externally. In case of a crash, the file will 
remain INCOMPLETE until it is removed by system by checking a specific 
amount of time has passed since backup was started (1-2 days).


WDYT?


[autopostgresqlbackup] https://github.com/k0lter/autopostgresqlbackup
[fuseki-server-protocol] 
https://jena.apache.org/documentation/fuseki2/fuseki-server-protocol.html



Thanks,
--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: Ofbiz using itext-2.1.7

2022-08-12 Thread Eugen Stan

Hi Rishi,

If you trust random people off the internet, here is an explanation 
https://opensource.stackexchange.com/a/7231 .


If you don't, contact a lawyer with software licensing practice.

Hope it helps.

On 12.08.2022 09:15, Rishi Agr wrote:

Hi, There is a usage of itext-2.1.7 (com.lowagie) library in ofbiz. And I
am not sure if this comes under open source or some other license. Is it
fine to use apache in commercial applications as it includes itext library?
Thank you.



--
Eugen Stan

+40770 941 271  / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Using htmx to make OFbiz more dynamic - FYI

2022-08-08 Thread Eugen Stan

Hello,


I recently came across htmx (and _hyperscript).
I am currently evaluating it - no real experience yet.
What I tested so far has impressed me.

I think htmx can bring a lot of value to a project like OFBiz .

It can provide a way to have a dynamic pages - that load fast and a good 
upgrade path:


* You still get to have pages rendered on server
* You add attributes to markup and these call in a service
* The service will reply with the bits of HTML that will replace an 
element in the page.



What I like about it is:
* Very small footprint (10k gzipped JS)
* Works with "normal" http
* Simple to reason about
* Content is generated on the back-end - so under all security rules
* Easy (IMO) to adopt to OFBiz UI - progressive enhancement

I do have some mixed feelings about _hyperscript - but that is optional.
I will try it though in a personal project and see how it goes.

Please try it out:  https://htmx.org/ .

Their tag line is:
(Haiku)
javascript fatigue:
longing for a hypertext
already in hand


--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



need help disabling some devices / device scanning - lspci shuts down my lenovo E480

2022-07-05 Thread Eugen Stan

Hello,

I'm writing here because I am a bit desperate and figured it's worth a 
shot.


I have a Lenovo E480 with Radeon RX550 
https://www.lenovo.com/in/en/laptops/thinkpad/thinkpad-e-series/ThinkPad-E480/p/22TP2TEE480 
.


The computer shuts down when I do lspci, hwinfo, or start lutris (for 
games) and sometimes when I log-in after resume.


Otherwise the computer works great and there are no issues.

If I disable acpi during kernel boot --acpi=off lspci works ok.
Any idea what is happening?
Any idea how I can disable ACPI scanning for the GPU / new video devices ?!

Any ideas on what to try to fix this?


More information:

* Running Debian 11.3 Linux 5.10.0-15-amd64 #1 SMP Debian 5.10.120-1 
(2022-06-09) x86_64 GNU/Linux

* I took the laptop to two repair shops. thermal paste was replaced.
* I upgraded Bios to latest version.

One thing that I did notice is that I can't see the dedicated Radeon GPU 
in lspci.


Ouptut from lspci, lsmod and dmesg:

lspci -nnk -> https://paste.debian.net/plain/1246205

lspci -> https://paste.debian.net/plain/1246206

lspci -vvv https://paste.debian.net/plain/1246207

lsmod -> https://paste.debian.net/plain/1246207

dmesg -T https://paste.debian.net/1246209/


Thanks,
Eugen



I would like to join the clojure maintainers team

2022-05-24 Thread Eugen Stan



Hi,

I'm a long time Debian user and contributor (translations, some bugs, 
attempts at packaging).


I've used Java / JVM for several years and started using Clojure a 
couple of years ago.


I would like to join the clojure maintainers and help out when I can.

Right now I think I can get familiar with bug triaging and perhaps fixing.

I would appreciate someone with more Debian project involvement 
mentoring me.


Thanks,
Eugen

___
Pkg-clojure-maintainers mailing list
Pkg-clojure-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-clojure-maintainers


Bug#1010365: probably related - seeed studio dual gigabit CM4 does not reboot + does not boot once upgraded.

2022-05-15 Thread Eugen Stan

Hello,

I have a seeed studio CM4 dual gigabit board that I have installed Raspi 
Debian on it 
https://raspi.debian.net/tested/20220121_raspi_4_bookworm.img.xz .



System works fine but does not reboot.
If I reboot it hangs instead and I push the small reset button to 
restart it (or unplug + plug).


I configured wireless AP and ran apt update + apt upgrade on the system.
It upgraded kernel and raspberry-firmware and then it did not boot again.

I had to start in boot mode again and reflash the debian image on the 
system to make it work.


Working system runs linux 5.15.0-2-arm64 - 5.15.5.-2 .
Raspi firmware is 1.20210805+ds-1


For some background, I flashed OpenWrt 22.xx-rc1 before Debian and 
reboot worked. 
https://github.com/sergey-brutsky/openwrt-seeed-carrier-board/issues/1 .


--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Bug#1010365: probably related - seeed studio dual gigabit CM4 does not reboot + does not boot once upgraded.

2022-05-15 Thread Eugen Stan

Hello,

I have a seeed studio CM4 dual gigabit board that I have installed Raspi 
Debian on it 
https://raspi.debian.net/tested/20220121_raspi_4_bookworm.img.xz .



System works fine but does not reboot.
If I reboot it hangs instead and I push the small reset button to 
restart it (or unplug + plug).


I configured wireless AP and ran apt update + apt upgrade on the system.
It upgraded kernel and raspberry-firmware and then it did not boot again.

I had to start in boot mode again and reflash the debian image on the 
system to make it work.


Working system runs linux 5.15.0-2-arm64 - 5.15.5.-2 .
Raspi firmware is 1.20210805+ds-1


For some background, I flashed OpenWrt 22.xx-rc1 before Debian and 
reboot worked. 
https://github.com/sergey-brutsky/openwrt-seeed-carrier-board/issues/1 .


--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: implement an LDAP view for authentication - expose any identity data source as LDAP

2022-05-02 Thread Eugen Stan
ceptor)
_ (.setInterceptors ds interceptors)
ldap-server (doto (LdapServer.)
  (.addTransports (->transport :port 10389))
  (.setDirectoryService ds))

_ (do
    (def ldaps ldap-server)
(-> ds .getChangeLog (.setEnabled true))
_ (.init ds-factory "ldap-auth-provider"))]
(log/info "Starting server")
(.start ldap-server)

(log/info "Server started"))

  (.stop ldaps))



--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard


-
To unsubscribe, e-mail: users-unsubscr...@directory.apache.org
For additional commands, e-mail: users-h...@directory.apache.org

Re: implement an LDAP view for authentication - expose any identity data source as LDAP

2022-05-02 Thread Eugen Stan

Hello Emmanuel,

Thanks for the reply.

I started working on this based on the sample here 
https://github.com/apache/directory-samples/blob/def6f8ac997a1da81360e5b1fe716a27a97d1a5b/embedded-sample-trunk/src/main/java/org/apache/directory/seserver/EmbeddedADSVerTrunk.java#L154 
.


But I did not get very far since it's based on version 1.x .
In the mean time the API's have changed.

Any idea where I can find a simple working example to get me started 
with a server that I can implement the delegator in?


(This message was in draft for such a long time :( ) .

Thanks,
Eugen

On 06.01.2022 10:39, Emmanuel Lécharny wrote:

Hi!

This is possible, all it needs is an implementation of a new Authenticator.

We already have a DelegatingAuthenticator class that delehgates 
authenticatio to a remote LDAP server, so for your need, you have to 
implement a similar class delagating authentication to a Oauth2 or 
OpenID provider.


Here are the references to the interface and class :

https://nightlies.apache.org/directory/apacheds/2.0.0.AM26/apidocs/org/apache/directory/shared/kerberos/messages/Authenticator.html 



and the DelegatingAuthenticator:


https://nightlies.apache.org/directory/apacheds/2.0.0.AM26/apidocs/org/apache/directory/server/core/authn/DelegatingAuthenticator.html 



(code : 
https://nightlies.apache.org/directory/apacheds/2.0.0.AM26/apidocs/src-html/org/apache/directory/server/core/authn/DelegatingAuthenticator.html#line.45) 



In order to have it to work, you will need to add some configurtaion 
element, like what has been done for the DelegatingAuthenticator:


dn: 
ads-authenticatorid=delegatingauthenticator,ou=authenticators,ads-interceptorId=authenticationInterceptor,ou=interceptors,ads-directoryServiceId=default,ou=config 


ads-authenticatorid: delegatingauthenticator
objectclass: top
objectclass: ads-base
objectClass: ads-authenticator
objectClass: ads-authenticatorImpl
ads-authenticatorClass: 
org.apache.directory.server.core.authn.DelegatingAuthenticator

ads-baseDn:
ads-enabled: FALSE

(this is in the config.ldif file).

Let me know if you need more direction...

On 02/01/2022 23:30, Eugen Stan wrote:

Hi,

I would like to know if this is doable with Apache DS or a ldap library.

I would like to build an application that can offer basic set of 
functionality to perform LDAP authentication (and maybe password 
reset) and delegate this to an existing auth service (Keycloak, a user 
and password database, a simple file, Google Auth, whatever ).


The use case is that some applications work with LDAP auth for unified 
authentication and don't provide Oauth2 / OpenID connect support.


I would like to deploy keycloak or another IDM server to manage users 
and offer those applications an ldaps endpoint for which they 
authenticate.




To my knowledge I would need some sort of **SIMPLE** embedded ldap 
server that I can map the auth structure to my existing data stored in 
a DB or a rest service.


User will configure legacy app to sue my ldap Auth server.
The auth server will receive auth requests and read data from my real 
auth service (Keycloak, plain user + pass file, etc ).



This is kind of the reverse of what people are doing (putting OpenID 
Connect on top of LDAP servers).


The use case is pretty small and I think I could get away with a 
simple ldap protocol parsing library.


I would like to avoid any unnecessary complexity: ldap schemas, etc.


Would this be possible?
What should I try ?


Thanks,


-
To unsubscribe, e-mail: users-unsubscr...@directory.apache.org
For additional commands, e-mail: users-h...@directory.apache.org






--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard


-
To unsubscribe, e-mail: users-unsubscr...@directory.apache.org
For additional commands, e-mail: users-h...@directory.apache.org

Re: Traveling to Prizren by car

2022-04-20 Thread Eugen Stan

Hi,

Thanks for asking this.
I am also considering coming by car and curios about card/cash.

Regards,
Eugen

On 20.04.2022 23:17, Damyan Ivanov wrote:

(I have sent a similar question on IRC, but the machine where the IRC
client was running experienced a series of power failures so I may
have missed a reply. Sorry if this comes to you twice)

I consider coming to Prizren by car, via Northern Macedonia.

The problem is, I have no idea what to expect, so I have questions :)

I know I have to buy a Liability Insurance at the border. Should
I expect to find one at the Bardovci/Elez Han border? What signs
should I look for?

Is there a suitable parking place around the venue, preferably
a guarded and/or locked one?

For the route from Skopje to Prizren, OSM suggests a route via Strpce
(90km distance). Would you recommend that too or should I use the
highways via Pristine (160km)?

One question that is not related to transportation, but I can't find
the answer on the web site. Is it generally OK to pay via credit/debit
card? Are cards broadly accepted or should I prepare enough cash?

Any other general hints?

Thanks!
 -- dam




--
Eugen Stan

+40770 941 271  / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard



Re: Unable to Parse MBox File

2022-02-15 Thread Eugen Stan

Hello Andrew,

I'm the original author of this code.
It was done so long ago :), happy to see it's used.

The mbox file you sent contains only one message.
The code I wrote might not take this into account.
(Contributions are welcomed).

Also you should be able to specify your own REGEX if the one provided is 
not enough.


Please share your results via mailing list.
It will help others.

Regards,
Eugen

On 14.02.2022 18:52, Andrew Lalis wrote:

Hi all,

I'm trying to use Mime4J's MboxIterator to parse an Mbox file (which 
actually was obtained from the Apache mailing lists archive originally). 
The problem is that after downloading the Mbox file, I attempt to parse 
it like so:


MboxIterator mboxIterator 
=MboxIterator.fromFile(file).charset(StandardCharsets.ISO_8859_1).build(); MimeStreamParser 
parser =new MimeStreamParser(); List emails =new ArrayList<>(); for 
(CharBufferWrapper w :mboxIterator) {
var handler =new EmailContentHandler(); parser.setContentHandler(handler); 
try {
   parser.parse(w.asInputStream(StandardCharsets.UTF_8)); 
emails.add(handler.getEmail()); }catch (MimeException |IOException e) {
   e.printStackTrace(); }
}

When running this snippet, my program crashes with an 
IllegalArgumentException:


|Exception in thread "main" java.lang.IllegalArgumentException: File 
A:\Programming\GitHub-andrewlalis\ApacheEmailDownloader\emails\hadoop.apache.org_common-dev_2006-01.mbox 
does not contain From_ lines that match the pattern '^From 
\S+@\S.*\d{4}$'! Maybe not be a valid Mbox or wrong matcher.
     at 
org.apache.james.mime4j.mboxiterator.MboxIterator.initMboxIterator(MboxIterator.java:107)
     at 
org.apache.james.mime4j.mboxiterator.MboxIterator.(MboxIterator.java:87)
     at 
org.apache.james.mime4j.mboxiterator.MboxIterator.(MboxIterator.java:53)
     at 
org.apache.james.mime4j.mboxiterator.MboxIterator$Builder.build(MboxIterator.java:260)

     at nl.andrewl.mbox_parser.MBoxParser.parse(MBoxParser.java:26)
     at nl.andrewl.mbox_parser.MBoxParser.main(MBoxParser.java:43)|

I have attached the file in question, for reference.

Is there something else I need to do in order to be able to read MBox files?





  1   2   3   4   5   6   7   8   9   10   >