[jira] [Resolved] (DELTASPIKE-1476) Destroy of RequestScoped not fired by JsfRequestBroadcaster
[
https://issues.apache.org/jira/browse/DELTASPIKE-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved DELTASPIKE-1476.
---
Fix Version/s: 2.0.1
Resolution: Fixed
> Destroy of RequestScoped not fired by JsfRequestBroadcaster
> ---
>
> Key: DELTASPIKE-1476
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1476
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Vladimir Dvorak
>Priority: Major
> Fix For: 2.0.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> destroyedEvent is not called due wrong annotation in destroyedEvent (should
> be @Destroyed not @Initialized) :
>
> @ApplicationScoped
> public class JsfRequestBroadcaster implements Deactivatable
> {
> @Inject @Initialized(RequestScoped.class) private Event
> initEvent;
> @Inject @Initialized(RequestScoped.class) private Event
> destroyedEvent;
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1476) Destroy of RequestScoped not fired by JsfRequestBroadcaster
[
https://issues.apache.org/jira/browse/DELTASPIKE-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868469#comment-17868469
]
Thomas Andraschko commented on DELTASPIKE-1476:
---
could you please provide a PR?
> Destroy of RequestScoped not fired by JsfRequestBroadcaster
> ---
>
> Key: DELTASPIKE-1476
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1476
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Vladimir Dvorak
>Priority: Major
>
> destroyedEvent is not called due wrong annotation in destroyedEvent (should
> be @Destroyed not @Initialized) :
>
> @ApplicationScoped
> public class JsfRequestBroadcaster implements Deactivatable
> {
> @Inject @Initialized(RequestScoped.class) private Event
> initEvent;
> @Inject @Initialized(RequestScoped.class) private Event
> destroyedEvent;
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1472) htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
[
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 dependency tree can be exluded via
> Dependency Management or while declaring the dependency in the consumer POM.
> {noformat}
>
> deltaspike-jsf-module-impl
> runtime
>
>
> org.seleniumhq.selenium
> html
[jira] [Updated] (DELTASPIKE-1472) htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
[
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 dependency tree can be exluded via
> Dependency Management or while declaring the dependency in the consumer POM.
> {noformat}
>
> deltaspike-jsf-module-impl
> runtime
>
>
> org.seleniumhq.selenium
> htm
[jira] [Created] (DELTASPIKE-1471) Remove @EnableInterceptors in favor of CDI InterceptionFactory
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
[ 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
[ 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)
[jira] [Resolved] (DELTASPIKE-1469) WindowIdHtmlRenderer loads wrong Javascript file
[ 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
[ 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
[
https://issues.apache.org/jira/browse/DELTASPIKE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegat
[jira] [Resolved] (DELTASPIKE-1468) AuditProvider (PrincipalProvider/TimestampsProvider) not working
[ 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
[ 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
[
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
[
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)
[jira] [Closed] (DELTASPIKE-740) Data module causes arquillian-weld-ee-embedded to fail when persistence.xml is present
[
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.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.startContainer(TestContainer.java:273)
> at
> org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:105)
> at
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> at
> org.jboss.arquillian.container.imp
[jira] [Closed] (DELTASPIKE-1450) Facing issue after Seam3 to deltaspike migration
[ 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
[ 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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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)
[jira] [Closed] (DELTASPIKE-1282) DeltaSpikeFacesContextWrapper leaks on TomEE
[ 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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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] [Closed] (DELTASPIKE-1421) Cannot exclude ApplicationScoped with @Produces method
[
https://issues.apache.org/jira/browse/DELTASPIKE-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko closed DELTASPIKE-1421.
-
Resolution: Incomplete
> Cannot exclude ApplicationScoped with @Produces method
> --
>
> Key: DELTASPIKE-1421
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1421
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: CdiControl
>Affects Versions: 1.9.4
>Reporter: Fabrizio Stellato
>Priority: Major
>
> I have *ApplicationScoped* beans on the _main_ java folder which work as
> resources class, therefore they contains methods with _Produces_ annotation .
> I'm currently using cucumber + deltaspike dependencies, and when I run my
> test I can see ALL dependencies are implicit injected.
> As I don't want to do that, I decided to exclude those ApplicationScoped
> classes from _beans.xml_ in this way:
> {code:java}
>
>
> {code}
> When I start my cucumber test, I can see these classes are still scanned,
> thus I receive ambiguos dependency because of my mock classes on _test_
> folder.
> Is there any way to exclude above classes with success or, even better, to
> explicitly add bean classes?
>
--
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
[
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
[ 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
[ 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
[
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
[
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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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)
[jira] [Closed] (DELTASPIKE-1442) Support for Jakarta EE 9.
[
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+0100] [glassfish 6.2] [INFO] []
> [org.jboss.weld.Bootstrap] [tid: _ThreadID=155 _ThreadName=weld-worker-8]
> [timeMillis: 1636726401118] [levelValue: 800] [[
> WELD-000119: Not generating any bean definitions from
> org.apache.deltaspike.core.impl.scope.conversation.GroupedConversationArtifactProducer
> b
[jira] [Resolved] (DELTASPIKE-1426) DeltaSpikeProxyFactory is slow on start
[ 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
[
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)
[jira] [Commented] (DELTASPIKE-1265) Align JSF module to features provided by JSF 2.3
[ https://issues.apache.org/jira/browse/DELTASPIKE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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)
[jira] [Closed] (DELTASPIKE-1265) Align JSF module to features provided by JSF 2.3
[ 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)
[jira] [Closed] (DELTASPIKE-1430) Migrate to Jakarta EE
[ 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
[
https://issues.apache.org/jira/browse/DELTASPIKE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DELTASPIKE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/DELTASPIKE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[jira] [Closed] (DELTASPIKE-1177) [Deltaspike Data] Regoznize Entity Type by method returned type if @Repository.forEntity is set to default
[
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
[ 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
[ 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
[ 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"
[ https://issues.apache.org/jira/browse/DELTASPIKE-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[
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.process.war".POST_MODULE: WFLYSRV0153:
> Failed to process phase POST_MODULE of deployment
> "ssp.webservices.process.war"}}
> {{ at
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)}}
> {{ at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.
[jira] [Closed] (DELTASPIKE-1218) Backport CDI 2.0 Request Context Controller
[
https://issues.apache.org/jira/browse/DELTASPIKE-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko closed DELTASPIKE-1218.
-
Resolution: Won't Fix
CDI 2.0 is already some years old now, lets close it.
> Backport CDI 2.0 Request Context Controller
> ---
>
> Key: DELTASPIKE-1218
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1218
> Project: DeltaSpike
> Issue Type: New Feature
> Components: CdiControl
>Reporter: John D. Ament
>Assignee: John D. Ament
>Priority: Major
>
> Backport the new features of context control to enable users to leverage the
> functionality now.
> {{@ActivateRequestContext}}
> {{RequestContextController}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DELTASPIKE-1392) Repositories seem to prevent Garbage Collection from Weblogic
[
https://issues.apache.org/jira/browse/DELTASPIKE-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved DELTASPIKE-1392.
---
Resolution: Duplicate
https://issues.apache.org/jira/browse/DELTASPIKE-1398
> Repositories seem to prevent Garbage Collection from Weblogic
> -
>
> Key: DELTASPIKE-1392
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1392
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Data-Module
>Affects Versions: 1.8.0
> Environment: Oracle 12c
> Weblogic 12.2.1-3-0
> Java EE 7
> Java SE 8
> Deltaspike 1.8.0
>Reporter: THEODOROS CHAIKALIS
>Priority: Major
> Attachments: Heap_walker_Incoming_References.html,
> Heap_walker_Incoming_References_2.html
>
>
> During my effort to detect possible memory leaks in our application i found a
> strange behavior of Deltaspike regarding the handling of Repositories.
> Specifically, after the *undeployment* and {color:#de350b}*deletion*{color}
> of a Java EE 7 war, Weblogic still holds all references to proxy EJBs that
> created before.
> Attached you will find the Heap dump for an EJB Service where if you trace
> the source you will end up in a
> {{*bmpSingleton* of class
> org.apache.deltaspike.core.api.provider.BeanManagerProvider.}}
>
> Am i missing some critical configuration for Weblogic?
> I already have declared
> {{globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy}}
> inside apache-deltaspike.properties.
>
> Thank you
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1393) POST request from a non-JSF to a JSF page fails with when ds:windowId is used
[
https://issues.apache.org/jira/browse/DELTASPIKE-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070319#comment-17070319
]
Thomas Andraschko commented on DELTASPIKE-1393:
---
Could you please post the whole stacktrace and describe what happens step by
step?
I could provide some help then.
> POST request from a non-JSF to a JSF page fails with when ds:windowId is used
> -
>
> Key: DELTASPIKE-1393
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1393
> Project: DeltaSpike
> Issue Type: Task
> Security Level: public(Regular issues)
> Components: JSF-Module
>Reporter: Christian Beikov
>Assignee: Mark Struberg
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When doing a POST request to a JSF page, I'm getting the following exception.
> This worked before withouth the ds:windowId tag. I will provide a PR showing
> the issue, but I'm not sure how this can be fixed yet. Obviously, one should
> use a GET request, but I have some legacy code that uses POST and it's hard
> to identify all cases. Would be great if we could solve this for other people.
> {noformat}
> org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active
> contexts for scope type org.apache.deltaspike.core.api.scope.WindowScoped
> at
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)
> at
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
> at
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> at
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
> at
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> at
> org.apache.deltaspike.jsf.impl.token.PostRequestTokenManager$Proxy$_$$_WeldClientProxy.createNewToken(Unknown
> Source){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (DELTASPIKE-1388) Can't extend Repository defined as an interface
[
https://issues.apache.org/jira/browse/DELTASPIKE-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko closed DELTASPIKE-1388.
-
> Can't extend Repository defined as an interface
> ---
>
> Key: DELTASPIKE-1388
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1388
> Project: DeltaSpike
> Issue Type: Bug
> Components: Data-Module
>Affects Versions: 1.9.1
>Reporter: Tomasz Wyszomirski
>Priority: Major
> Fix For: 1.9.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When I define my repository of interface like this:
> @Repository
> public interface SuperRepository extends FullEntityRepository< MyEntity,
> Long>{}
> and try to extend it like this:
> @Repository
> public interface ExtendedRepository extends SuperRepository {}
>
> I get initialization failure in:
> org.apache.deltaspike.data.impl.metaEntityMetadataInitializer#init(RepositoryMetadata)[39]
> Caused by: java.lang.NullPointerException
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.EntityMetadataInitializer.init(EntityMetadataInitializer.java:39)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.EntityMetadataInitializer$Proxy$_$$_WeldClientProxy.init(Unknown
> Source)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataInitializer.init(RepositoryMetadataInitializer.java:83)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataInitializer$Proxy$_$$_WeldClientProxy.init(Unknown
> Source)
> rcs-cps | at
> deployment.rcs-cps-deployable.war//org.apache.deltaspike.data.impl.meta.RepositoryMetadataHandler.init(RepositoryMetadataHandler.java:50)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (DELTASPIKE-1391) CLIENTWINDOW JS code breaks Primefaces tabview
[
https://issues.apache.org/jira/browse/DELTASPIKE-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko closed DELTASPIKE-1391.
-
> CLIENTWINDOW JS code breaks Primefaces tabview
> --
>
> Key: DELTASPIKE-1391
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1391
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Reporter: Christian Beikov
>Priority: Major
> Fix For: 1.9.2
>
>
> Using a Primefaces tabview is impossible with the CLIENTWINDOW JS code as it
> will do a page redirect for links that have a href like {{#tabview:tabId}}
> which is due to the fact, that all links except ones with just {{#}} in the
> href, get a special onclick handler causing this. The intent of the handler
> is to handle opening new windows, but it should ignore any links with any
> kind of anchor navigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (DELTASPIKE-1396) Incorrect parameter meaning in AbstractQuartzScheduler.stop of Scheduler Module
[ https://issues.apache.org/jira/browse/DELTASPIKE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1396. - > Incorrect parameter meaning in AbstractQuartzScheduler.stop of Scheduler > Module > --- > > Key: DELTASPIKE-1396 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1396 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Gary Hodgson >Assignee: Mark Struberg >Priority: Major > Fix For: 1.9.2 > > Time Spent: 40m > Remaining Estimate: 0h > > The AbstractQuartzScheduler.stop method calls the shutdown method of the > Quartz scheduler with the base config of "deltaspike.scheduler.force_stop": > > this.scheduler.shutdown(SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); > > ([https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/AbstractQuartzScheduler.java#L161]) > However the parameter is called waitForJobsToComplete > * @param waitForJobsToComplete > * if true the scheduler will not allow this method > * to return until all currently executing jobs have completed. > which means the config actually does the opposite of what it intends, i.e. > deltaspike.scheduler.force_stop=true would actually wait for the executing > jobs to complete rather than stopping immediately. > I presume this would be fixed by negating the parameter: > > this.scheduler.shutdown(!SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); > > Mailing List Thread: > [https://lists.apache.org/thread.html/366d51433ea5c5deb7e1d83e09891e426bff9cae0eb6bff98990eb40@%3Cusers.deltaspike.apache.org%3E] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (DELTASPIKE-1390) Client window handler doesn't work with frames
[ https://issues.apache.org/jira/browse/DELTASPIKE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1390. - > Client window handler doesn't work with frames > -- > > Key: DELTASPIKE-1390 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1390 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) > Components: JSF-Module >Reporter: Christian Beikov >Priority: Major > Fix For: 1.9.2 > > Time Spent: 40m > Remaining Estimate: 0h > > The CLIENTWINDOW handler code loses the window when frames are involved. > Using e.g. a window scoped bean with the Primefaces Dialog Framework will > result in issues. The bean is initialized in window1. A click on a button > opens a dialog, which is opened through an iframe, but the dialog doesn't use > the window id defined in the parent window. If a button in the dialog > requires the original bean, it will find an uninitialized bean, because the > frame gets a new window id window2. > The solution is to use the root window for the window id. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (DELTASPIKE-1387) Update ASM to 7.2
[ https://issues.apache.org/jira/browse/DELTASPIKE-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1387. - > Update ASM to 7.2 > - > > Key: DELTASPIKE-1387 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1387 > Project: DeltaSpike > Issue Type: Improvement > Components: Proxy-Module >Affects Versions: 1.9.1 >Reporter: Christian Beikov >Priority: Major > Fix For: 1.9.2 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Java 13 was just released and has a new class file version and ASM 7.0 does > not have support for that. ASM 7.2 on the other hand already does. Since it's > a minor update, please get that into 1.9.2 so we can start testing with Java > 13. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (DELTASPIKE-1359) wrong parent version of deltaspike-data-module-test-ee7
[ https://issues.apache.org/jira/browse/DELTASPIKE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1359. - > wrong parent version of deltaspike-data-module-test-ee7 > --- > > Key: DELTASPIKE-1359 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1359 > Project: DeltaSpike > Issue Type: Bug > Components: Data-Module >Affects Versions: 1.9.0 >Reporter: Gerhard Petracek >Assignee: Mark Struberg >Priority: Minor > Fix For: 1.9.2 > > > deltaspike-data-module-test-ee7 wasn't upgraded to 1.9.1-SNAPSHOT during the > release of 1.9.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (DELTASPIKE-1364) Variable Replacement with @ConfigProperty not project stage aware
[
https://issues.apache.org/jira/browse/DELTASPIKE-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko closed DELTASPIKE-1364.
-
> Variable Replacement with @ConfigProperty not project stage aware
> -
>
> Key: DELTASPIKE-1364
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1364
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 1.8.2
>Reporter: Nicolò Chieffo
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.2
>
>
> reading a property with injection does not correctly use project stage
> properties.
> I have a property file with this content:
>
> {code:java}
> xxx.frontend.prefix=https://dev.xxx.it
> xxx.frontend.prefix.Production=https://prod.xxx.it
> xxx.rsalogin.url=${xxx.frontend.prefix}/#/rsalogin/{rsalogin}
> {code}
>
>
> when reading xxx.rsalogin.url using annontations
> {code:java}
> @Inject
> @ConfigProperty(name = "xxx.rsalogin.url")
> private String url;
> {code}
> In the production environment (noticed that I don't have a
> org.apache.deltaspike.ProjectStage=Production property set because by default
> the stage is Production) it should be evaluated as
> *[https://prod.xxx.it/#/rsalogin/\{rsalogin}|https://prod.xxx.it/#/rsalogin/]*
> but instead I get
> *[https://dev.xxx.it/#/rsalogin/\{rsalogin}|https://dev.xxx.it/#/rsalogin/]*
> When using the declarative API it works correctly
> {code:java}
> ConfigResolver.getProjectStageAwarePropertyValue("xxx.rsalogin.url",
> "");{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (DELTASPIKE-1386) Unhandled Exception in DefaultConfigSourceProvider causes deployment failure
[
https://issues.apache.org/jira/browse/DELTASPIKE-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko closed DELTASPIKE-1386.
-
> Unhandled Exception in DefaultConfigSourceProvider causes deployment failure
>
>
> Key: DELTASPIKE-1386
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1386
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.9.1
>Reporter: Thomas Frühbeck
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.2
>
>
> For some reason DefaultConfigSourceProvider tries to access the home
> directory of the services user.
> If the access is prohibited by SecurityManager, the AccessControlException is
> not handled and the deployment of the complete application fails.
> 2019-09-15 23:19:21,075 ERROR [org.jboss.msc.service.fail] (MSC service
> thread 1-6) MSC01: Failed to start service
> jboss.deployment.unit."mssms-sec-ear.ear".POST_MODULE:
> org.jboss.msc.service.StartException in service jboss.
> deployment.unit."mssms-sec-ear.ear".POST_MODULE: WFLYSRV0153: Failed to
> process phase POST_MODULE of deployment "mssms-sec-ear.ear"
> at
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.util.ServiceConfigurationError:
> org.apache.deltaspike.core.spi.config.ConfigSourceProvider: Provider
> org.apache.deltaspike.core.impl.config.DefaultConfigSourceProvider could not
> be instantiated
> at java.util.ServiceLoader.fail(ServiceLoader.java:232)
> at java.util.ServiceLoader.access$100(ServiceLoader.java:185)
> at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:384)
> at java.util.ServiceLoader$LazyIterator.access$700(ServiceLoader.java:323)
> at java.util.ServiceLoader$LazyIterator$2.run(ServiceLoader.java:407)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:409)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.deltaspike.core.util.ServiceUtils.loadServiceImplementations(ServiceUtils.java:81)
> at org.apache.deltaspike.core.impl.config.ConfigImpl.init(ConfigImpl.java:70)
> at
> org.apache.deltaspike.core.impl.config.ConfigProviderImpl.getConfig(ConfigProviderImpl.java:53)
> at
> org.apache.deltaspike.core.impl.config.ConfigProviderImpl.getConfig(ConfigProviderImpl.java:43)
> at
> org.apache.deltaspike.core.api.config.ConfigResolver.resolve(ConfigResolver.java:613)
> at
> org.apache.deltaspike.core.api.config.base.CoreBaseConfig$BeanManagerIntegration.(CoreBaseConfig.java:30)
> at
> org.apache.deltaspike.core.api.provider.BeanManagerProvider.(BeanManagerProvider.java:79)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at
> org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at
> org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at
> org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: java.security.AccessControlException: WFSM01: Permission check
> failed (permission "("java.io.FilePermission"
> "/home/thomas/.deltaspike/apache-deltaspike.properties" "read")" in code
> source "(vfs:/work/java/mssms/w
> ildfly1011/standalone/deployments/mssms-sec-ear.ear/lib/deltaspike-core-api-1.9.0.jar
> )" of "null")
> at
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at
> org.wildfly.security.manager.WildFlySecurityMan
[jira] [Updated] (DELTASPIKE-1241) [Config] fallback chain logic
[
https://issues.apache.org/jira/browse/DELTASPIKE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated DELTASPIKE-1241:
--
Fix Version/s: (was: 1.9.3)
> [Config] fallback chain logic
> -
>
> Key: DELTASPIKE-1241
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1241
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
>
> We got the request to add handling similar to
> ConfigResolver#getProjectStageAwarePropertyValue and
> ConfigResolver#getPropertyAwarePropertyValue but in a more generic way.
> Something I've been experimenting with since a long time was to introduce a
> more generic logic based on different lookup paths with themselves represent
> a postfix.
> The idea is to extend the TypedResolver with a method
> {code}
> TypedResolver#withLookupPath(String... lookupPaths)
> {code}
> where each lookupPath String could either be a hardcoded value (e.g.
> evaluated upfront) or a variable "${somevariable}" which will be evaluted on
> the fly.
> ConfigResolver.getPropertyAwarePropertyValue("dbvendor") could e.g. also be
> written as
> {code}
> TypedResolver ds =
> ConfigResolver.resolve("myprj.datasource")
>.withLookupPath("${dbvendor}", "${deltaspike.projectstage}");
> ds.get();
> {code}
> Assuming we are in the ProjectStage UnitTest this would result in the
> following lookup paths:
> * datasource.mysql.UnitTest
> * datasource.mysql
> * datasource.UnitTest
> * datasource
> The lookupChain is kind of a binary field with all flags set to 1 (in the
> sample this would be: 11) and then decremented for each lookup (11, 10, 01,
> 00). Where 1 means to lookup with the specific postfix and 0 without.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DELTASPIKE-1323) upgrade maven-bundle-plugin to more recent version
[ https://issues.apache.org/jira/browse/DELTASPIKE-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-1323: -- Fix Version/s: (was: 1.9.3) > 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 >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.3.4#803005)
[jira] [Closed] (DELTASPIKE-1398) Weblogic memory leak
[
https://issues.apache.org/jira/browse/DELTASPIKE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko closed DELTASPIKE-1398.
-
> Weblogic memory leak
>
>
> Key: DELTASPIKE-1398
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1398
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 1.8.0
>Reporter: THEODOROS CHAIKALIS
>Assignee: Thomas Andraschko
>Priority: Blocker
> Fix For: 1.9.2
>
> Attachments: mleak-1.png, mleak-2-leak.png, mleak-2.png,
> mleak-debug1.png, mleak-debug2.png, mleak-debug3.png, server_small.war,
> server_small.zip
>
>
> This extends previously reported issue 1392
> Iam returning back to a previously reported serious memory leak in Weblogic
> 12.2.1-3.
> To be more precise: EJB helpler classes (EJBName_randomChars_NoIntfViewImpl)
> are not being garbage collected after application removal.
>
> Steps to reproduce:
>
> # deploy the attached war (server-small)
> # {{open the webpage at /server-small/views/index.xhtml (mleak2)}}
> # monitor the classes created with a profiler (with starting name
> gr.teohaik...) (mleak1)
> # delete the app
> # check again the profiler. The ejbs are still there! (mleak3)
>
> A suggestion in 1392 was to debug BeanManagerProvider, so we did.
> {{but bpmSingleton.bminfos contains 2 objects. but method }}
> {{cleanupStoredBeanManagerOnShutdown(@Observes BeforeShutdown beforeShutdown)
> }}
> {{is called only once}}
> Attached you can see relevant object contents in the debugger screenshots
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DELTASPIKE-1323) upgrade maven-bundle-plugin to more recent version
[ https://issues.apache.org/jira/browse/DELTASPIKE-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-1323: -- Fix Version/s: (was: 1.9.2) 1.9.3 > 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 >Priority: Major > Fix For: 1.9.3 > > > 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.3.4#803005)
[jira] [Updated] (DELTASPIKE-1348) Deltaspike is unusable with junit's @category
[ https://issues.apache.org/jira/browse/DELTASPIKE-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-1348: -- Fix Version/s: (was: 1.9.2) 1.9.3 > Deltaspike is unusable with junit's @category > - > > Key: DELTASPIKE-1348 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1348 > Project: DeltaSpike > Issue Type: Bug > Components: TestControl >Affects Versions: 1.7.2 >Reporter: Lonzak >Priority: Major > Labels: category, cdi, junit, test > Fix For: 1.9.3 > > > A while ago we separated our tests in standard junit- and integration tests > using junit's category mechanism: [Example > Article|https://www.javaworld.com/article/2074569/core-java/unit-and-integration-tests-with-maven-and-junit-categories.html]. > The goal: When maven 'package' is used, then all tests annotated with > @category are skipped. When using 'install' they are executed. If in either > build a junit test fails, the build fails. > So now we switched to Deltaspike's CdiTestRunner. And now the above mechanism > doesn't work anymore: > # The integration tests are always executed ignoring the build phase > (package, install...) > # If the integration fails the build doesn't fail. > We were using the "RunWith" before so I think it is not a junit problem. I > did some research but only gradle seemed to had a similar problem > ([https://github.com/gradle/gradle/issues/3189|https://github.com/gradle/gradle/pull/4321]) > Any ideas how to get it to work again? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DELTASPIKE-1348) Deltaspike is unusable with junit's @category
[ https://issues.apache.org/jira/browse/DELTASPIKE-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-1348: -- Fix Version/s: (was: 1.9.3) > Deltaspike is unusable with junit's @category > - > > Key: DELTASPIKE-1348 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1348 > Project: DeltaSpike > Issue Type: Bug > Components: TestControl >Affects Versions: 1.7.2 >Reporter: Lonzak >Priority: Major > Labels: category, cdi, junit, test > > A while ago we separated our tests in standard junit- and integration tests > using junit's category mechanism: [Example > Article|https://www.javaworld.com/article/2074569/core-java/unit-and-integration-tests-with-maven-and-junit-categories.html]. > The goal: When maven 'package' is used, then all tests annotated with > @category are skipped. When using 'install' they are executed. If in either > build a junit test fails, the build fails. > So now we switched to Deltaspike's CdiTestRunner. And now the above mechanism > doesn't work anymore: > # The integration tests are always executed ignoring the build phase > (package, install...) > # If the integration fails the build doesn't fail. > We were using the "RunWith" before so I think it is not a junit problem. I > did some research but only gradle seemed to had a similar problem > ([https://github.com/gradle/gradle/issues/3189|https://github.com/gradle/gradle/pull/4321]) > Any ideas how to get it to work again? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DELTASPIKE-1241) [Config] fallback chain logic
[
https://issues.apache.org/jira/browse/DELTASPIKE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated DELTASPIKE-1241:
--
Fix Version/s: (was: 1.9.2)
1.9.3
> [Config] fallback chain logic
> -
>
> Key: DELTASPIKE-1241
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1241
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.3
>
>
> We got the request to add handling similar to
> ConfigResolver#getProjectStageAwarePropertyValue and
> ConfigResolver#getPropertyAwarePropertyValue but in a more generic way.
> Something I've been experimenting with since a long time was to introduce a
> more generic logic based on different lookup paths with themselves represent
> a postfix.
> The idea is to extend the TypedResolver with a method
> {code}
> TypedResolver#withLookupPath(String... lookupPaths)
> {code}
> where each lookupPath String could either be a hardcoded value (e.g.
> evaluated upfront) or a variable "${somevariable}" which will be evaluted on
> the fly.
> ConfigResolver.getPropertyAwarePropertyValue("dbvendor") could e.g. also be
> written as
> {code}
> TypedResolver ds =
> ConfigResolver.resolve("myprj.datasource")
>.withLookupPath("${dbvendor}", "${deltaspike.projectstage}");
> ds.get();
> {code}
> Assuming we are in the ProjectStage UnitTest this would result in the
> following lookup paths:
> * datasource.mysql.UnitTest
> * datasource.mysql
> * datasource.UnitTest
> * datasource
> The lookupChain is kind of a binary field with all flags set to 1 (in the
> sample this would be: 11) and then decremented for each lookup (11, 10, 01,
> 00). Where 1 means to lookup with the specific postfix and 0 without.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1398) Weblogic memory leak
[
https://issues.apache.org/jira/browse/DELTASPIKE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16994604#comment-16994604
]
Thomas Andraschko commented on DELTASPIKE-1398:
---
The bug is the following:
When we add the BM, we add a cache entry for the current CL and the parent CL.
But when we cleanup, we don't remove the parentCL entry.
It was introduced by:
https://github.com/apache/deltaspike/commit/35883fbd0d1a1c3dfc9023d67d4c5449e97fe6c2#diff-e7ec55687361a85269330f4f18cfa6d2
Nevertheless... Mark, Romain and I agreed to use CDI.current only if available
and skip our caching. Then it's up to the container to provide the right BM.
The whole behavior can be deactivated by:
deltaspike.bean-manager.delegate_lookup = false
> Weblogic memory leak
>
>
> Key: DELTASPIKE-1398
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1398
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 1.8.0
>Reporter: THEODOROS CHAIKALIS
>Priority: Blocker
> Fix For: 1.9.2
>
> Attachments: mleak-1.png, mleak-2-leak.png, mleak-2.png,
> mleak-debug1.png, mleak-debug2.png, mleak-debug3.png, server_small.war,
> server_small.zip
>
>
> This extends previously reported issue 1392
> Iam returning back to a previously reported serious memory leak in Weblogic
> 12.2.1-3.
> To be more precise: EJB helpler classes (EJBName_randomChars_NoIntfViewImpl)
> are not being garbage collected after application removal.
>
> Steps to reproduce:
>
> # deploy the attached war (server-small)
> # {{open the webpage at /server-small/views/index.xhtml (mleak2)}}
> # monitor the classes created with a profiler (with starting name
> gr.teohaik...) (mleak1)
> # delete the app
> # check again the profiler. The ejbs are still there! (mleak3)
>
> A suggestion in 1392 was to debug BeanManagerProvider, so we did.
> {{but bpmSingleton.bminfos contains 2 objects. but method }}
> {{cleanupStoredBeanManagerOnShutdown(@Observes BeforeShutdown beforeShutdown)
> }}
> {{is called only once}}
> Attached you can see relevant object contents in the debugger screenshots
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DELTASPIKE-1398) Weblogic memory leak
[
https://issues.apache.org/jira/browse/DELTASPIKE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved DELTASPIKE-1398.
---
Assignee: Thomas Andraschko
Resolution: Fixed
> Weblogic memory leak
>
>
> Key: DELTASPIKE-1398
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1398
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 1.8.0
>Reporter: THEODOROS CHAIKALIS
>Assignee: Thomas Andraschko
>Priority: Blocker
> Fix For: 1.9.2
>
> Attachments: mleak-1.png, mleak-2-leak.png, mleak-2.png,
> mleak-debug1.png, mleak-debug2.png, mleak-debug3.png, server_small.war,
> server_small.zip
>
>
> This extends previously reported issue 1392
> Iam returning back to a previously reported serious memory leak in Weblogic
> 12.2.1-3.
> To be more precise: EJB helpler classes (EJBName_randomChars_NoIntfViewImpl)
> are not being garbage collected after application removal.
>
> Steps to reproduce:
>
> # deploy the attached war (server-small)
> # {{open the webpage at /server-small/views/index.xhtml (mleak2)}}
> # monitor the classes created with a profiler (with starting name
> gr.teohaik...) (mleak1)
> # delete the app
> # check again the profiler. The ejbs are still there! (mleak3)
>
> A suggestion in 1392 was to debug BeanManagerProvider, so we did.
> {{but bpmSingleton.bminfos contains 2 objects. but method }}
> {{cleanupStoredBeanManagerOnShutdown(@Observes BeforeShutdown beforeShutdown)
> }}
> {{is called only once}}
> Attached you can see relevant object contents in the debugger screenshots
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DELTASPIKE-1398) Weblogic memory leak
[
https://issues.apache.org/jira/browse/DELTASPIKE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated DELTASPIKE-1398:
--
Fix Version/s: 1.9.2
> Weblogic memory leak
>
>
> Key: DELTASPIKE-1398
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1398
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 1.8.0
>Reporter: THEODOROS CHAIKALIS
>Priority: Blocker
> Fix For: 1.9.2
>
> Attachments: mleak-1.png, mleak-2-leak.png, mleak-2.png,
> mleak-debug1.png, mleak-debug2.png, mleak-debug3.png, server_small.war,
> server_small.zip
>
>
> This extends previously reported issue 1392
> Iam returning back to a previously reported serious memory leak in Weblogic
> 12.2.1-3.
> To be more precise: EJB helpler classes (EJBName_randomChars_NoIntfViewImpl)
> are not being garbage collected after application removal.
>
> Steps to reproduce:
>
> # deploy the attached war (server-small)
> # {{open the webpage at /server-small/views/index.xhtml (mleak2)}}
> # monitor the classes created with a profiler (with starting name
> gr.teohaik...) (mleak1)
> # delete the app
> # check again the profiler. The ejbs are still there! (mleak3)
>
> A suggestion in 1392 was to debug BeanManagerProvider, so we did.
> {{but bpmSingleton.bminfos contains 2 objects. but method }}
> {{cleanupStoredBeanManagerOnShutdown(@Observes BeforeShutdown beforeShutdown)
> }}
> {{is called only once}}
> Attached you can see relevant object contents in the debugger screenshots
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1398) Weblogic memory leak
[
https://issues.apache.org/jira/browse/DELTASPIKE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16992899#comment-16992899
]
Thomas Andraschko commented on DELTASPIKE-1398:
---
I already consider it but don't have much time.
Can you try to debug BeanManagerProvider?
The logic is quite simple:
BeanManagerProvider#setBeanManager should add it to bmInfos
BeanManagerProvider#cleanupStoredBeanManagerOnShutdown should remove it when
undeployed
> Weblogic memory leak
>
>
> Key: DELTASPIKE-1398
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1398
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 1.8.0
>Reporter: THEODOROS CHAIKALIS
>Priority: Blocker
> Attachments: mleak-1.png, mleak-2-leak.png, mleak-2.png,
> mleak-debug1.png, mleak-debug2.png, mleak-debug3.png, server_small.war,
> server_small.zip
>
>
> This extends previously reported issue 1392
> Iam returning back to a previously reported serious memory leak in Weblogic
> 12.2.1-3.
> To be more precise: EJB helpler classes (EJBName_randomChars_NoIntfViewImpl)
> are not being garbage collected after application removal.
>
> Steps to reproduce:
>
> # deploy the attached war (server-small)
> # {{open the webpage at /server-small/views/index.xhtml (mleak2)}}
> # monitor the classes created with a profiler (with starting name
> gr.teohaik...) (mleak1)
> # delete the app
> # check again the profiler. The ejbs are still there! (mleak3)
>
> A suggestion in 1392 was to debug BeanManagerProvider, so we did.
> {{but bpmSingleton.bminfos contains 2 objects. but method }}
> {{cleanupStoredBeanManagerOnShutdown(@Observes BeforeShutdown beforeShutdown)
> }}
> {{is called only once}}
> Attached you can see relevant object contents in the debugger screenshots
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1398) Weblogic memory leak
[
https://issues.apache.org/jira/browse/DELTASPIKE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16992727#comment-16992727
]
Thomas Andraschko commented on DELTASPIKE-1398:
---
I can also replicate it in TomEE with a simple WAR.
BeforeShutdown is called once (which is expected, there is only one shutdown of
the application) but the cleanup doesn't work correctly.
Make the ClassLoader is different
> Weblogic memory leak
>
>
> Key: DELTASPIKE-1398
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1398
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 1.8.0
>Reporter: THEODOROS CHAIKALIS
>Priority: Blocker
> Attachments: mleak-1.png, mleak-2-leak.png, mleak-2.png,
> mleak-debug1.png, mleak-debug2.png, mleak-debug3.png, server_small.war,
> server_small.zip
>
>
> This extends previously reported issue 1392
> Iam returning back to a previously reported serious memory leak in Weblogic
> 12.2.1-3.
> To be more precise: EJB helpler classes (EJBName_randomChars_NoIntfViewImpl)
> are not being garbage collected after application removal.
>
> Steps to reproduce:
>
> # deploy the attached war (server-small)
> # {{open the webpage at /server-small/views/index.xhtml (mleak2)}}
> # monitor the classes created with a profiler (with starting name
> gr.teohaik...) (mleak1)
> # delete the app
> # check again the profiler. The ejbs are still there! (mleak3)
>
> A suggestion in 1392 was to debug BeanManagerProvider, so we did.
> {{but bpmSingleton.bminfos contains 2 objects. but method }}
> {{cleanupStoredBeanManagerOnShutdown(@Observes BeforeShutdown beforeShutdown)
> }}
> {{is called only once}}
> Attached you can see relevant object contents in the debugger screenshots
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1395) specialized bean in jsf module are not available to EAR layer in wildfly 18
[
https://issues.apache.org/jira/browse/DELTASPIKE-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966613#comment-16966613
]
Thomas Andraschko commented on DELTASPIKE-1395:
---
Is this really a bug?
The weld issue states that it works like expected?
[~struberg] can you check this?
> specialized bean in jsf module are not available to EAR layer in wildfly 18
> ---
>
> Key: DELTASPIKE-1395
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1395
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 1.9.1
> Environment: jboss EAP 7.2.4 / wildfly 18.0.0.Final
>Reporter: Xavier Mourgues
>Priority: Major
>
> Hello,
>
> This is a follow-up of an [issue open to jboss
> weld|https://issues.jboss.org/browse/WELD-2601].
> When using deltaspike-core in an EAR and deltaspike-jsf-module in a WAR,
> there are some unsatisfied dependencies
> {code:java}
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
> dependencies for type LocaleResolver with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private
> org.apache.deltaspike.core.impl.message.DefaultMessageContext.localeResolver
> at
> org.apache.deltaspike.core.impl.message.DefaultMessageContext.localeResolver(DefaultMessageContext.java:0)
> at
> org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
> at
> org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
> at
> org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:143)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
> at
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
> at
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
> at
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
> This is due to the use of @Specialized bean being in a module (the war) not
> visible/accessible by the injection point being in the EAR.
> On EAP 6.4 or jboss AS 7, after trying some simple use case, it appears that
> the resolved bean was always the @Specialized bean whether or not it was
> injected in the EAR layer or in the WAR layer. => I'm not sure this was the
> correct behavior anyway but it allowed the application to be deployed.
> On EAP 7.2.4 or wildfly 18.0.0.Final, the application doesn't even deploy due
> to the DeploymentException shown above.
>
> As a workaround, one can set-up a dependency from the ear deployment to the
> war subdeployment in the jboss-deployment-structure.xml (see below) but this
> break the EE spec as it gives the visibility of the war module to every other
> module in the application.
> {code:xml}
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> true
>
>
>export="true"/>
>
>
>
> {code}
>
> After some more test, it seems that using an @Alternative (and setting up in
> the beans.xml of the jsf-module web-fragment) in place of @Specialize would
> not cause a deployment problem but have the following behavior
> On EAP 7 / wildfly 18, injections point in the EAR are resolved to the
> "non-alternative" bean and injections point in the WAR are resolved to the
> @Alternative one => This looks like the coherent behavior
> On EAP 6 / AS 7, injections point in the EAR and in the WAR are bot resolved
> to the "non-alternative" bean => This isn't coherent, like with the
> @Specialize issue on this environment but in a different way which would
> probably fail some regression tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1394) Injecting Data Repository in javafx controller causes connection pool reaching max size
[ https://issues.apache.org/jira/browse/DELTASPIKE-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16956857#comment-16956857 ] Thomas Andraschko commented on DELTASPIKE-1394: --- Is your Repository ApplicationScoped? If not, try it. Otherwise no idea. Never used JavaFX. Try to debug by yourself and find the reason. > Injecting Data Repository in javafx controller causes connection pool > reaching max size > --- > > Key: DELTASPIKE-1394 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1394 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: abderrahim khaled >Priority: Major > > injecting Data Repository in regular POJO doesn't cause the problem -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1392) Repositories seem to prevent Garbage Collection from Weblogic
[
https://issues.apache.org/jira/browse/DELTASPIKE-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16951961#comment-16951961
]
Thomas Andraschko commented on DELTASPIKE-1392:
---
actually not
it may just be a bug
i dont have time sorry, maybe mark or any other can help you
but in best case you can try to debug a bit if the BeanManagerProvider cleanup
is done - just check the sources
> Repositories seem to prevent Garbage Collection from Weblogic
> -
>
> Key: DELTASPIKE-1392
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1392
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Data-Module
>Affects Versions: 1.8.0
> Environment: Oracle 12c
> Weblogic 12.2.1-3-0
> Java EE 7
> Java SE 8
> Deltaspike 1.8.0
>Reporter: THEODOROS CHAIKALIS
>Priority: Major
> Attachments: Heap_walker_Incoming_References.html,
> Heap_walker_Incoming_References_2.html
>
>
> During my effort to detect possible memory leaks in our application i found a
> strange behavior of Deltaspike regarding the handling of Repositories.
> Specifically, after the *undeployment* and {color:#de350b}*deletion*{color}
> of a Java EE 7 war, Weblogic still holds all references to proxy EJBs that
> created before.
> Attached you will find the Heap dump for an EJB Service where if you trace
> the source you will end up in a
> {{*bmpSingleton* of class
> org.apache.deltaspike.core.api.provider.BeanManagerProvider.}}
>
> Am i missing some critical configuration for Weblogic?
> I already have declared
> {{globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy}}
> inside apache-deltaspike.properties.
>
> Thank you
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1392) Repositories seem to prevent Garbage Collection from Weblogic
[
https://issues.apache.org/jira/browse/DELTASPIKE-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16951935#comment-16951935
]
Thomas Andraschko commented on DELTASPIKE-1392:
---
[~struberg] could it be that BeanManagerProvider is not cleanup correctly?
> Repositories seem to prevent Garbage Collection from Weblogic
> -
>
> Key: DELTASPIKE-1392
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1392
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Data-Module
>Affects Versions: 1.8.0
> Environment: Oracle 12c
> Weblogic 12.2.1-3-0
> Java EE 7
> Java SE 8
> Deltaspike 1.8.0
>Reporter: THEODOROS CHAIKALIS
>Priority: Major
> Attachments: Heap_walker_Incoming_References.html
>
>
> During my effort to detect possible memory leaks in our application i found a
> strange behavior of Deltaspike regarding the handling of Repositories.
> Specifically, after the *undeployment* and {color:#de350b}*deletion*{color}
> of a Java EE 7 war, Weblogic still holds all references to proxy EJBs that
> created before.
> Attached you will find the Heap dump for an EJB Service where if you trace
> the source you will end up in a
> {{*bmpSingleton* of class
> org.apache.deltaspike.core.api.provider.BeanManagerProvider.}}
>
> Am i missing some critical configuration for Weblogic?
> I already have declared
> {{globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy}}
> inside apache-deltaspike.properties.
>
> Thank you
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DELTASPIKE-1391) CLIENTWINDOW JS code breaks Primefaces tabview
[
https://issues.apache.org/jira/browse/DELTASPIKE-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved DELTASPIKE-1391.
---
Resolution: Fixed
> CLIENTWINDOW JS code breaks Primefaces tabview
> --
>
> Key: DELTASPIKE-1391
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1391
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Reporter: Christian Beikov
>Priority: Major
> Fix For: 1.9.2
>
>
> Using a Primefaces tabview is impossible with the CLIENTWINDOW JS code as it
> will do a page redirect for links that have a href like {{#tabview:tabId}}
> which is due to the fact, that all links except ones with just {{#}} in the
> href, get a special onclick handler causing this. The intent of the handler
> is to handle opening new windows, but it should ignore any links with any
> kind of anchor navigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DELTASPIKE-1390) Client window handler doesn't work with frames
[ https://issues.apache.org/jira/browse/DELTASPIKE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-1390. --- Resolution: Fixed > Client window handler doesn't work with frames > -- > > Key: DELTASPIKE-1390 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1390 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) > Components: JSF-Module >Reporter: Christian Beikov >Priority: Major > Fix For: 1.9.2 > > Time Spent: 40m > Remaining Estimate: 0h > > The CLIENTWINDOW handler code loses the window when frames are involved. > Using e.g. a window scoped bean with the Primefaces Dialog Framework will > result in issues. The bean is initialized in window1. A click on a button > opens a dialog, which is opened through an iframe, but the dialog doesn't use > the window id defined in the parent window. If a button in the dialog > requires the original bean, it will find an uninitialized bean, because the > frame gets a new window id window2. > The solution is to use the root window for the window id. -- This message was sent by Atlassian Jira (v8.3.4#803005)
