October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1054) Better subsystem test coverage

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1054?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1054: ------------------------------------------ Shouldn't this be rescheduled for 3? > Better subsystem test coverage > ------------------------------ > > Key: WFCORE-1054 > URL: https://issues.jboss.org/browse/WFCORE-1054 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 2.0.0.CR8 > > > The subsystem and core-model tests should be expanded to test FULL models. In many(?) cases these tests do not use a full xml. We should generate a full xml file for testing, possibly by using the schema. Or by inspecting the resource registrations a bit similar to the ExpressionSupportTestCase. > We might need something to deal with the case where e.g. a parent expects only one of two children to be set (i.e. there is a choice) and not both. In those cases it would be good to be able to test all possible permutations. This testing should be at least the parsing and marshalling of the main model. It is uncertain whether it will be possible to do do transformers, although perhaps we could do something like the DomainAdjusters from the mixed domain tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1053) Model compatibility tests

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1053?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1053: ------------------------------------------ Shouldn't this be rescheduled for 3? > Model compatibility tests > ------------------------- > > Key: WFCORE-1053 > URL: https://issues.jboss.org/browse/WFCORE-1053 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 2.0.0.CR8 > > > Once the infrastructure is in place, we will need to test all subsystems here and in WildFly. > The basic idea is some variety of CompareModelVersionsUtil and compare the current resource registrations against a stored snapshot of the resource registrations -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5539) Infinispan subsystem attributes are not persisted

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5539?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-5539: ------------------------------------ [~mbabacek] You can use a cache container configured in the infinispan subsystem and still programmatically configure a cache (with indexing) that uses that cache-container. Indexing as a subsystem configuration option isn't going to be supported in WF10. > Infinispan subsystem attributes are not persisted > ------------------------------------------------- > > Key: WFLY-5539 > URL: https://issues.jboss.org/browse/WFLY-5539 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR2 > Reporter: Michal Karm Babacek > Assignee: Paul Ferraro > Priority: Critical > Fix For: 10.0.0.CR4 > > > Certain cache configuration attributes are not persisted after reload. I find this issue being a critical one because if effectively prevents me from enabling indexing on my custom caches. > For instance, there are no attributes *indexing* nor *batching* in the [jboss-as-infinispan_4_0.xsd|https://github.com/wildfly/wildfly/blob/maste...], whereas CLI allows one to set these; nonetheless in vain, because the values are not persisted. > {noformat} > [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=batching) > { > "outcome" => "success", > "result" => false > } > [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=indexing) > { > "outcome" => "success", > "result" => "NONE" > } > [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:write-attribute(name=indexing,value=ALL) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:write-attribute(name=batching,value=true) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] reload > [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=indexing) > { > "outcome" => "success", > "result" => "NONE" > } > [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=batching) > { > "outcome" => "success", > "result" => false > } > {noformat} > Is there any other way how one could enable indexing on one's cache? E.g. my cache: > {code} > <replicated-cache name="BLACKLIST_CACHE" mode="ASYNC"> > <locking acquire-timeout="60000" concurrency-level="3000" isolation="REPEATABLE_READ"/> > <transaction mode="NONE"/> > <eviction max-entries="10000000" strategy="NONE"/> > <expiration interval="-1" lifespan="-1" max-idle="-1"/> > <file-store/> > <state-transfer timeout="300000"/> > </replicated-cache> > {code} Obviously, adding aforementioned attributes to the cache element results in an XML parsing error... > Last but not least, is there any way how to circumvent the bug and force indexing so as to avoid deadly exceptions such as: {noformat}java.lang.IllegalArgumentException: Indexing was not enabled on this cache. interface org.hibernate.search.spi.SearchIntegrator not found in registry{noformat}? I'm very well aware of the possibility to configure the whole cache programatically in runtime using CacheManager -- but that is the very situation I was trying to migrate away from. > Thx for comments. > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1062) Deployments from the domain/data/content folder goes missing after few minutes if the Host controller is started with --backup option.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1062?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1062: ------------------------------------- Priority: Blocker (was: Major) > Deployments from the domain/data/content folder goes missing after few minutes if the Host controller is started with --backup option. > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1062 > URL: https://issues.jboss.org/browse/WFCORE-1062 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR7 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Blocker > Fix For: 2.0.0.CR8 > > > Host controller started with --backup option deletes the deployments from the domain/data/content folder after approximately 10 mins. > The deployment is restored or recreated if the HostController is started. > Version-Release number of selected component (if applicable): 6.4.x > How reproducible: > Steps to Reproduce: > > 1. Setup domaincontroller > 2. Setup hostcontroller > 3. Start domaincontroller > 4. Start hostcontroller with --backup option. > 5. deploy an application using cli or admin console > ./jboss-cli.sh --connect --controller=x.x.x.x:9999 --command='deploy /PathToApp/App.war --server-groups=main-server-group' > 6. deployments are available under $JBOSS_HOME/domain/data/content > 7. Wait for approximately 10 minutes > 8. Cached deployments are deleted on hostcontroller (domain/data/content is empty). Following is the logging seen on the console : > ++++++++++++++ > [Host Controller] 14:20:40,439 INFO [org.jboss.as.repository] (Host Controller Service Threads - 4) JBAS014903: Content /NotBackedUp/JAR-Folder/EAPs/EAP6/jboss-eap-6.4.3-Patched/domain/data/content/47/1108a27fa1b82e6a92fb56ee25bc76f2625249 is obsolete and will be removed > [Host Controller] 14:20:40,440 INFO [org.jboss.as.repository] (Host Controller Service Threads - 4) JBAS014901: Content removed from location /NotBackedUp/JAR-Folder/EAPs/EAP6/jboss-eap-6.4.3-Patched/domain/data/content/47/1108a27fa1b82e6a92fb56ee25bc76f2625249/content > ++++++++++++++ > 9. After restarting the Host Controller, the deployment is restored and the cached deployment can now be seen under the Host Controller's domain/data/content folder. > Actual results: Deployment folder form domain/data/content folder gets deleted after approx 10 mins and are restored if the Host Controller is restarted > Expected results: The cached deplpyments folder should never be removed from the HostController's domain/data/content folder. > Additional info: This does not affect the availability of the application since the applications are also availbale with the assigned server's under their data/content folder. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1062) Deployments from the domain/data/content folder goes missing after few minutes if the Host controller is started with --backup option.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1062?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1062: ------------------------------------- Fix Version/s: 2.0.0.CR8 > Deployments from the domain/data/content folder goes missing after few minutes if the Host controller is started with --backup option. > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1062 > URL: https://issues.jboss.org/browse/WFCORE-1062 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR7 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Blocker > Fix For: 2.0.0.CR8 > > > Host controller started with --backup option deletes the deployments from the domain/data/content folder after approximately 10 mins. > The deployment is restored or recreated if the HostController is started. > Version-Release number of selected component (if applicable): 6.4.x > How reproducible: > Steps to Reproduce: > > 1. Setup domaincontroller > 2. Setup hostcontroller > 3. Start domaincontroller > 4. Start hostcontroller with --backup option. > 5. deploy an application using cli or admin console > ./jboss-cli.sh --connect --controller=x.x.x.x:9999 --command='deploy /PathToApp/App.war --server-groups=main-server-group' > 6. deployments are available under $JBOSS_HOME/domain/data/content > 7. Wait for approximately 10 minutes > 8. Cached deployments are deleted on hostcontroller (domain/data/content is empty). Following is the logging seen on the console : > ++++++++++++++ > [Host Controller] 14:20:40,439 INFO [org.jboss.as.repository] (Host Controller Service Threads - 4) JBAS014903: Content /NotBackedUp/JAR-Folder/EAPs/EAP6/jboss-eap-6.4.3-Patched/domain/data/content/47/1108a27fa1b82e6a92fb56ee25bc76f2625249 is obsolete and will be removed > [Host Controller] 14:20:40,440 INFO [org.jboss.as.repository] (Host Controller Service Threads - 4) JBAS014901: Content removed from location /NotBackedUp/JAR-Folder/EAPs/EAP6/jboss-eap-6.4.3-Patched/domain/data/content/47/1108a27fa1b82e6a92fb56ee25bc76f2625249/content > ++++++++++++++ > 9. After restarting the Host Controller, the deployment is restored and the cached deployment can now be seen under the Host Controller's domain/data/content folder. > Actual results: Deployment folder form domain/data/content folder gets deleted after approx 10 mins and are restored if the Host Controller is restarted > Expected results: The cached deplpyments folder should never be removed from the HostController's domain/data/content folder. > Additional info: This does not affect the availability of the application since the applications are also availbale with the assigned server's under their data/content folder. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5553) Remove unneeded messages from deprecated batch subsystem

by James Perkins (JIRA)

James Perkins created WFLY-5553: ----------------------------------- Summary: Remove unneeded messages from deprecated batch subsystem Key: WFLY-5553 URL: https://issues.jboss.org/browse/WFLY-5553 Project: WildFly Issue Type: Task Components: Batch Reporter: James Perkins Assignee: James Perkins The deprecated batch subsystem still contains i18n messages which clash with the {{batch-jberet}} subsystem. These messages are not used and should be removed. A review the LocalDescriptions.properties should be done too. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-335) ServerAuthenticationContext state machine is incorrect

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-335?page=com.atlassian.jira.plugin.sy... ] David Lloyd resolved ELY-335. ----------------------------- Fix Version/s: 1.1.0.Alpha2 Resolution: Done > ServerAuthenticationContext state machine is incorrect > ------------------------------------------------------ > > Key: ELY-335 > URL: https://issues.jboss.org/browse/ELY-335 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Critical > Fix For: 1.1.0.Alpha2 > > > The state machine should allow the name to be re-set repeatedly as long as the authentication principal is unchanged. The state machine should allow authorization and repeated run-as authorization changes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5552) Upgrade PicketLink to 2.5.5.SP1

by Pedro Igor (JIRA)

Pedro Igor created WFLY-5552: -------------------------------- Summary: Upgrade PicketLink to 2.5.5.SP1 Key: WFLY-5552 URL: https://issues.jboss.org/browse/WFLY-5552 Project: WildFly Issue Type: Component Upgrade Components: Security Affects Versions: 10.0.0.CR3 Reporter: Pedro Igor Assignee: Pedro Igor -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1064) Creating named multicast socket doesn't properly register socket using name

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1064?page=com.atlassian.jira.plugi... ] Paul Ferraro reassigned WFCORE-1064: ------------------------------------ Assignee: Brian Stansberry (was: Paul Ferraro) > Creating named multicast socket doesn't properly register socket using name > --------------------------------------------------------------------------- > > Key: WFCORE-1064 > URL: https://issues.jboss.org/browse/WFCORE-1064 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR7 > Reporter: Paul Ferraro > Assignee: Brian Stansberry > > I'm not sure why this is, but the socket binding manager ignores the name of the multicast socket and registers the socket using the unnamed registry. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1063) Creating named datagram socket throws ISE

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1063?page=com.atlassian.jira.plugi... ] Paul Ferraro reassigned WFCORE-1063: ------------------------------------ Assignee: Brian Stansberry (was: Paul Ferraro) > Creating named datagram socket throws ISE > ----------------------------------------- > > Key: WFCORE-1063 > URL: https://issues.jboss.org/browse/WFCORE-1063 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR7 > Reporter: Paul Ferraro > Assignee: Brian Stansberry > > The DatagramSocket createDatagramSocket(String name, SocketAddress address) method of org.jboss.as.network.SocketBindingManagerImpl creates a ManagedDatagramSocketBinding with a null name, yet registers the socket using the NamedManagedBindingRegistry. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2015