July 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1388) benchmark against http://www.xstm.net/

by Mircea Markus (JIRA)

benchmark against http://www.xstm.net/ -------------------------------------- Key: JBCACHE-1388 URL: http://jira.jboss.com/jira/browse/JBCACHE-1388 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Environment: add http://www.xstm.net/ as a product to the cache benchmark framework Reporter: Mircea Markus Assigned To: Manik Surtani -- 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

16 years, 1 month

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1382) Investigate use of ExposedBAOS instead of BAOS when marshalling objects

by Manik Surtani (JIRA)

Investigate use of ExposedBAOS instead of BAOS when marshalling objects ----------------------------------------------------------------------- Key: JBCACHE-1382 URL: http://jira.jboss.com/jira/browse/JBCACHE-1382 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.2.0.GA, 3.0.0 >From Bela's email: "At least in AbstractMarshaller: public byte[] objectToByteBuffer(Object obj) throws Exception { ByteArrayOutputStream baos = new ByteArrayOutputStream(); ObjectOutputStream out = ObjectSerializationFactory.createObjectOutputStream(baos); objectToObjectStream(obj, out); out.close(); return baos.toByteArray(); } Here, an ExposedByteArrayOutputStream instead of a BAOS would prevent the COPY of the byte buffer. We also don't need to be concerned about reentrancy as the output streams are local (stack) variables... Maybe you guys should take a look at all occurrences of BAOS !" -- 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

16 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1322) Optimise Fqn class for performance in equals() and hashcode()

by Manik Surtani (JIRA)

Optimise Fqn class for performance in equals() and hashcode() ------------------------------------------------------------- Key: JBCACHE-1322 URL: http://jira.jboss.com/jira/browse/JBCACHE-1322 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.2.0.GA A part of this will be to mark all constructors as @Deprecated and make them all private (or protected?) in 3.0.0. Provide adequate factory methods that would create Fqns. The main benefit is that we can intern Fqns and not have to construct them each time. Other improvements are a link to the parent and the current "name", rather than the whole list of elements. Hashcodes and equals can be calculated quickly this way, and caching hashcodes/equality tests based on identity become a possibility. Other suggestions in design forum thread. -- 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

16 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-797) Cache to provide a Node implementation that can hide the internal metadata

by Ben Wang (JIRA)

Cache to provide a Node implementation that can hide the internal metadata -------------------------------------------------------------------------- Key: JBCACHE-797 URL: http://jira.jboss.com/jira/browse/JBCACHE-797 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ben Wang Assigned To: Manik Surtani Fix For: 2.1.0 This came up from a Forum thread. Can we offer a second node implementation such that we can deposit the metadata into that node that is hiding away from the user? -- 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

16 years, 1 month

4
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2095) Localize CMS Portlet Error Message

by Magesh Kumar B (JIRA)

Localize CMS Portlet Error Message ---------------------------------- Key: JBPORTAL-2095 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2095 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.4 Final Reporter: Magesh Kumar B Assignee: Sohil Shah Priority: Minor Currently the Access Denied error message is hard coded in CMSPortlet. This needs to be loaded from ResourceBundle for Internationalization and Localization needs. -- 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

16 years, 1 month

1
1
0 / 0

[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

16 years, 1 month

1
2
0 / 0

[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

16 years, 1 month

1
2
0 / 0

[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

16 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-1015) CLONE [JBREM-1014] - Support injection of socket factory class name into AbstractInvoker

by Ron Sigal (JIRA)

CLONE [JBREM-1014] - Support injection of socket factory class name into AbstractInvoker ---------------------------------------------------------------------------------------- Key: JBREM-1015 URL: https://jira.jboss.org/jira/browse/JBREM-1015 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP8 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP9 It is intended that org.jboss.remoting.AbstractInvoker can accept the class name of a SocketFactory, using the parameter org.jboss.remoting.Remoting.SOCKET_FACTORY_NAME (actual value "socketFactory"). Unfortunately, the parameter name "socketFactory" conflicts with the bean property of the same name. In particular, the problem is that the method public void setSocketFactory(SocketFactory socketFactory) in AbstractInvoker expects a SocketFactory instead of a String. -- 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

16 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBASM-9) Create simple tests to start/stop Server

by Andrew Lee Rubinger (JIRA)

Create simple tests to start/stop Server ---------------------------------------- Key: JBASM-9 URL: https://jira.jboss.org/jira/browse/JBASM-9 Project: JBoss AS Server Manager Issue Type: Task Affects Versions: 0.1.0.GA Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 0.1.0.GA JBASM has no Test Suite. Create a simple unit test to start, stop, check servers are running to provide some minimal coverage. -- 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

16 years, 1 month

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2008