[JBoss JIRA] (WFLY-11879) Add a more in-depth section in the docs covering authentication.
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-11879:
---------------------------------------
Summary: Add a more in-depth section in the docs covering authentication.
Key: WFLY-11879
URL: https://issues.jboss.org/browse/WFLY-11879
Project: WildFly
Issue Type: Task
Components: Documentation, Security
Reporter: Darran Lofthouse
Fix For: 17.0.0.Beta1
A detailed authentication section, this will be huge but I don't think we have a clear picture of how the different pieces really come together i.e. realms, domains, mappers and decoders and subsequently the authentication factories.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Matej Novotny commented on WFLY-11858:
--------------------------------------
bq. Martin Kouba I thought it's the container (WFLY) which would provide that. That's not right?
That is right. However, the question is where precisely is it coming from? EJB subsystem? Some other integration layer? CDI/Weld certainly doesn't provide {{InitialContext}} as a bean.
If we knew that, we could then look into why you sometimes can sometimes cannot select that bean.
As for proposed solution - that _should_ work because you no longer require CDI to get instance of {{InitialContext}}.
Though I am not sure you will get the correct instance? Not all that familiar with {{InitialContext}}, but I would expect some sharing of instances whereas here you basically create new one for each {{JNDIBean}} created.
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka edited comment on WFLY-11858 at 3/20/19 6:21 AM:
-----------------------------------------------------------------
[~mkouba] I thought it's the container (WFLY) which would provide that. That's not right?
[~mkouba][~manovotn] do you think this type of change would be reasonable? : https://github.com/ochaloup/narayana/commit/964222d60c6f64849430057cd744d...
Does have some difference to do {{CDI.current().select(InitialContext.class).get().lookup(this.name)}} against the {{new InitialContext().lookup(this.name)}}?
[~rakcheru] I'm still not sure how to reproduce your issue. Do you think you have time to try how your case behaves with the [code changed referenced above|https://github.com/ochaloup/narayana/commit/964222d60c6f64849430057... If so I would provide you detailed steps for Narayana code base compilation and updating the module in WFLY.
was (Author: ochaloup):
[~mkouba] I thought it's the container (WFLY) which would provide that. That's not right?
[~mkouba][~manovotn] do you think this type of change would be reasonable? : https://github.com/ochaloup/narayana/commit/964222d60c6f64849430057cd744d...
Does have some difference to do {{CDI.current().select(InitialContext.class).get().lookup(this.name)}} against the {{new InitialContext().lookup(this.name)}}?
[~rakcheru] I'm still not sure how to reproduce your issue. Do you think you have time to try how your case behaves with the [code changed referenced above|https://github.com/ochaloup/narayana/commit/964222d60c6f64849430057... If you be so kind I would provide you detailed steps for Narayana code base compilation and updating the module in WFLY.
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-11858:
----------------------------------------
[~mkouba] I thought it's the container (WFLY) which would provide that. That's not right?
[~mkouba][~manovotn] do you think this type of change would be reasonable? : https://github.com/ochaloup/narayana/commit/964222d60c6f64849430057cd744d...
Does have some difference to do {{CDI.current().select(InitialContext.class).get().lookup(this.name)}} against the {{new InitialContext().lookup(this.name)}}?
[~rakcheru] I'm still not sure how to reproduce your issue. Do you think you have time to try how your case behaves with the [code changed referenced above|https://github.com/ochaloup/narayana/commit/964222d60c6f64849430057... If you be so kind I would provide you detailed steps for Narayana code base compilation and updating the module in WFLY.
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11727) QPid Proton-J version is lagging behind
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-11727?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet updated WFLY-11727:
-------------------------------------
Description:
When Artemis was upgraded, qpid proton-j version wasn't aligned.
We should align it with the version of Artemis : 0.31
was:
When Artemis was upgraded, qpid proton-j version wasn't aligned.
We should align it with the version of Artemis : 0.32
> QPid Proton-J version is lagging behind
> ---------------------------------------
>
> Key: WFLY-11727
> URL: https://issues.jboss.org/browse/WFLY-11727
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JMS
> Affects Versions: 16.0.0.Beta1
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Major
>
> When Artemis was upgraded, qpid proton-j version wasn't aligned.
> We should align it with the version of Artemis : 0.31
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (JGRP-2333) pbcast.GMS#getView returns ViewId as opposed to the View
by Radoslav Husar (Jira)
Radoslav Husar created JGRP-2333:
------------------------------------
Summary: pbcast.GMS#getView returns ViewId as opposed to the View
Key: JGRP-2333
URL: https://issues.jboss.org/browse/JGRP-2333
Project: JGroups
Issue Type: Bug
Reporter: Radoslav Husar
Assignee: Bela Ban
Basically org.jgroups.protocols.pbcast.GMS#getView is now identical to org.jgroups.protocols.pbcast.GMS#getViewId while the intention is to be able to see the current view.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-9407) Upgrade Artemis 2.6.3.jbossorg-001
by Seckin Pulatkan (Jira)
[ https://issues.jboss.org/browse/WFLY-9407?page=com.atlassian.jira.plugin.... ]
Seckin Pulatkan commented on WFLY-9407:
---------------------------------------
Hi [~jmesnil] We were using Wildfly 13.0.0 Final with remote connector to Artemis 2.6.2 server with following change on broker.xml
{code:xml|title=broker.xml acceptor definition}
<acceptor name="artemis">tcp://0.0.0.0:61616?anycastPrefix=jms.queue.;multicastPrefix=jms.topic.;
{code}
We wanted to upgrade to Wildfly 15.0.1 Final but we noticed that topics are created with prefix "jms.topic." . I tried to find a configuration to disable it but it did not work
{code:xml|title=standalone.xml system property}
<property name="org.apache.activemq.artemis.api.jms.ActiveMQJMSClient.enable1xPrefixes" value="false" />
{code}
With WFLY-9407, it seems this flag is set to true explicitly (ActiveMQResourceAdapter constructor and ConnectionFactoryAdd.createConfiguration method). And still it is true on master branch. Will this be the case on all future releases of Wildfly or will there be a configuration to disable 1x prefixes? Since we had the topics and queues without the prefix on our active environments, we would like to use without prefix. For consumers, we can set topicPrefix as ActivationConfigProperty but while producing the message, the messages are being set to the topic with "jms.topic." prefix.
> Upgrade Artemis 2.6.3.jbossorg-001
> ----------------------------------
>
> Key: WFLY-9407
> URL: https://issues.jboss.org/browse/WFLY-9407
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Major
> Labels: downstream_dependency
> Fix For: 14.0.0.Final
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11873) JGroups subsystem pbcast.GMS/view attribute only shows the viewID
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11873?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-11873:
----------------------------------
Summary: JGroups subsystem pbcast.GMS/view attribute only shows the viewID (was: JGroups subsystem pbcast.GMS/view attribute shows outdated value)
> JGroups subsystem pbcast.GMS/view attribute only shows the viewID
> -----------------------------------------------------------------
>
> Key: WFLY-11873
> URL: https://issues.jboss.org/browse/WFLY-11873
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Affects Versions: 16.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> {code}
> [standalone@127.0.0.1:10190 /] /subsystem=jgroups/channel=ee/protocol=pbcast.GMS:read-resource(include-runtime=true
> {
> "outcome" => "success",
> "result" => {
> "after_creation_hook" => undefined,
> "coord" => false,
> "ergonomics" => true,
> "flush_invoker_class" => undefined,
> "id" => 12,
> "implementation" => "ParticipantGmsImpl",
> "install_view_locally_first" => true,
> "is_leaving" => false,
> "join_timeout" => 3000L,
> "leave_timeout" => 3000L,
> "level" => undefined,
> "local_address" => "node3",
> "log_collect_msgs" => false,
> "log_view_warnings" => true,
> "max_bundling_time" => 50L,
> "max_join_attempts" => 10L,
> "members" => "(2) node2,node3",
> "merge_id" => undefined,
> "merge_in_progress" => false,
> "merge_killer_running" => false,
> "merge_task_running" => false,
> "merge_timeout" => 5000L,
> "num_members" => 2,
> "num_prev_mbrs" => 50,
> "num_prev_views" => 10,
> "number_of_views" => 0,
> "print_local_addr" => false,
> "print_physical_addrs" => true,
> "stats" => false,
> "use_delta_views" => true,
> "use_flush_if_present" => true,
> "view" => "[node2|1]",
> "view_ack_collection_timeout" => 2000L,
> "view_bundling" => true,
> "view_handler_size" => 0,
> "view_handler_suspended" => false
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months