[JBoss JIRA] (WFLY-13811) The org.jboss.as.ejb3 module dependency on org.jboss.as.remoting is not optional
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13811:
---------------------------------------
Summary: The org.jboss.as.ejb3 module dependency on org.jboss.as.remoting is not optional
Key: WFLY-13811
URL: https://issues.redhat.com/browse/WFLY-13811
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The WFLY-13423 changes weren't enough to make EJB3's dep on org.jboss.as.remoting optional as AssociationService/AssociationImpl are installed from the subsystem root
and use RemotingConnectorBindingInfoService/RemotingConnectorInfo.
I'll file other JIRAs to make it possible to cut this connection, but for now the dep should not be optional.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (WFLY-13809) Get application name from BatchEnvironment instead of jndi lookup
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13809?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13809:
------------------------------
Description:
AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently.
Need to adjust {{BatchEnvironmentService}} to provide application name.
was:AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently.
> Get application name from BatchEnvironment instead of jndi lookup
> -----------------------------------------------------------------
>
> Key: WFLY-13809
> URL: https://issues.redhat.com/browse/WFLY-13809
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch
> Affects Versions: 20.0.1.Final
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
>
> AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently.
> Need to adjust {{BatchEnvironmentService}} to provide application name.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (WFLY-13809) Get application name from BatchEnvironment instead of jndi lookup
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13809?page=com.atlassian.jira.plugi... ]
Cheng Fang moved JBERET-496 to WFLY-13809:
------------------------------------------
Project: WildFly (was: JBeret)
Key: WFLY-13809 (was: JBERET-496)
Component/s: Batch
(was: jberet-core)
Affects Version/s: 20.0.1.Final
(was: 1.4.0.Alpha1)
Fix Version/s: (was: 1.4.0.Final)
> Get application name from BatchEnvironment instead of jndi lookup
> -----------------------------------------------------------------
>
> Key: WFLY-13809
> URL: https://issues.redhat.com/browse/WFLY-13809
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch
> Affects Versions: 20.0.1.Final
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
>
> AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac updated WFWIP-339:
------------------------------
Description:
It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
{quote}
16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
{quote}
There are two questions from this:
# Is this change of OpenSSL provider being initialized during the boot in this configuration case expected?
# I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE.
Hope I don't have any misconfiguration in the configuration itself.
was:
It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
{quote}
16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
{quote}
> OpenSSL security provider seems to be used when not defined now
> ---------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
> There are two questions from this:
> # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected?
> # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE.
> Hope I don't have any misconfiguration in the configuration itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac updated WFWIP-339:
------------------------------
Steps to Reproduce:
# unzip server
# copy `server.jks`, `client.jks` and `standalone-full.xml` files into the `EAP_HOME/standalone/configuration` directory
# start server
{code:java}
./bin/standalone.sh -c standalone-full.xml
{code}
# see relevant `WFOPENSSL0002` message is present during the server boot
was:
# unzip server
# copy `server.jks`, `client.jks` and `standalone-full.xml` files into the `EAP_HOME/standalone/configuration` directory
# start server
{code}
./bin/standalone.sh -c standalone-full.xml
{code}
> OpenSSL security provider seems to be used when not defined now
> ---------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac updated WFWIP-339:
------------------------------
Attachment: client.jks
server.jks
standalone-full.xml
> OpenSSL security provider seems to be used when not defined now
> ---------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months