Mateusz Kwiatkowski

About
  • First commit 21 November 2016
  • Latest commit 31 May 2019
Last Week All Time
Commits: 0 4,626

Reviews

2 active reviews

Counts may include data that you cannot access.

Line History

Line history chart not available

Line history chart not available

 

Commit Activity

Commits By Day In Week
52 week commits volume
Commits By Day In Week
Commits by day
Commits By Day In Week
Commits by hour
Commits By Hour In Day
Commit calendar
 

Committer Mappings

Mateusz Kwiatkowski is mapped to 50 committers over 31 repositories
Username mkwiatkowski is mapped to:
Tuesday 11 Jun
10:36 am

Mateusz Kwiatkowski

Tuesday 16 Apr
8:24 am

Mateusz Kwiatkowski

Monday 15 Apr
8:43 am

Mateusz Kwiatkowski

Friday 12 Apr
1:20 pm

Mateusz Kwiatkowski

1:20 pm

Mateusz Kwiatkowski

Thursday 11 Apr
5:11 pm

Mateusz Kwiatkowski

OLMIS-6193: fixed translating stockout notifications
OLMIS-6193: fixed translating stockout notifications
Wednesday 10 Apr
5:38 pm

Mateusz Kwiatkowski

As I mentioned on Slack while doing using a @Async new thread is losing context by default. We are getting locale info from LocaleContextHolder while translating messages so this was causing missin...

As I mentioned on Slack while doing using a @Async new thread is losing context by default. We are getting locale info from LocaleContextHolder while translating messages so this was causing missing translations for email notifications. Here is a GitHub issue regarding this problem: https://github.com/spring-projects/spring-boot/issues/14079
I think we are safe to use "dispatcherServlet.setThreadContextInheritable(true);" but Javadoc says:
/**

  • Set whether to expose the LocaleContext and RequestAttributes as inheritable
  • for child threads (using an
    Unknown macro: {@link java.lang.InheritableThreadLocal}

    ).

  • <p>Default is "false", to avoid side effects on spawned background threads.
  • Switch this to "true" to enable inheritance for custom child threads which
  • are spawned during request processing and only used for this request
  • (that is, ending after their initial task, without reuse of the thread).
  • <p><b>WARNING:</b> Do not use inheritance for child threads if you are
  • accessing a thread pool which is configured to potentially add new threads
  • on demand (e.g. a JDK
    Unknown macro: {@link java.util.concurrent.ThreadPoolExecutor}

    ),

  • since this will expose the inherited context to such a pooled thread.
    */
    Alternatively, we could retrieve locale before starting a new thread and passing it there, but it would require more work.
    I would be nice if we could agree on a solution quickly as it is blocking release and I still need to include it in patch release for Angola. Also, I would need to include those changes in other services that are sending notifications asynchronously.
5:30 pm

Mateusz Kwiatkowski

OLMIS-6193: added inheriting context to dispatcher servlet
OLMIS-6193: added inheriting context to dispatcher servlet
Friday 05 Apr
9:40 am

Mateusz Kwiatkowski

Thursday 04 Apr
8:09 am

Mateusz Kwiatkowski

From what I know Łukasz Lewczyński introduced v5 with new gradle version because it was required by a newer version of hapifhir so yes, it is used. https://github.com/OpenLMIS/openlmis-hapifhir/pul...

From what I know Łukasz Lewczyński introduced v5 with new gradle version because it was required by a newer version of hapifhir so yes, it is used.
https://github.com/OpenLMIS/openlmis-hapifhir/pull/2/files

Wednesday 03 Apr
3:36 pm

Mateusz Kwiatkowski

OLMIS-6128: changed docker-dev version to 5.2
OLMIS-6128: changed docker-dev version to 5.2
12:30 pm

Mateusz Kwiatkowski

9:31 am

Mateusz Kwiatkowski

No. those flags are skipping asking the user about token which is the default and recommended way of authorization, look at the bottom here: https://docs.transifex.com/client/init We are handling p...

No. those flags are skipping asking the user about token which is the default and recommended way of authorization, look at the bottom here: https://docs.transifex.com/client/init
We are handling pushing to transifex using env variables.

Tuesday 02 Apr
4:05 pm

Mateusz Kwiatkowski

This seems to fix the issue with pulling from and pushing into transifex, but there is another issue. The gradle version was changed in the v5 version of docker-dev, but services are not using this...

This seems to fix the issue with pulling from and pushing into transifex, but there is another issue. The gradle version was changed in the v5 version of docker-dev, but services are not using this version. After trying to use it in referencedata build failed: http://build.openlmis.org/job/OpenLMIS-referencedata-pipeline/job/master/614/console
Not sure if I should change gradle version back to the previous one or try to change our gradle build process to work with new gradle version.

4:03 pm

Mateusz Kwiatkowski

3:59 pm

Mateusz Kwiatkowski

OLMIS-6128: added force and no interactive flag to transifex init
OLMIS-6128: added force and no interactive flag to transifex init
Thursday 21 Mar
10:06 am

Mateusz Kwiatkowski

9:40 am

Mateusz Kwiatkowski

9:40 am

Mateusz Kwiatkowski

Wednesday 20 Mar
3:42 pm

Mateusz Kwiatkowski

OLMIS-3641: removed supply line expand feature flag support
OLMIS-3641: removed supply line expand feature flag support
3:40 pm

Mateusz Kwiatkowski

OLMIS-3641: removed supply line expand feature flag
OLMIS-3641: removed supply line expand feature flag
3:39 pm

Mateusz Kwiatkowski

Revert "OLMIS-3641: added using v2 of supply lines endpoint"
Revert "OLMIS-3641: added using v2 of supply lines endpoint"
9:53 am

Mateusz Kwiatkowski

Tuesday 19 Mar
5:25 pm

Mateusz Kwiatkowski

OLMIS-3641: fixed problem with sorting supply lines by supplying facility
OLMIS-3641: fixed problem with sorting supply lines by supplying facility
4:46 pm

Mateusz Kwiatkowski

4:29 pm

Mateusz Kwiatkowski

12:39 pm

Mateusz Kwiatkowski

12:29 pm

Mateusz Kwiatkowski

I don't think so. When flag would be removed we don't want to introduce new code, only remove the old version, as we would do refactor using flag.

I don't think so. When flag would be removed we don't want to introduce new code, only remove the old version, as we would do refactor using flag.

12:20 pm

Mateusz Kwiatkowski

Because this info after my changes is located in supply line itself, but I cannot remove this whole resolve until we remove flag completely. The empty object is the easiest solution I think.

Because this info after my changes is located in supply line itself, but I cannot remove this whole resolve until we remove flag completely. The empty object is the easiest solution I think.

12:12 pm

Mateusz Kwiatkowski