[JBoss JIRA] (WFLY-6800) Database ignored in Postgres JDBC URL
by Mickaël Vera (JIRA)
[ https://issues.jboss.org/browse/WFLY-6800?page=com.atlassian.jira.plugin.... ]
Mickaël Vera commented on WFLY-6800:
------------------------------------
This issue is the same as this one : WFLY-6200
> Database ignored in Postgres JDBC URL
> -------------------------------------
>
> Key: WFLY-6800
> URL: https://issues.jboss.org/browse/WFLY-6800
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Environment: java 8
> windows 7
> postgresql 9.4
> Reporter: Mickaël Vera
> Assignee: Scott Marlow
>
> I created a data source like this
> {code:xml}
> <datasource jndi-name="java:jboss/datasources/crawlRuntimeDS" pool-name="crawlRuntimePool" enabled="true" use-java-context="true">
> <connection-url>jdbc:postgresql://localhost:5432/runtimedb</connection-url>
> <driver>postgresDD</driver>
> <security>
> <user-name>postgres</user-name>
> <password>postgres</password>
> </security>
> </datasource>
> {code}
> {code:xml}
> I reference it in a persistent unit:
> <persistence-unit name="crawl-runtime-pu">
> <jta-data-source>java:jboss/datasources/crawlRuntimeDS</jta-data-source>
> <class>org.mvera.webscrap.model.crawl.runtime.CrawlEntity</class>
> <class>org.mvera.webscrap.model.crawl.runtime.PageCrawlStatusEntity</class>
> <exclude-unlisted-classes>true</exclude-unlisted-classes>
> <properties>
> <property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect" />
> <property name="hibernate.show_sql" value="true" />
> <property name="hibernate.format_sql" value="true" />
> <property name="javax.persistence.schema-generation.database.action"
> value="none" />
> <property name="javax.persistence.schema-generation.scripts.action"
> value="drop-and-create" />
> <property name="javax.persistence.schema-generation.scripts.create-target"
> value="D:/mvera/crawl-runtime-pu-create.sql" />
> <property name="javax.persistence.schema-generation.scripts.drop-target"
> value="D:/mvera/crawl-runtime-pu-drop.sql" />
> </properties>
> </persistence-unit>
> {code}
> I thought for a moment that all was working right. My data was persisted and I could read it from within an EJB using this datasource. But then I discovered that my data was not persisted at all in the database "crawlRuntimeDS" specified on the jdbc URL of the datasource but in the database "postgres" (a default database created during install of postgres).
> This is a real problem as my application uses serveral databases (several persistence units). The workaround today is to put all entities in the same "postgres" database.
> In the datasource, I can put any name as the database name, it is ignored, even if the database doesn't exist.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6200) connection-url is required even when not used
by Mickaël Vera (JIRA)
[ https://issues.jboss.org/browse/WFLY-6200?page=com.atlassian.jira.plugin.... ]
Mickaël Vera commented on WFLY-6200:
------------------------------------
I reproduce this problem on wildfly-10.0.0.Final with postgresql.
<datasource jndi-name="java:jboss/datasources/crawlResultDS" pool-name="crawlResultPool" enabled="true" use-java-context="true">
<connection-url>jdbc:postgresql://localhost:5432/resultdb</connection-url>
<driver>postgresDD</driver>
<security>
<user-name>postgres</user-name>
<password>postgres</password>
</security>
</datasource>
<drivers>
<driver name="postgresDD" module="org.postgresql">
<xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
<datasource-class>org.postgresql.ds.PGSimpleDataSource</datasource-class>
</driver>
</drivers>.
I can replace
<connection-url>jdbc:postgresql://localhost:5432/resultdb</connection-url>
with
<connection-url>anything</connection-url>
Wildfly ignores it.
> connection-url is required even when not used
> ---------------------------------------------
>
> Key: WFLY-6200
> URL: https://issues.jboss.org/browse/WFLY-6200
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Lin Gao
>
> Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start:
> {noformat}
> 09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "GamingPortalDS")
> ]) - failure description: "WFLYCTL0155: connection-url may not be null"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ELY-580) Add the ability to filter out unavailable mechanisms using the MechanismConfigurationSelector once the host name and protocol name are known
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-580?page=com.atlassian.jira.plugin.sy... ]
Farah Juma commented on ELY-580:
--------------------------------
Instead of the approach in the description, as mentioned in [PR #460|https://github.com/wildfly-security/wildfly-elytron/pull/460], we can select the {{MechanismConfiguration}} when setting the {{MechanismInformation}}. This allows {{createSaslServer}} to just return {{null}} if the {{MechanismConfiguration}} cannot be resolved. For the HTTP case, we can just return if the {{MechanismConfiguration}} cannot be resolved when evaluating an HTTP request.
> Add the ability to filter out unavailable mechanisms using the MechanismConfigurationSelector once the host name and protocol name are known
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-580
> URL: https://issues.jboss.org/browse/ELY-580
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Authentication Mechanisms, HTTP
> Reporter: Farah Juma
> Assignee: Farah Juma
>
> We could modify the {{HttpServerAuthenticationMechanism}} mechanism supplier to take an {{HttpServerRequest}} parameter in order to filter out unavailable mechanisms. (For HTTP auth, the host name and protocol name are obtained using the {{HttpServerRequest}}).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1635) Write attribute on a new deployment scanner fails in batch
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1635?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1635:
------------------------------------------
Probably better than catching and ignoring an ISE though is wrapping logic in an if (controller.getState() == UP) { ... } block.
> Write attribute on a new deployment scanner fails in batch
> ----------------------------------------------------------
>
> Key: WFCORE-1635
> URL: https://issues.jboss.org/browse/WFCORE-1635
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Affects Versions: 3.0.0.Alpha3
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> Creating a new deployment-scanner and altering it's attribute fails if done in single batch. Running the commands without batch or running batch on CLI embed-server works fine.
> *reproduce*
> {noformat}
> batch
> /subsystem=deployment-scanner/scanner=scan:add(path=log, relative-to="jboss.server.base.dir", auto-deploy-exploded=false, scan-enabled=false)
> /subsystem=deployment-scanner/scanner=scan:write-attribute(name=scan-interval, value=6000)
> run-batch
> {noformat}
> fails with
> {noformat}
> 08:09:19,076 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "deployment-scanner"),
> ("scanner" => "scan")
> ]): java.lang.IllegalStateException
> at org.jboss.as.server.deployment.scanner.DeploymentScannerService.getValue(DeploymentScannerService.java:234)
> at org.jboss.as.server.deployment.scanner.DeploymentScannerService.getValue(DeploymentScannerService.java:62)
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> at org.jboss.as.controller.OperationContextImpl$OperationContextServiceController.getValue(OperationContextImpl.java:2282)
> at org.jboss.as.server.deployment.scanner.AbstractWriteAttributeHandler.applyUpdateToRuntime(AbstractWriteAttributeHandler.java:58)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(AccessController.java:686)
> at javax.security.auth.Subject.doAs(Subject.java:569)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> using the embed server works
> {noformat}
> embed-server
> batch
> /subsystem=deployment-scanner/scanner=scan:add(path=log, relative-to="jboss.server.base.dir", auto-deploy-exploded=false, scan-enabled=false)
> /subsystem=deployment-scanner/scanner=scan:write-attribute(name=scan-interval, value=6000)
> run-batch
> {noformat}
> Setting only as minor as there is no real use case behind this (scan-interval can be set while adding a new scanner) - run into it quite accidentally. No regression against previous release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1635) Write attribute on a new deployment scanner fails in batch
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1635?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1635:
------------------------------------------
I think if controller.getValue() fails it can just ignore the failure. In the batch the Stage.MODEL handling of the write-attribute runs before the Stage.RUNTIME of the add, which means the Stage.RUNTIME of the add is using the correct value of the scan-interval attribute and there's no need for the Stage.RUNTIME of the write-attribute modify the service.
> Write attribute on a new deployment scanner fails in batch
> ----------------------------------------------------------
>
> Key: WFCORE-1635
> URL: https://issues.jboss.org/browse/WFCORE-1635
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Affects Versions: 3.0.0.Alpha3
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> Creating a new deployment-scanner and altering it's attribute fails if done in single batch. Running the commands without batch or running batch on CLI embed-server works fine.
> *reproduce*
> {noformat}
> batch
> /subsystem=deployment-scanner/scanner=scan:add(path=log, relative-to="jboss.server.base.dir", auto-deploy-exploded=false, scan-enabled=false)
> /subsystem=deployment-scanner/scanner=scan:write-attribute(name=scan-interval, value=6000)
> run-batch
> {noformat}
> fails with
> {noformat}
> 08:09:19,076 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "deployment-scanner"),
> ("scanner" => "scan")
> ]): java.lang.IllegalStateException
> at org.jboss.as.server.deployment.scanner.DeploymentScannerService.getValue(DeploymentScannerService.java:234)
> at org.jboss.as.server.deployment.scanner.DeploymentScannerService.getValue(DeploymentScannerService.java:62)
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> at org.jboss.as.controller.OperationContextImpl$OperationContextServiceController.getValue(OperationContextImpl.java:2282)
> at org.jboss.as.server.deployment.scanner.AbstractWriteAttributeHandler.applyUpdateToRuntime(AbstractWriteAttributeHandler.java:58)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(AccessController.java:686)
> at javax.security.auth.Subject.doAs(Subject.java:569)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> using the embed server works
> {noformat}
> embed-server
> batch
> /subsystem=deployment-scanner/scanner=scan:add(path=log, relative-to="jboss.server.base.dir", auto-deploy-exploded=false, scan-enabled=false)
> /subsystem=deployment-scanner/scanner=scan:write-attribute(name=scan-interval, value=6000)
> run-batch
> {noformat}
> Setting only as minor as there is no real use case behind this (scan-interval can be set while adding a new scanner) - run into it quite accidentally. No regression against previous release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1632) Server processing request isn't stopped immediately but waits for request processing to finish
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1632?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1632:
------------------------------------------
This is an interesting problem. The graceful shutdown timeout was meant to be a limit on how long the server would try and be graceful, but not a limit on how long it would take to stop once it stopped being graceful.
I don't think we should act as if it's a shutdown timeout, at least not without a formal RFE, as that's an open ended commitment. But, still, it's better if it can be closer to that.
I haven't looked closely at the link in the description, but I figure it's ultimately about using a shared thread pool that is depended upon but not controlled by the webserver instead of using one that the webserver itself shuts down.
> Server processing request isn't stopped immediately but waits for request processing to finish
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1632
> URL: https://issues.jboss.org/browse/WFCORE-1632
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, IO, Server
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Critical
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> When stopping server which is processing request, it terminates the connection from the client but doesn't stop the request processing as such.
> After debugging and searching when the issue appeared I've found out that the issue was introduced with this commit: [https://github.com/wildfly/wildfly-core/commit/7304c019705c5f7ec0378e1c51...]
> Steps to reproduce:
> 1) start EAP server with deployed app from attachment
> 2) create request to long running application: {{curl -i http://127.0.0.1:8080/long-running-servlet/HeavyProcessing?duration=25000}}
> 3) stop server (you can do it even gracefully) using {{./jboss-cli.sh -c ":shutdown(timeout=1)"}}
> See that server is stopped after 25 seconds since request from step 2 was issued, as that is duration of the request processing requested by param duration, instead of being terminated after 1 second.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6803) Add multi-server support to mod_cluster
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-6803:
----------------------------------
Summary: Add multi-server support to mod_cluster
Key: WFLY-6803
URL: https://issues.jboss.org/browse/WFLY-6803
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Currently, mod_cluster subsystem supports only a single configuration, which references the default undertow server. However, Undertow supports multiple servers, and exposes a distinct route capability per server (see WFLY-6778).
mod_cluster should therefore support multiple "profiles", where each profile references a specific undertow server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1379) service.bat points user to wrong directory
by Kuthair Habboush (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1379?page=com.atlassian.jira.plugi... ]
Kuthair Habboush commented on WFCORE-1379:
------------------------------------------
Can someone please post the link to the other defect? TIA
> service.bat points user to wrong directory
> ------------------------------------------
>
> Key: WFCORE-1379
> URL: https://issues.jboss.org/browse/WFCORE-1379
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 2.0.10.Final
> Reporter: Nicklas Karlsson
> Assignee: Tomaz Cerar
> Priority: Trivial
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> Running service.bat from the docs/contrib/scripts/service dir tells user to run the script under bin/service*s* but the binary paths to the services expects bin/service, resulting in service install failure with file not found
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months