[JBoss JIRA] (WFLY-10475) JSF installer module definitions are not synced with JSF modules
by Jan Blizňák (JIRA)
[ https://issues.jboss.org/browse/WFLY-10475?page=com.atlassian.jira.plugin... ]
Jan Blizňák edited comment on WFLY-10475 at 6/21/18 5:36 AM:
-------------------------------------------------------------
[~treblereel] I see, you fixed the issue with incorrect XML files in WFLY-10567, thanks.
I checked again the current state of:
https://github.com/wildfly/wildfly/tree/master/jsf/multi-jsf-installer/sr...
and
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
Ignoring the EE8 preview switch, which would eventually go away, there is one more difference I'd like to be solved, the dependency on org.omg.api module:
https://github.com/wildfly/wildfly/blob/master/jsf/multi-jsf-installer/sr...
https://github.com/wildfly/wildfly/blob/master/jsf/multi-jsf-installer/sr...
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
Judging from https://github.com/wildfly/wildfly/pull/11279/files, this should go away.
was (Author: jbliznak):
[~treblereel] I see, you fixed the issue with incorrect XML files in WFLY-10567, thanks.
I checked again the current state of:
https://github.com/wildfly/wildfly/tree/master/jsf/multi-jsf-installer/sr...
and
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
Ignoring the EE8 preview switch, which would eventually go away, there is one more difference I'd like to be solved, the dependency on org.omg.api module:
https://github.com/wildfly/wildfly/blob/master/jsf/multi-jsf-installer/sr...
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
Judging from https://github.com/wildfly/wildfly/pull/11279/files, this should go away too.
> JSF installer module definitions are not synced with JSF modules
> ----------------------------------------------------------------
>
> Key: WFLY-10475
> URL: https://issues.jboss.org/browse/WFLY-10475
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 13.0.0.Final
> Reporter: Jan Blizňák
> Assignee: Dmitrii Tikhomirov
> Fix For: 14.0.0.CR1
>
>
> There is a JSF installer module resources https://github.com/wildfly/wildfly/tree/master/jsf/multi-jsf-installer/sr... which seem to be out of sync with the JSF modules defined in feature-pack:
> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
> I guess these should be synced, ie. changes from feature-pack should be reflected in JSF installer too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2268) Disable reliable transmission of SEQUENCER on coordinator change
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2268?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2268:
---------------------------
Description:
The SEQUENCER protocol ensures that the messages that are not acked by the previous coordinator are forwarded to the new coordinator. This ensures reliable transmission of data. It will be better to have a way to turn off this behavior. I.e. when a coord change has occurred, drop all the messages in the forward table.
Background:
A network partition can cause data inconsistencies if both sub-groups continue to support updates. I do not want to continue processing on the sub-group that has lost its coord (or continue transmission with the new coord of the un-acked data).
was:The SEQUENCER protocol ensures that the messages that are not acked by the previous coordinator are forwarded to the new coordinator. This ensures reliable transmission of data. It will be better to have a way to turn off this behavior.
> Disable reliable transmission of SEQUENCER on coordinator change
> ----------------------------------------------------------------
>
> Key: JGRP-2268
> URL: https://issues.jboss.org/browse/JGRP-2268
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Kishore Kumar
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 4.0.13
>
>
> The SEQUENCER protocol ensures that the messages that are not acked by the previous coordinator are forwarded to the new coordinator. This ensures reliable transmission of data. It will be better to have a way to turn off this behavior. I.e. when a coord change has occurred, drop all the messages in the forward table.
> Background:
> A network partition can cause data inconsistencies if both sub-groups continue to support updates. I do not want to continue processing on the sub-group that has lost its coord (or continue transmission with the new coord of the un-acked data).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski edited comment on WFLY-10280 at 6/21/18 4:34 AM:
--------------------------------------------------------------------
Well, the whole clustering service dependencies/suppliers/functional services are quite confusing. What I fail to understand is why service deployed in /subsystem=ejb3/service=remote (EJBRemotingConnectorClientMappingsEntryProviderService) registers as service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
[~pferraro] ^^ ?
was (Author: baranowb):
Well, the whole clustering service dependencies/suppliers/functional services are quite confusing. What I fail to understand is why service deployed in /subsystem=ejb3/service=remote (EJBRemotingConnectorClientMappingsEntryProviderService) registers as service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings
[~pferraro] ^^ ?
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Bartosz Baranowski
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-10280:
-------------------------------------------
Well, the whole clustering service dependencies/suppliers/functional services are quite confusing. What I fail to understand is why service deployed in /subsystem=ejb3/service=remote (EJBRemotingConnectorClientMappingsEntryProviderService) registers as service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings
[~pferraro] ^^ ?
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Bartosz Baranowski
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10616) ContextResolver doesn't work
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-10616?page=com.atlassian.jira.plugin... ]
Alessio Soldano updated WFLY-10616:
-----------------------------------
Fix Version/s: 14.0.0.CR1
> ContextResolver doesn't work
> ----------------------------
>
> Key: WFLY-10616
> URL: https://issues.jboss.org/browse/WFLY-10616
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 13.0.0.Final
> Reporter: George Trudeau
> Assignee: R Searls
> Fix For: 14.0.0.CR1
>
>
> I have a simple ContextResolver to set Date serialization format for my JAX-RS service, it works on 12.0.0.Final but it doesn't anymore on 13.0.0.Final :
> {code:java}
> @Provider
> public class DateResolver implements ContextResolver<ObjectMapper>
> {
> private final ObjectMapper mapper;
> public DateResolver()
> {
> mapper = new ObjectMapper();
> mapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ"));
> mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
> }
> @Override
> public ObjectMapper getContext(Class<?> type) { return mapper; }
> }
> {code}
> The {{getContext}} method isn't called on 13.0.0.Final.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10616) ContextResolver doesn't work
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-10616?page=com.atlassian.jira.plugin... ]
Alessio Soldano reassigned WFLY-10616:
--------------------------------------
Assignee: R Searls (was: Alessio Soldano)
> ContextResolver doesn't work
> ----------------------------
>
> Key: WFLY-10616
> URL: https://issues.jboss.org/browse/WFLY-10616
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 13.0.0.Final
> Reporter: George Trudeau
> Assignee: R Searls
>
> I have a simple ContextResolver to set Date serialization format for my JAX-RS service, it works on 12.0.0.Final but it doesn't anymore on 13.0.0.Final :
> {code:java}
> @Provider
> public class DateResolver implements ContextResolver<ObjectMapper>
> {
> private final ObjectMapper mapper;
> public DateResolver()
> {
> mapper = new ObjectMapper();
> mapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ"));
> mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
> }
> @Override
> public ObjectMapper getContext(Class<?> type) { return mapper; }
> }
> {code}
> The {{getContext}} method isn't called on 13.0.0.Final.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3877) Make implementing the org.wildfly.extension.elytron.Configurable optional for configurable components.
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3877?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-3877:
--------------------------------
Fix Version/s: 6.0.0.Alpha3
(was: 6.0.0.Alpha2)
> Make implementing the org.wildfly.extension.elytron.Configurable optional for configurable components.
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3877
> URL: https://issues.jboss.org/browse/WFCORE-3877
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Martin Mazanek
> Fix For: 6.0.0.Alpha3
>
>
> Presently custom components within the Elytron subsystem are required to implement the 'org.wildfly.extension.elytron.Configurable' interface if they wish to support receiving a Map of configuration Strings.
> This means that the custom component needs to depend on both the WildFly Elytron project and the subsystem.
> It should be possible for components to add the following method without implementing the interface and be configurable.
> {noformat}
> void initialize(final Map<String, String> configuration);
> {noformat}
> We also have a long standing issue in that if we add a new component to WildFly Elytron it can not be used until we can add a resource to configure it. By supporting configurable custom components without needing a dependency on the subsystem new components added to WildFly Elytron could be usable whilst the subsystem definitions catch up.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month