[JBoss JIRA] (WFLY-4699) Expose EJB3 deployment information at runtime
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-4699?page=com.atlassian.jira.plugin... ]
Cheng Fang commented on WFLY-4699:
----------------------------------
Analysis document proposal: https://github.com/wildfly/wildfly-proposals/pull/271
> Expose EJB3 deployment information at runtime
> ---------------------------------------------
>
> Key: WFLY-4699
> URL: https://issues.redhat.com/browse/WFLY-4699
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Bilgehan Ozpeynirci
> Assignee: Cheng Fang
> Priority: Minor
> Fix For: 19.0.0.Beta1
>
>
> User will be able to get EJB Deployment Information at runtime for the following areas:
> - Class name
> - Local JNDI name
> - Remote JNDI name
> - Security roles
> - Bean statistics (beans in use, access count, idle count, ...)
> - Destination JNDI (for MDBs)
> - Activation config properties
> - EJB timeout (Stateful Timeouts , and Stateless Instance timeout)
> A lot of this information were previously (EAP 5) obtained from the deployment descriptor that was published by the bean ("deploymentDescriptor" attribute). In the past, this metadata could be retrieved from EAP 5 via jmx which no longer exists in EAP 6+ (JBoss AS 7+). Now with EJB 3, users provide that information through annotations (and also through the Deployment Descriptor file), so users need means to get those informations at runtime.
> The goal of this is not only for MDB but for all kinds of EJB (session, stateful, MDB, ...)
> MORE INFO:
> The local and remote JNDI are related to Session EJBs.
> However we need to access the JNDI of the destination configured for the MDB.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFWIP-284) Clarify what is invalid header name
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFWIP-284?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFWIP-284:
----------------------------------------
The definition of a HTTP Header is defined here : -
https://tools.ietf.org/html/rfc2616#page-31
{noformat}
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
{noformat}
The field name is a token.
The definition of token is defined here: -
https://tools.ietf.org/html/rfc2616#page-17
{noformat}
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
{noformat}
RFC2616 specifically prohibits the use of the characters you are attempting to use in a HTTP header name.
> Clarify what is invalid header name
> -----------------------------------
>
> Key: WFWIP-284
> URL: https://issues.redhat.com/browse/WFWIP-284
> Project: WildFly WIP
> Issue Type: Task
> Reporter: Tomas Terem
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: management
>
> Header names should follow rules described here:
> https://tools.ietf.org/html/rfc5322#section-2.2
> However, rules for custom headers seems to be more restrictive - for example @ or = are not allowed.
> I see that these characters are mentioned in https://tools.ietf.org/html/rfc2616#page-16, but it only says that they should be in quotes. However I am not able to configure header containing them in quotes either.
> Is this on purpose?
> If yes, this needs to be mentioned in analysis&documentation. If not, we need to create critical JBEAP jira for 7.4
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFLY-12861) microprofile-config subsystem should not expose smallrye implementation to deployments
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-12861?page=com.atlassian.jira.plugi... ]
Paul Ferraro edited comment on WFLY-12861 at 12/11/19 9:32 AM:
---------------------------------------------------------------
We can probably generalize this into a "multiple deployments & smallrye" topic - as that's when reliance on TCCL becomes problematic (and, to your point, has security implications).
was (Author: pferraro):
We can probably generalize this into a "multiple deployments & smallrye" topic - as that's when reliance on TCCL becomes problematic.
> microprofile-config subsystem should not expose smallrye implementation to deployments
> --------------------------------------------------------------------------------------
>
> Key: WFLY-12861
> URL: https://issues.redhat.com/browse/WFLY-12861
> Project: WildFly
> Issue Type: Bug
> Components: MP Config
> Affects Versions: 18.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Smallrye is an implementation detail of the specification and should not be exposed to deployments. It seems the only reasons to expose io.smallrye.config to a deployment is to allow CDI to dynamically load its portable extension. Registering these manually removes that requirement.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFLY-12861) microprofile-config subsystem should not expose smallrye implementation to deployments
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-12861?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-12861:
-----------------------------------------
+1 We are using the SmallRye libraries slightly differently to how they have been used so far, in the case of JWT I had an issue where a static was used to cache state - this was fine when included in the deployments class loader but once we have a shared module the static became shared.
> microprofile-config subsystem should not expose smallrye implementation to deployments
> --------------------------------------------------------------------------------------
>
> Key: WFLY-12861
> URL: https://issues.redhat.com/browse/WFLY-12861
> Project: WildFly
> Issue Type: Bug
> Components: MP Config
> Affects Versions: 18.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Smallrye is an implementation detail of the specification and should not be exposed to deployments. It seems the only reasons to expose io.smallrye.config to a deployment is to allow CDI to dynamically load its portable extension. Registering these manually removes that requirement.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFLY-12861) microprofile-config subsystem should not expose smallrye implementation to deployments
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-12861?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on WFLY-12861:
-------------------------------------
We can probably generalize this into a "multiple deployments & smallrye" topic - as that's when reliance on TCCL becomes problematic.
> microprofile-config subsystem should not expose smallrye implementation to deployments
> --------------------------------------------------------------------------------------
>
> Key: WFLY-12861
> URL: https://issues.redhat.com/browse/WFLY-12861
> Project: WildFly
> Issue Type: Bug
> Components: MP Config
> Affects Versions: 18.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Smallrye is an implementation detail of the specification and should not be exposed to deployments. It seems the only reasons to expose io.smallrye.config to a deployment is to allow CDI to dynamically load its portable extension. Registering these manually removes that requirement.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFWIP-250) How to install operator to watch list of namespaces?
by Petr Kremensky (Jira)
[ https://issues.redhat.com/browse/WFWIP-250?page=com.atlassian.jira.plugin... ]
Petr Kremensky resolved WFWIP-250.
----------------------------------
Resolution: Done
> How to install operator to watch list of namespaces?
> ----------------------------------------------------
>
> Key: WFWIP-250
> URL: https://issues.redhat.com/browse/WFWIP-250
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> We do not have eap operator on the stage OperatorHub WFWIP-232, so I could not try myself. But this questions arise.
> {code:yaml|title=deploy/configmap-eap-operator.gen.yaml}
> ...
> deployments:
> - name: eap-operator
> spec:
> replicas: 1
> selector:
> matchLabels:
> name: eap-operator
> strategy: {}
> template:
> metadata:
> labels:
> name: eap-operator
> spec:
> containers:
> - command:
> - wildfly-operator
> env:
> - name: WATCH_NAMESPACE
> valueFrom:
> fieldRef:
> fieldPath: metadata.annotations['olm.targetNamespaces']
> ...
> {code}
> {code:yaml|title=deploy/operator-group.yaml}
> apiVersion: operators.coreos.com/v1
> kind: OperatorGroup
> metadata:
> name: example
> namespace: eap-operator
> spec:
> targetNamespaces:
> - eap-operator
> {code}
> 1. Does it mean operator by default watch only {{eap-operator}} namespace? Will that be parametrized in Web Console?
> 2. If user want to install operator to watch multiple/all namespaces how should he do? Will that be exposed in Web Console?
> If I try to edit {{WATCH_NAMESPACE}} on eap-operator Deployment it is owerwriten back to
> {code}
> valueFrom:
> fieldRef:
> apiVersion: v1
> fieldPath: 'metadata.annotations[''olm.targetNamespaces'']'
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFWIP-250) How to install operator to watch list of namespaces?
by Petr Kremensky (Jira)
[ https://issues.redhat.com/browse/WFWIP-250?page=com.atlassian.jira.plugin... ]
Petr Kremensky commented on WFWIP-250:
--------------------------------------
Works as generally described at https://access.redhat.com/documentation/en-us/openshift_container_platfor...
> How to install operator to watch list of namespaces?
> ----------------------------------------------------
>
> Key: WFWIP-250
> URL: https://issues.redhat.com/browse/WFWIP-250
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> We do not have eap operator on the stage OperatorHub WFWIP-232, so I could not try myself. But this questions arise.
> {code:yaml|title=deploy/configmap-eap-operator.gen.yaml}
> ...
> deployments:
> - name: eap-operator
> spec:
> replicas: 1
> selector:
> matchLabels:
> name: eap-operator
> strategy: {}
> template:
> metadata:
> labels:
> name: eap-operator
> spec:
> containers:
> - command:
> - wildfly-operator
> env:
> - name: WATCH_NAMESPACE
> valueFrom:
> fieldRef:
> fieldPath: metadata.annotations['olm.targetNamespaces']
> ...
> {code}
> {code:yaml|title=deploy/operator-group.yaml}
> apiVersion: operators.coreos.com/v1
> kind: OperatorGroup
> metadata:
> name: example
> namespace: eap-operator
> spec:
> targetNamespaces:
> - eap-operator
> {code}
> 1. Does it mean operator by default watch only {{eap-operator}} namespace? Will that be parametrized in Web Console?
> 2. If user want to install operator to watch multiple/all namespaces how should he do? Will that be exposed in Web Console?
> If I try to edit {{WATCH_NAMESPACE}} on eap-operator Deployment it is owerwriten back to
> {code}
> valueFrom:
> fieldRef:
> apiVersion: v1
> fieldPath: 'metadata.annotations[''olm.targetNamespaces'']'
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months