[JBoss JIRA] (JBEE-157) Improper exception handling in org.jboss.com.sun.corba.se.impl.javax.rmi.PortableRemoteObject#narrow()
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBEE-157?page=com.atlassian.jira.plugin.s... ]
David Lloyd resolved JBEE-157.
------------------------------
Resolution: Done
> Improper exception handling in org.jboss.com.sun.corba.se.impl.javax.rmi.PortableRemoteObject#narrow()
> ------------------------------------------------------------------------------------------------------
>
> Key: JBEE-157
> URL: https://issues.jboss.org/browse/JBEE-157
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-rmi-api
> Reporter: David Lloyd
> Assignee: Shelly McGowan
>
> org.jboss.com.sun.corba.se.impl.javax.rmi.PortableRemoteObject#narrow() has a {{catch (Exception error)}} block in it which wraps all exceptions in a {{ClassCastException}}. However, there should be a second catch block which catches {{RuntimeException}} and rethrows them verbatim, in order to avoid confusing incorrect error messages.
> In particular, you can get a {{ClassCastException}} whose cause is another {{ClassCastException}}.
> Problem found in 1.0.4.Final; no version for this exists in the JIRA schema however.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JBEE-156) Missing privileged action in org.jboss.com.sun.corba.se.impl.util.Utility
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBEE-156?page=com.atlassian.jira.plugin.s... ]
David Lloyd resolved JBEE-156.
------------------------------
Resolution: Done
> Missing privileged action in org.jboss.com.sun.corba.se.impl.util.Utility
> -------------------------------------------------------------------------
>
> Key: JBEE-156
> URL: https://issues.jboss.org/browse/JBEE-156
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-rmi-api
> Reporter: David Lloyd
> Assignee: Shelly McGowan
>
> org.jboss.com.sun.corba.se.impl.util.Utility#loadStub(org.omg.CORBA.Object, java.lang.Class<?>)
> This method has the following method:
> {code}
> /*
> * Load an RMI-IIOP Stub. This is used in PortableRemoteObject.narrow.
> */
> public static Object loadStub(org.omg.CORBA.Object narrowFrom, Class<?> narrowTo)
> {
> Object result = null;
> try
> {
> // Get the codebase from the delegate to use when loading the new stub, if possible...
> String codebase = null;
> try
> {
> // We can't assume that narrowFrom is a CORBA_2_3 stub, yet it may have a 2_3 Delegate that provides a
> // codebase. Swallow the ClassCastException otherwise.
> Delegate delegate = StubAdapter.getDelegate(narrowFrom);
> codebase = ((org.omg.CORBA_2_3.portable.Delegate) delegate).get_codebase(narrowFrom);
> }
> catch (ClassCastException e)
> {
> throw wrapper.classCastExceptionInLoadStub(e);
> }
> PresentationManager.StubFactoryFactory sff = org.jboss.com.sun.corba.se.spi.orb.ORB.getStubFactoryFactory();
> PresentationManager.StubFactory sf = sff.createStubFactory(narrowTo.getName(), false, codebase, narrowTo,
> narrowTo.getClassLoader());
> result = sf.makeStub();
> StubAdapter.setDelegate(result, StubAdapter.getDelegate(narrowFrom));
> }
> catch (Exception err)
> {
> throw wrapper.exceptionInLoadStub(err);
> }
> return result;
> }
> {code}
> The {{narrowTo.getClassLoader()}} should be made privileged.
> Problem found in jboss-rmi-api_1.0_spec-1.0.4.Final; no version seems to exist for this release.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-1054) Application deployment collisions
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1054?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned WFLY-1054:
---------------------------------
Assignee: (was: David Lloyd)
> Application deployment collisions
> ---------------------------------
>
> Key: WFLY-1054
> URL: https://issues.jboss.org/browse/WFLY-1054
> Project: WildFly
> Issue Type: Feature Request
> Components: Server
> Reporter: Jim Tyrrell
> Labels: eap6-ux
>
> In playing with the JBoss Central demo applications and with the quickstarts several of these overlap in name. If you have deployed the war files via JBDS into the deployments directory, and then use the quickstarts the API will deploy over the existing application without any issue. It appears on a server restart however it remembers the .war file that is in the deployments directory, and the one deployed via API in the quickstarts. The war file ends up with a deployed failed marker file, but no indication about what is going on is in the console log or in the failed file. Better error reporting would be nice for naming collisions in deployment.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-2680) java:comp/DefaultDataSource doesn't work in persistence.xml
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-2680?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned WFLY-2680:
---------------------------------
Assignee: (was: David Lloyd)
> java:comp/DefaultDataSource doesn't work in persistence.xml
> -----------------------------------------------------------
>
> Key: WFLY-2680
> URL: https://issues.jboss.org/browse/WFLY-2680
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, JPA / Hibernate
> Affects Versions: 8.0.0.CR1
> Reporter: arjan tijms
> Labels: javaee7, jdbc
>
> Having a persistence.xml with the following content fails the deployment on WildFly 8 CR1:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
>
> <persistence-unit name="testPU">
> <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
> </persistence-unit>
> </persistence>
> {code}
> It results in the following error:
> {noformat}
> 13:51:40,367 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dynamic-named-query.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dynamic-named-query.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.dynamic-named-query.dynamic-named-query.DefaultDataSource]"]}
> {noformat}
> When I proposed the feature for the default data source over at the Java EE JIRA (https://java.net/jira/browse/JAVAEE_SPEC-4) I intended this to work. In the description I hinted that the standard JNDI name would be the standard alternative for {{java:jboss/datasources/ExampleDS}} on JBoss. The latter indeed does work in {{persistence.xml}} using WildFly 8 CR1.
> Omitting the {{jta-data-source}} element altogether *does* work, which is great. However, I foresee a lot of users tripping over this in the future and just giving up the idea of using a default data source, especially since the error message is very cryptic for new developers.
> In GlassFish 4 using {{java:comp/DefaultDataSource}} in {{persistence.xml}} does work.
> See also WFLY-2027 and WFLY-2158
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-3335) JAXB transformer initiation
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3335?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3335:
-----------------------------------
This issue may be resolved in recent WildFly releases; can you please test again to verify?
> JAXB transformer initiation
> ---------------------------
>
> Key: WFLY-3335
> URL: https://issues.jboss.org/browse/WFLY-3335
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.0.0.Final, 8.1.0.CR1
> Environment: Ubuntu 14.04 with java 7 openjdk
> Reporter: Ghet Ghetolay
> Assignee: David Lloyd
> Priority: Critical
>
> I'm not directly using JAXB and SaxTransformer, it's part of a the [dcm4chee-arc project|https://github.com/dcm4che/dcm4chee-arc] which I tried to use on Wildfly. It's a rather big and complicated project so I've create a test application to illustrate the bug. I've used a JAR-RS application to illustrate the bug (like the original case) but this should not be related to it.
> {code:title=TestRS.java}
> @Path("test")
> public class TestRS {
>
> private static SAXTransformerFactory factory =
> (SAXTransformerFactory) TransformerFactory.newInstance();
>
> @GET
> public Response test(){
> try {
> Templates template = factory.newTemplates(new StreamSource(
> TestRS.class.getResource("json_compact.xsl").toString()));
>
> factory.newTransformerHandler(template);
>
> } catch (TransformerConfigurationException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> return Response.ok().build();
> }
> }
> {code}
> {code:title=json_compact.xsl}
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
> <xsl:output method="text"/>
> <xsl:template match="/">
> <xsl:text>Test</xsl:text>
> </xsl:template>
> </xsl:stylesheet>
> {code}
> {quote}
> 15:24:48,564 ERROR [stderr] (default task-1) javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 15:24:48,564 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformerHandler(TransformerFactoryImpl.java:1062)
> 15:24:48,565 ERROR [stderr] (default task-1) at __redirected.__TransformerFactory.newTransformerHandler(__TransformerFactory.java:193)
> 15:24:48,566 ERROR [stderr] (default task-1) at test.TestRS.test(TestRS.java:25)
> {quote}
> I've discovered that the initial exception is :
> {quote}
> java.lang.NoClassDefFoundError: com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet
> {quote}
> Both my test case and dcm4che-arc project works fine on JBoss 7.1.1.Final.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-3466) No error reported when remote handshake fails
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3466?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3466:
-----------------------------------
This may have been fixed as of WildFly 11; I'll leave this open for now until it can be verified.
> No error reported when remote handshake fails
> ---------------------------------------------
>
> Key: WFLY-3466
> URL: https://issues.jboss.org/browse/WFLY-3466
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Paul Benedict
> Assignee: David Lloyd
>
> When the destination server fails to respond and thus the remote handshake cannot be made, nothing gets reported in the client's log -- even when put on TRACE. I spent many days trying to get to the bottom of this. This abnormal condition is too important for it to go unreported.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-3431) outbound connection to remote ejbs attempts to use http upgrade even if protocol="remote" is specified.
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3431?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3431:
-----------------------------------
This should have been fixed as of WildFly 11; I'll leave this open for now until it can be verified.
> outbound connection to remote ejbs attempts to use http upgrade even if protocol="remote" is specified.
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3431
> URL: https://issues.jboss.org/browse/WFLY-3431
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 8.0.0.Final
> Reporter: Jason Essington
> Assignee: David Lloyd
>
> When attempting to connect to remote EJBs running on JBoss AS 7.2.0.Final from WildFly 8.0.0.Final, WildFly chooses to use http upgrade even though the outbound connection specifies protocol="remote"
> Outbound remoting connections in the wildfly config are defined like:
> {code:xml}
> <remote-outbound-connection name="remote-ds-connection" outbound-socket-binding-ref="remote-dataserver" username="calypso_user" security-realm="engine-security-realm" protocol="remote">
> <properties>
> <property name="SASL_POLICY_NOANONYMOUS" value="false"/>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </remote-outbound-connection>
> {code}
> Yet, when attempting to connect to remote EJBs located on the JBoss AS 7.2.0.Final server, the jboss log shows:
> {noformat}
> 11:10:21,581 ERROR [org.jboss.remoting.remote.connection] (Remoting "standalone-dataserver" read-1) JBREM000200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856
> {noformat}
> and the stacktrace on wildfly shows:
> {noformat}
> 2014-06-02 11:10:21,506 WARN [org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector] (ServerService Thread Pool -- 67) Could not register a EJB receiver for connection to localhost:4447: java.lang.RuntimeException: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> ... clipped ...
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:298) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:281) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> at org.jboss.ejb.client.remoting.EndpointPool$PooledEndpoint.connect(EndpointPool.java:187) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> ... 110 more
> {noformat}
> and ultimately shows:
> {noformat}
> Caused by: java.lang.RuntimeException: Unable to connect to ejb:/dataserver//com.xxxx.yy.service.SomeService!com.xxxx.yy.service.SomeService at remote://localhost:4447
> .... clipped ...
> {noformat}
> Which shows that it should be using a remote URL (as well as remote protocol rather than http-remoting) and is the same host/port on the connection defined in configuration. Yet the errors seem to indicate that WildFly is attempting to use http upgrade.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3566) Different results of disabling commands already disabled deployment
by Vratislav Marek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3566?page=com.atlassian.jira.plugi... ]
Vratislav Marek commented on WFCORE-3566:
-----------------------------------------
Preparing tests for coverage issue.
> Different results of disabling commands already disabled deployment
> -------------------------------------------------------------------
>
> Key: WFCORE-3566
> URL: https://issues.jboss.org/browse/WFCORE-3566
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Vratislav Marek
> Assignee: Martin Stefanko
>
> *Different command result of disabling already disabled deployment in standalone and domain mode*
> * In standalone return
> {noformat}
> WFLYCTL0155: 'steps' may not be null
> {noformat}
> * In domain return nothing, no warning or error
> {noformat}
> [standalone@localhost:9990 /] deployment info
> NAME RUNTIME-NAME PERSISTENT ENABLED STATUS
> cli-test-another-deploy.war cli-test-another-deploy.war true true OK
> cli-test-app1-deploy.war cli-test-app1-deploy.war true false STOPPED
> cli-test-app2-deploy.war cli-test-app2-deploy.war true true OK
> [standalone@localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
> WFLYCTL0155: 'steps' may not be null
> [standalone@localhost:9990 /]
> {noformat}
> {noformat}
> [domain@localhost:9990 /] deployment info --server-groups=main-server-group
> NAME RUNTIME-NAME STATE
> cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled
> cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added
> cli-test-app2-deploy-all.war cli-test-app2-deploy-all.war not added
> cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war enabled
> [domain@localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
> [domain@localhost:9990 /]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months