[JBoss JIRA] (WFLY-3594) Wildfly showing the war file status as Failed after restart the server
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3594?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski updated WFLY-3594:
-------------------------------------
Fix Version/s: (was: 8.0.0.Final)
> Wildfly showing the war file status as Failed after restart the server
> ----------------------------------------------------------------------
>
> Key: WFLY-3594
> URL: https://issues.jboss.org/browse/WFLY-3594
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Final
> Environment: windows server 2003 32 bit O.S,Java 7,flex, Apache axis web services
> Reporter: shaik masthan
> Assignee: Bartosz Baranowski
> Priority: Minor
> Labels: restarting
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> after successful deployment , war file status is deployed. When i restart the server , war files status is showing as failed. there were no errors in the logs and i am able to access the the application without any problems.
> After some time happen , again i restart the server this time war file status is deployed.
> intermittently i am viewing this weird behavior with war files w.r. t restarting the server.
> let me know any workaround or fix for this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-3594) Wildfly showing the war file status as Failed after restart the server
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3594?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski updated WFLY-3594:
-------------------------------------
Priority: Minor (was: Critical)
> Wildfly showing the war file status as Failed after restart the server
> ----------------------------------------------------------------------
>
> Key: WFLY-3594
> URL: https://issues.jboss.org/browse/WFLY-3594
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Final
> Environment: windows server 2003 32 bit O.S,Java 7,flex, Apache axis web services
> Reporter: shaik masthan
> Assignee: Jason Greene
> Priority: Minor
> Labels: restarting
> Fix For: 8.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> after successful deployment , war file status is deployed. When i restart the server , war files status is showing as failed. there were no errors in the logs and i am able to access the the application without any problems.
> After some time happen , again i restart the server this time war file status is deployed.
> intermittently i am viewing this weird behavior with war files w.r. t restarting the server.
> let me know any workaround or fix for this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager
by shinzey shinzey (JIRA)
[ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.... ]
shinzey shinzey updated WFLY-4096:
----------------------------------
Affects Version/s: 8.2.0.Final
> Datasource Defined in web.xml Does Not Work with JPA Entity Manager
> -------------------------------------------------------------------
>
> Key: WFLY-4096
> URL: https://issues.jboss.org/browse/WFLY-4096
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Web (JBoss Web)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Windows 7
> Java 8u25
> WildFly 8.1.0.Final
> Reporter: shinzey shinzey
> Assignee: Scott Marlow
> Priority: Critical
> Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit
>
> The datasource defined in web.xml:
> {quote}
> <data-source>
> <name>java:/datasources/test</name>
> <class-name>org.apache.derby.jdbc.ClientDataSource</class-name>
> <database-name>test</database-name>
> <url>jdbc:derby://localhost:1527/test</url>
> <user>test</user>
> <password>test</password>
> </data-source>
> {quote}
> The persistence unit:
> {quote}
> <persistence-unit name="wtpu" transaction-type="JTA">
> <jta-data-source>java:/datasources/test</jta-data-source>
> </persistence-unit>
> {quote}
> The deployment error:
> {quote}
> 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war")
> 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu
> 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"])
> 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war")
> 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__]
> {quote}
> If I remove the persistence unit, the datasource can be successfully bound:
> {quote}
> 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test]
> {quote}
> The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager
by shinzey shinzey (JIRA)
[ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.... ]
shinzey shinzey commented on WFLY-4096:
---------------------------------------
The issue still exists in 8.2.0.Final.
> Datasource Defined in web.xml Does Not Work with JPA Entity Manager
> -------------------------------------------------------------------
>
> Key: WFLY-4096
> URL: https://issues.jboss.org/browse/WFLY-4096
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Web (JBoss Web)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Windows 7
> Java 8u25
> WildFly 8.1.0.Final
> Reporter: shinzey shinzey
> Assignee: Scott Marlow
> Priority: Critical
> Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit
>
> The datasource defined in web.xml:
> {quote}
> <data-source>
> <name>java:/datasources/test</name>
> <class-name>org.apache.derby.jdbc.ClientDataSource</class-name>
> <database-name>test</database-name>
> <url>jdbc:derby://localhost:1527/test</url>
> <user>test</user>
> <password>test</password>
> </data-source>
> {quote}
> The persistence unit:
> {quote}
> <persistence-unit name="wtpu" transaction-type="JTA">
> <jta-data-source>java:/datasources/test</jta-data-source>
> </persistence-unit>
> {quote}
> The deployment error:
> {quote}
> 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war")
> 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu
> 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"])
> 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war")
> 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__]
> {quote}
> If I remove the persistence unit, the datasource can be successfully bound:
> {quote}
> 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test]
> {quote}
> The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4072) Unable to Enable JTA for a Datasource
by shinzey shinzey (JIRA)
[ https://issues.jboss.org/browse/WFLY-4072?page=com.atlassian.jira.plugin.... ]
shinzey shinzey commented on WFLY-4072:
---------------------------------------
Yes the issue doesn't appear in 8.2.0.Final. Sorry for the late response.
> Unable to Enable JTA for a Datasource
> -------------------------------------
>
> Key: WFLY-4072
> URL: https://issues.jboss.org/browse/WFLY-4072
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.1.0.Final
> Environment: Windows 7
> Java 8u25
> WildFly 8.1.0.Final
> Reporter: shinzey shinzey
> Assignee: Stefano Maestri
> Priority: Critical
> Labels: Datasource, JTA, ejb, wildfly
>
> Whenever trying to enable JTA, the following error is reported:
> Unknown error
> Unexpected HTTP response: 500
> Request
> {
> "name" => "test",
> "user-name" => "test",
> "password" => "test",
> "security-domain" => "",
> "jndi-name" => "java:/datasource/test",
> "transaction-isolation" => "TRANSACTION_READ_COMMITTED",
> "new-connection-sql" => "",
> "connection-url" => "jdbc:derby://localhost:1527/test",
> "driver-class" => "org.apache.derby.jdbc.ClientDriver",
> "jta" => true,
> "pool-name" => "",
> "use-ccm" => false,
> "datasource-class" => "",
> "valid-connection-checker-class-name" => "",
> "check-valid-connection-sql" => "",
> "background-validation" => false,
> "background-validation-millis" => -1L,
> "validate-on-match" => false,
> "stale-connection-checker-class-name" => "",
> "exception-sorter-class-name" => "",
> "prepared-statements-cache-size" => -1L,
> "share-prepared-statements" => false,
> "enabled" => false,
> "driver-name" => "Derby_org.apache.derby.jdbc.ClientDriver_10_10",
> "operation" => "enable",
> "address" => [
> ("subsystem" => "datasources"),
> ("data-source" => "test")
> ]
> }
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014750: Operation handler failed to complete",
> "rolled-back" => true
> }
> Due to this issue, EJB's transaction management does not work. I tested the same database on GlassFish and JTA works fine.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (SECURITY-874) CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/SECURITY-874?page=com.atlassian.jira.plug... ]
Bartosz Baranowski updated SECURITY-874:
----------------------------------------
Attachment: SECURITY-874.patch
Alternate solution. This patch add inner class with equals/hashCode methods, instead of anonymous class.
> CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions
> -------------------------------------------------------------------------------------------------
>
> Key: SECURITY-874
> URL: https://issues.jboss.org/browse/SECURITY-874
> Project: PicketBox
> Issue Type: Bug
> Components: Identity
> Affects Versions: PicketBox_4_0_21.Final
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Attachments: SECURITY-874.patch
>
>
> org.jboss.security.identity.extensions.CredentialIdentityFactory.NULL_IDENTITY does not get initialized to an empty identity due to initialization method returning a reference to NULL_IDENTITY, which has not initialized yet, resulting in null pointer. This causes NullPointerException in org.jboss.security.SecurityContextUtil.clearIdentities() and org.jboss.security.SecurityContextUtil.getIdentities() methods.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS edited comment on JGRP-1876 at 1/19/15 3:07 AM:
-------------------------------------------------------------
Yes finally all members merge into a new view= A,B,C.
I'm making a sequence diagram to describe what happen in that scenario.
was (Author: ammous):
Yes finally all members merge into a new view= A,B,C.
I'm making a sequence diagram of what happen in that scenario.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS edited comment on JGRP-1876 at 1/19/15 3:02 AM:
-------------------------------------------------------------
Yes finally all members merge into a new view= A,B,C.
I'm making a sequence diagram of what happen in that scenario.
was (Author: ammous):
Yes finally all members merge into a new view {A,B,C}.
I'm making a sequence diagram of what happen in that scenario.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months