[JBoss JIRA] (WFWIP-60) smallrye-config: Consider logging a message when properties with same key and ordinal are present
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFWIP-60?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil commented on WFWIP-60:
----------------------------------
[~mjurc] Consistent order for config source is fixed by https://github.com/smallrye/smallrye-config/pull/12.
I'll address the management operations in another WildFly PR once the subsystem is integrated
> smallrye-config: Consider logging a message when properties with same key and ordinal are present
> -------------------------------------------------------------------------------------------------
>
> Key: WFWIP-60
> URL: https://issues.jboss.org/browse/WFWIP-60
> Project: WildFly WIP
> Issue Type: Enhancement
> Components: MP Config
> Reporter: Michal Jurc
> Assignee: Jeff Mesnil
>
> Consider a deployment with default {{microprofile-config.properties}}:
> {code}managementDefault=Default value from default microprofile-config.properties{code}
> Deployment is deployed on server with the following {{ConfigSource}} defined:
> {code}[standalone@localhost:9990 /] /subsystem=microprofile-config-smallrye/config-source=testdefault:read-resource
> {
> "outcome" => "success",
> "result" => {
> "class" => undefined,
> "dir" => undefined,
> "ordinal" => 100,
> "properties" => {"managementDefault" => "Value from WildFly microprofile-config-smallrye config-source"}
> }
> }
> {code}
> Property {{"managementDefault"}} is always resolved to {{"Value from WildFly microprofile-config-smallrye config-source"}} in deployment.
> It would be useful to log a {{WARN}} level message when there is conflict like this with a notification of {{ConfigSources}} to save detective work in real world scenarios.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBVFS-206) [GSS](7.1.z) URL.getContent() returns VirtualFile instead of ImageProducer
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/JBVFS-206?page=com.atlassian.jira.plugin.... ]
Tomas Hofman moved JBEAP-15070 to JBVFS-206:
--------------------------------------------
Project: JBoss VFS (was: JBoss Enterprise Application Platform)
Key: JBVFS-206 (was: JBEAP-15070)
Workflow: classic default workflow (was: CDW with loose statuses v1)
Component/s: (was: VFS)
Affects Version/s: 3.2.12.Final
(was: 7.1.3.GA)
> [GSS](7.1.z) URL.getContent() returns VirtualFile instead of ImageProducer
> --------------------------------------------------------------------------
>
> Key: JBVFS-206
> URL: https://issues.jboss.org/browse/JBVFS-206
> Project: JBoss VFS
> Issue Type: Bug
> Affects Versions: 3.2.12.Final
> Environment: Windows XP
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> URL.getContent() behaves differently within JBoss than it does in a normal JVM. In our case, when a jar is used in a normal JVM, URL.getContent() returns an ImageProducer. When the same jar is used from within JBoss, a VirtualFile is returned which then causes a ClassCastException.
> Note: This worked fine in JBoss 4.2.3.GA.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFWIP-60) smallrye-config: Consider logging a message when properties with same key and ordinal are present
by Michal Jurc (JIRA)
[ https://issues.jboss.org/browse/WFWIP-60?page=com.atlassian.jira.plugin.s... ]
Michal Jurc commented on WFWIP-60:
----------------------------------
[~jmesnil] I think that having at least an arbitrary rule is better than inconsistence so that suggestion is fine by me :)
> smallrye-config: Consider logging a message when properties with same key and ordinal are present
> -------------------------------------------------------------------------------------------------
>
> Key: WFWIP-60
> URL: https://issues.jboss.org/browse/WFWIP-60
> Project: WildFly WIP
> Issue Type: Enhancement
> Components: MP Config
> Reporter: Michal Jurc
> Assignee: Jeff Mesnil
>
> Consider a deployment with default {{microprofile-config.properties}}:
> {code}managementDefault=Default value from default microprofile-config.properties{code}
> Deployment is deployed on server with the following {{ConfigSource}} defined:
> {code}[standalone@localhost:9990 /] /subsystem=microprofile-config-smallrye/config-source=testdefault:read-resource
> {
> "outcome" => "success",
> "result" => {
> "class" => undefined,
> "dir" => undefined,
> "ordinal" => 100,
> "properties" => {"managementDefault" => "Value from WildFly microprofile-config-smallrye config-source"}
> }
> }
> {code}
> Property {{"managementDefault"}} is always resolved to {{"Value from WildFly microprofile-config-smallrye config-source"}} in deployment.
> It would be useful to log a {{WARN}} level message when there is conflict like this with a notification of {{ConfigSources}} to save detective work in real world scenarios.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFWIP-60) smallrye-config: Consider logging a message when properties with same key and ordinal are present
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFWIP-60?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil commented on WFWIP-60:
----------------------------------
It is not specified in the spec (i.e. config source should have different ordinal).
In our implementation, order between 2 config source with the same ordinal is not specified.
(the code where we sort them is at https://github.com/smallrye/smallrye-config/blob/3b249ee0d13eb438d2ac3b07...).
We can improve this by using the config source name to provide at least consistent order when the ordinal is the same.
> smallrye-config: Consider logging a message when properties with same key and ordinal are present
> -------------------------------------------------------------------------------------------------
>
> Key: WFWIP-60
> URL: https://issues.jboss.org/browse/WFWIP-60
> Project: WildFly WIP
> Issue Type: Enhancement
> Components: MP Config
> Reporter: Michal Jurc
> Assignee: Jeff Mesnil
>
> Consider a deployment with default {{microprofile-config.properties}}:
> {code}managementDefault=Default value from default microprofile-config.properties{code}
> Deployment is deployed on server with the following {{ConfigSource}} defined:
> {code}[standalone@localhost:9990 /] /subsystem=microprofile-config-smallrye/config-source=testdefault:read-resource
> {
> "outcome" => "success",
> "result" => {
> "class" => undefined,
> "dir" => undefined,
> "ordinal" => 100,
> "properties" => {"managementDefault" => "Value from WildFly microprofile-config-smallrye config-source"}
> }
> }
> {code}
> Property {{"managementDefault"}} is always resolved to {{"Value from WildFly microprofile-config-smallrye config-source"}} in deployment.
> It would be useful to log a {{WARN}} level message when there is conflict like this with a notification of {{ConfigSources}} to save detective work in real world scenarios.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10339:
------------------------------------
[~pferraro] I'll assign this issue to you. Please note that this is impacted by WFLY-10518 as the discovery-group resource (among others) will be moved from under /subsystem=messaging-activemq/server=* to be directly under /subsystem=messaging-activemq.
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Jeff Mesnil
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-9064) HibernateNativeAPINaturalIdTestCase fails with security manager
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9064?page=com.atlassian.jira.plugin.... ]
Romain Pelisse reassigned WFLY-9064:
------------------------------------
Assignee: Scott Marlow (was: Romain Pelisse)
> HibernateNativeAPINaturalIdTestCase fails with security manager
> ---------------------------------------------------------------
>
> Key: WFLY-9064
> URL: https://issues.jboss.org/browse/WFLY-9064
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Test Suite
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Scott Marlow
> Priority: Critical
> Labels: security-manager
>
> {{HibernateNativeAPINaturalIdTestCase}} fails with security manager because of missing permission {{"("java.lang.RuntimePermission" "createClassLoader")"}}:
> {noformat}
> javax.ejb.EJBException: java.lang.RuntimeException: Could not setup config
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.StatefulBMTInterceptor.handleInvocation(StatefulBMTInterceptor.java:96)
> ...
> Caused by: java.lang.RuntimeException: Could not setup config
> at org.jboss.as.test.integration.hibernate.naturalid.SFSBHibernateSFNaturalId.setupConfig(SFSBHibernateSFNaturalId.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createClassLoader")" in code source "(vfs:/content/hibernate4naturalid_test.ear/beans.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.hibernate4naturalid_test.ear.beans.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
> at org.wildfly.security.manager.WildFlySecurityManager.checkCreateClassLoader(WildFlySecurityManager.java:308)
> ...
> {noformat}
> After adding the permission, there is another missing permission {{"("java.io.FilePermission" "/home/okotek/git/wildfly/dist/target/wildfly-11.0.0.Beta1-SNAPSHOT/modules/system/layers/base/org/hibernate/main/hibernate-envers-5.1.8.Final.jar" "read")"}}. A privileged section is missing probably.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFWIP-60) smallrye-config: Consider logging a message when properties with same key and ordinal are present
by Michal Jurc (JIRA)
[ https://issues.jboss.org/browse/WFWIP-60?page=com.atlassian.jira.plugin.s... ]
Michal Jurc commented on WFWIP-60:
----------------------------------
[~jmesnil]: What exactly is the mechanism for picking which {{config-source}} will be used if both have the same property and ordinal by the way? That may be useful to be documented eventually too and I cannot find it anywhere in the spec either.
> smallrye-config: Consider logging a message when properties with same key and ordinal are present
> -------------------------------------------------------------------------------------------------
>
> Key: WFWIP-60
> URL: https://issues.jboss.org/browse/WFWIP-60
> Project: WildFly WIP
> Issue Type: Enhancement
> Components: MP Config
> Reporter: Michal Jurc
> Assignee: Jeff Mesnil
>
> Consider a deployment with default {{microprofile-config.properties}}:
> {code}managementDefault=Default value from default microprofile-config.properties{code}
> Deployment is deployed on server with the following {{ConfigSource}} defined:
> {code}[standalone@localhost:9990 /] /subsystem=microprofile-config-smallrye/config-source=testdefault:read-resource
> {
> "outcome" => "success",
> "result" => {
> "class" => undefined,
> "dir" => undefined,
> "ordinal" => 100,
> "properties" => {"managementDefault" => "Value from WildFly microprofile-config-smallrye config-source"}
> }
> }
> {code}
> Property {{"managementDefault"}} is always resolved to {{"Value from WildFly microprofile-config-smallrye config-source"}} in deployment.
> It would be useful to log a {{WARN}} level message when there is conflict like this with a notification of {{ConfigSources}} to save detective work in real world scenarios.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years