[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6554:
------------------------------------
Can you post your hibernate configuration file?
> Cache configuration are not eagerly defined in Cache Container
> --------------------------------------------------------------
>
> Key: WFLY-6554
> URL: https://issues.jboss.org/browse/WFLY-6554
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration.
> In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc.
> This trick has only one bad side effect, which was the creation of unecessary caches.
> Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not.
> I do not know if this is a bug or this is by design but this seems wrong to me.
> If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there.
> I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started").
> Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFCORE-1515) Improve PersistentResourceDefinition to make it easier to register attribute write handlers
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1515?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-1515:
--------------------------------
Summary: Improve PersistentResourceDefinition to make it easier to register attribute write handlers (was: Improve PeristentResourceDefinition to make it easier to register attribute write handlers)
> Improve PersistentResourceDefinition to make it easier to register attribute write handlers
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-1515
> URL: https://issues.jboss.org/browse/WFCORE-1515
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 3.0.0.Alpha1
>
>
> Currently if you want to take register custom write handler you need to override whole registerAttributes methods and do it yourself all the way.
> We could add PersistentResourceDefinition.getAttributeHandlers() method that returns
> a Map<String, OperationStepHandler>.
> And then registerAttributes uses the map instead of hardcoding ReloadRequiredWriteAttributeHandler. Default impl just fills the map values with
> ReloadRequiredWriteAttributeHandler.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFLY-6572) ageout-history does not report failures
by Bartosz Spyrko-Śmietanko (JIRA)
[ https://issues.jboss.org/browse/WFLY-6572?page=com.atlassian.jira.plugin.... ]
Bartosz Spyrko-Śmietanko reassigned WFLY-6572:
----------------------------------------------
Assignee: Bartosz Spyrko-Śmietanko (was: Jason Greene)
> ageout-history does not report failures
> ----------------------------------------
>
> Key: WFLY-6572
> URL: https://issues.jboss.org/browse/WFLY-6572
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Dennis Reed
> Assignee: Bartosz Spyrko-Śmietanko
>
> When ageout-history cannot delete the old CP files, it silently fails and returns "success".
> LocalAgeoutHistoryHandler#recursiveDelete does keep track of whether the
> delete failed or succeeded, but the return value from this method is ignored
> in execute(...).
> If recursiveDelete returns false, it should report a failure.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ELY-444) AuthorizationIdentity and PermissionMapper
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-444?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-444:
---------------------------------
BTW The way you do this is via the org.wildfly.security.auth.server.SecurityIdentity#intersectWith method. You can never increase the permission set of an identity with this method, but you can narrow it.
> AuthorizationIdentity and PermissionMapper
> ------------------------------------------
>
> Key: ELY-444
> URL: https://issues.jboss.org/browse/ELY-444
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI, Realms
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta6
>
>
> When we initially designed the PermissionMapper we went to certain lengths to avoid exposing details of the realm. But now as the API has evolved it is clear that the permission mapper will need access to more information. The AuthorizationIdentity (or perhaps another object which includes the AuthorizationIdentity) should be made available to the permission mapper.
> In addition, this object could be expanded to include more information about the authentication, for example mechanism-specific information, which can feed into the authorization decision and could be useful for other things. Examples include: authentication timestamp, mechanism name/kind, forwarding credentials, and other attributes which derive from the mechanism as opposed to the identity.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFCORE-1517) can't start server with configuration file from EAP 6.4.7 (and above)
by Ladislav Thon (JIRA)
Ladislav Thon created WFCORE-1517:
-------------------------------------
Summary: can't start server with configuration file from EAP 6.4.7 (and above)
Key: WFCORE-1517
URL: https://issues.jboss.org/browse/WFCORE-1517
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Ladislav Thon
Assignee: Brian Stansberry
Priority: Blocker
When trying to run EAP 7 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
{code}
14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
Message: Unexpected element '{urn:jboss:domain:1.8}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
... 3 more
14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFCORE-1517) can't start server with configuration file from EAP 6.4.7 (and above)
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1517?page=com.atlassian.jira.plugi... ]
Ladislav Thon updated WFCORE-1517:
----------------------------------
Description:
When trying to run WildFly 10 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
{code}
14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
Message: Unexpected element '{urn:jboss:domain:1.8}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
... 3 more
14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
was:
When trying to run EAP 7 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
{code}
14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
Message: Unexpected element '{urn:jboss:domain:1.8}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
... 3 more
14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
> can't start server with configuration file from EAP 6.4.7 (and above)
> ---------------------------------------------------------------------
>
> Key: WFCORE-1517
> URL: https://issues.jboss.org/browse/WFCORE-1517
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Priority: Blocker
>
> When trying to run WildFly 10 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
> {code}
> 14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
> Message: Unexpected element '{urn:jboss:domain:1.8}server'
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> ... 3 more
> 14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ELY-444) AuthorizationIdentity and PermissionMapper
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-444?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-444:
---------------------------------
I think we're already well-equipped for custom providers now: the security domain can now transform the SI to have any arbitrary permission enforcement model, even beyond permission mappers.
> AuthorizationIdentity and PermissionMapper
> ------------------------------------------
>
> Key: ELY-444
> URL: https://issues.jboss.org/browse/ELY-444
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI, Realms
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta6
>
>
> When we initially designed the PermissionMapper we went to certain lengths to avoid exposing details of the realm. But now as the API has evolved it is clear that the permission mapper will need access to more information. The AuthorizationIdentity (or perhaps another object which includes the AuthorizationIdentity) should be made available to the permission mapper.
> In addition, this object could be expanded to include more information about the authentication, for example mechanism-specific information, which can feed into the authorization decision and could be useful for other things. Examples include: authentication timestamp, mechanism name/kind, forwarding credentials, and other attributes which derive from the mechanism as opposed to the identity.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (JGRP-2058) Probe: add bundler type at runtime
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2058?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2058:
--------------------------------
The method to replace the bundler is {{TP.bundler(String type)}}. Examples:
* {{probe.sh op=UDP.bundler["sender-sends']}}
* {{probe.sh op=UDP.bundler["com.widgets.MyCustomBundler"]}}
> Probe: add bundler type at runtime
> ----------------------------------
>
> Key: JGRP-2058
> URL: https://issues.jboss.org/browse/JGRP-2058
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> Add a method to shutdown the old Bundler implementation in TP and create and start a new one. Argument should either be {{bundler_type}} or the fully qualified classname of a {{Bundler}} impl, so that unknown bundlers can also be created as long as the code is on the classpath.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months