[JBoss JIRA] (WFLY-3439) Websockets not working
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-3439?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-3439:
------------------------------------
Ivan, can you create a forum thread here https://developer.jboss.org/en/wildfly/content to discuss it. There are users who have websocket working fine in WildFly 8. You state that you are using OpenShift, and that might be playing a role here. So please create a forum thread with all relevant details so that someone can help.
> Websockets not working
> ----------------------
>
> Key: WFLY-3439
> URL: https://issues.jboss.org/browse/WFLY-3439
> Project: WildFly
> Issue Type: Bug
> Components: Web Sockets
> Affects Versions: 8.1.0.Final
> Reporter: Veli Cris
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> Hi,
> I deployed a .war file containing a single endpoint definition (Websocket). I can see following lines in console but nothing happens when trying to open connection from a websocket client. Same .war deployed in WildFly 8.0.0 is working. Please investigate!
> The configuration is standalone.
> [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /0.0.0.0:8080
> [io.undertow.websockets.jsr] (MSC service thread 1-4) UT026003: Adding annotated server endpoint ...
> [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017534: Registered web context: ...
> [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "web.war" (runtime-name : "web.war")
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 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 edited comment on WFLY-4096 at 11/26/14 12:44 AM:
------------------------------------------------------------------
There are no exceptions, just these error messages. I don't think a simple unit test can cover this. You can just create a simple web application, configure all the stuffs like mine and easily observe the deployment error with a simple EJB like this:
{quote}
@Stateless
public class TestEjb {
@PersistenceContext(unitName = "xxx")
private EntityManager em;
}
{quote}
was (Author: shinzey):
There are no exceptions, just these error messages. I don't think a simple unit test can cover this. You can just create a simple web application, configure all the stuffs like mine and easily observe the deployment error.
> 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
> 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.8#6338)
9 years, 10 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:
---------------------------------------
There are no exceptions, just these error messages. I don't think a simple unit test can cover this. You can just create a simple web application, configure all the stuffs like mine and easily observe the deployment error.
> 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
> 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.8#6338)
9 years, 10 months
[JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-4125:
------------------------------------
The EJB 3 spec does mandate logging the exception, but as Stuart states, I think this should be made configurable (and default to logging it). There are users who have asked for such logs to be disabled.
> javax.ejb.NoSuchEJBException should not print a stacktrace on the server console
> ---------------------------------------------------------------------------------
>
> Key: WFLY-4125
> URL: https://issues.jboss.org/browse/WFLY-4125
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Sande Gilda
> Assignee: David Lloyd
>
> See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293
> The shopping-cart quickstart has a note in the README file that states:
> Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available.
> However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868)
> I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it.
> See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983
> David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-4126:
-------------------------------
Fix Version/s: (was: 8.2.0.Final)
> java.lang.ExceptionInInitializerError when invoking BIRT service
> ----------------------------------------------------------------
>
> Key: WFLY-4126
> URL: https://issues.jboss.org/browse/WFLY-4126
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Windows 7 and JDK 1.8
> Reporter: Chezy Palani
> Assignee: Stuart Douglas
>
> There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception.
> Context Path:
> /actuatejavacomponent
> Servlet Path:
> /iv
> Path Info:
> null
> Query String:
> __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US
> Stack Trace
> javax.servlet.ServletException: java.lang.ExceptionInInitializerError
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198)
> io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279)
> com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261)
> com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144)
> com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFLY-3439) Websockets not working
by Ivan Kolev (JIRA)
[ https://issues.jboss.org/browse/WFLY-3439?page=com.atlassian.jira.plugin.... ]
Ivan Kolev commented on WFLY-3439:
----------------------------------
Hey, is this still not working in 8.2.0? I am trying it on Openshift and get exactly the same problem as Veli Cris, clear console but no connection to the websocket. I can't believe websocket is broken in wildfly and nobody notices!
> Websockets not working
> ----------------------
>
> Key: WFLY-3439
> URL: https://issues.jboss.org/browse/WFLY-3439
> Project: WildFly
> Issue Type: Bug
> Components: Web Sockets
> Affects Versions: 8.1.0.Final
> Reporter: Veli Cris
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> Hi,
> I deployed a .war file containing a single endpoint definition (Websocket). I can see following lines in console but nothing happens when trying to open connection from a websocket client. Same .war deployed in WildFly 8.0.0 is working. Please investigate!
> The configuration is standalone.
> [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /0.0.0.0:8080
> [io.undertow.websockets.jsr] (MSC service thread 1-4) UT026003: Adding annotated server endpoint ...
> [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017534: Registered web context: ...
> [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "web.war" (runtime-name : "web.war")
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months