[JBoss JIRA] Created: (JBREM-990) CLONE [JBREM-960] - Remoting configured with Servlet invoker can return misleading Exceptions when Servlet path is incorrect
by Ron Sigal (JIRA)
CLONE [JBREM-960] - Remoting configured with Servlet invoker can return misleading Exceptions when Servlet path is incorrect
----------------------------------------------------------------------------------------------------------------------------
Key: JBREM-990
URL: http://jira.jboss.com/jira/browse/JBREM-990
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 2.4.0.GA (Pinto), 2.2.2.SP8, 2.4.1.Beta
Reporter: Galder Zamarreno
Assigned To: Ron Sigal
Fix For: 2.2.2.SP8
I've been struggling to set up a ServletInvoker in Remoting to be able to
use the unified invoker to talk to EJB2 beans in AS/EAP 4.x. I had the Connector
set up like this:
<mbean code="org.jboss.remoting.transport.Connector"
name="jboss.remoting:service=connector,transport=servlet"
display-name="Servlet transport Connector">
<attribute name="Configuration">
<config>
<invoker transport="servlet">
<attribute name="dataType" isParam="true">invocation</attribute>
<attribute name="marshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationMarshaller</attribute>
<attribute name="unmarshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationUnMarshaller</attribute>
<attribute name="serverBindAddress">${jboss.bind.address}</attribute>
<attribute name="serverBindPort">8080</attribute>
<attribute name="path">unified-http-invoker/ServerInvokerServlet</attribute>
</invoker>
<handlers>
<handler subsystem="invoker">jboss:service=invoker,type=unified-http</handler>
</handlers>
</config>
</attribute>
</mbean>
But the path attribute was incorrect. Remoting was coming back with something like this:
org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:333)
at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:135)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:183)
at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
at $Proxy0.create(Unknown Source)
at com.acme.ejb2.slsb.TimerEnquirerHttpTest.test000(TimerEnquirerHttpTest.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.io.StreamCorruptedException: invalid stream header
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:764)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:277)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:95)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:72)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:119)
at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
at org.jboss.remoting.transport.http.HTTPClientInvoker.readResponse(HTTPClientInvoker.java:471)
at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:305)
... 31 more
Now, to get this Exception is very misleading. It generally means that either you have different
client and server side Remoting versions, or you're using different serialization methods on either
side.
Once I started to dig into what Remoting was doing, I spotted HTTPClientInvoker does the following in
useHttpURLConnection() method:
if (sendingData)
{
//POST or PUT
conn.setDoOutput(true);
conn.setDoInput(true);
conn.setRequestMethod(type);
OutputStream stream = conn.getOutputStream();
if (marshaller instanceof VersionedMarshaller)
((VersionedMarshaller) marshaller).write(invocation, stream, Version.getDefaultVersion());
else
marshaller.write(invocation, stream);
responseCode = conn.getResponseCode();
InputStream is = (responseCode < 400) ? conn.getInputStream() : conn.getErrorStream();
Map headers = conn.getHeaderFields();
if (metadata == null)
{
metadata = new HashMap();
}
// sometimes I get headers with "null" keys (I don't know who's fault is it), so I need
// to clean the header map, unless I want to get an NPE thrown by metadata.putAll()
if (headers != null)
{
for(Iterator i = headers.entrySet().iterator(); i.hasNext(); )
{
Map.Entry e = (Map.Entry)i.next();
if (e.getKey() != null)
{
metadata.put(e.getKey(), e.getValue());
}
}
}
metadata.put(HTTPMetadataConstants.RESPONSE_CODE_MESSAGE, conn.getResponseMessage());
metadata.put(HTTPMetadataConstants.RESPONSE_CODE, new Integer(responseCode));
result = readResponse(metadata, headers, unmarshaller, is);
}
The Exception reported is coming from readResponse() but before that if the Servlet was not available,
like in my case, conn.getResponseCode() was returning 404.
Remoting code should check what the response code was, whether this is an invalid code, i.e. does not exist...etc,
and throw an Exception if invalid, like in this case, giving the caller much better clue of what is going on.
Thoughts?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
- 1
- 2
[JBoss JIRA] Created: (JBAS-5822) Add support for value-factory injection to -service.xml parsing
by Brian Stansberry (JIRA)
Add support for value-factory injection to -service.xml parsing
---------------------------------------------------------------
Key: JBAS-5822
URL: https://jira.jboss.org/jira/browse/JBAS-5822
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Deployers
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: JBossAS-5.0.0.CR2
Allow equivalent to microcontainer's "value-factory" element as the value for a -service.xml's server/mbean/attribute element.
Can handle this:
<mbean ...>
<attribute name="Foo">
<value-factory bean="FooProvider" method="getFoo" parameter="A" default="1100"/>
</attribute>
</mbean>
And this:
<attribute name="Foo">
<value-factory bean="FooProvider" method="getFoo" default="1100">
<parameter>A</parameter>
<parameter>1</parameter>
</value-factory>
</attribute>
And, as long as parameter type com.foo.Bar is visible and a PropertyEditor exists, this:
<attribute name="Foo">
<value-factory bean="FooProvider" method="getFoo" default="1100">
<parameter class="com.foo.Bar">A</parameter>
<parameter class="java.lang.Integer">1</parameter>
</value-factory>
</attribute>
Injecting a type assignable from the parameter type is supported:
<attribute name="Foo">
<value-factory bean="FooProvider" method="getFoo" default="1100">
<parameter class="java.lang.Object">
<value class="java.lang.Integer">1</value>
</parameter>
</value-factory>
</attribute>
The following MC value-factory features are not supported:
<attribute name="Foo">
<value-factory bean="FooProvider" method="getFoo" default="1100">
<parameter><inject bean"FooParamProvider"/></parameter>
</value-factory>
</attribute>
<attribute name="Foo">
<value-factory bean="FooProvider" method="getFoo" default="1100">
<parameter>
<bean name="FooParam" class="com.foo.FooParam"/>
</parameter>
</value-factory>
</attribute>
<attribute name="Foo">
<value-factory bean="FooProvider" method="getFoo" default="1100">
<parameter>
<map>
...
</map>
</parameter>
</value-factory>
</attribute>
(or any of the other collection types).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
- 1
- 2
[JBoss JIRA] Created: (JBRULES-1708) BRMS: cannot reopen a closed rule window
by Jaroslaw Kijanowski (JIRA)
BRMS: cannot reopen a closed rule window
----------------------------------------
Key: JBRULES-1708
URL: https://jira.jboss.org/jira/browse/JBRULES-1708
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-brms
Affects Versions: 5.0.0.M1
Reporter: Jaroslaw Kijanowski
Assignee: Michael Neale
Fix For: 5.0.0.M2
I have one technical rule and two business rules.
To open the technical rule I do:
Packages->my package->Technical rule assets
A list of my technical rules shows up (1 item)
Double click on it, rule shows up, close it.
I'm back on the screen showing the list of my technical rules.
Double click on it, rule does NOT show up.
Same for business rules (obviously), however FWIW:
When I click on Business rule assets and get a list of two rules, click on the first and close it. I'm not able to reopen the rule. When I double click on the second, open it, then I'm able to open the first rule again.
I'm using firefox2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
- 2
- 1