[jira] [Resolved] (DELTASPIKE-1472) htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope

2024-04-19 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1472.
---
Resolution: Fixed

> htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
> 
>
> Key: DELTASPIKE-1472
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1472
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.0.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Since version 2.0.0, {{deltaspike-jsf-module-impl}} has a compile dependency 
> to {{htmlunit3-driver}}.
> This includes a subtree of several other transitive dependencies, including 
> Selenium, OpenTelemetry and Jetty Components, which are then also packaged in 
> an application (e.g. WAR or EAR) that uses the DeltaSpike JSF Module.
> {noformat}
> +- org.apache.deltaspike.modules:deltaspike-jsf-module-impl:jar:2.0.0:runtime
>\- org.seleniumhq.selenium:htmlunit3-driver:jar:4.18.1:runtime
>   +- org.seleniumhq.selenium:selenium-api:jar:4.18.1:runtime
>   +- org.seleniumhq.selenium:selenium-support:jar:4.18.1:runtime
>   |  +- com.google.auto.service:auto-service-annotations:jar:1.1.1:runtime
>   |  +- org.seleniumhq.selenium:selenium-json:jar:4.18.1:runtime
>   |  \- org.seleniumhq.selenium:selenium-remote-driver:jar:4.18.1:runtime
>   | +- 
> io.opentelemetry.semconv:opentelemetry-semconv:jar:1.23.1-alpha:runtime
>   | +- io.opentelemetry:opentelemetry-api:jar:1.35.0:runtime
>   | +- io.opentelemetry:opentelemetry-context:jar:1.35.0:runtime
>   | +- 
> io.opentelemetry:opentelemetry-exporter-logging:jar:1.35.0:runtime
>   | +- io.opentelemetry:opentelemetry-sdk-common:jar:1.35.0:runtime
>   | +- 
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:jar:1.35.0:runtime
>   | +- 
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure:jar:1.35.0:runtime
>   | |  \- 
> io.opentelemetry:opentelemetry-api-events:jar:1.35.0-alpha:runtime
>   | +- io.opentelemetry:opentelemetry-sdk-trace:jar:1.35.0:runtime
>   | |  \- 
> io.opentelemetry:opentelemetry-extension-incubator:jar:1.35.0-alpha:runtime
>   | +- io.opentelemetry:opentelemetry-sdk:jar:1.35.0:runtime
>   | |  +- 
> io.opentelemetry:opentelemetry-sdk-metrics:jar:1.35.0:runtime
>   | |  \- io.opentelemetry:opentelemetry-sdk-logs:jar:1.35.0:runtime
>   | +- org.seleniumhq.selenium:selenium-http:jar:4.18.1:runtime
>   | |  \- dev.failsafe:failsafe:jar:3.3.2:runtime
>   | +- org.seleniumhq.selenium:selenium-manager:jar:4.18.1:runtime
>   | \- org.seleniumhq.selenium:selenium-os:jar:4.18.1:runtime
>   |\- org.apache.commons:commons-exec:jar:1.3:runtime
>   \- org.htmlunit:htmlunit:jar:3.11.0:runtime
>  +- org.apache.httpcomponents:httpmime:jar:4.5.14:runtime
>  |  \- org.apache.httpcomponents:httpclient:jar:4.5.14:runtime
>  | \- org.apache.httpcomponents:httpcore:jar:4.4.16:runtime
>  +- org.htmlunit:htmlunit-core-js:jar:3.11.0:runtime
>  +- org.htmlunit:neko-htmlunit:jar:3.11.2:runtime
>  +- org.htmlunit:htmlunit-cssparser:jar:3.11.0:runtime
>  +- org.htmlunit:htmlunit-xpath:jar:3.11.0:runtime
>  +- org.htmlunit:htmlunit-csp:jar:3.11.0:runtime
>  +- commons-io:commons-io:jar:2.15.0:runtime
>  +- commons-logging:commons-logging:jar:1.3.0:runtime
>  +- commons-net:commons-net:jar:3.10.0:runtime
>  +- commons-codec:commons-codec:jar:1.16.1:runtime
>  +- org.brotli:dec:jar:0.1.2:runtime
>  \- 
> org.eclipse.jetty.websocket:websocket-client:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-client:jar:9.4.53.v20231009:runtime
> |  \- org.eclipse.jetty:jetty-http:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-util:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-io:jar:9.4.53.v20231009:runtime
> \- 
> org.eclipse.jetty.websocket:websocket-common:jar:9.4.53.v20231009:runtime
>\- 
> org.eclipse.jetty.websocket:websocket-api:jar:9.4.53.v20231009:runtime
> {noformat}
> h3. Workaround
> {{htmlunit3-driver}} and the transitive depend

[jira] [Updated] (DELTASPIKE-1472) htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope

2024-04-19 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko updated DELTASPIKE-1472:
--
Fix Version/s: 2.0.1

> htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
> 
>
> Key: DELTASPIKE-1472
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1472
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.0.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Since version 2.0.0, {{deltaspike-jsf-module-impl}} has a compile dependency 
> to {{htmlunit3-driver}}.
> This includes a subtree of several other transitive dependencies, including 
> Selenium, OpenTelemetry and Jetty Components, which are then also packaged in 
> an application (e.g. WAR or EAR) that uses the DeltaSpike JSF Module.
> {noformat}
> +- org.apache.deltaspike.modules:deltaspike-jsf-module-impl:jar:2.0.0:runtime
>\- org.seleniumhq.selenium:htmlunit3-driver:jar:4.18.1:runtime
>   +- org.seleniumhq.selenium:selenium-api:jar:4.18.1:runtime
>   +- org.seleniumhq.selenium:selenium-support:jar:4.18.1:runtime
>   |  +- com.google.auto.service:auto-service-annotations:jar:1.1.1:runtime
>   |  +- org.seleniumhq.selenium:selenium-json:jar:4.18.1:runtime
>   |  \- org.seleniumhq.selenium:selenium-remote-driver:jar:4.18.1:runtime
>   | +- 
> io.opentelemetry.semconv:opentelemetry-semconv:jar:1.23.1-alpha:runtime
>   | +- io.opentelemetry:opentelemetry-api:jar:1.35.0:runtime
>   | +- io.opentelemetry:opentelemetry-context:jar:1.35.0:runtime
>   | +- 
> io.opentelemetry:opentelemetry-exporter-logging:jar:1.35.0:runtime
>   | +- io.opentelemetry:opentelemetry-sdk-common:jar:1.35.0:runtime
>   | +- 
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:jar:1.35.0:runtime
>   | +- 
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure:jar:1.35.0:runtime
>   | |  \- 
> io.opentelemetry:opentelemetry-api-events:jar:1.35.0-alpha:runtime
>   | +- io.opentelemetry:opentelemetry-sdk-trace:jar:1.35.0:runtime
>   | |  \- 
> io.opentelemetry:opentelemetry-extension-incubator:jar:1.35.0-alpha:runtime
>   | +- io.opentelemetry:opentelemetry-sdk:jar:1.35.0:runtime
>   | |  +- 
> io.opentelemetry:opentelemetry-sdk-metrics:jar:1.35.0:runtime
>   | |  \- io.opentelemetry:opentelemetry-sdk-logs:jar:1.35.0:runtime
>   | +- org.seleniumhq.selenium:selenium-http:jar:4.18.1:runtime
>   | |  \- dev.failsafe:failsafe:jar:3.3.2:runtime
>   | +- org.seleniumhq.selenium:selenium-manager:jar:4.18.1:runtime
>   | \- org.seleniumhq.selenium:selenium-os:jar:4.18.1:runtime
>   |\- org.apache.commons:commons-exec:jar:1.3:runtime
>   \- org.htmlunit:htmlunit:jar:3.11.0:runtime
>  +- org.apache.httpcomponents:httpmime:jar:4.5.14:runtime
>  |  \- org.apache.httpcomponents:httpclient:jar:4.5.14:runtime
>  | \- org.apache.httpcomponents:httpcore:jar:4.4.16:runtime
>  +- org.htmlunit:htmlunit-core-js:jar:3.11.0:runtime
>  +- org.htmlunit:neko-htmlunit:jar:3.11.2:runtime
>  +- org.htmlunit:htmlunit-cssparser:jar:3.11.0:runtime
>  +- org.htmlunit:htmlunit-xpath:jar:3.11.0:runtime
>  +- org.htmlunit:htmlunit-csp:jar:3.11.0:runtime
>  +- commons-io:commons-io:jar:2.15.0:runtime
>  +- commons-logging:commons-logging:jar:1.3.0:runtime
>  +- commons-net:commons-net:jar:3.10.0:runtime
>  +- commons-codec:commons-codec:jar:1.16.1:runtime
>  +- org.brotli:dec:jar:0.1.2:runtime
>  \- 
> org.eclipse.jetty.websocket:websocket-client:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-client:jar:9.4.53.v20231009:runtime
> |  \- org.eclipse.jetty:jetty-http:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-util:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-io:jar:9.4.53.v20231009:runtime
> \- 
> org.eclipse.jetty.websocket:websocket-common:jar:9.4.53.v20231009:runtime
>\- 
> org.eclipse.jetty.websocket:websocket-api:jar:9.4.53.v20231009:runtime
> {noformat}
> h3. Workaround
> {{htmlunit3-driver}} and the transitive depend

Re: 2.0.1-SNAPSHOT - module buile not possible - org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT was not found

2024-04-17 Thread Thomas Andraschko
JFYI i fixed the current github actions build

Am Fr., 5. Apr. 2024 um 10:17 Uhr schrieb Thomas Andraschko <
andraschko.tho...@gmail.com>:

> CI is also broken:
> https://github.com/apache/deltaspike/actions/runs/8482148343/job/23240815428
>
> maybe maven didnt set all versions in all POMs? Or somehow our build is
> broken and it just worked in the past as there were already 2.0.0-SNAPSHOTS
> in maven repos...
>
> Am Fr., 5. Apr. 2024 um 10:10 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
>> Hi Thomas,
>>
>> Did you build the project before running your command (mvn install
>> -DskipTests -T1C)?
>> Which maven version do you use, 3.9?
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le ven. 5 avr. 2024 à 09:56, Thomas Frühbeck  a
>> écrit :
>>
>> > Hi,
>> >
>> > since move do 2.0.1-SNAPSHOT it is not possible to build modules:
>> > (commit 48fbfea1ef93da80f2e8b620808332be4cef66f4)
>> >
>> >  The following artifacts could not be resolved:
>> > org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT (absent)
>> >
>> > I don't know how to build the pom locally :-/
>> >
>> >
>> > Your branch is up to date with 'origin/master'.
>> > ~/workspace-ds/deltaspike/deltaspike> mvn dependency:tree -pl
>> > modules/data/impl/
>> > [INFO] Scanning for projects...
>> > [INFO]
>> > [INFO] -< org.apache.deltaspike.modules:deltaspike-data-module-impl
>> > >--
>> > [INFO] Building Apache DeltaSpike Data-Module Impl 2.0.1-SNAPSHOT
>> > [INFO]   from pom.xml
>> > [INFO] [ jar
>> > ]-
>> > [INFO]
>> > 
>> > [INFO] BUILD FAILURE
>> > [INFO]
>> > 
>> > [INFO] Total time:  1.087 s
>> > [INFO] Finished at: 2024-04-05T09:51:17+02:00
>> > [INFO]
>> > 
>> > [ERROR] Failed to execute goal on project deltaspike-data-module-impl:
>> > Could not resolve dependencies for project
>> >
>> >
>> org.apache.deltaspike.modules:deltaspike-data-module-impl:jar:2.0.1-SNAPSHOT:
>> > Failed to collect dependencies at
>> >
>> >
>> org.apache.deltaspike.modules:deltaspike-data-module-api:jar:2.0.1-SNAPSHOT:
>> > Failed to read artifact descriptor for
>> >
>> >
>> org.apache.deltaspike.modules:deltaspike-data-module-api:jar:2.0.1-SNAPSHOT:
>> > The following artifacts could not be resolved:
>> > org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT (absent):
>> > org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT was not found in
>> > https://repository.apache.org/snapshots/ during a previous attempt.
>> This
>> > failure was cached in the local repository and resolution is not
>> > reattempted until the update interval of apache-snapshot-repository has
>> > elapsed or updates are forced -> [Help 1]
>> >
>> >
>> > [ERROR] Failed to execute goal on project deltaspike-data-module-api:
>> Could
>> > not resolve dependencies for project
>> >
>> >
>> org.apache.deltaspike.modules:deltaspike-data-module-api:jar:2.0.1-SNAPSHOT:
>> > Failed to collect dependencies at
>> > org.apache.deltaspike.core:deltaspike-core-api:jar:2.0.1-SNAPSHOT:
>> Failed
>> > to read artifact descriptor for
>> > org.apache.deltaspike.core:deltaspike-core-api:jar:2.0.1-SNAPSHOT: The
>> > following artifacts could not be resolved:
>> > org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT (absent): Could not
>> > find artifact org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT in
>> > apache-snapshot-repository (https://repository.apache.org/snapshots/)
>> >
>>
>


Re: 2.0.1-SNAPSHOT - module buile not possible - org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT was not found

2024-04-05 Thread Thomas Andraschko
CI is also broken:
https://github.com/apache/deltaspike/actions/runs/8482148343/job/23240815428

maybe maven didnt set all versions in all POMs? Or somehow our build is
broken and it just worked in the past as there were already 2.0.0-SNAPSHOTS
in maven repos...

Am Fr., 5. Apr. 2024 um 10:10 Uhr schrieb Romain Manni-Bucau <
rmannibu...@gmail.com>:

> Hi Thomas,
>
> Did you build the project before running your command (mvn install
> -DskipTests -T1C)?
> Which maven version do you use, 3.9?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 5 avr. 2024 à 09:56, Thomas Frühbeck  a
> écrit :
>
> > Hi,
> >
> > since move do 2.0.1-SNAPSHOT it is not possible to build modules:
> > (commit 48fbfea1ef93da80f2e8b620808332be4cef66f4)
> >
> >  The following artifacts could not be resolved:
> > org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT (absent)
> >
> > I don't know how to build the pom locally :-/
> >
> >
> > Your branch is up to date with 'origin/master'.
> > ~/workspace-ds/deltaspike/deltaspike> mvn dependency:tree -pl
> > modules/data/impl/
> > [INFO] Scanning for projects...
> > [INFO]
> > [INFO] -< org.apache.deltaspike.modules:deltaspike-data-module-impl
> > >--
> > [INFO] Building Apache DeltaSpike Data-Module Impl 2.0.1-SNAPSHOT
> > [INFO]   from pom.xml
> > [INFO] [ jar
> > ]-
> > [INFO]
> > 
> > [INFO] BUILD FAILURE
> > [INFO]
> > 
> > [INFO] Total time:  1.087 s
> > [INFO] Finished at: 2024-04-05T09:51:17+02:00
> > [INFO]
> > 
> > [ERROR] Failed to execute goal on project deltaspike-data-module-impl:
> > Could not resolve dependencies for project
> >
> >
> org.apache.deltaspike.modules:deltaspike-data-module-impl:jar:2.0.1-SNAPSHOT:
> > Failed to collect dependencies at
> >
> >
> org.apache.deltaspike.modules:deltaspike-data-module-api:jar:2.0.1-SNAPSHOT:
> > Failed to read artifact descriptor for
> >
> >
> org.apache.deltaspike.modules:deltaspike-data-module-api:jar:2.0.1-SNAPSHOT:
> > The following artifacts could not be resolved:
> > org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT (absent):
> > org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT was not found in
> > https://repository.apache.org/snapshots/ during a previous attempt. This
> > failure was cached in the local repository and resolution is not
> > reattempted until the update interval of apache-snapshot-repository has
> > elapsed or updates are forced -> [Help 1]
> >
> >
> > [ERROR] Failed to execute goal on project deltaspike-data-module-api:
> Could
> > not resolve dependencies for project
> >
> >
> org.apache.deltaspike.modules:deltaspike-data-module-api:jar:2.0.1-SNAPSHOT:
> > Failed to collect dependencies at
> > org.apache.deltaspike.core:deltaspike-core-api:jar:2.0.1-SNAPSHOT: Failed
> > to read artifact descriptor for
> > org.apache.deltaspike.core:deltaspike-core-api:jar:2.0.1-SNAPSHOT: The
> > following artifacts could not be resolved:
> > org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT (absent): Could not
> > find artifact org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT in
> > apache-snapshot-repository (https://repository.apache.org/snapshots/)
> >
>


Re: [VOTE] Release Apache DeltaSpike-2.0.0

2024-03-29 Thread Thomas Andraschko
+1

Romain Manni-Bucau  schrieb am Fr., 29. März 2024,
19:15:

> +1
>
> Le ven. 29 mars 2024 à 18:55, John D. Ament  a
> écrit :
>
> > +1 LGTM
> >
> > Though I always question when release notes mention things that are Won't
> > Do as being included in them, not a problem for the release.
> >
> > On Fri, Mar 29, 2024 at 10:45 AM Mark Struberg  >
> > wrote:
> >
> > > Good afternoon!
> > >
> > > I'd like to call a VOTE on releasing Apache DeltaSpike-2.0.0
> > >
> > > The list of fixed tickets can be found in the release notes
> > >
> > >
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/readme/ReleaseNotes-2.0.0.txt
> > >
> > > This is the first version to natively target JakartaEE-9 and the
> > jakarta.*
> > > namespace.
> > >
> > > The staging repo is available under:
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1060/
> > >
> > > The source release zip can be found here
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1060/org/apache/deltaspike/deltaspike/2.0.0/
> > >
> > > the sha512 is
> > >
> > >
> >
> 06a462cd3e66457cc35bc88e8ec0f63f4560fa4bdf4d91cb0983e07001c05fbf4fa7d50d73310a9e52fb420824256e69bf373a1d03750858645f5e83120f5d1e
> > >
> > > Please VOTE
> > >
> > > [+1] let's ship it
> > > [+0] don't care
> > > [-1] stop, there is a ${showstopper}
> > >
> > > The VOTE is open for 72h
> > >
> > >
> > >
> > > txs and LieGrue,
> > > strub
> > >
> >
>


Re: Release 2.0.0-M1?

2024-03-21 Thread Thomas Andraschko
why is not needed for batchee? ->
https://github.com/apache/geronimo-batchee/blob/master/pom.xml#L66

Im not really sure about doing a "real" release as we removed so many code
and features, i'm not sure if we removed to much or miss something.
Therefore i thought about a M1 or RC1 first.

Am Do., 21. März 2024 um 12:04 Uhr schrieb Romain Manni-Bucau <
rmannibu...@gmail.com>:

> Hi Thomas,
>
> This is not needed for BatchEE but ultimately I guess we can do a 2.0.0,
> nothing crazy is really expected after anyway and we can do 2.0.1 if needed
> no? (milestones and alpha are always dead numbers from my perspective so it
> is either ready or it is not - this philosophy makes things simpler after
> IMHO).
>
> Best,
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 21 mars 2024 à 09:45, Thomas Andraschko <
> andraschko.tho...@gmail.com>
> a écrit :
>
> > Hi,
> >
> > short: We need a DS release, to release BatchEE, to release TomEE M1.
> >
> > In general i think we are ready for a M1, our tests are running,
> > OWB+Weld+Wildfly builds are green. TomEE and Payara are almost green, see
> > the other mail.
> >
> > WDYT?
> >
> > Best regards,
> > Thomas
> >
>


Release 2.0.0-M1?

2024-03-21 Thread Thomas Andraschko
Hi,

short: We need a DS release, to release BatchEE, to release TomEE M1.

In general i think we are ready for a M1, our tests are running,
OWB+Weld+Wildfly builds are green. TomEE and Payara are almost green, see
the other mail.

WDYT?

Best regards,
Thomas


DS-2.0.0 - integration tests status

2024-03-18 Thread Thomas Andraschko
-Ptomee-build-managed
   works for 99%, the new release of htmlunit will fix it (
https://github.com/HtmlUnit/htmlunit/issues/732)


-Pwildfly-build-managed
   works because of deltaspike.bean-manager.delegate_lookup=false


-Ppayara-build-managed
   works for 99% AFAICS, JSF module just fails because of a very old
mojarra version: https://github.com/payara/Payara/issues/6578


Re: DS-2.0.0 - Wildfly - BeanMangerDelegate - subdeployment reverse bean visibilty issue

2024-03-18 Thread Thomas Andraschko
Can we just set this property based on the profiles for our tests?
This is probably also required for payara users, we have to add it to the
docs then of course.

Am So., 10. März 2024 um 14:49 Uhr schrieb Thomas Frühbeck <
t.fruehb...@gmail.com>:

> We have already discussed the problem of interceptorLookup for PartialBean
> on Wildfly.
> IMHO due to subdeployment CL-visibilty issues (not flat!) the interceptors
> in jar A are not visible in jar DS-partial-bean-impl.
>
> A possible solution for this can be:
> BeanMangerProvider#getBeanManager(): extend decision on lookup strategy
> like
> private static boolean useDelegateLookup()
> {
> return CoreBaseConfig.BeanManagerIntegration.DELEGATE_LOOKUP
> && System.getProperty("jboss.server.name") == null;
> }
>
> Then all tests in partial-bean-impl -P wildfly-build-managed run
> successfully!
>
> Another issue that could be resolved this way: TransactionStrategy lookup
> in data-impl:
> Instead of @Priority workaround
>   - activate ContainerMangedTxStrategy in beans.xml
>   - and change Injection of TransactionStrategy in TransactionalQueryRunner
> like:
> protected Object executeTransactional(final QueryBuilder builder, final
> CdiQueryInvocationContext context)
> {
> TransactionStrategy strategy =
> BeanProvider.getContextualReference(TransactionStrategy.class);
>
> will also work fine!
>
> Just to show the massive impact of the identified (supposed?) bug in
> Wildfly subdeployment class visibility.
>
> First step: your feedback on the proposed (temporary?) fix on
> abovementioned change in BeanManagerLookup
> :-/
>


Re: DS-2.0.0 - PartialBean - Proxy doesn't call delegate?

2024-03-11 Thread Thomas Andraschko
Cant open the link :/

Thomas Frühbeck  schrieb am Mo., 11. März 2024,
21:03:

> Now it seems fixed: Wildfly's BDAs are isolated, no visibility inside DS of
> outside Beans/Interceptors/...
> Details see: https://issues.redhat.com/browse/WFLY-19111
> Kinda interresting read - no spec violation by raw words - but I don't
> quite get the point :-/
>
> Am So., 10. März 2024 um 15:20 Uhr schrieb Thomas Frühbeck <
> t.fruehb...@gmail.com>:
>
> > Now issue created successfully:
> > https://issues.redhat.com/browse/WFLY-19111
> >
> > Am Sa., 9. März 2024 um 17:18 Uhr schrieb Thomas Frühbeck <
> > t.fruehb...@gmail.com>:
> >
> >> Follow-Up: I think I successfully created a 2-module war project
> >> reproducing the problem.
> >> Tried to create a bug report on Wildfly - permission denied
> >> :-/
> >>
> >> Am Sa., 9. März 2024 um 13:29 Uhr schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com>:
> >>
> >>> We can but wonder if it does not depend on wildfly version too but
> >>> ultimagely we could detect it is wildfly and not capture the same BM.
> >>> For standalone case it misses a web-inf/classes global BM so back to
> the
> >>> BDA issue.
> >>> By reflection you can always lookup the right one using CDI impl -
> >>> forcing
> >>> caller class directly - but not sure it is good.
> >>>
> >>>
> >>>
>


Re: [PR] Wildfly-31 wildfly-build-managed - BeansXmlUtil.discovery-mode=all - mostly working [deltaspike]

2024-02-29 Thread Thomas Andraschko
seems to work, nice!
JSF module still fails on Payara (
https://github.com/payara/Payara/issues/6578) and TomEE (the HTMLUnit bug,
should be released soon)
probably the last thing for wildfly is the interceptor bug like mentioned
in the other mail?


Am Do., 29. Feb. 2024 um 08:03 Uhr schrieb Thomas Frühbeck <
t.fruehb...@gmail.com>:

> the reason for failure was an IMHO unfortunate import of MyFaces Assert,
> which is not availble on Wildfly.
>  +import org.apache.myfaces.core.api.shared.lang.Assert;
> After replacement all tests work again, PR sent.
>
> mvn -Drat.skip clean install -Pwildfly-build-managed -pl
> deltaspike/modules/jsf/impl/
> 
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 115, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time:  48.660 s
> [INFO] Finished at: 2024-02-29T08:01:32+01:00
> [INFO]
> --------
>
>
>
> Am Mi., 28. Feb. 2024 um 11:49 Uhr schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
>
> > i currently tried to workaround to the mojarra #encodeRedirectUrl bug but
> > there are still many tests failing with mojarra (both wildfly and
> payara) -
> > tomee works
> >
> > i will push it for now, can you have a look again and debug?
> >
> > Am Mo., 26. Feb. 2024 um 23:39 Uhr schrieb Thomas Frühbeck <
> > t.fruehb...@gmail.com>:
> >
> > > Please note, that w/o --fail-at-end the build will fail on
> > > Partial-Bean-Module Impl.
> > > As I already noted in previous mail.
> > >
> > > [INFO] Reactor Summary for Apache DeltaSpike 2.0.0-SNAPSHOT:
> > > [INFO]
> > > [INFO] Apache DeltaSpike .. SUCCESS [
> > >  0.999 s]
> > > [INFO] Apache DeltaSpike Sources .. SUCCESS [
> > >  0.187 s]
> > > [INFO] Apache DeltaSpike CheckStyle-rules . SUCCESS [
> > >  0.405 s]
> > > [INFO] Apache DeltaSpike Parent ... SUCCESS [
> > >  1.332 s]
> > > [INFO] Apache DeltaSpike Test-Utils ... SUCCESS [
> > >  1.369 s]
> > > [INFO] Apache DeltaSpike Code Parent .. SUCCESS [
> > >  4.421 s]
> > > [INFO] Apache DeltaSpike Core . SUCCESS [
> > >  3.593 s]
> > > [INFO] Apache DeltaSpike Core-API . SUCCESS [
> > >  5.778 s]
> > > [INFO] Apache DeltaSpike Core-Implementation .. SUCCESS [
> > > 39.661 s]
> > > [INFO] Apache DeltaSpike ContainerControl parent .. SUCCESS [
> > >  0.267 s]
> > > [INFO] Apache DeltaSpike CDI ContainerControl API . SUCCESS [
> > >  0.215 s]
> > > [INFO] Apache DeltaSpike CDI Weld-ContainerControl  SUCCESS [
> > >  0.382 s]
> > > [INFO] Apache DeltaSpike Modules .. SUCCESS [
> > >  3.733 s]
> > > [INFO] Apache DeltaSpike Proxy-Module . SUCCESS [
> > >  3.678 s]
> > > [INFO] Apache DeltaSpike Proxy-Module API . SUCCESS [
> > >  4.647 s]
> > > [INFO] Apache DeltaSpike Proxy-Module Impl ASM  SUCCESS [
> > >  5.056 s]
> > > [INFO] Apache DeltaSpike Security-Module .. SUCCESS [
> > >  3.504 s]
> > > [INFO] Apache DeltaSpike Security-Module API .. SUCCESS [
> > >  3.853 s]
> > > [INFO] Apache DeltaSpike Security-Module Impl . SUCCESS [
> > > 13.192 s]
> > > [INFO] Apache DeltaSpike JSF-Module ... SUCCESS [
> > >  3.603 s]
> > > [INFO] Apache DeltaSpike JSF-Module API ... SUCCESS [
> > >  4.338 s]
> > > [INFO] Apache DeltaSpike JSF-Module Impl .. SUCCESS [
> > > 42.537 s]
> > > [INFO] Apache DeltaSpike Partial-Bean-Module .. SUCCESS [
> > >  3.565 s]
> > > [INFO] Apache DeltaSpike Partial-Bean-Module API .. SUCCESS [
> > >  3.825 s]
> > > [INFO] Apache DeltaSpike Partial-Bean-Module Impl . FAILURE [
> > > 19.794 s]
> > > [INFO] Apache DeltaSpike JPA-Module ... SUCCESS [
> > >  3.655 s]
> > > [INFO] Apache DeltaSpike JPA-Module API ... SUCCESS [
> > >  3.972 s]
> > > [INFO] Apache DeltaSpike JPA-

Re: [PR] Wildfly-31 wildfly-build-managed - BeansXmlUtil.discovery-mode=all - mostly working [deltaspike]

2024-02-28 Thread Thomas Andraschko
O] Apache DeltaSpike Site . SUCCESS [
>  0.023 s]
> [INFO]
> ----
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  03:53 min
> [INFO] Finished at: 2024-02-26T22:18:04+01:00
> [INFO]
> 
>
> Am Mo., 26. Feb. 2024 um 15:24 Uhr schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
>
> > Are you sure that it's "mostly working"?
> >
> > not even core-api tests are running with wildfly-build-managed, see:
> >
> >
> https://github.com/apache/deltaspike/actions/runs/8049145992/job/21981920123
> >
> > Am Mo., 26. Feb. 2024 um 10:15 Uhr schrieb tandraschko (via GitHub) <
> > g...@apache.org>:
> >
> > >
> > > tandraschko merged PR #151:
> > > URL: https://github.com/apache/deltaspike/pull/151
> > >
> > >
> > > --
> > > This is an automated message from the Apache Git Service.
> > > To respond to the message, please log on to GitHub and use the
> > > URL above to go to the specific comment.
> > >
> > > To unsubscribe, e-mail: dev-unsubscr...@deltaspike.apache.org
> > >
> > > For queries about this service, please contact Infrastructure at:
> > > us...@infra.apache.org
> > >
> > >
> >
>


[jira] [Created] (DELTASPIKE-1471) Remove @EnableInterceptors in favor of CDI InterceptionFactory

2024-02-27 Thread Thomas Andraschko (Jira)
Thomas Andraschko created DELTASPIKE-1471:
-

 Summary: Remove @EnableInterceptors in favor of CDI 
InterceptionFactory
 Key: DELTASPIKE-1471
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1471
 Project: DeltaSpike
  Issue Type: Task
  Security Level: public (Regular issues)
Reporter: Thomas Andraschko






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


[jira] [Updated] (DELTASPIKE-1471) Remove @EnableInterceptors in favor of CDI InterceptionFactory

2024-02-27 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko updated DELTASPIKE-1471:
--
Fix Version/s: 2.0

> Remove @EnableInterceptors in favor of CDI InterceptionFactory
> --
>
> Key: DELTASPIKE-1471
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1471
> Project: DeltaSpike
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>    Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 2.0
>
>




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


[jira] [Resolved] (DELTASPIKE-1471) Remove @EnableInterceptors in favor of CDI InterceptionFactory

2024-02-27 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1471.
---
  Assignee: Thomas Andraschko
Resolution: Fixed

> Remove @EnableInterceptors in favor of CDI InterceptionFactory
> --
>
> Key: DELTASPIKE-1471
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1471
> Project: DeltaSpike
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>    Reporter: Thomas Andraschko
>    Assignee: Thomas Andraschko
>Priority: Major
> Fix For: 2.0
>
>




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


DS-2.0.0 - tomee-build-managed status

2024-02-27 Thread Thomas Andraschko
JFYI

tomee-build-managed with TomEE 10-M1-SNAPSHOT works for 99%, there is just
a small issue open in HtmlUnit, then the build should be green:
https://github.com/HtmlUnit/htmlunit/issues/732


Re: DS-2.0.0 - PartialBean - Proxy doesn't call delegate?

2024-02-27 Thread Thomas Andraschko
I had a look on the partialbean-impl module and it fails with weld (payara
& wildfly-build-managed) but works fine on tomee:
the problem seems to be in DeltaSpikeProxyInvocationHandler as the
interceptors are empty.
it seems that DeltaSpikeProxyInterceptorLookup the right interceptor are
correctly extracted but
beanManager.resolveInterceptors(InterceptionType.AROUND_INVOKE,
interceptorBindings);
doesnt return the SimpleCacheInterceptor.

maybe you can debug a bit more into weld or talk with them?


Am So., 25. Feb. 2024 um 18:43 Uhr schrieb Thomas Frühbeck <
t.fruehb...@gmail.com>:

> Hi,
> the last test currently failing in wildfly-build-managed are PartialBean -
> Interceptor tests.
> As far as I could trace the problem weld detects the PartialBean, the
> PartialBeanExtension creates proxy and the Interceptor is correctly
> registered.
> But when the proxy is invoked, the invokation does not seem to be passed on
> to the delegate.
>
> Help appreciated.
> Thomas
>


Re: [PR] Wildfly-31 wildfly-build-managed - BeansXmlUtil.discovery-mode=all - mostly working [deltaspike]

2024-02-26 Thread Thomas Andraschko
Are you sure that it's "mostly working"?

not even core-api tests are running with wildfly-build-managed, see:
https://github.com/apache/deltaspike/actions/runs/8049145992/job/21981920123

Am Mo., 26. Feb. 2024 um 10:15 Uhr schrieb tandraschko (via GitHub) <
g...@apache.org>:

>
> tandraschko merged PR #151:
> URL: https://github.com/apache/deltaspike/pull/151
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@deltaspike.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>


Re: DS-2.0.0 - JSF - Wildfly-31 - Validator / Converter

2024-02-25 Thread Thomas Andraschko
I dont know, this was decided in JSF 2.2 or 2.3 specs

Thomas Frühbeck  schrieb am So., 25. Feb. 2024,
11:18:

> They didn't, now they have, tests work now.
> Thanks for the information!
>
> btw: why is "managed" default false?
> How many use cases are there for Converter/Validator classes with injection
> points not being intended as beans?
> Or are many potentially ambiguous beans to be expected?
>
> Am Sa., 24. Feb. 2024 um 20:54 Uhr schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
>
> > Does it have @FacesConverter(managed=true)? Otherwise it wont work
> >
> > Thomas Frühbeck  schrieb am Sa., 24. Feb. 2024,
> > 19:49:
> >
> > > Hi,
> > > I have verified, that all JSF Drone tests currently fail on vanilla
> > > Wildfly-31 due to Mojarra Bug #5383
> > > <https://github.com/eclipse-ee4j/mojarra/issues/5383>
> > >  (initial redirect on DS windowId)
> > >
> > > For Drone tests jsf/impl/injection on Wildfly-31/Mojarra:
> > > on HotFixed Wildfly-31 Mojarra seems not to inject @FacesConverter
> > > and @FacesValidator objects
> > >
> > > Does this happen on TomEE/MyFaces?
> > >
> >
> >
>


Re: DS-2.0.0 - JSF - Wildfly-31 - Validator / Converter

2024-02-24 Thread Thomas Andraschko
Does it have @FacesConverter(managed=true)? Otherwise it wont work

Thomas Frühbeck  schrieb am Sa., 24. Feb. 2024,
19:49:

> Hi,
> I have verified, that all JSF Drone tests currently fail on vanilla
> Wildfly-31 due to Mojarra Bug #5383
> 
>  (initial redirect on DS windowId)
>
> For Drone tests jsf/impl/injection on Wildfly-31/Mojarra:
> on HotFixed Wildfly-31 Mojarra seems not to inject @FacesConverter
> and @FacesValidator objects
>
> Does this happen on TomEE/MyFaces?
>
> If so, what is to be done for Wildfly?
>
> A possible solution would be to move to "validator" / "converter"
> attributes like:
>converter="#{myValueConverter.getAsObject}">
> 
> 
>
>  validator="#{myBeanValidator.validate}">
> 
> 
>


Re: Deltaspike-2.0.0 - jbossas7 cleanup

2024-02-21 Thread Thomas Andraschko
+1

Thomas Frühbeck  schrieb am Do., 22. Feb. 2024,
08:17:

> Currently there are many different definitions of JBoss AS7
> definitions/settings found in DS build and tests.
>
> I propose to (re-)move ALL legacy references to AS7 and leave only wildfly
> related.
>
> Please comment.
> Thomas
>


Re: RFC: ArquillianTests - CDI 4.0 - bean-discovery-mode

2024-02-21 Thread Thomas Andraschko
+1

Thomas Frühbeck  schrieb am Do., 22. Feb. 2024,
07:42:

> The current CDI 4.0 spec has moved to default bean-discovery-mode
> "annotated".
>
> All Arquillian tests - I have seen yet - are using Asset.Empty as
> "beans.xml" which causes all tests to fail - at least on Wildfly-31.0.0.
> This seems to be in accordance to spec.
>
> I propose to replace all - yet unspecific usages of Asset.Empty with the
> following default:
> ArchiveUtils:
> public static final Asset beansXmlAll = new StringAsset(" bean-discovery-mode=\"all\"/>")
>
> Using this default beans.xml all Arquillian tests in "wildfly-managed" are
> OK - at least in Deltaspike-Core.
>
> Please note, that usage of "" is here unwanted, as it makes all
> default beans unavailable.
> All test I have seen yet seem to rely heavily on the previous default
> discovery-mode="all"!
>
> Please comment.
> Thomas
>


Re: [PR] Arquillian.protocol to jakarta,6.0 - TestCase for Failure on generic … [deltaspike]

2024-02-20 Thread Thomas Andraschko
can you try to fix wildfly-build-managed?
tomee-build-managed already runs fine now

is think there is some work needed in the arquillian config

Am Di., 20. Feb. 2024 um 12:08 Uhr schrieb Thomas Frühbeck <
t.fruehb...@gmail.com>:

> Please accept the changes regarding Arquillian (dependency
> management/servlet protocol & version, etc.)
> or else - at least on my side - Arquillian won't run at all.
> New PR on the way.
>
> Am Di., 20. Feb. 2024 um 09:17 Uhr schrieb tandraschko (via GitHub) <
> g...@apache.org>:
>
> >
> > tandraschko commented on PR #149:
> > URL:
> https://github.com/apache/deltaspike/pull/149#issuecomment-1953685637
> >
> >can you please provide a PR without code changes?
> > (EntityMetadataInitializer.java, just adding tests to see what fails?)
> >
>


Re: [PR] Weld5 - add Dependent scope to @Repository, skip intermediate generic… [deltaspike]

2024-02-19 Thread Thomas Andraschko
I would suggest the following:

1) we revert your PR
2) you add your testcase in a new PR and you try to fail our Weld CI build
3) when it fails, we can debug together and work on a fix

Am Mo., 19. Feb. 2024 um 14:32 Uhr schrieb Thomas Frühbeck <
t.fruehb...@gmail.com>:

> the intermediate Repository class:
>
> *// no annotation present!!*
>
> public abstract class AbstractElementRepository extends Serializable> extends AbstractFullEntityRepository
> implements
> ElementRelated {
>
>
> in RepsitoryExtension: for the intermediate AbstractElementRepository class
> (no Annotation!!!) Weld will find:
> event.getAnnotatedType().getJavaClass(): class
> at.telekom.archive.repository.AbstractElementRepository
> and:
>
> event.getAnnotatedType().getJavaClass().isAnnotationPresent(Repository.class)
> == true
>
> Help very much appreciated, else application broken!!!
>
>
> Am Mo., 19. Feb. 2024 um 14:07 Uhr schrieb tandraschko (via GitHub) <
> g...@apache.org>:
>
> >
> > tandraschko commented on code in PR #147:
> > URL:
> https://github.com/apache/deltaspike/pull/147#discussion_r1494524740
> >
> >
> > ##
> >
> >
> deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/RepositoryExtension.java:
> > ##
> > @@ -90,6 +90,11 @@ else if (isRepository(event.getAnnotatedType()))
> >  LOG.log(Level.FINER, "Class {0} is Deactivated",
> > repositoryClass);
> >  return;
> >  }
> > +if (repositoryClass.getDeclaredAnnotation(Repository.class)
> > == null)
> >
> > Review Comment:
> >the outer if should already exact do this code
> >
> >
> >
> > ##
> >
> >
> deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/RepositoryExtension.java:
> > ##
> > @@ -90,6 +90,11 @@ else if (isRepository(event.getAnnotatedType()))
> >  LOG.log(Level.FINER, "Class {0} is Deactivated",
> > repositoryClass);
> >  return;
> >  }
> > +if (repositoryClass.getDeclaredAnnotation(Repository.class)
> > == null)
> >
> > Review Comment:
> >the outer if should already exact do this check in #isRepository
> >
> >
> >
> > --
> > This is an automated message from the Apache Git Service.
> > To respond to the message, please log on to GitHub and use the
> > URL above to go to the specific comment.
> >
> > To unsubscribe, e-mail: dev-unsubscr...@deltaspike.apache.org
> >
> > For queries about this service, please contact Infrastructure at:
> > us...@infra.apache.org
> >
> >
>


[jira] [Resolved] (DELTASPIKE-1469) WindowIdHtmlRenderer loads wrong Javascript file

2024-01-16 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1469.
---
Fix Version/s: 2.0
   Resolution: Fixed

> WindowIdHtmlRenderer loads wrong Javascript file
> 
>
> Key: DELTASPIKE-1469
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1469
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0
>Reporter: Peter Nimmervoll
>    Assignee: Thomas Andraschko
>Priority: Major
> Fix For: 2.0
>
>
> At least in the latest Mojarra release (4.0.5) the jsf.js was renamed to 
> faces.js but WindowIdHtmlRenderer still loads jsf.js. 



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


[jira] [Assigned] (DELTASPIKE-1469) WindowIdHtmlRenderer loads wrong Javascript file

2024-01-16 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko reassigned DELTASPIKE-1469:
-

Assignee: Thomas Andraschko

> WindowIdHtmlRenderer loads wrong Javascript file
> 
>
> Key: DELTASPIKE-1469
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1469
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0
>Reporter: Peter Nimmervoll
>    Assignee: Thomas Andraschko
>Priority: Major
>
> At least in the latest Mojarra release (4.0.5) the jsf.js was renamed to 
> faces.js but WindowIdHtmlRenderer still loads jsf.js. 



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


[jira] [Commented] (DELTASPIKE-1470) PSQLException: ERROR: syntax error at or near ")" when using IN clause and empty list

2024-01-16 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807223#comment-17807223
 ] 

Thomas Andraschko commented on DELTASPIKE-1470:
---

a PR would be very very great!

> PSQLException: ERROR: syntax error at or near ")" when using IN clause and 
> empty list
> -
>
> Key: DELTASPIKE-1470
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1470
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Data-Module, JPA-Module
>Affects Versions: 1.9.4
>Reporter: Gilberto C Andrade
>Priority: Minor
>
> I'm getting this exception every time one query, that uses IN clause, 
> receives an empty parameter:
> {code:java}
> // 
> Caused by: javax.persistence.PersistenceException: Exception 
> [EclipseLink-4002] (Eclipse Persistence Services - 
> 2.7.7.v20200504-69f2c2b80d): 
> org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception: org.postgresql.util.PSQLException: ERROR: syntax error at 
> or near ")"
>   Posição: 396
> Error Code: 0
> Call: SELECT titulo_cobranca_id, ACEITE, codigo_movimento_remessa, 
> codigo_movimento_retorno, documento, dt_documento, dt_efetivacao_credito, 
> dt_emissao, dt_ocorrencia, dt_vencimento, especie, valor_juro, 
> motivo_ocorrencia, valor_multa, nosso_numero, situacao, valor, 
> valor_juros_multa_encargos, valor_pago, valor_tarifa, conta_bancaria_id, 
> pagador_id FROM gace.titulo_cobranca WHERE (nosso_numero IN ())
> Query: ReadAllQuery(referenceClass=TituloCobranca sql="SELECT 
> titulo_cobranca_id, ACEITE, codigo_movimento_remessa, 
> codigo_movimento_retorno, documento, dt_documento, dt_efetivacao_credito, 
> dt_emissao, dt_ocorrencia, dt_vencimento, especie, valor_juro, 
> motivo_ocorrencia, valor_multa, nosso_numero, situacao, valor, 
> valor_juros_multa_encargos, valor_pago, valor_tarifa, conta_bancaria_id, 
> pagador_id FROM gace.titulo_cobranca WHERE (nosso_numero IN ?)")
>     at 
> org.eclipse.persistence.internal.jpa.QueryImpl.getDetailedException(QueryImpl.java:391)
>     at 
> org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:264)
>     at 
> org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:482)
>     at org.apache.openejb.persistence.JtaQuery.getResultList(JtaQuery.java:87)
>     at 
> org.apache.deltaspike.data.impl.builder.result.QueryProcessorFactory$ListResultQueryProcessor.executeQuery(QueryProcessorFactory.java:96)
>     at 
> org.apache.deltaspike.data.impl.handler.CdiQueryInvocationContext.executeQuery(CdiQueryInvocationContext.java:253)
>     at 
> org.apache.deltaspike.data.impl.builder.AnnotatedQueryBuilder.execute(AnnotatedQueryBuilder.java:51)
>     at 
> org.apache.deltaspike.data.impl.builder.QueryBuilder.executeQuery(QueryBuilder.java:57)
>     at 
> org.apache.deltaspike.data.impl.builder.AnnotatedQueryBuilder$$OwbNormalScopeProxy0.executeQuery(org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java)
>     at 
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeNonTransactional(TransactionalQueryRunner.java:62)
>     at 
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeQuery(TransactionalQueryRunner.java:57)
>     at 
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner$$OwbNormalScopeProxy0.executeQuery(org/apache/deltaspike/data/impl/tx/TransactionalQueryRunner.java)
>     at 
> org.apache.deltaspike.data.impl.handler.QueryHandler.process(QueryHandler.java:151)
>     at 
> org.apache.deltaspike.data.impl.handler.QueryHandler.invoke(QueryHandler.java:130)
>     at 
> org.apache.deltaspike.data.impl.handler.QueryHandler$$OwbNormalScopeProxy0.invoke(org/apache/deltaspike/data/impl/handler/QueryHandler.java)
>     at 
> org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler.proceed(DeltaSpikeProxyInvocationHandler.java:97)
>     at 
> org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler.invoke(DeltaSpikeProxyInvocationHandler.java:78)
>     at 
> org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler$$OwbNormalScopeProxy0.invoke(org/apache/deltaspike/proxy/spi/invocation/DeltaSpikeProxyInvocationHandler.java)
>     at 
> br.gov.to.bem.gace.repository.TituloCobrancaRepository$$DSPartialBeanProxy.findAllByNossoNumero(Unknown
>  Source)
>     at 
> br.gov.to.bem.gace.service.RetornoService.gerar(RetornoService.java:191)
>     at

[jira] [Resolved] (DELTASPIKE-1468) AuditProvider (PrincipalProvider/TimestampsProvider) not working

2024-01-10 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1468.
---
Resolution: Fixed

> AuditProvider (PrincipalProvider/TimestampsProvider) not working
> 
>
> Key: DELTASPIKE-1468
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1468
> Project: DeltaSpike
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: JPA-Module
>Affects Versions: 2.0
> Environment: symptom exhibited on Payara6 WELD 
>Reporter: Phillip Ross
>Priority: Blocker
>
> PrincipalProvider and TimestampsProvider stop working in v2.0 (probably since 
> DELTASPIKE-1466) as they lack an explicit CDI scope annotation.  Since they 
> are loaded/referenced programmatically, no error is thrown by the bean 
> container explicitly, but rather they are just never resolved and effectively 
> ignored.
> A simple fix is to add @Dependent CDI scope annotation (probably an oversight 
> from the CDI-3 refactor).
> I'll open a GitHub PR with this fix next.



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


[jira] [Updated] (DELTASPIKE-1468) AuditProvider (PrincipalProvider/TimestampsProvider) not working

2024-01-10 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko updated DELTASPIKE-1468:
--
Fix Version/s: 2.0

> AuditProvider (PrincipalProvider/TimestampsProvider) not working
> 
>
> Key: DELTASPIKE-1468
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1468
> Project: DeltaSpike
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: JPA-Module
>Affects Versions: 2.0
> Environment: symptom exhibited on Payara6 WELD 
>Reporter: Phillip Ross
>Priority: Blocker
> Fix For: 2.0
>
>
> PrincipalProvider and TimestampsProvider stop working in v2.0 (probably since 
> DELTASPIKE-1466) as they lack an explicit CDI scope annotation.  Since they 
> are loaded/referenced programmatically, no error is thrown by the bean 
> container explicitly, but rather they are just never resolved and effectively 
> ignored.
> A simple fix is to add @Dependent CDI scope annotation (probably an oversight 
> from the CDI-3 refactor).
> I'll open a GitHub PR with this fix next.



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


[jira] [Updated] (DELTASPIKE-1467) Saving existing entity throws an exception

2024-01-09 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko updated DELTASPIKE-1467:
--
Fix Version/s: 2.0

> Saving existing entity throws an exception
> --
>
> Key: DELTASPIKE-1467
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1467
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Data-Module
>Affects Versions: 1.9.6
>Reporter: Stonewoodman
>Priority: Major
> Fix For: 2.0
>
>
> {code:java}
> @Entity(name = "Foo")
> @Table(name = "foo")
> public class FooEntity implements Serializable
> {
>     @Id
> @GeneratedValue(strategy = GenerationType.IDENTITY)
> private Long id;
> ...
> }{code}
> {code:java}
> @Transactional 
> @Repository(forEntity = FooEntity.class) 
> public abstract class FooRepository extends 
> AbstractEntityRepository
> {
> ...
> }
> {code}
> Loading an entity in JSF
> Edit and save it.
> It generates following exception
> Caused by: javax.transaction.RollbackException: Transaction is marked for 
> rollback
> The origin error occurs in CdiQueryInvocationContext.java#countCheck(Object, 
> Property)
> Because for this generated select is using the class name instead of entity 
> name.
> See PR
> https://github.com/apache/deltaspike/pull/137



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


[jira] [Resolved] (DELTASPIKE-1467) Saving existing entity throws an exception

2024-01-09 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1467.
---
Resolution: Fixed

> Saving existing entity throws an exception
> --
>
> Key: DELTASPIKE-1467
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1467
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Data-Module
>Affects Versions: 1.9.6
>Reporter: Stonewoodman
>Priority: Major
> Fix For: 2.0
>
>
> {code:java}
> @Entity(name = "Foo")
> @Table(name = "foo")
> public class FooEntity implements Serializable
> {
>     @Id
> @GeneratedValue(strategy = GenerationType.IDENTITY)
> private Long id;
> ...
> }{code}
> {code:java}
> @Transactional 
> @Repository(forEntity = FooEntity.class) 
> public abstract class FooRepository extends 
> AbstractEntityRepository
> {
> ...
> }
> {code}
> Loading an entity in JSF
> Edit and save it.
> It generates following exception
> Caused by: javax.transaction.RollbackException: Transaction is marked for 
> rollback
> The origin error occurs in CdiQueryInvocationContext.java#countCheck(Object, 
> Property)
> Because for this generated select is using the class name instead of entity 
> name.
> See PR
> https://github.com/apache/deltaspike/pull/137



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


Re: JTA / CMT vs BM Tx Stragy changes

2023-10-10 Thread Thomas Andraschko
What change do you mean exactly?


Am Di., 10. Okt. 2023 um 08:36 Uhr schrieb Thomas Frühbeck <
t.fruehb...@gmail.com>:

> Hi,
> since March 2023 changes in the JPA TxStrategy have been made, so now my
> properties-based CMT logic doesn't work anymore.
> Can you please give some hints how it is meant to be done in future?
> Thanks,
> Thomas
>


[jira] [Closed] (DELTASPIKE-740) Data module causes arquillian-weld-ee-embedded to fail when persistence.xml is present

2023-10-09 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-740.

Resolution: Incomplete

no feedback since years

> Data module causes arquillian-weld-ee-embedded to fail when persistence.xml 
> is present
> --
>
> Key: DELTASPIKE-740
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-740
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.0.3
> Environment: arquillian:1.0.3.Final
> org.jboss.arquillian.container:arquillian-weld-ee-embedded-1.1:1.0.0.CR8
>Reporter: Ove Ranheim
>Assignee: Thomas Hug
>Priority: Major
>
> When persistence.xml is added to shrinkwrap using weld-ee container the Data 
> module fails to load and the test case crashes. 
> {code}
> @Deployment
> public static WebArchive createDeployment() {
> return ShrinkWrap.create(WebArchive.class, "test.war")
> .addAsLibraries(ShrinkWrapArchiveUtil.getArchives(null, 
> "META-INF/beans.xml", new String[]{
> "org.apache.deltaspike.core",
> "org.apache.deltaspike.descriptor.category"
> }, null, null))
> .addPackage(MyRepository.class.getPackage())
> .addClass(TestEntity.class)
> .addAsResource("META-INF/persistence.xml")
> .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml")
> ;
> }
> {code}
> {code}
> INFO: class: org.apache.deltaspike.data.impl.RepositoryExtension 
> activated=true
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: -123,542.439 
> sec <<< FAILURE! - in org.jboss.weld.WeldTransactionServicesTest
> org.jboss.weld.WeldTransactionServicesTest  Time elapsed: -123,542.44 sec  
> <<< ERROR!
> org.jboss.weld.exceptions.DefinitionException: Exception List with 1 
> exceptions:
> Exception 0 :
> java.lang.IllegalArgumentException: URL does not exist: 
> archive:test.war/WEB-INF/classes/META-INF/persistence.xml
>   at 
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
>   at 
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
>   at 
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
>   at 
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
>   at 
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
>   at 
> org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:74)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
>   at 
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
>   at 
> org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
>   at 
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
>   at 
> org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
>   at 
> org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:174)
>   at 
> org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:133)
>   at 
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:107)
>   at 
> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54)
>   at 
> org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
>   at 
> org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:45)
>   at 
> org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:385)
>   at 
> org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
>   at 
> org.jboss.arq

[jira] [Closed] (DELTASPIKE-1450) Facing issue after Seam3 to deltaspike migration

2023-10-09 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1450.
-
Resolution: Incomplete

i will close this for now
if you can post a reproducer, we can have a look

> Facing issue after Seam3 to deltaspike migration
> 
>
> Key: DELTASPIKE-1450
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1450
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 1.9.5
> Environment: dev
>Reporter: Narayan Datt Rai
>Priority: Major
> Attachments: seam3ToDeltaspikeMigrationError.log
>
>
> Hi Team,
>  
> We have recently migrated sema3 to deltaspike.
>  
> Soler, JSF, CDI Weld were used in while seam3 was there. Now with deltaspike, 
> we are not able to trigger the java code from index.xhtml, which was working 
> before deltraspike.
>  
> Below is the error seen while accessing the xhtml page.
>  
>  
> Error Rendering View[/login.xhtml]
> [exec] 44030: FND-Bhanu: Mar 25 2022 06:29:28.527 +: 
> %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default 
> task-14][part=44029.2/78]: javax.el.ELException: /login.xhtml: The class 
> 'com.cisco.cgms.webapp.aaa.CgmsUser' does not have the property 
> 'restoreMessages'.
> [exec] 44031: FND-Bhanu: Mar 25 2022 06:29:28.527 +: 
> %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default 
> task-14][part=44029.3/78]: at 
> com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:47)
> [exec] 44032: FND-Bhanu: Mar 25 2022 06:29:28.527 +: 
> %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default 
> task-14][part=44029.4/78]: at 
> com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:41)
> [exec] 44033: FND-Bhanu: Mar 25 2022 06:29:28.527 +: 
> %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default 
> task-14][part=44029.5/78]: at 
> com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:169)
> [exec] 44034: FND-Bhanu: Mar 25 2022 06:29:28.527 +: 
> %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default 
> task-14][part=44029.6/78]: at 
> javax.faces.component.UIComponent.encodeAll(UIComponent.java:1650)
> [exec] 44035: FND-Bhanu: Mar 25 2022 06:29:28.527 +: 
> %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default 
> task-14][part=44029.7/78]: at 
> com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:468)
> [exec] 44036: FND-Bhanu: Mar 25 2022 06:29:28.527 +: 
> %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default 
> task-14][part=44029.8/78]: at 
> com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:170)
> [exec] 44037: FND-Bhanu: Mar 25 2022 06:29:28.527 +: 
> %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default 
> task-14][part=44029.9/78]: at 
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:132)
>  
>  
> Log file is attached for further analysis.
>  
> Please help us to resolve this issue.
>  
> Thanks.



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


[jira] [Closed] (DELTASPIKE-1461) Cleanup Window/ViewAcessScoped

2023-10-09 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1461.
-
Resolution: Fixed

i will close this for now
i didnt remove WindowContext/Scoped for now

> Cleanup Window/ViewAcessScoped
> --
>
> Key: DELTASPIKE-1461
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1461
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>    Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 2.0
>
>
> Currently ViewAcessScoped and WindowScoped is in DS Core
> since Faces 4.0, we could just remove WindowScoped and change all occurances 
> to Faces ClientWindowScoped
> this would require to move ViewAcessScoped to the faces module
> IMO we should do this for a cleanup, i dont think ANYONE will ever use 
> ViewAcessScoped outside of Faces.
> WDYT [~struberg] [~gpetracek]?



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


[jira] [Resolved] (DELTASPIKE-1434) Namespace change javax to jakarta

2023-10-09 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1434.
---
Resolution: Fixed

basically done

> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems 
> to be required to use deltaspike in the future. 
> https://jakarta.ee/compatibility/



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


[jira] [Updated] (DELTASPIKE-1434) Namespace change javax to jakarta

2023-10-09 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko updated DELTASPIKE-1434:
--
Fix Version/s: 2.0

> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems 
> to be required to use deltaspike in the future. 
> https://jakarta.ee/compatibility/



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


[jira] [Closed] (DELTASPIKE-1381) Method Expressions not validated at deployment time

2023-10-09 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1381.
-
Resolution: Incomplete

> Method Expressions not validated at deployment time
> ---
>
> Key: DELTASPIKE-1381
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1381
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.9.0
> Environment: JDK 8
> Postgres 10
> Hibernate 5.3.6
> WildFly 13.0.0
>Reporter: Ehsan Zaery Moghaddam
>Priority: Minor
>
> In the documentation it's explicitly mentioned that method expressions are 
> validated upon deployment to see if there is any typo in them: 
> *_Note that DeltaSpike will validate those expressions during startup, so you 
> will notice early in case you have a typo in those expressions_*.
>  
> But seems this validation doesn't happen during deployment and the code fails 
> when the given method is being called. In the following example, the 
> "LessThan" comparator is misspelled and the stack trace of the runtime error 
> is as below:
>  
> *Caused by: org.apache.deltaspike.data.api.QueryInvocationException: Failed 
> calling Repository: 
> [Repository=com.one.paymentgateway.persistence.repository.PendingCaptureRepository,entity=com.one.paymentgateway.persistence.entity.PendingCaptureEntity,method=findAnyByPendingTimeLesThanEqualsOrderByPendingTime,*
>  at 
> org.apache.deltaspike.data.impl.builder.DelegateQueryBuilder.execute(DelegateQueryBuilder.java:83)
>  at 
> org.apache.deltaspike.data.impl.builder.QueryBuilder.executeQuery(QueryBuilder.java:57)
>  at 
> org.apache.deltaspike.data.impl.builder.DelegateQueryBuilder$Proxy$_$$_WeldClientProxy.executeQuery(Unknown
>  Source)
>  at 
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeNonTransactional(TransactionalQueryRunner.java:62)
>  at 
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeQuery(TransactionalQueryRunner.java:57)
>  at 
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner$Proxy$_$$_WeldClientProxy.executeQuery(Unknown
>  Source)
>  at 
> org.apache.deltaspike.data.impl.handler.QueryHandler.process(QueryHandler.java:151)
>  ... 161 more



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


[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta

2023-04-24 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715722#comment-17715722
 ] 

Thomas Andraschko commented on DELTASPIKE-1434:
---

100% of the still active commiters maintains multiple Java/JakartaEE projects 
on apache here, DeltaSpike is just that with the lowest prio for us.
We first try to get all other libs running again, so we have "our" application 
server (TomEE) before we can even use DeltaSpike again. Its not an easy task to 
migrate like 15 libs from javax to jakarta.

We need at least some tests running on real containers, everyone can help here 
migrating the tests.





> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems 
> to be required to use deltaspike in the future. 
> https://jakarta.ee/compatibility/



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


[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta

2023-04-21 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714994#comment-17714994
 ] 

Thomas Andraschko commented on DELTASPIKE-1434:
---

our integrationtests are built to run on different javax containers in 1.x
noone tried to migrate those to jakarta containers yet, even not sure if 
arquillian is ready etc.

> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems 
> to be required to use deltaspike in the future. 
> https://jakarta.ee/compatibility/



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


[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta

2023-04-21 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714964#comment-17714964
 ] 

Thomas Andraschko commented on DELTASPIKE-1434:
---

i migrated most of the modules to jakarta last month but we still dont have 
running integration tests
if you have time to get all tests running on recent containers, i can help on 
fixing the tests.

> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems 
> to be required to use deltaspike in the future. 
> https://jakarta.ee/compatibility/



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


[jira] [Closed] (DELTASPIKE-1462) Rename jsf to faces and jpa to persistence

2023-04-07 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1462.
-
Fix Version/s: (was: 2.0)
   Resolution: Won't Fix

> Rename jsf to faces and jpa to persistence
> --
>
> Key: DELTASPIKE-1462
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1462
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>    Reporter: Thomas Andraschko
>Priority: Major
>




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


[jira] [Closed] (DELTASPIKE-1234) DS 2: check if we can remove our proxy module

2023-04-07 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1234.
-
Fix Version/s: (was: 2.0)
   Resolution: Won't Fix

> DS 2: check if we can remove our proxy module
> -
>
> Key: DELTASPIKE-1234
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1234
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Proxy-Module
>Affects Versions: 2.0
>    Reporter: Thomas Andraschko
>    Assignee: Thomas Andraschko
>Priority: Major
>
> in favor of the InterceptionFactory
> This will likely not work because we also support abstract classes



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


Re: Jakarta EE / DeltaSpike 2.0 Status

2023-04-04 Thread Thomas Andraschko
I think the most features and modules are just working fine - normal tests
are running.
Just container testing may find weird bugs.
So its not about the effort of "reimplementing features" vs "dropping
features", its all already there.

Am Di., 4. Apr. 2023 um 10:44 Uhr schrieb Romain Manni-Bucau <
rmannibu...@gmail.com>:

> Le mar. 4 avr. 2023 à 10:22, Thomas Andraschko <
> andraschko.tho...@gmail.com>
> a écrit :
>
> > In theory we could remove TX (if all cases are handled by JTA) and move
> the
> > EntityManagerResolver + JPA descriptor parsing to Data itself.
> >
> > In general i think our goal should be to port the DS features, if still
> not
> > existing in EE10, to EE10. Not to remove everything not widely used.
> > This allows users to migrate to EE10 with some adjustments.
> >
>
> This assumes it is used but this is really unsure, stats we have (central)
> are really about CI zone and major is our best chance to drop what is not
> needed to focus our effort on what is actually used.
> Indeed not a blocker but my 2cts would be to drop what we can to
> potentially add it back if we get a lot of demand rather than the opposite
> which means we'll keep dragging things to maintain almost nobody needs.
>
>
> >
> >
> > Am Di., 4. Apr. 2023 um 10:06 Uhr schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com>:
> >
> > > Hi,
> > >
> > > Do we have some visibility about the usage?
> > > Think jpa/tx feature tend to disappear in new applications because JTA
> > got
> > > it (we like or not the design is another thing but feature is there
> > > built-in now comared to when DS was created).
> > > So for a new major we can aim at dropping it - keeping in 1.x.
> > > About data module I guess the adoption is not that high even if module
> is
> > > really "cool" - guess we miss the jaxrs bridge but we never got any
> > request
> > > about it - so not sure its future.
> > > It can likely be the same for almost all core module which is now
> almost
> > > standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> > > things without added value in time for a new major).
> > >
> > > So overall I wouldnt aim at renaming but more pruning what is built in
> or
> > > will be soon and make DS lighter now resources are very low and the
> need
> > of
> > > the project really less important than years ago.
> > >
> > > Hope it makes sense.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> > > andraschko.tho...@gmail.com>
> > > a écrit :
> > >
> > > > JPA is also about reading the JPA XML descriptors and resolving
> > > > EntityManagers, which is both heavily used in the Data module.
> > > > So its currently much more than TX. I would rename it to
> ds-persistence
> > > and
> > > > ds-faces.
> > > >
> > > > Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> > > > gpetra...@apache.org>:
> > > >
> > > > > hi thomas,
> > > > >
> > > > > we need to fix the rat-check (see [1]).
> > > > >
> > > > > @renaming the modules:
> > > > > the jpa-module was always mainly about the "entitymanager" +
> > > > > "transaction" (see the package-naming)... with the main focus on
> > > > > transactions (see @Transactional and @TransactionScoped as the main
> > > > > api).
> > > > > therefore we almost renamed it to ds-tx (in the beginning). we just
> > > > > kept 'jpa', because it wasn't clear what we might add later on.
> > > > > maybe we should just start a community-poll about it.
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > > [1]
> > > > >
> > >
> https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> > > > >
> > > > >
> > > > >
> > > > > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > > > > :
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > last week i had some time and migrated almost all still existing
> > > > modules
> > > > > to
> > > > > > Jakarta. Only scheduler is currently not migrated.
> > > > > > AFAICS servlet, bean-validation has been removed, also other
> small
> > > > pieces
> > > > > > of core.
> > > > > >
> > > > > > I would also like to rename jpa and jsf to their new jakarta name
> > > > > > (persistence and faces).
> > > > > > WDYT guys?
> > > > > >
> > > > > > After that rename and reintroduce the scheduler module, i would
> be
> > > > happy
> > > > > > enough to release a RC1.
> > > > > >
> > > > > > AFAICS a big missing part are the tests on real containers?!
> > > > > > Any other topics we need to address?
> > > > > >
> > > > > > Best regards,
> > > > > > Thomas
> > > > >
> > > >
> > >
> >
>


Re: Jakarta EE / DeltaSpike 2.0 Status

2023-04-04 Thread Thomas Andraschko
In theory we could remove TX (if all cases are handled by JTA) and move the
EntityManagerResolver + JPA descriptor parsing to Data itself.

In general i think our goal should be to port the DS features, if still not
existing in EE10, to EE10. Not to remove everything not widely used.
This allows users to migrate to EE10 with some adjustments.


Am Di., 4. Apr. 2023 um 10:06 Uhr schrieb Romain Manni-Bucau <
rmannibu...@gmail.com>:

> Hi,
>
> Do we have some visibility about the usage?
> Think jpa/tx feature tend to disappear in new applications because JTA got
> it (we like or not the design is another thing but feature is there
> built-in now comared to when DS was created).
> So for a new major we can aim at dropping it - keeping in 1.x.
> About data module I guess the adoption is not that high even if module is
> really "cool" - guess we miss the jaxrs bridge but we never got any request
> about it - so not sure its future.
> It can likely be the same for almost all core module which is now almost
> standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> things without added value in time for a new major).
>
> So overall I wouldnt aim at renaming but more pruning what is built in or
> will be soon and make DS lighter now resources are very low and the need of
> the project really less important than years ago.
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> andraschko.tho...@gmail.com>
> a écrit :
>
> > JPA is also about reading the JPA XML descriptors and resolving
> > EntityManagers, which is both heavily used in the Data module.
> > So its currently much more than TX. I would rename it to ds-persistence
> and
> > ds-faces.
> >
> > Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> > gpetra...@apache.org>:
> >
> > > hi thomas,
> > >
> > > we need to fix the rat-check (see [1]).
> > >
> > > @renaming the modules:
> > > the jpa-module was always mainly about the "entitymanager" +
> > > "transaction" (see the package-naming)... with the main focus on
> > > transactions (see @Transactional and @TransactionScoped as the main
> > > api).
> > > therefore we almost renamed it to ds-tx (in the beginning). we just
> > > kept 'jpa', because it wasn't clear what we might add later on.
> > > maybe we should just start a community-poll about it.
> > >
> > > regards,
> > > gerhard
> > >
> > > [1]
> > >
> https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> > >
> > >
> > >
> > > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > > :
> > > >
> > > > Hi,
> > > >
> > > > last week i had some time and migrated almost all still existing
> > modules
> > > to
> > > > Jakarta. Only scheduler is currently not migrated.
> > > > AFAICS servlet, bean-validation has been removed, also other small
> > pieces
> > > > of core.
> > > >
> > > > I would also like to rename jpa and jsf to their new jakarta name
> > > > (persistence and faces).
> > > > WDYT guys?
> > > >
> > > > After that rename and reintroduce the scheduler module, i would be
> > happy
> > > > enough to release a RC1.
> > > >
> > > > AFAICS a big missing part are the tests on real containers?!
> > > > Any other topics we need to address?
> > > >
> > > > Best regards,
> > > > Thomas
> > >
> >
>


Re: Jakarta EE / DeltaSpike 2.0 Status

2023-04-04 Thread Thomas Andraschko
JPA is also about reading the JPA XML descriptors and resolving
EntityManagers, which is both heavily used in the Data module.
So its currently much more than TX. I would rename it to ds-persistence and
ds-faces.

Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
gpetra...@apache.org>:

> hi thomas,
>
> we need to fix the rat-check (see [1]).
>
> @renaming the modules:
> the jpa-module was always mainly about the "entitymanager" +
> "transaction" (see the package-naming)... with the main focus on
> transactions (see @Transactional and @TransactionScoped as the main
> api).
> therefore we almost renamed it to ds-tx (in the beginning). we just
> kept 'jpa', because it wasn't clear what we might add later on.
> maybe we should just start a community-poll about it.
>
> regards,
> gerhard
>
> [1]
> https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
>
>
>
> Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> :
> >
> > Hi,
> >
> > last week i had some time and migrated almost all still existing modules
> to
> > Jakarta. Only scheduler is currently not migrated.
> > AFAICS servlet, bean-validation has been removed, also other small pieces
> > of core.
> >
> > I would also like to rename jpa and jsf to their new jakarta name
> > (persistence and faces).
> > WDYT guys?
> >
> > After that rename and reintroduce the scheduler module, i would be happy
> > enough to release a RC1.
> >
> > AFAICS a big missing part are the tests on real containers?!
> > Any other topics we need to address?
> >
> > Best regards,
> > Thomas
>


Jakarta EE / DeltaSpike 2.0 Status

2023-04-03 Thread Thomas Andraschko
Hi,

last week i had some time and migrated almost all still existing modules to
Jakarta. Only scheduler is currently not migrated.
AFAICS servlet, bean-validation has been removed, also other small pieces
of core.

I would also like to rename jpa and jsf to their new jakarta name
(persistence and faces).
WDYT guys?

After that rename and reintroduce the scheduler module, i would be happy
enough to release a RC1.

AFAICS a big missing part are the tests on real containers?!
Any other topics we need to address?

Best regards,
Thomas


[jira] [Closed] (DELTASPIKE-1282) DeltaSpikeFacesContextWrapper leaks on TomEE

2023-03-31 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1282.
-
Fix Version/s: (was: 2.0)
   Resolution: Cannot Reproduce

> DeltaSpikeFacesContextWrapper leaks on TomEE
> 
>
> Key: DELTASPIKE-1282
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1282
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JSF-Module
>Affects Versions: 1.8.0
>    Reporter: Thomas Andraschko
>    Assignee: Thomas Andraschko
>Priority: Major
>




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


[jira] [Commented] (DELTASPIKE-1443) deltaspike-cdictrl-weld depends on junit

2023-03-31 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707208#comment-17707208
 ] 

Thomas Andraschko commented on DELTASPIKE-1443:
---

mvn dependency:tree outputs

[INFO] +- junit:junit:jar:4.13.2:test

in trunk

> deltaspike-cdictrl-weld depends on junit
> 
>
> Key: DELTASPIKE-1443
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1443
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 1.9.5
>Reporter: Björn Kautler
>Priority: Major
>
> deltaspike-cdictrl-weld (and probably all modules as it is defined in parent) 
> depends on junit.
> We use deltaspike-cdictrl-weld in production, so this dependency leaks junit 
> into the runtime classpath.
> It should probably only be in test scope.



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


[jira] [Closed] (DELTASPIKE-1443) deltaspike-cdictrl-weld depends on junit

2023-03-31 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1443.
-
Resolution: Cannot Reproduce

> deltaspike-cdictrl-weld depends on junit
> 
>
> Key: DELTASPIKE-1443
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1443
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 1.9.5
>Reporter: Björn Kautler
>Priority: Major
>
> deltaspike-cdictrl-weld (and probably all modules as it is defined in parent) 
> depends on junit.
> We use deltaspike-cdictrl-weld in production, so this dependency leaks junit 
> into the runtime classpath.
> It should probably only be in test scope.



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


[jira] [Resolved] (DELTASPIKE-1435) dsrwid cookie should not be set to sameSite="None" - again

2023-03-31 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1435.
---
Resolution: Fixed

> dsrwid cookie should not be set to sameSite="None" - again
> --
>
> Key: DELTASPIKE-1435
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1435
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 1.9.5
>Reporter: Juri Berlanda
>Priority: Major
> Fix For: 2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Very similar to DELTASPIKE-1413, this refers to the missing {{SameSite}} 
> attribute in {{windowhandler.js}} 
> (https://github.com/apache/deltaspike/blob/deltaspike-1.9.5/deltaspike/modules/jsf/impl/src/main/resources/META-INF/resources/deltaspike/windowhandler.js#L619)
> This means, that the following warning still appears in Firefox (tested on 
> 90.0.2):
> {quote}Cookie “dsrwid-326” will be soon rejected because it has the 
> “SameSite” attribute set to “None” or an invalid value, without the “secure” 
> attribute. To know more about the “SameSite“ attribute, read 
> https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite 
> windowhandler.js.xhtml:17:364{quote}
> Now, I'd propose to set the cookie to {{SameSite=Strict}} here, too. PR is in 
> the works.



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


[jira] [Closed] (DELTASPIKE-1428) Empty resolvedComponents not cached in InjectionResolver

2023-03-31 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1428.
-
Resolution: Won't Fix

we removed the injection wrapping in favor of native JSF 2.3+ injection feature

> Empty resolvedComponents not cached in InjectionResolver
> 
>
> Key: DELTASPIKE-1428
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1428
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: Vladimir Dvorak
>Priority: Minor
>
> Issue was reported originally repoted as an OWB problem:
> https://issues.apache.org/jira/browse/OWB-1381
> but was shown the problem is in DS, reproducible example is at:
> [https://github.com/skybber/pf-expensive-converter|http://example.com/]



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


[jira] [Assigned] (DELTASPIKE-1323) upgrade maven-bundle-plugin to more recent version

2023-03-31 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko reassigned DELTASPIKE-1323:
-

Assignee: Mark Struberg

> upgrade maven-bundle-plugin to more recent version
> --
>
> Key: DELTASPIKE-1323
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1323
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Build
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
>
> we currently use a very old OSGi bundle plugin version which doesn't work 
> with Java8 constructs.
>  
> I've tried to update to any more recent version but failed. My OSGi mojo is 
> not strong enough.
> maven-bundle-plugin 2.5.0 complains about wrong imports and any more recent 
> version (e.g. 3.5.0) totally breaks the compilation.
>  
> The only workaround I found so far is to switch from 'bundle' to 'jar' 
> packaging.
>  
> Would be great if someone with OSGi knowledge could take a look at it.



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


[jira] [Assigned] (DELTASPIKE-1406) Usage of "SHA-256" and "AES" is insecure

2023-03-31 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko reassigned DELTASPIKE-1406:
-

Assignee: Mark Struberg

> Usage of "SHA-256" and "AES" is insecure
> 
>
> Key: DELTASPIKE-1406
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1406
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Reporter: Md Mahir Asef Kabir
>Assignee: Mark Struberg
>Priority: Major
>
> *Vulnerability Description:* In 
> “deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/crypto/DefaultCipherService.java”,
>  the following algorithms were set to use later - 
> {code:java}
> private static final String HASH_ALGORITHM = "SHA-256";
> private static final String CIPHER_ALGORITHM = "AES";
> {code}
> Here, SHA-256 and AES are vulnerable.
> *Reason it’s vulnerable:* According to 
> [this|https://soylentnews.org/article.pl?sid=19/09/10/2351241], SHA256 can be 
> broken.
> ”AES” is also not secure. For further reference, please follow 
> [this|https://zachgrace.com/posts/attacking-ecb/]
> *Suggested Fix:* The secure algorithms to set would be -
> {code:java}
> private static final String HASH_ALGORITHM = "SHA-512";
> private static final String CIPHER_ALGORITHM = "AES/CFB/PKCS5Padding";
> {code}
> *Feedback:* Please select any of the options down below to help us get an 
> idea about how you felt about the suggestion - 
> # Liked it and will make the suggested changes
> # Liked it but happy with the existing version
> # Didn’t find the suggestion helpful



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


[jira] [Updated] (DELTASPIKE-1435) dsrwid cookie should not be set to sameSite="None" - again

2023-03-31 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko updated DELTASPIKE-1435:
--
Fix Version/s: 2.0

> dsrwid cookie should not be set to sameSite="None" - again
> --
>
> Key: DELTASPIKE-1435
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1435
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 1.9.5
>Reporter: Juri Berlanda
>Priority: Major
> Fix For: 2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Very similar to DELTASPIKE-1413, this refers to the missing {{SameSite}} 
> attribute in {{windowhandler.js}} 
> (https://github.com/apache/deltaspike/blob/deltaspike-1.9.5/deltaspike/modules/jsf/impl/src/main/resources/META-INF/resources/deltaspike/windowhandler.js#L619)
> This means, that the following warning still appears in Firefox (tested on 
> 90.0.2):
> {quote}Cookie “dsrwid-326” will be soon rejected because it has the 
> “SameSite” attribute set to “None” or an invalid value, without the “secure” 
> attribute. To know more about the “SameSite“ attribute, read 
> https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite 
> windowhandler.js.xhtml:17:364{quote}
> Now, I'd propose to set the cookie to {{SameSite=Strict}} here, too. PR is in 
> the works.



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


[jira] [Resolved] (DELTASPIKE-1464) Use jfwid over dswid

2023-03-31 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1464.
---
Resolution: Fixed

> Use jfwid over dswid
> 
>
> Key: DELTASPIKE-1464
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1464
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>    Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 2.0
>
>




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


[jira] [Created] (DELTASPIKE-1464) Use jfwid over dswid

2023-03-30 Thread Thomas Andraschko (Jira)
Thomas Andraschko created DELTASPIKE-1464:
-

 Summary: Use jfwid over dswid
 Key: DELTASPIKE-1464
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1464
 Project: DeltaSpike
  Issue Type: Improvement
  Security Level: public (Regular issues)
Reporter: Thomas Andraschko
 Fix For: 2.0






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


[jira] [Resolved] (DELTASPIKE-1463) Reimplement DS ClientWindow as native Faces ClientWindow

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1463.
---
Resolution: Fixed

> Reimplement DS ClientWindow as native Faces ClientWindow
> 
>
> Key: DELTASPIKE-1463
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1463
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>    Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 2.0
>
>
> then we can also remove the ds:disableClientWindow component
> JSF components already have a built-it disableClientWindow attr on components



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


[jira] [Assigned] (DELTASPIKE-1264) Remove portions of BeanProvider/BeanManagerProvider

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko reassigned DELTASPIKE-1264:
-

Assignee: Mark Struberg

> Remove portions of BeanProvider/BeanManagerProvider
> ---
>
> Key: DELTASPIKE-1264
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1264
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0
>
>
> These internal utilities may not be needed based on CDI.current() from CDI 
> 1.1.



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


[jira] [Resolved] (DELTASPIKE-1263) Remove BeanBuilder

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1263.
---
Resolution: Fixed

> Remove BeanBuilder
> --
>
> Key: DELTASPIKE-1263
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1263
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Priority: Major
> Fix For: 2.0
>
>
> CDI 2.0 introduces bean configurators, which handle the use cases of 
> BeanBuilder.



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


[jira] [Updated] (DELTASPIKE-1463) Reimplement DS ClientWindow as native Faces ClientWindow

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko updated DELTASPIKE-1463:
--
Description: 
then we can also remove the ds:disableClientWindow component
JSF components already have a built-it disableClientWindow attr on components

> Reimplement DS ClientWindow as native Faces ClientWindow
> 
>
> Key: DELTASPIKE-1463
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1463
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>    Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 2.0
>
>
> then we can also remove the ds:disableClientWindow component
> JSF components already have a built-it disableClientWindow attr on components



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


[jira] [Resolved] (DELTASPIKE-1265) Align JSF module to features provided by JSF 2.3

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1265.
---
Resolution: Fixed

> Align JSF module to features provided by JSF 2.3
> 
>
> Key: DELTASPIKE-1265
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1265
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Priority: Major
> Fix For: 2.0
>
>
> The JSF module provides a lot of functionality that overlaps with JSF 2.1/2.2 
> features.  We should review this content and see what can be removed vs what 
> is provided OOTB.
>  * JSF module (e.g. remove all the reflection hacks for ClientWindow)



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


[jira] [Created] (DELTASPIKE-1463) Reimplement DS ClientWindow as native Faces ClientWindow

2023-03-30 Thread Thomas Andraschko (Jira)
Thomas Andraschko created DELTASPIKE-1463:
-

 Summary: Reimplement DS ClientWindow as native Faces ClientWindow
 Key: DELTASPIKE-1463
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1463
 Project: DeltaSpike
  Issue Type: Improvement
  Security Level: public (Regular issues)
Reporter: Thomas Andraschko
 Fix For: 2.0






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


[jira] [Created] (DELTASPIKE-1462) Rename jsf to faces and jpa to persistence

2023-03-30 Thread Thomas Andraschko (Jira)
Thomas Andraschko created DELTASPIKE-1462:
-

 Summary: Rename jsf to faces and jpa to persistence
 Key: DELTASPIKE-1462
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1462
 Project: DeltaSpike
  Issue Type: Improvement
  Security Level: public (Regular issues)
Reporter: Thomas Andraschko
 Fix For: 2.0






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


[jira] [Created] (DELTASPIKE-1461) Cleanup Window/ViewAcessScoped

2023-03-30 Thread Thomas Andraschko (Jira)
Thomas Andraschko created DELTASPIKE-1461:
-

 Summary: Cleanup Window/ViewAcessScoped
 Key: DELTASPIKE-1461
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1461
 Project: DeltaSpike
  Issue Type: Improvement
  Security Level: public (Regular issues)
Reporter: Thomas Andraschko
 Fix For: 2.0


Currently ViewAcessScoped and WindowScoped is in DS Core

since Faces 4.0, we could just remove WindowScoped and change all occurances to 
Faces ClientWindowScoped

this would require to move ViewAcessScoped to the faces module

IMO we should do this for a cleanup, i dont think ANYONE will ever use 
ViewAcessScoped outside of Faces.


WDYT [~struberg] [~gpetracek]?



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


[jira] [Resolved] (DELTASPIKE-1266) Remove != JavaEE8 workarounds

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1266.
---
Resolution: Fixed

> Remove != JavaEE8 workarounds
> -
>
> Key: DELTASPIKE-1266
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1266
> Project: DeltaSpike
>  Issue Type: Improvement
>    Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 2.0
>
>
> * EntityGraphHelper
>  * remove OWB 1.1.x workarounds in proxy module



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


[jira] [Updated] (DELTASPIKE-1265) Align JSF module to features provided by JSF 2.3

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko updated DELTASPIKE-1265:
--
Description: 
The JSF module provides a lot of functionality that overlaps with JSF 2.1/2.2 
features.  We should review this content and see what can be removed vs what is 
provided OOTB.


 * JSF module (e.g. remove all the reflection hacks for ClientWindow)


  was:The JSF module provides a lot of functionality that overlaps with JSF 
2.1/2.2 features.  We should review this content and see what can be removed vs 
what is provided OOTB.


> Align JSF module to features provided by JSF 2.3
> 
>
> Key: DELTASPIKE-1265
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1265
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Priority: Major
> Fix For: 2.0
>
>
> The JSF module provides a lot of functionality that overlaps with JSF 2.1/2.2 
> features.  We should review this content and see what can be removed vs what 
> is provided OOTB.
>  * JSF module (e.g. remove all the reflection hacks for ClientWindow)



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


[jira] [Updated] (DELTASPIKE-1266) Remove != JavaEE8 workarounds

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko updated DELTASPIKE-1266:
--
Description: 
* EntityGraphHelper
 * remove OWB 1.1.x workarounds in proxy module

  was:
* EntityGraphHelper
 * JSF module (e.g. remove all the reflection hacks for ClientWindow)
 * remove OWB 1.1.x workarounds in proxy module


> Remove != JavaEE8 workarounds
> -
>
> Key: DELTASPIKE-1266
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1266
> Project: DeltaSpike
>  Issue Type: Improvement
>    Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 2.0
>
>
> * EntityGraphHelper
>  * remove OWB 1.1.x workarounds in proxy module



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


[jira] [Resolved] (DELTASPIKE-1261) Remove BeanVal Module

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1261.
---
Resolution: Fixed

> Remove BeanVal Module
> -
>
> Key: DELTASPIKE-1261
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1261
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Priority: Major
> Fix For: 2.0
>
>
> The Bean Validation module is fully supposed by Java EE 7+ and can be removed.



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


[jira] [Resolved] (DELTASPIKE-1260) Remove Servlet Module

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1260.
---
Resolution: Fixed

> Remove Servlet Module
> -
>
> Key: DELTASPIKE-1260
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1260
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Priority: Major
> Fix For: 2.0
>
>
> The Servlet module is fully supported by features of Java EE 7+, and is no 
> longer useful.



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


[jira] [Closed] (DELTASPIKE-1459) Please release master so jakarta namespace will work

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1459.
-
Resolution: Duplicate

> Please release master so jakarta namespace will work
> 
>
> Key: DELTASPIKE-1459
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1459
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Build
>Affects Versions: 1.9.6
>Reporter: Jeremy Landis
>Priority: Major
>
> The released jakarta was overly aggressive changing javax to jakarta that do 
> not exist.  This was fixed on master.  The repo has no zero activity since 
> July.  Please release this.  Its impossible to use this with jakarta right 
> now which is a high blocker.
>  
> Would also be nice to use some 'bom's - one for legacy and one for jakarta.  
> The method used to make this jakarta is a mad mess.  We have to add 
> exclusions to nearly everything to get non jakarta components to go away.  
> This is a separate issue but worth pointing out just how incredibly difficult 
> this is to use.



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


[jira] [Commented] (DELTASPIKE-1459) Please release master so jakarta namespace will work

2023-03-30 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17706829#comment-17706829
 ] 

Thomas Andraschko commented on DELTASPIKE-1459:
---

duplicate of DELTASPIKE-1434

> Please release master so jakarta namespace will work
> 
>
> Key: DELTASPIKE-1459
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1459
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Build
>Affects Versions: 1.9.6
>Reporter: Jeremy Landis
>Priority: Major
>
> The released jakarta was overly aggressive changing javax to jakarta that do 
> not exist.  This was fixed on master.  The repo has no zero activity since 
> July.  Please release this.  Its impossible to use this with jakarta right 
> now which is a high blocker.
>  
> Would also be nice to use some 'bom's - one for legacy and one for jakarta.  
> The method used to make this jakarta is a mad mess.  We have to add 
> exclusions to nearly everything to get non jakarta components to go away.  
> This is a separate issue but worth pointing out just how incredibly difficult 
> this is to use.



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


[jira] [Updated] (DELTASPIKE-1460) Move outdated APIs

2023-03-30 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko updated DELTASPIKE-1460:
--
Fix Version/s: 2.0

> Move outdated APIs
> --
>
> Key: DELTASPIKE-1460
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1460
> Project: DeltaSpike
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 2.0
>
>
> some parts of the api aren't needed with cdi 2.0+
> therefore that parts should be moved until they get removed completely.



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


Re: [VOTE] Release Apache DeltaSpike-1.9.6

2022-04-08 Thread Thomas Andraschko
+1

John D. Ament  schrieb am Fr., 8. Apr. 2022, 21:30:

> +1
>
> On Fri, Apr 8, 2022 at 12:27 Mark Struberg 
> wrote:
>
> > Hi lords and ladies!
> >
> > I'd like to call a VOTE on releasing Apache DeltaSpike-1.9.6
> >
> > The following tickets got resolved:
> >
> >
> > Bug
> > [DELTASPIKE-1133] - Don't override the log level
> > [DELTASPIKE-1427] - JUL Logging with {} as param leeds to
> > NumberFormatException
> > [DELTASPIKE-1433] - EntityManagerFactoryProducer should also provide
> a
> > @Disposes method
> > [DELTASPIKE-1453] - injecting config of Class got broken
> >
> > New Feature
> > [DELTASPIKE-1431] - add easy way to disable InvocationResultLogger
> > [DELTASPIKE-1444] - Create POJO and Record based Config
> > [DELTASPIKE-1445] - Dynamic Config injection via a Supplier
> >
> > Improvement
> > [DELTASPIKE-1426] - DeltaSpikeProxyFactory is slow on start
> > [DELTASPIKE-1432] - Proxy class definition does not work
> > [DELTASPIKE-1454] - Upgrade ASM to 9.3
> >
> > Task
> > [DELTASPIKE-1452] - upgrade to apache-parent 25
> >
> >
> >
> > The staging repository can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/
> > <
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/
> > >
> >
> > The source repo is located at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/org/apache/deltaspike/deltaspike/1.9.6/
> > <
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/org/apache/deltaspike/deltaspike/1.9.6/
> > >
> > sha512 is
> >
> ae2b2b183a54b9dff00d78a8f3a60fc87bde701599390a437970b218c208cb636d058fa596d0ab0ac3dfa9dd022c383c59f9ac6f5bab4e3bfe47db0a063af490
> >
> > Please VOTE
> >
> > [+1] yeah, ship it!
> > [+0] meh, don't care
> > [-1]  stop there is a ${showstopper}
> >
> > The VOTE is open for 72h.
> >
> > txs and LieGrue,
> > strub
> >
> >
> >
>


[jira] [Closed] (DELTASPIKE-1442) Support for Jakarta EE 9.

2021-11-12 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1442.
-
Resolution: Duplicate

duplicate of https://issues.apache.org/jira/browse/DELTASPIKE-1434

> Support for Jakarta EE 9.
> -
>
> Key: DELTASPIKE-1442
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1442
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Data-Module
>Affects Versions: 1.9.5
> Environment: JDK 17, Jakarta EE 9 (Glassfish 6)
>Reporter: Roman Müller
>Priority: Major
> Attachments: jakarta-deltaspike-data.zip, server.log
>
>
> Hello,
> I want to migrate a Java EE 7 project to Jakarta EE 9. It will eventually run 
> on Java 17 with Glassfish 6 and up. 
> The project fails compilation though where the compilation error does not 
> contain info at all.
> {quote}C:\Users\mueller-83\Development\Workspace\jakarta-deltaspike-data>mvn 
> clean install
> [INFO] Scanning for projects...
> [INFO]
> [INFO] --{-}< roman:jakarta-deltaspike-data 
> >{-}---
> [INFO] Building jakarta-deltaspike-data 1.0-SNAPSHOT
> [INFO] ---{-}[ war 
> ]{-}
> Downloading from central: 
> [https://repo.maven.apache.org/maven2/jakarta/platform/jakarta.jakartaee-api/9.1.0/jakarta.jakartaee-api-9.1.0.pom]
> Downloaded from central: 
> [https://repo.maven.apache.org/maven2/jakarta/platform/jakarta.jakartaee-api/9.1.0/jakarta.jakartaee-api-9.1.0.pom]
>  (0 B at 0 B/s)
> Downloading from central: 
> [https://repo.maven.apache.org/maven2/jakarta/platform/jakartaee-api-parent/9.1.0/jakartaee-api-parent-9.1.0.pom]
> Downloaded from central: 
> [https://repo.maven.apache.org/maven2/jakarta/platform/jakartaee-api-parent/9.1.0/jakartaee-api-parent-9.1.0.pom]
>  (0 B at 0 B/s)
> Downloading from central: 
> [https://repo.maven.apache.org/maven2/org/eclipse/ee4j/project/1.0.7/project-1.0.7.pom]
> Downloaded from central: 
> [https://repo.maven.apache.org/maven2/org/eclipse/ee4j/project/1.0.7/project-1.0.7.pom]
>  (0 B at 0 B/s)
> Downloading from central: 
> [https://repo.maven.apache.org/maven2/jakarta/platform/jakarta.jakartaee-api/9.1.0/jakarta.jakartaee-api-9.1.0.jar]
> Downloaded from central: 
> [https://repo.maven.apache.org/maven2/jakarta/platform/jakarta.jakartaee-api/9.1.0/jakarta.jakartaee-api-9.1.0.jar]
>  (0 B at 0 B/s)
> [INFO]
> [INFO] — maven-clean-plugin:2.5:clean (default-clean) @ 
> jakarta-deltaspike-data —
> [INFO]
> [INFO] — maven-toolchains-plugin:3.0.0:toolchain (default) @ 
> jakarta-deltaspike-data —
> [INFO] Required toolchain: jdk [ vendor='openjdk' version='1.17' ]
> [INFO] Found matching toolchain for type jdk: 
> JDK[C:/Users/mueller-83/Development/jdk-17.0.1_12]
> [INFO]
> [INFO] — maven-resources-plugin:2.6:resources (default-resources) @ 
> jakarta-deltaspike-data —
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ 
> jakarta-deltaspike-data —
> [INFO] Toolchain in compiler-plugin: 
> JDK[C:/Users/mueller-83/Development/jdk-17.0.1_12]
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to 
> C:\Users\mueller-83\Development\Workspace\jakarta-deltaspike-data\target\classes
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  7.305 s
> [INFO] Finished at: 2021-11-12T15:29:11+01:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) 
> on project jakarta-deltaspike-data: Compilation failure -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> [http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException]
> {quote}
> It compiles with Jakarta EE 8. But does not deploy to Glassfish 6 due to 
> changed package names. See also attached server.log file.
>  
> {quote}[2021-11-12T15:13:21.118+01

Re: some draft for DS-2.0

2021-09-25 Thread Thomas Andraschko
Mark, AFAICS you did it in a new main branch instead of master?
I would move master to 1.9.x branch and do 2.x in master

Why isnt it in GitHub?

Thomas Andraschko  schrieb am Do., 23. Sept.
2021, 21:33:

> +1 for making it master
>
> Mark Struberg  schrieb am Do., 23. Sept. 2021,
> 20:13:
>
>> hi!
>>
>> I've migrated a few things over to the jakarta namespace and started
>> dropping a few old features.
>> Right now it's just core which I got working, but will now also move over
>> module by module.
>>
>> The draft can be viewed here:
>> https://github.com/struberg/deltaspike/tree/fb_ds20 <
>> https://github.com/struberg/deltaspike/tree/fb_ds20>
>> What branch name do we want to give it finally? Take the chance to switch
>> to 'main' and somewhat later rename the master branch to mt_ds1.x?
>>
>> How did I proceed?
>> I did not yet delete anything. Pieces which I do not see as part of
>> DS-2.0 got moved to an 'obsolete' directory with the same structure. If we
>> figure that we do still want to keep some of the features, then we can
>> simply move those files back without loosing any history.
>>
>> Happ to get feedback!
>>
>> LieGrue,
>> strub
>>
>>
>>


Re: some draft for DS-2.0

2021-09-23 Thread Thomas Andraschko
+1 for making it master

Mark Struberg  schrieb am Do., 23. Sept. 2021,
20:13:

> hi!
>
> I've migrated a few things over to the jakarta namespace and started
> dropping a few old features.
> Right now it's just core which I got working, but will now also move over
> module by module.
>
> The draft can be viewed here:
> https://github.com/struberg/deltaspike/tree/fb_ds20 <
> https://github.com/struberg/deltaspike/tree/fb_ds20>
> What branch name do we want to give it finally? Take the chance to switch
> to 'main' and somewhat later rename the master branch to mt_ds1.x?
>
> How did I proceed?
> I did not yet delete anything. Pieces which I do not see as part of DS-2.0
> got moved to an 'obsolete' directory with the same structure. If we figure
> that we do still want to keep some of the features, then we can simply move
> those files back without loosing any history.
>
> Happ to get feedback!
>
> LieGrue,
> strub
>
>
>


[jira] [Resolved] (DELTASPIKE-1426) DeltaSpikeProxyFactory is slow on start

2021-09-19 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1426.
---
Fix Version/s: 1.9.6
   Resolution: Fixed

> DeltaSpikeProxyFactory is slow on start
> ---
>
> Key: DELTASPIKE-1426
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1426
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Reporter: Vladimir Dvorak
>Priority: Minor
> Fix For: 1.9.6
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Deltaspike ProxyFactory start is slow. YourKit shows that the bottleneck is 
> in the method "collectAllMethods". It intensively uses Class.getMethod(name, 
> args), that is known by having poor performance. It seems, that number of 
> calls could be distinctly decreased by skipping checks of public abstracts 
> from proxy base class. In my case it improves OWB boot time by 7%.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (DELTASPIKE-1432) Proxy class definition does not work

2021-09-19 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1432.
---
Fix Version/s: 1.9.6
   Resolution: Fixed

> Proxy class definition does not work
> 
>
> Key: DELTASPIKE-1432
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1432
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Proxy-Module
>Affects Versions: 1.9.5
>Reporter: Christian Beikov
>Priority: Major
> Fix For: 1.9.6
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> In 
> {{org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator#loadClass}}
>  the current implementation always tries to make the 
> {{ClassLoader#defineClass}} method (of module java.base) accessible which is 
> disallowed by default since 16. To workaround this, one has to add the 
> following command line flags {{\--add-opens java.base/java.lang=ALL-UNNAMED}} 
> or {{\--add-opens java.base/java.lang=deltaspike.proxy.module.impl.asm}} if 
> running in modular mode. This can be properly implemented though by using the 
> new supported API {{java.lang.invoke.MethodHandles.Lookup#defineClass}} like 
> Weld 3.1.7 now also did. This would help usability of Deltaspike a lot.
> Here is the exception one sees without the flag:
>  
> {code}
> java.lang.reflect.InaccessibleObjectException: Unable to make protected final 
> java.lang.Class 
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
>  throws java.lang.ClassFormatError accessible: module java.base does not 
> "opens java.lang" to module deltaspike.proxy.module.impl.asm
>   at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
>   at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
>   at 
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
>   at 
> java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
>   at 
> deltaspike.proxy.module.impl.asm@1.9.4/org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator.loadClass(AsmDeltaSpikeProxyClassGenerator.java:528)
>   at 
> deltaspike.proxy.module.impl.asm@1.9.4/org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator.generateProxyClass(AsmDeltaSpikeProxyClassGenerator.java:73)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: [DISCUSS] Apache DeltaSpike 2.0 targeting Java 17 and Jakarta-9.0

2021-09-11 Thread Thomas Andraschko
Yeah
I think a 2.0 with some removed modules and Features is a good start
We may remove more with Jakarta ee 10

Mark Struberg  schrieb am Sa., 11. Sept. 2021,
20:53:

> ds-core has still a ton of useful unique features.
> DS-config is probably the most mature config systems out there.
> @Exclude together with config -> feature switch on stereoids. I don't know
> any other project which provides this.
> @MessageBundle is another neat feature
> ProjectStage yet another
>
> Other modules are still really worth it, e.g. the jpa module with
> @Transactional. This is still great since jakarta took over the broken
> javax.transaction.Transactional with the same borked Exception semantics
> like EJB.
>
> There is for sure a lot which can be ditched. E.g. exception eventing,
> injectable file resources, etc.
>
> But there is plenty of great stuff in here still.
>
> LieGrue,
> strub
>
> > Am 11.09.2021 um 18:48 schrieb Romain Manni-Bucau  >:
> >
> > Le sam. 11 sept. 2021 à 18:46, Thomas Andraschko <
> > andraschko.tho...@gmail.com> a écrit :
> >
> >> true romain
> >>
> >> i think the most features can you go into the the spec (e.g. CDI event
> >> broadcast of JSF events should be in JSF directly)
> >> i think the biggest module is Data, which cant be easily put into JPA
> >>
> >
> > Can go into openjpa but i didnt see a lot of adoption so can stay in 1.x
> i
> > guess
> >
> >
> >
> >> Am Sa., 11. Sept. 2021 um 18:42 Uhr schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com>:
> >>
> >>> Well transitive dep issue is solved with proper boms.
> >>> Think we should ask ourselves the future of DS.
> >>> Im not fully convinced of the added value these days in current IT
> >>> ecosystem so maybe it should be split in subprojects and some full
> parts
> >>> dropped or given to other asf projects?
> >>>
> >>> Le sam. 11 sept. 2021 à 17:29, Thomas Andraschko <
> >>> andraschko.tho...@gmail.com> a écrit :
> >>>
> >>>> see:
> >>>>
> >>>>
> >>>
> >>
> https://issues.apache.org/jira/browse/DELTASPIKE-1376?jql=project%20%3D%20DELTASPIKE%20AND%20fixVersion%20%3D%202.0
> >>>>
> >>>> Am Sa., 11. Sept. 2021 um 17:25 Uhr schrieb Thomas Andraschko <
> >>>> andraschko.tho...@gmail.com>:
> >>>>
> >>>>> +1
> >>>>>
> >>>>> i created some jira tickets for it 1-2 years ago
> >>>>>
> >>>>> Am Sa., 11. Sept. 2021 um 14:58 Uhr schrieb Cody Lerum <
> >>>>> cody.le...@gmail.com>:
> >>>>>
> >>>>>> +1
> >>>>>>
> >>>>>> 1.9.x seems very stable with minimal updates so it is unlikely to be
> >>>>>> much of a burden to keep it alive for pre-Jakarta use.
> >>>>>>
> >>>>>> I could see some people say setting a JDK 17 minimum would be
> >>>>>> aggressive, but those starting new Jakarta projects or going through
> >>>>>> the upgrade work for an older project should really be moving up to
> >>>>>> it.
> >>>>>>
> >>>>>> -C
> >>>>>>
> >>>>>> On Sat, Sep 11, 2021 at 6:48 AM Mark Struberg
> >>>  >>>>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi folks!
> >>>>>>>
> >>>>>>> There was a bunch of user requests on the mailing list  to add
> >>> support
> >>>>>> for Jakarta enterprise namespaces.
> >>>>>>> I tried to implement this via shading but it seems not to be
> >>>> sufficient.
> >>>>>>> The problem with shading is that the poms only have classifier to
> >>>>>> access deltaspike.
> >>>>>>> This is especially a problem with transitive dependencies.
> >>>>>>>
> >>>>>>> The other point is that we had many discussions about shipping an
> >>>>>> upgraded version of DeltaSpike and deprecate/remove some obsolete
> >>> APIs.
> >>>>>>> So let's go big and why not move up to jakartaEE namespace and
> >>> Java17
> >>>>>> at the same time?
> >>>>>>>
> >>>&

Re: [DISCUSS] Apache DeltaSpike 2.0 targeting Java 17 and Jakarta-9.0

2021-09-11 Thread Thomas Andraschko
true romain

i think the most features can you go into the the spec (e.g. CDI event
broadcast of JSF events should be in JSF directly)
i think the biggest module is Data, which cant be easily put into JPA

Am Sa., 11. Sept. 2021 um 18:42 Uhr schrieb Romain Manni-Bucau <
rmannibu...@gmail.com>:

> Well transitive dep issue is solved with proper boms.
> Think we should ask ourselves the future of DS.
> Im not fully convinced of the added value these days in current IT
> ecosystem so maybe it should be split in subprojects and some full parts
> dropped or given to other asf projects?
>
> Le sam. 11 sept. 2021 à 17:29, Thomas Andraschko <
> andraschko.tho...@gmail.com> a écrit :
>
> > see:
> >
> >
> https://issues.apache.org/jira/browse/DELTASPIKE-1376?jql=project%20%3D%20DELTASPIKE%20AND%20fixVersion%20%3D%202.0
> >
> > Am Sa., 11. Sept. 2021 um 17:25 Uhr schrieb Thomas Andraschko <
> > andraschko.tho...@gmail.com>:
> >
> > > +1
> > >
> > > i created some jira tickets for it 1-2 years ago
> > >
> > > Am Sa., 11. Sept. 2021 um 14:58 Uhr schrieb Cody Lerum <
> > > cody.le...@gmail.com>:
> > >
> > >> +1
> > >>
> > >> 1.9.x seems very stable with minimal updates so it is unlikely to be
> > >> much of a burden to keep it alive for pre-Jakarta use.
> > >>
> > >> I could see some people say setting a JDK 17 minimum would be
> > >> aggressive, but those starting new Jakarta projects or going through
> > >> the upgrade work for an older project should really be moving up to
> > >> it.
> > >>
> > >> -C
> > >>
> > >> On Sat, Sep 11, 2021 at 6:48 AM Mark Struberg
>  > >
> > >> wrote:
> > >> >
> > >> > Hi folks!
> > >> >
> > >> > There was a bunch of user requests on the mailing list  to add
> support
> > >> for Jakarta enterprise namespaces.
> > >> > I tried to implement this via shading but it seems not to be
> > sufficient.
> > >> > The problem with shading is that the poms only have classifier to
> > >> access deltaspike.
> > >> > This is especially a problem with transitive dependencies.
> > >> >
> > >> > The other point is that we had many discussions about shipping an
> > >> upgraded version of DeltaSpike and deprecate/remove some obsolete
> APIs.
> > >> > So let's go big and why not move up to jakartaEE namespace and
> Java17
> > >> at the same time?
> > >> >
> > >> > Potential candidates for dropping coming to my mind:
> > >> >
> > >> > .) BeanManagerProvider/BeanProvider. We historically kept this for 2
> > >> reasons. 1.) backward compatibility with CDI-1.0, 2.) in EARs this is
> > still
> > >> the only way which works to properly access the BeanManager on all
> > >> containers. CDI.current() is sadly broken in EARs in almost all
> > containers.
> > >> But since EARs might go away in JakartaEE anyways, I'm fine with
> > dropping
> > >> it.
> > >> >
> > >> > .) servlet module. Injecting the various servlet information objects
> > >> like HttpServletRequest, HttpSession etc is nowadays specified by the
> > CDI
> > >> spec as well.
> > >> >
> > >> > .) Many parts of the JSF module are nowadays not needed anymore as
> > >> well. Remember the times when there was no injection into
> PhaseListeners
> > >> and FacesConverters? We did have support for it since ages, the spec
> > added
> > >> this much later, but they finally did.
> > >> >
> > >> > .) bean validation module. Those parts are imo all part of the spec
> > >> nowadays
> > >> >
> > >> > .) scheduler. I'm not sure about that one. It probably would make
> > sense
> > >> to implement an own smallish scheduler based on ScheduledExecutor
> > instead
> > >> of going fully blown quartz?
> > >> >
> > >> >
> > >> >
> > >> > wdyt?
> > >> >
> > >> > I'd go on and create a new umbrella ticket for all the work.
> > >> >
> > >> > LieGrue,
> > >> > strub
> > >> >
> > >> >
> > >>
> > >
> >
>


[jira] [Commented] (DELTASPIKE-1265) Align JSF module to features provided by JSF 2.3

2021-09-11 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413547#comment-17413547
 ] 

Thomas Andraschko commented on DELTASPIKE-1265:
---

we can also remove windowscoped 
maybe i can also try to push event publish function to Faces 4.0

> Align JSF module to features provided by JSF 2.3
> 
>
> Key: DELTASPIKE-1265
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1265
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Priority: Major
> Fix For: 2.0
>
>
> The JSF module provides a lot of functionality that overlaps with JSF 2.1/2.2 
> features.  We should review this content and see what can be removed vs what 
> is provided OOTB.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Reopened] (DELTASPIKE-1265) Align JSF module to features provided by JSF 2.3

2021-09-11 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko reopened DELTASPIKE-1265:
---

> Align JSF module to features provided by JSF 2.3
> 
>
> Key: DELTASPIKE-1265
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1265
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Priority: Major
> Fix For: 2.0
>
>
> The JSF module provides a lot of functionality that overlaps with JSF 2.1/2.2 
> features.  We should review this content and see what can be removed vs what 
> is provided OOTB.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: [DISCUSS] Apache DeltaSpike 2.0 targeting Java 17 and Jakarta-9.0

2021-09-11 Thread Thomas Andraschko
see:
https://issues.apache.org/jira/browse/DELTASPIKE-1376?jql=project%20%3D%20DELTASPIKE%20AND%20fixVersion%20%3D%202.0

Am Sa., 11. Sept. 2021 um 17:25 Uhr schrieb Thomas Andraschko <
andraschko.tho...@gmail.com>:

> +1
>
> i created some jira tickets for it 1-2 years ago
>
> Am Sa., 11. Sept. 2021 um 14:58 Uhr schrieb Cody Lerum <
> cody.le...@gmail.com>:
>
>> +1
>>
>> 1.9.x seems very stable with minimal updates so it is unlikely to be
>> much of a burden to keep it alive for pre-Jakarta use.
>>
>> I could see some people say setting a JDK 17 minimum would be
>> aggressive, but those starting new Jakarta projects or going through
>> the upgrade work for an older project should really be moving up to
>> it.
>>
>> -C
>>
>> On Sat, Sep 11, 2021 at 6:48 AM Mark Struberg 
>> wrote:
>> >
>> > Hi folks!
>> >
>> > There was a bunch of user requests on the mailing list  to add support
>> for Jakarta enterprise namespaces.
>> > I tried to implement this via shading but it seems not to be sufficient.
>> > The problem with shading is that the poms only have classifier to
>> access deltaspike.
>> > This is especially a problem with transitive dependencies.
>> >
>> > The other point is that we had many discussions about shipping an
>> upgraded version of DeltaSpike and deprecate/remove some obsolete APIs.
>> > So let's go big and why not move up to jakartaEE namespace and Java17
>> at the same time?
>> >
>> > Potential candidates for dropping coming to my mind:
>> >
>> > .) BeanManagerProvider/BeanProvider. We historically kept this for 2
>> reasons. 1.) backward compatibility with CDI-1.0, 2.) in EARs this is still
>> the only way which works to properly access the BeanManager on all
>> containers. CDI.current() is sadly broken in EARs in almost all containers.
>> But since EARs might go away in JakartaEE anyways, I'm fine with dropping
>> it.
>> >
>> > .) servlet module. Injecting the various servlet information objects
>> like HttpServletRequest, HttpSession etc is nowadays specified by the CDI
>> spec as well.
>> >
>> > .) Many parts of the JSF module are nowadays not needed anymore as
>> well. Remember the times when there was no injection into PhaseListeners
>> and FacesConverters? We did have support for it since ages, the spec added
>> this much later, but they finally did.
>> >
>> > .) bean validation module. Those parts are imo all part of the spec
>> nowadays
>> >
>> > .) scheduler. I'm not sure about that one. It probably would make sense
>> to implement an own smallish scheduler based on ScheduledExecutor instead
>> of going fully blown quartz?
>> >
>> >
>> >
>> > wdyt?
>> >
>> > I'd go on and create a new umbrella ticket for all the work.
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>>
>


[jira] [Closed] (DELTASPIKE-1265) Align JSF module to features provided by JSF 2.3

2021-09-11 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1265.
-
Resolution: Fixed

> Align JSF module to features provided by JSF 2.3
> 
>
> Key: DELTASPIKE-1265
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1265
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Priority: Major
> Fix For: 2.0
>
>
> The JSF module provides a lot of functionality that overlaps with JSF 2.1/2.2 
> features.  We should review this content and see what can be removed vs what 
> is provided OOTB.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: [DISCUSS] Apache DeltaSpike 2.0 targeting Java 17 and Jakarta-9.0

2021-09-11 Thread Thomas Andraschko
+1

i created some jira tickets for it 1-2 years ago

Am Sa., 11. Sept. 2021 um 14:58 Uhr schrieb Cody Lerum :

> +1
>
> 1.9.x seems very stable with minimal updates so it is unlikely to be
> much of a burden to keep it alive for pre-Jakarta use.
>
> I could see some people say setting a JDK 17 minimum would be
> aggressive, but those starting new Jakarta projects or going through
> the upgrade work for an older project should really be moving up to
> it.
>
> -C
>
> On Sat, Sep 11, 2021 at 6:48 AM Mark Struberg 
> wrote:
> >
> > Hi folks!
> >
> > There was a bunch of user requests on the mailing list  to add support
> for Jakarta enterprise namespaces.
> > I tried to implement this via shading but it seems not to be sufficient.
> > The problem with shading is that the poms only have classifier to access
> deltaspike.
> > This is especially a problem with transitive dependencies.
> >
> > The other point is that we had many discussions about shipping an
> upgraded version of DeltaSpike and deprecate/remove some obsolete APIs.
> > So let's go big and why not move up to jakartaEE namespace and Java17 at
> the same time?
> >
> > Potential candidates for dropping coming to my mind:
> >
> > .) BeanManagerProvider/BeanProvider. We historically kept this for 2
> reasons. 1.) backward compatibility with CDI-1.0, 2.) in EARs this is still
> the only way which works to properly access the BeanManager on all
> containers. CDI.current() is sadly broken in EARs in almost all containers.
> But since EARs might go away in JakartaEE anyways, I'm fine with dropping
> it.
> >
> > .) servlet module. Injecting the various servlet information objects
> like HttpServletRequest, HttpSession etc is nowadays specified by the CDI
> spec as well.
> >
> > .) Many parts of the JSF module are nowadays not needed anymore as well.
> Remember the times when there was no injection into PhaseListeners and
> FacesConverters? We did have support for it since ages, the spec added this
> much later, but they finally did.
> >
> > .) bean validation module. Those parts are imo all part of the spec
> nowadays
> >
> > .) scheduler. I'm not sure about that one. It probably would make sense
> to implement an own smallish scheduler based on ScheduledExecutor instead
> of going fully blown quartz?
> >
> >
> >
> > wdyt?
> >
> > I'd go on and create a new umbrella ticket for all the work.
> >
> > LieGrue,
> > strub
> >
> >
>


[jira] [Closed] (DELTASPIKE-1430) Migrate to Jakarta EE

2021-07-13 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1430.
-

> Migrate to Jakarta EE
> -
>
> Key: DELTASPIKE-1430
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1430
> Project: DeltaSpike
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Mark Struberg
>Priority: Major
>
> Please provide version of DeltaSpike that depends on Jakarta EE APIs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (DELTASPIKE-1432) Proxy class definition does not work

2021-07-13 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379717#comment-17379717
 ] 

Thomas Andraschko commented on DELTASPIKE-1432:
---

[~christian.beikov] interessted in providing a PR?

> Proxy class definition does not work
> 
>
> Key: DELTASPIKE-1432
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1432
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Proxy-Module
>Affects Versions: 1.9.5
>Reporter: Christian Beikov
>Priority: Major
>
> In 
> {{org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator#loadClass}}
>  the current implementation always tries to make the 
> {{ClassLoader#defineClass}} method (of module java.base) accessible which is 
> disallowed by default since 16. To workaround this, one has to add the 
> following command line flags {{\--add-opens java.base/java.lang=ALL-UNNAMED}} 
> or {{\--add-opens java.base/java.lang=deltaspike.proxy.module.impl.asm}} if 
> running in modular mode. This can be properly implemented though by using the 
> new supported API {{java.lang.invoke.MethodHandles.Lookup#defineClass}} like 
> Weld 3.1.7 now also did. This would help usability of Deltaspike a lot.
> Here is the exception one sees without the flag:
>  
> {code}
> java.lang.reflect.InaccessibleObjectException: Unable to make protected final 
> java.lang.Class 
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
>  throws java.lang.ClassFormatError accessible: module java.base does not 
> "opens java.lang" to module deltaspike.proxy.module.impl.asm
>   at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
>   at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
>   at 
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
>   at 
> java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
>   at 
> deltaspike.proxy.module.impl.asm@1.9.4/org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator.loadClass(AsmDeltaSpikeProxyClassGenerator.java:528)
>   at 
> deltaspike.proxy.module.impl.asm@1.9.4/org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator.generateProxyClass(AsmDeltaSpikeProxyClassGenerator.java:73)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (DELTASPIKE-1430) Migrate to Jakarta EE

2021-07-13 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko resolved DELTASPIKE-1430.
---
Resolution: Duplicate

of #1434

> Migrate to Jakarta EE
> -
>
> Key: DELTASPIKE-1430
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1430
> Project: DeltaSpike
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Mark Struberg
>Priority: Major
>
> Please provide version of DeltaSpike that depends on Jakarta EE APIs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (DELTASPIKE-1428) Empty resolvedComponents not cached in InjectionResolver

2021-03-25 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308707#comment-17308707
 ] 

Thomas Andraschko commented on DELTASPIKE-1428:
---

Please work on a PR. I would make ManagedArtifactResolver a @ApplicationSCoped 
bean and add a cache there

> Empty resolvedComponents not cached in InjectionResolver
> 
>
> Key: DELTASPIKE-1428
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1428
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: Vladimir Dvorak
>Priority: Minor
>
> Issue was reported originally repoted as an OWB problem:
> https://issues.apache.org/jira/browse/OWB-1381
> but was shown the problem is in DS, reproducible example is at:
> [https://github.com/skybber/pf-expensive-converter|http://example.com/]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (DELTASPIKE-1426) DeltaSpikeProxyFactory is slow on start

2021-03-25 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308594#comment-17308594
 ] 

Thomas Andraschko commented on DELTASPIKE-1426:
---

Feel free to work on a PR, so we can review your ideas.

> DeltaSpikeProxyFactory is slow on start
> ---
>
> Key: DELTASPIKE-1426
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1426
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Reporter: Vladimir Dvorak
>Priority: Minor
>
> Deltaspike ProxyFactory start is slow. YourKit shows that the bottleneck is 
> in the method "collectAllMethods". It intensively uses Class.getMethod(name, 
> args), that is known by having poor performance. It seems, that number of 
> calls could be distinctly decreased by skipping checks of public abstracts 
> from proxy base class. In my case it improves OWB boot time by 7%.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (DELTASPIKE-1424) BeanProvider.getContextualReference Failing After Upgrading to v1.9.2

2021-03-08 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17297464#comment-17297464
 ] 

Thomas Andraschko commented on DELTASPIKE-1424:
---

can you set deltaspike.bean-manager.delegate_lookup = false?

probably this issue: https://issues.apache.org/jira/browse/DELTASPIKE-1398

> BeanProvider.getContextualReference Failing After Upgrading to v1.9.2
> -
>
> Key: DELTASPIKE-1424
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1424
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.2, 1.9.3, 1.9.4
> Environment: Ubuntu 18.04
> Java 1.8
> Jboss Wildfly 18.0.1
>Reporter: Patrick Buchheit
>Priority: Major
>
> I have been using deltaspike successfully to do injection of my entity 
> manager into a non-bean class. Recently, I decided to upgrade from version 
> 1.5.1 to the current version 1.9.4 to get access to variables in the 
> apache-deltaspike.properties file. As soon as I made the change, I started 
> seeing errors like this:
>  
> {code:java}
> Caused by: java.lang.IllegalStateException: Could not find beans for 
> Type=interface javax.persistence.EntityManager and 
> qualifiers:[@com.tura.common.service.qualifier.EntityManagerQualifier()]Caused
>  by: java.lang.IllegalStateException: Could not find beans for Type=interface 
> javax.persistence.EntityManager and 
> qualifiers:[@com.tura.common.service.qualifier.EntityManagerQualifier()] at 
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:154)
>  at 
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:121)
>  at 
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:100)
>  at 
> com.tura.product.service.test.Test.testUploadFrameImages(Test.java:9702){code}
>  
> Nothing in my code has changed; the only alteration I have made is to change 
> the deltaspike version in my pom. Just to make sure, I tried rolling back to 
> an earlier version of deltaspike. Versions 1.9.1 and earlier all work fine. 
> As soon as I change to 1.9.2 or earlier I get an error. I couldn't find 
> anything in the patch notes indicating changes I would need to make to 
> migrate to a newer version. Is this a bug, or is there some change I need to 
> make to my code to make it compatible again?
>  
> Some code snippets:
>  
> *entity manager lookup-*
> {code:java}
> EntityManager entityManager = 
> BeanProvider.getContextualReference(EntityManager.class, new 
> EntityManagerQualifierLiteral());{code}
>  
> *Producer Bean*
>  
> {code:java}
> @Alternative
> public class TestCDIModule
> {
> @PersistenceContext(unitName = "TestProductPersistenceUnit")
> private EntityManager entityManager;
>  
> @Produces
> @EntityManagerQualifier
> public EntityManager getEntityManager()
> {
> return this.entityManager;
> }
> }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: [VOTE] Release Apache DeltaSpike-1.9.5

2021-03-06 Thread Thomas Andraschko
+1

Romain Manni-Bucau  schrieb am Sa., 6. März 2021,
10:13:

> +1
>
> Le sam. 6 mars 2021 à 01:08, Daniel Dias Dos Santos <
> daniel.dias.analist...@gmail.com> a écrit :
>
> > Hello ,
> >
> > +1
> >
> > On Fri, Mar 5, 2021, 19:45 Mark Struberg 
> > wrote:
> >
> > > Hi Lords and Ladies!
> > >
> > > I'd like to call a VOTE for releasing Apache DeltaSpike-1.9.5
> > >
> > > The following tickets got closed:
> > > Bug
> > >
> > > [DELTASPIKE-1314 <
> https://issues.apache.org/jira/browse/DELTASPIKE-1314
> > >]
> > > - ContainerCtrlTckTest fails with tomee7-build-managed
> > > [DELTASPIKE-1413 <
> https://issues.apache.org/jira/browse/DELTASPIKE-1413
> > >]
> > > - dsrwid cookie should not be set to sameSite="None"
> > > [DELTASPIKE-1416 <
> https://issues.apache.org/jira/browse/DELTASPIKE-1416
> > >]
> > > - deltaspike-core-impl.jar does not contain the Main class to execute
> in
> > > your Manifest.MF to Crypto
> > > [DELTASPIKE-1423 <
> https://issues.apache.org/jira/browse/DELTASPIKE-1423
> > >]
> > > - JSF-2.3 managed() in FacesValidator and FacesConverter break CDI
> > > integration
> > > Improvement
> > >
> > > [DELTASPIKE-1420 <
> https://issues.apache.org/jira/browse/DELTASPIKE-1420
> > >]
> > > - Update ASM to 9.1
> > >
> > >
> > > The staging repository is
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1056/
> > > <
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1056/
> > > >
> > >
> > > The source zip can be found at
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1056/org/apache/deltaspike/deltaspike/1.9.5/
> > > <
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1056/org/apache/deltaspike/deltaspike/1.9.5/
> > > >
> > > sha1 is fa8779819026c86320959ffb7d1ce6546b6ad1e2
> > >
> > > Please VOTE
> > >
> > > [+1] yikes, go ship it!
> > > [+0] meh, don't care
> > > [-1] nah stop, there is a ${showstopper}
> > >
> > > The VOTE is open for 72h.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> >
>


[jira] [Closed] (DELTASPIKE-1177) [Deltaspike Data] Regoznize Entity Type by method returned type if @Repository.forEntity is set to default

2021-02-26 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1177.
-
Resolution: Won't Fix

Current design is 1 entity for 1 repo only

> [Deltaspike Data] Regoznize Entity Type by method returned type if 
> @Repository.forEntity is set to default
> --
>
> Key: DELTASPIKE-1177
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1177
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.7.0
>Reporter: Tibor Digana
>Priority: Major
>
> I want to use Deltaspike Data Repo as a Service because it is simplistic and 
> not DAO.
> Since of service operates over multiple entities I want the extension to 
> recognize the Entity type dynamically by method return type.
> Notice the example does not implement _EntityRepository_ and therefore the 
> only return type should be checked.
> {code}
> @Repository
> public interface Java8Repository {
>   MyEntity findByCourse(@NotNull String courseName);
>   AnotherEntity findByCustomer(@NotNull String customerName);
>   @Query("")
>   Object[] findMultipleEntityTypes(@NotNull String attribute);
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (DELTASPIKE-1238) Create a better default TransactionStrategy

2021-02-26 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1238.
-
Resolution: Won't Fix

Talked with Mark, lets close it for now. 4 years no progress

> Create a better default TransactionStrategy
> ---
>
> Key: DELTASPIKE-1238
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1238
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Assignee: John D. Ament
>Priority: Major
> Fix For: 2.0
>
>
> Create a better default TransactionStrategy that handles more use cases out 
> of the box.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (DELTASPIKE-1190) Add more examples

2021-02-26 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1190.
-
Resolution: Incomplete

noone provided a PR for that, lets close for now

> Add more examples
> -
>
> Key: DELTASPIKE-1190
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1190
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Documentation, Examples
>Reporter: John D. Ament
>Priority: Major
>
> We've added a lot of new functionality in recent releases.  It would be great 
> to see some new examples being added.  
> Current examples are found at : 
> https://github.com/apache/deltaspike/tree/master/deltaspike/examples
> - Add examples w/ Data
> - Add examples w/ JPA
> - Add test control examples
> - Add examples for partial bean/proxy



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (DELTASPIKE-988) ViewAccessHandler API

2021-02-26 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-988.

Resolution: Won't Fix

lets close for now

> ViewAccessHandler API
> -
>
> Key: DELTASPIKE-988
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-988
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: JSF-Module
>Affects Versions: 1.5.0
>Reporter: Richard DiCroce
>Assignee: Gerhard Petracek
>Priority: Major
>
> Currently, there is no way to programmatically evaluate the Secured 
> annotations on a ViewConfig. I have created a PR on GitHub to add such an 
> API. As a bonus, I also added some tests for the Secured/ViewConfig 
> integration.
> PR is here: https://github.com/apache/deltaspike/pull/44



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (DELTASPIKE-1413) dsrwid cookie should not be set to sameSite="None"

2021-02-26 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17291681#comment-17291681
 ] 

Thomas Andraschko commented on DELTASPIKE-1413:
---

[~mwalliczek] a PR would be great

> dsrwid cookie should not be set to sameSite="None"
> --
>
> Key: DELTASPIKE-1413
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1413
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Matthias Walliczek
>Priority: Critical
>
> Currently the dsrwid cookie set by the lazy window handler is set to 
> secure=false and sameSite=None.
> This combination will not be allowed by Firefox in the future. See 
> [https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Set-Cookie/SameSite.|https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Set-Cookie/SameSite]
> Instead sameSite should be set to "lax", which is default in modern browsers.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (DELTASPIKE-1104) Import Microscoped scopes into DeltaSpike

2021-02-26 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1104.
-
Resolution: Won't Fix

noone requested it or worked on it, lets close for now

> Import Microscoped scopes into DeltaSpike
> -
>
> Key: DELTASPIKE-1104
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1104
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core, Servlet-Module, Timer-Module
>Reporter: John D. Ament
>Priority: Major
>
> Import the newly created microscoped scopes into DeltaSpike.
> Some high level mappings
> MethodScoped -> Core
> DomainScoped -> Servlet
> HeaderScoped -> Servlet
> TimerScoped -> New module?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (DELTASPIKE-1418) BeanManagerProvider didn't implement the javax.enterprise.inject.spi.Extension interface

2021-02-26 Thread Thomas Andraschko (Jira)


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

Thomas Andraschko closed DELTASPIKE-1418.
-
Resolution: Incomplete

no feedback

> BeanManagerProvider didn't implement the 
> javax.enterprise.inject.spi.Extension interface
> 
>
> Key: DELTASPIKE-1418
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1418
> Project: DeltaSpike
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.8.2
> Environment: Wildfly 18.1
> Deltaspike 1.8.2
>Reporter: THEODOROS CHAIKALIS
>Assignee: Mark Struberg
>Priority: Major
>
> Iam getting a strange error during deployment:
> The scenario is: Iam trying to port the application from Weblogic 12c to 
> Wildfly 18.1.
> The war deploys successfully on WL 12c
>  
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: 
> WFLYWELD0021: Service class 
> org.apache.deltaspike.core.api.provider.BeanManagerProvider didn't implement 
> the javax.enterprise.inject.spi.Extension interface
>  
>  
>  
> FULL ERROR STACK:
>  
> {{17:39:06,999 INFO [org.jboss.as.repository] (management-handler-thread - 1) 
> WFLYDR0001: Content added at location 
> C:\Wildfly\wildfly-18.0.1.Final\standalone\data\content\ae\a8437df71db3a6747bc93111cc195e59d7355a\content}}
> {{17:39:07,004 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) 
> WFLYSRV0027: Starting deployment of "ssp.webservices.process.war" 
> (runtime-name: "ssp.webservices.process.war")}}
> {{17:39:08,786 INFO [org.jboss.as.jpa] (MSC service thread 1-3) WFLYJPA0002: 
> Read persistence.xml for auditPU}}
> {{17:39:08,788 INFO [org.jboss.as.jpa] (MSC service thread 1-3) WFLYJPA0002: 
> Read persistence.xml for commonPU}}
> {{17:39:08,791 INFO [org.jboss.as.jpa] (MSC service thread 1-3) WFLYJPA0002: 
> Read persistence.xml for processPU}}
> {{17:39:08,797 INFO [org.jboss.as.jpa] (MSC service thread 1-3) WFLYJPA0002: 
> Read persistence.xml for registryPU}}
> {{17:39:08,800 INFO [org.jboss.as.jpa] (MSC service thread 1-3) WFLYJPA0002: 
> Read persistence.xml for rulesPU}}
> {{17:39:09,337 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 83) 
> WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 
> 'ssp.webservices.process.war#auditPU'}}
> {{17:39:09,337 INFO [org.hibernate.jpa.internal.util.LogHelper] 
> (ServerService Thread Pool -- 83) HHH000204: Processing PersistenceUnitInfo 
> [}}
> {{ name: auditPU}}
> {{ ...]}}
> {{17:39:09,415 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 95) 
> WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 
> 'ssp.webservices.process.war#registryPU'}}
> {{17:39:09,418 INFO [org.hibernate.jpa.internal.util.LogHelper] 
> (ServerService Thread Pool -- 95) HHH000204: Processing PersistenceUnitInfo 
> [}}
> {{ name: registryPU}}
> {{ ...]}}
> {{17:39:09,417 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 96) 
> WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 
> 'ssp.webservices.process.war#rulesPU'}}
> {{17:39:09,429 INFO [org.hibernate.jpa.internal.util.LogHelper] 
> (ServerService Thread Pool -- 96) HHH000204: Processing PersistenceUnitInfo 
> [}}
> {{ name: rulesPU}}
> {{ ...]}}
> {{17:39:09,417 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 93) 
> WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 
> 'ssp.webservices.process.war#processPU'}}
> {{17:39:09,438 INFO [org.hibernate.jpa.internal.util.LogHelper] 
> (ServerService Thread Pool -- 93) HHH000204: Processing PersistenceUnitInfo 
> [}}
> {{ name: processPU}}
> {{ ...]}}
> {{17:39:09,418 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 94) 
> WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 
> 'ssp.webservices.process.war#commonPU'}}
> {{17:39:09,447 INFO [org.hibernate.jpa.internal.util.LogHelper] 
> (ServerService Thread Pool -- 94) HHH000204: Processing PersistenceUnitInfo 
> [}}
> {{ name: commonPU}}
> {{ ...]}}
> {{17:39:09,999 INFO [org.jboss.weld.deployer] (MSC service thread 1-8) 
> WFLYWELD0003: Processing weld deployment ssp.webservices.process.war}}
> {{17:39:10,122 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) 
> MSC01: Failed to start service 
> jboss.deployment.unit."ssp.webservices.process.war".POST_MODULE: 
> org.jboss.msc.service.StartException in service 
> jboss.deployment.unit."ssp.webservices.p

  1   2   3   4   5   6   7   8   9   10   >