[JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves Remnants in standalone.xml
by Chris Giddings (JIRA)
[ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.... ]
Chris Giddings commented on WFLY-9681:
--------------------------------------
h2. DETAILS
[~dlofthouse] Understood. This is why I included the [StackOverflow ID|https://stackoverflow.com/questions/47700782/i-deleted-the-exampleds-f...], but for the sake of brevity and simplicity I understand.
Here is that StackOverflow user's error:
{code:java}
"WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.jboss.datasources.ExampleDS"], "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.WebJ2EE.WebJ2EE.DefaultDataSource is missing [jboss.naming.context.java.jboss.datasources.ExampleDS]"] } 18:32:10,189 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "WebJ2EE.war" (runtime-name : "WebJ2EE.war") 18:32:10,189 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report WFLYCTL0184: New missing/unsatisfied dependencies: service jboss.naming.context.java.jboss.datasources.ExampleDS (missing) dependents: [service jboss.naming.context.java.module.WebJ2EE.WebJ2EE.DefaultDataSource]
{code}
This error is nearly identical to my own with exception to dates/times etc. I chose to rely upon the already existing StackOverflow request vs creating a duplicate of it, or again reproducing the issue from scratch which I have done several times now. Apologies if that's a bit lazy.
h2. RESPONSE
Yes, the default configuration contains the offending 'Example' details. Regardless of this, deleting an 'Example' item from default configuration should probably not lead to manual intervention in configuration files. I think it reasonable that any administrator may assume all references to a deleted 'Example' resource to also be removed when that resource is deleted. If the resource were required by the system (it does not appear to be), it should likely then not be labeled as 'Example'.
> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
> Key: WFLY-9681
> URL: https://issues.jboss.org/browse/WFLY-9681
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 11.0.0.Final
> Reporter: Chris Giddings
> Assignee: Stefano Maestri
> Priority: Minor
> Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves Remnants in standalone.xml
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-9681:
----------------------------------------
For an issue like this it would help if in the bug report you can include the actual error message you see and also show the configuration you are referring to that is left behind.
I only find 3 uses of the word 'Example' in the default configuration, generally when an administrator removes a resource they should be updating references to that resource first.
> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
> Key: WFLY-9681
> URL: https://issues.jboss.org/browse/WFLY-9681
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 11.0.0.Final
> Reporter: Chris Giddings
> Assignee: Stefano Maestri
> Priority: Minor
> Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves Remnants in standalone.xml
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-9681:
--------------------------------------
Assignee: Stefano Maestri (was: Jason Greene)
> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
> Key: WFLY-9681
> URL: https://issues.jboss.org/browse/WFLY-9681
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 11.0.0.Final
> Reporter: Chris Giddings
> Assignee: Stefano Maestri
> Priority: Minor
> Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves Remnants in standalone.xml
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-9681:
-----------------------------------
Component/s: JCA
> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
> Key: WFLY-9681
> URL: https://issues.jboss.org/browse/WFLY-9681
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 11.0.0.Final
> Reporter: Chris Giddings
> Assignee: Jason Greene
> Priority: Minor
> Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-8913) It is not possible to add cache store in infinispan subsystem
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8913?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-8913:
------------------------------------
[~Maxoid] Alternatively (to running as a batch), you can run the cache store add operation using the allow-resource-service-restart flag.
e.g.
{code}/subsystem=infinispan/cache-container=hibernate/local-cache=foobar1/store=file:add(){allow-resource-service-restart=true}{code}
N.B. The above command is the non-deprecated equivalent of the command specified in the description.
This ensure that the conflicting services are removed prior to installing the requisite file store service.
> It is not possible to add cache store in infinispan subsystem
> -------------------------------------------------------------
>
> Key: WFLY-8913
> URL: https://issues.jboss.org/browse/WFLY-8913
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Beta1
>
>
> Adding cache store to already created cache ends by failure even if it should succeed:
> {code}
> [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=hibernate/invalidation-cache=foobar/store=STORE:add(class="org.infinispan.configuration.cache.SingleFileStoreConfigurationBuilder")
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache.store.hibernate.foobar is already registered",
> "rolled-back" => true
> }
> {code}
> This is a regression against 7.1.0.DR18.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves Remnants in standalone.xml
by Chris Giddings (JIRA)
Chris Giddings created WFLY-9681:
------------------------------------
Summary: Deleting ExampleDS Leaves Remnants in standalone.xml
Key: WFLY-9681
URL: https://issues.jboss.org/browse/WFLY-9681
Project: WildFly
Issue Type: Bug
Affects Versions: 11.0.0.Final
Reporter: Chris Giddings
Assignee: Jason Greene
Priority: Minor
h2. SUMMARY
When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
h2. WORKAROUND
Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
h2. BUG JUSTIFICATION
# I would expect anything labeled as "Example" to be deleted by an administrator in most environments
# I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-8913) It is not possible to add cache store in infinispan subsystem
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8913?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-8913:
--------------------------------------
[~Maxoid] You need to run this script in a batch.
> It is not possible to add cache store in infinispan subsystem
> -------------------------------------------------------------
>
> Key: WFLY-8913
> URL: https://issues.jboss.org/browse/WFLY-8913
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Beta1
>
>
> Adding cache store to already created cache ends by failure even if it should succeed:
> {code}
> [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=hibernate/invalidation-cache=foobar/store=STORE:add(class="org.infinispan.configuration.cache.SingleFileStoreConfigurationBuilder")
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache.store.hibernate.foobar is already registered",
> "rolled-back" => true
> }
> {code}
> This is a regression against 7.1.0.DR18.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9675) Cannot disable 'max-post-size' check for undertow listeners
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9675?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9675:
---------------------------------
Summary: Cannot disable 'max-post-size' check for undertow listeners (was: cannot disable 'max-post-size' check for undertow listeners)
> Cannot disable 'max-post-size' check for undertow listeners
> -----------------------------------------------------------
>
> Key: WFLY-9675
> URL: https://issues.jboss.org/browse/WFLY-9675
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> With EAP7.1.0.GA, there has been added a validator for 'max-post-size' attribute for listeners in undertow subsystem. This validator requires positive integer values starting with value 1. That means, you cannot disable 'max-post-size' for such listener using 0 value anymore.
> In EAP6.4 and EAP7.0, it was possible to disable 'max-post-size' check with 0 value. I understand that we might not want to allow user to set this to 0 value as it might be a potentional security risk. Still, maybe we should relax this restriction as it was possible to configure it that way in previous versions of EAP.
> Also there is a [Knowledge Base article|https://access.redhat.com/solutions/714173] regarding to this feature, which we should update in case we won't reconsider our position.
> Just for the record - quoting question from mailing list:
> {quote}
> Dear Experts,
> Based on KCS, the "max-post-size" in "http-listener" from "undertow" subsystem can be disabled by setting "0" to it, it worked for EAP 6.x and 7.0 GA.
> But in EAP 7.1.0 GA, it didn't work:
> ~~~
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/http-listener=default/:write-attribute(name=max-post-size,value=0)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0117: 0 is an invalid value for parameter max-post-size. A minimum value of 1 is required",
> "rolled-back" => true
> }
> ~~~
> By comparing schemas:
> ~~~
> jboss-eap-7.0/docs/schema/wildfly-undertow_x_x.xsd:
> <xs:attribute name="max-post-size" type="xs:long" default="0"/>
> ---
> jboss-eap-7.1/docs/schema/wildfly-undertow_x_x.xsd:
> <xs:attribute name="max-post-size" type="xs:long" default="10485760"/>
> ~~~
> The behaviour changed.
> And I found WFLY-6437 and JBEAP-3974, but failed to open links inside those.
> So can I ask if "max-post-size" can be disabled in EAP 7.1.0 GA and the reason if possible?
> Best Regards,
> Zhang Xu
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9680) EJBs can't inherit a JDK8 default method when default implementation is in a third interface
by Daniel Bildhauer (JIRA)
Daniel Bildhauer created WFLY-9680:
--------------------------------------
Summary: EJBs can't inherit a JDK8 default method when default implementation is in a third interface
Key: WFLY-9680
URL: https://issues.jboss.org/browse/WFLY-9680
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 11.0.0.Final, 10.1.0.Final
Reporter: Daniel Bildhauer
Attachments: ejb-in-ear.zip, wildfly-ejb-in-ear-ear.ear
Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
{code}
org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
{code}
Example code:
{code}
@Remote
interface MyEJBInterface {
void doMagic();
}
interface MyEJBMixin extends MyEJBInterface {
default void doMagic() { .... }
}
@Stateless
class MyEJBBean extends MyEJBMixin {
}
{code}
The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces.
A example is attached and I will submitt a pull request with a fix.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months