Nabble - Netty Developer Group

Re: Documentation

2009-07-02T19:22:08Z

Hi Mike,

Sure. We are interested. However, I would prefer contributing to the
official user guide rather than rewriting. If you think reorganization,
let me know so that we can find a way to the better documentation.

Thanks,
Trustin

On 07/03/2009 10:15 AM, Michael McGrady wrote:

> While working on learning Netty I have started some documentation.
> Would Netty or others be interested? Anyway, a bit of a start is in the
> accompanying document.
>
> Mike
>
>
> Mike McGrady
> Principal Investigator AF081-028 AFRL SBIR
> Senior Engineer
> Topia Technology, Inc
> 1.253.720.3365
> mmcgrady@...
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> netty-dev mailing list
> netty-dev@...
> https://lists.jboss.org/mailman/listinfo/netty-dev

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

— Trustin Lee, http://gleamynode.net/

Documentation

2009-07-02T18:15:49Z

While working on learning Netty I have started some documentation.
Would Netty or others be interested? Anyway, a bit of a start is in
the accompanying document.

Mike

Mike McGrady
Principal Investigator AF081-028 AFRL SBIR
Senior Engineer
Topia Technology, Inc
1.253.720.3365
mmcgrady@...

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

Netty Architecture_v001_mike_mcgrady.pdf (1M) Download Attachment

[JBoss JIRA] Created: (NETTY-187) Subsitute ReplayingDecoder with FrameDecoder without losing stored buffer

2009-07-01T06:10:52Z

Subsitute ReplayingDecoder with FrameDecoder without losing stored buffer
-------------------------------------------------------------------------

Key: NETTY-187
URL: https://jira.jboss.org/jira/browse/NETTY-187
Project: Netty
Issue Type: Feature Request
Components: Handler
Affects Versions: 3.0.2.GA
Environment: Using ubuntu 9.10, java 6
Reporter: Miguel Angel Cabrera
Assignee: Trustin Lee
Priority: Minor

I try to replace a ReplayingDecoder with a FrameDecoder but the buffered data is lost, i would need a mechanism to hand remaining data in buffer to the next handler.

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

Bayeux4Netty Report 1 & 2

2009-06-29T10:09:46Z

Hi everyone,

Bayeux comes back! I am so sorry it's about 2 months since I first
post my proposal of Bayeux here in April,
http://n2.nabble.com/My-proposal-for-GSoC09%3A-Bayeux4Netty-tp2729263p2729263.html.
Maybe it has been already forgotten by you^_^. Actually, I got some
terrible personal trouble in May. It makes me demotivating and I have
to postpone my work includes Bayeux. But I never give it up, I am
always thinking about how to design and implement it better. In recent
month, I recover to Bayeux4Netty project and continue to coding. I
have implemented a JSON parser and request successfully though a rough
version codec. Here are the two reports in detail:

Report 1 - Get started
Time: 4.27-6.23
Purpose: Design architecture of Bayeux codec and all Bayeux messages,
implement JSONParser and a basic codec for 3 types messages
Works:
1.Follow advice from my mentor, Trustin, I began to read source
codes mentioned in user guide one by one. It's really a good shot cut
to learn Netty deeply. I figure out Netty's wonderful pipeline work
process and details of some core classes and important codecs.
2.With the help of Netty's mailist, I attend some discussions and
learnt a lot from application problems, like, when and how to
disconnect a channel, how to send a large file. Also I found some
people who are working on top of HTTP codec, which are kind of similar
to mine.
3.Start a open source project to host Bayeux4Netty's codes in
Google Code, see here, http://code.google.com/p/bayeux4netty. And I
successfully import them, a Maven project, into it by svn in Netbeans
IDE 6.7.
4.Reading the Bayeux protocol again more carefully, I work out
it's most important information and design Bayeux codec's
architecture. The architecture is some different from what I describe
in the proposal. In proposal, there are different decoders/encoders
for each type of Bayeux message. Now ,there is only a unify decoder(or
encoder) to parse HTTP request, and encapsulate it into kinds of
Bayeux messages by a JSONParser class.
5.Because Bayeux's stateful data, I choosed class
OneToOneDecoder/Encoder to be parent class of Bayeux's
Decoder/Encoder.Then, I write some example codes to run a basic Bayeux
server, which can print HTTP request's information to console.
Result: I've learnt how to work in a opensource community and how to
write a codec of Netty. But, due to some personal reasons, just less
than half of purposes are finished, progress is postponed by 2 weeks.
So, I decided to change my plan to speed up whole progress.

Report 2 - On the way
Time: 6.23-6.29
Purpose: Implement JSONParser and a basic decoder for 2 types
messages: handshake and conect
Work:
1. Study some official recommendation implements of JSON, but,
they are for general purpose and heavy weight. So I choose to
implement a light weight JSON parse like grizzly.
2. It costs most days to implement the class JSONParser. At first,
I thought it over complicatedly, design one parser nested in another.
I even doubt "JSON is easy to parse", said in its official site
www.json.org. Finally, I drew again parser's state diagram and
implenent it within 200 lines(except for comments).
3. By using the parser, Bayeux decoder fetch content from HTTP
request and parse it into Java data types, which will be used for
Bayeux applications. Additionally, I add a configure parameter in
decoder's constructor, which can specify HTTP request parameter to
carry JSON string.
Result: Basically, the initial purposes are all fulfilled. In the
following, it will be easy to complete decoder for other messages.
But, its cost is a little more than expected. Discussion maybe a good
way to save time and avoid detours. In next 3~4 days, I plan to
complete decoder and implement some part of decoder to make through a
full handshake and connect process.

As you seen, I have made some great progresses. So, I am very sure to
release it in August on time. Your suggestions are so important for me
and I am very happy to hear any feedback from you.

Best regards,

Dai Jun or Danny Dai in English, http://guiwuu.googlepages.com
GTalk: guiwuu@... | QQ: 93409048 | MSN: guiwuu@... |
Twitter: guiwuu
_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Resolved: (NETTY-186) Multipart messages cause IllegalArgumentException

2009-06-25T21:36:56Z

[ https://jira.jboss.org/jira/browse/NETTY-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee resolved NETTY-186.
-------------------------------

Resolution: Rejected

I initially thought mistakenly that the exception is raised during decoding, but it actually was during encoding.

It is an expected behavior for HttpMessage.addHeader() to reject a value which contains a newline character, which can violate the HTTP specification unintentionally. For example, a user could put many newline characters to mess up the connection, and HttpMessage's validation step prevents such a problem.

To fix this problem, you have to provide a value string that does not contain either '\r', '\n', '\v', or '\f'.

> Multipart messages cause IllegalArgumentException
> -------------------------------------------------
>
> Key: NETTY-186
> URL: https://jira.jboss.org/jira/browse/NETTY-186
> Project: Netty
> Issue Type: Bug
> Affects Versions: 3.1.0.CR1
> Reporter: Alessio Soldano
> Assignee: Trustin Lee
>
> As said on IRC, I'm getting this:
> #
> java.lang.IllegalArgumentException: value contains one of the following prohibited characters: \r\n\v\f: multipart/related; type="application/xop+xml"; start="<rootpart@...>";
> #
> start-info="text/xml";
> #
> boundary="----=_Part_1_12572266.1245942516794"
> #
> at org.jboss.netty.handler.codec.http.DefaultHttpMessage.validateHeaderValue(DefaultHttpMessage.java:144)
> #
> at org.jboss.netty.handler.codec.http.DefaultHttpMessage.addHeader(DefaultHttpMessage.java:62)
> #
> at org.jboss.ws.core.client.HTTPRemotingConnection.setAdditionalHeaders(HTTPRemotingConnection.java:392)
> #
> at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:262)
> #
> at org.jboss.ws.core.client.SOAPProtocolConnectionHTTP.invoke(SOAPProtocolConnectionHTTP.java:68)
> #
> at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:340)
> #
> at org.jboss.ws.core.jaxrpc.client.CallImpl.invokeInternal(CallImpl.java:516)
> #
> at org.jboss.ws.core.jaxrpc.client.CallImpl.invoke(CallImpl.java:275)
> #
> at org.jboss.ws.core.jaxrpc.client.PortProxy.invoke(PortProxy.java:154)
> #
> at $Proxy4.ping(Unknown Source)
> #
> at org.jboss.test.ws.jaxrpc.xop.rpclit.XOPBase.requestComplex(XOPBase.java:86)
> #
> at org.jboss.test.ws.jaxrpc.xop.rpclit.XOPBase.testResponseOptimized(XOPBase.java:68)

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Commented: (NETTY-186) Multipart messages cause IllegalArgumentException

2009-06-25T10:27:56Z

[ https://jira.jboss.org/jira/browse/NETTY-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473814#action_12473814 ]

Trustin Lee commented on NETTY-186:
-----------------------------------

The dot (.) before start="..." is actually tab (\t) according to the hex dump he provided:

00000000 50 4f 53 54 20 2f 6a 61 78 72 70 63 2d 78 6f 70 POST /ja xrpc-xop
00000010 2d 72 70 63 6c 69 74 20 48 54 54 50 2f 31 2e 31 -rpclit HTTP/1.1
00000020 0d 0a 53 4f 41 50 41 63 74 69 6f 6e 3a 20 22 22 ..SOAPAc tion: ""
00000030 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 ..Conten t-Type:
00000040 6d 75 6c 74 69 70 61 72 74 2f 72 65 6c 61 74 65 multipar t/relate
00000050 64 3b 20 74 79 70 65 3d 22 61 70 70 6c 69 63 61 d; type= "applica
00000060 74 69 6f 6e 2f 78 6f 70 2b 78 6d 6c 22 3b 20 73 tion/xop +xml"; s
00000070 74 61 72 74 3d 22 3c 72 6f 6f 74 70 61 72 74 40 tart="<r ootpart@
00000080 77 73 2e 6a 62 6f 73 73 2e 6f 72 67 3e 22 3b 20 ws.jboss .org>";
00000090 0d 0a 09 73 74 61 72 74 2d 69 6e 66 6f 3d 22 74 ...start -info="t
000000A0 65 78 74 2f 78 6d 6c 22 3b 20 0d 0a 09 62 6f 75 ext/xml" ; ...bou
000000B0 6e 64 61 72 79 3d 22 2d 2d 2d 2d 3d 5f 50 61 72 ndary="- ---=_Par
000000C0 74 5f 30 5f 32 36 35 36 32 34 34 31 2e 31 32 34 t_0_2656 2441.124
000000D0 35 39 34 33 32 39 30 31 35 38 22 0d 0a 4a 42 6f 59432901 58"..JBo
000000E0 73 73 2d 52 65 6d 6f 74 69 6e 67 2d 56 65 72 73 ss-Remot ing-Vers
000000F0 69 6f 6e 3a 20 32 32 0d 0a 55 73 65 72 2d 41 67 ion: 22. .User-Ag
00000100 65 6e 74 3a 20 4a 42 6f 73 73 52 65 6d 6f 74 69 ent: JBo ssRemoti
00000110 6e 67 20 2d 20 32 2e 35 2e 30 2e 53 50 32 20 28 ng - 2.5 .0.SP2 (
00000120 46 6c 6f 75 6e 64 65 72 29 0d 0a 48 6f 73 74 3a Flounder )..Host:
00000130 20 31 32 37 2e 30 2e 30 2e 31 3a 38 30 38 30 0d 127.0.0 .1:8080.
00000140 0a 41 63 63 65 70 74 3a 20 74 65 78 74 2f 68 74 .Accept: text/ht
00000150 6d 6c 2c 20 69 6d 61 67 65 2f 67 69 66 2c 20 69 ml, imag e/gif, i
00000160 6d 61 67 65 2f 6a 70 65 67 2c 20 2a 3b 20 71 3d mage/jpe g, *; q=
00000170 2e 32 2c 20 2a 2f 2a 3b 20 71 3d 2e 32 0d 0a 43 .2, */*; q=.2..C
00000180 6f 6e 6e 65 63 74 69 6f 6e 3a 20 6b 65 65 70 2d onnectio n: keep-
00000190 61 6c 69 76 65 0d 0a 54 72 61 6e 73 66 65 72 2d alive..T ransfer-
000001A0 45 6e 63 6f 64 69 6e 67 3a 20 63 68 75 6e 6b 65 Encoding : chunke
000001B0 64 0d 0a 0d 0a d....
000001B5 32 37 37 0d 0a 0d 0a 2d 2d 2d 2d 2d 2d 3d 5f 50 277....- -----=_P
000001C5 61 72 74 5f 30 5f 32 36 35 36 32 34 34 31 2e 31 art_0_26 562441.1
000001D5 32 34 35 39 34 33 32 39 30 31 35 38 0d 0a 43 6f 24594329 0158..Co
000001E5 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 70 6c ntent-Ty pe: appl
000001F5 69 63 61 74 69 6f 6e 2f 78 6f 70 2b 78 6d 6c 3b ication/ xop+xml;
00000205 20 74 79 70 65 3d 22 74 65 78 74 2f 78 6d 6c 22 type="t ext/xml"
00000215 0d 0a 43 6f 6e 74 65 6e 74 2d 54 72 61 6e 73 66 ..Conten t-Transf
00000225 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 38 62 69 er-Encod ing: 8bi
00000235 74 0d 0a 43 6f 6e 74 65 6e 74 2d 49 44 3a 20 3c t..Conte nt-ID: <
00000245 72 6f 6f 74 70 61 72 74 40 77 73 2e 6a 62 6f 73 rootpart @ws.jbos
00000255 73 2e 6f 72 67 3e 0d 0a 0d 0a 3c 65 6e 76 3a 45 s.org>.. ..<env:E
00000265 6e 76 65 6c 6f 70 65 20 78 6d 6c 6e 73 3a 65 6e nvelope xmlns:en
00000275 76 3d 27 68 74 74 70 3a 2f 2f 73 63 68 65 6d 61 v='http: //schema
00000285 73 2e 78 6d 6c 73 6f 61 70 2e 6f 72 67 2f 73 6f s.xmlsoa p.org/so
00000295 61 70 2f 65 6e 76 65 6c 6f 70 65 2f 27 3e 3c 65 ap/envel ope/'><e
000002A5 6e 76 3a 48 65 61 64 65 72 3e 3c 2f 65 6e 76 3a nv:Heade r></env:
000002B5 48 65 61 64 65 72 3e 3c 65 6e 76 3a 42 6f 64 79 Header>< env:Body
000002C5 3e 3c 6e 73 31 3a 70 69 6e 67 20 78 6d 6c 6e 73 ><ns1:pi ng xmlns
000002D5 3a 6e 73 31 3d 27 68 74 74 70 3a 2f 2f 6a 62 6f :ns1='ht tp://jbo
000002E5 73 73 2e 6f 72 67 2f 74 65 73 74 2f 77 73 2f 78 ss.org/t est/ws/x
000002F5 6f 70 27 3e 3c 70 61 72 61 6d 65 74 65 72 73 20 op'><par ameters
00000305 78 6d 6c 6e 73 3a 78 73 69 3d 22 68 74 74 70 3a xmlns:xs i="http:
00000315 2f 2f 77 77 77 2e 77 33 2e 6f 72 67 2f 32 30 30 //www.w3 .org/200
00000325 31 2f 58 4d 4c 53 63 68 65 6d 61 2d 69 6e 73 74 1/XMLSch ema-inst
00000335 61 6e 63 65 22 3e 3c 6d 65 73 73 61 67 65 3e 31 ance"><m essage>1
00000345 7c 31 3c 2f 6d 65 73 73 61 67 65 3e 3c 78 6f 70 |1</mess age><xop
00000355 43 6f 6e 74 65 6e 74 3e 3c 78 6f 70 3a 49 6e 63 Content> <xop:Inc
00000365 6c 75 64 65 20 78 6d 6c 6e 73 3a 78 6f 70 3d 22 lude xml ns:xop="
00000375 68 74 74 70 3a 2f 2f 77 77 77 2e 77 33 2e 6f 72 http://w ww.w3.or
00000385 67 2f 32 30 30 34 2f 30 38 2f 78 6f 70 2f 69 6e g/2004/0 8/xop/in
00000395 63 6c 75 64 65 22 20 68 72 65 66 3d 22 63 69 64 clude" h ref="cid
000003A5 3a 78 6f 70 43 6f 6e 74 65 6e 74 2d 61 36 34 63 :xopCont ent-a64c
000003B5 39 30 38 62 2d 64 31 32 36 2d 34 39 34 64 2d 61 908b-d12 6-494d-a
000003C5 35 63 30 2d 66 64 65 31 32 65 31 38 31 33 35 34 5c0-fde1 2e181354
000003D5 40 77 73 2e 6a 62 6f 73 73 2e 6f 72 67 22 3e 3c @ws.jbos s.org"><
000003E5 2f 78 6f 70 3a 49 6e 63 6c 75 64 65 3e 3c 2f 78 /xop:Inc lude></x
000003F5 6f 70 43 6f 6e 74 65 6e 74 3e 3c 2f 70 61 72 61 opConten t></para
00000405 6d 65 74 65 72 73 3e 3c 2f 6e 73 31 3a 70 69 6e meters>< /ns1:pin
00000415 67 3e 3c 2f 65 6e 76 3a 42 6f 64 79 3e 3c 2f 65 g></env: Body></e
00000425 6e 76 3a 45 6e 76 65 6c 6f 70 65 3e 0d 0a nv:Envel ope>..
00000433 64 66 0d 0a 0d 0a 2d 2d 2d 2d 2d 2d 3d 5f 50 61 df....-- ----=_Pa
00000443 72 74 5f 30 5f 32 36 35 36 32 34 34 31 2e 31 32 rt_0_265 62441.12
00000453 34 35 39 34 33 32 39 30 31 35 38 0d 0a 43 6f 6e 45943290 158..Con
00000463 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 70 6c 69 tent-Typ e: appli
00000473 63 61 74 69 6f 6e 2f 6f 63 74 65 74 2d 73 74 72 cation/o ctet-str
00000483 65 61 6d 0d 0a 43 6f 6e 74 65 6e 74 2d 54 72 61 eam..Con tent-Tra
00000493 6e 73 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 nsfer-En coding:
000004A3 62 69 6e 61 72 79 0d 0a 43 6f 6e 74 65 6e 74 2d binary.. Content-
000004B3 49 64 3a 20 3c 78 6f 70 43 6f 6e 74 65 6e 74 2d Id: <xop Content-
000004C3 61 36 34 63 39 30 38 62 2d 64 31 32 36 2d 34 39 a64c908b -d126-49
000004D3 34 64 2d 61 35 63 30 2d 66 64 65 31 32 65 31 38 4d-a5c0- fde12e18
000004E3 31 33 35 34 40 77 73 2e 6a 62 6f 73 73 2e 6f 72 1354@ws. jboss.or
000004F3 67 3e 0d 0a 0d 0a 41 6e 6f 74 68 65 72 20 70 6c g>....An other pl
00000503 61 69 6e 20 74 65 78 74 20 61 74 74 61 63 68 6d ain text attachm
00000513 65 6e 74 0d 0a ent..
00000518 32 62 0d 0a 0d 0a 2d 2d 2d 2d 2d 2d 3d 5f 50 61 2b....-- ----=_Pa
00000528 72 74 5f 30 5f 32 36 35 36 32 34 34 31 2e 31 32 rt_0_265 62441.12
00000538 34 35 39 34 33 32 39 30 31 35 38 2d 2d 0d 0a 0d 45943290 158--...
00000548 0a .
00000549 30 0d 0a 0..
0000054C 0d 0a ..

[JBoss JIRA] Commented: (NETTY-186) Multipart messages cause IllegalArgumentException

2009-06-25T08:28:56Z

[ https://jira.jboss.org/jira/browse/NETTY-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473800#action_12473800 ]

Alessio Soldano commented on NETTY-186:
---------------------------------------

The message I'd like to send is something like:

POST /jaxrpc-xop-rpclit HTTP/1.1

SOAPAction: ""

Content-Type: multipart/related; type="application/xop+xml"; start="<rootpart@...>";

.start-info="text/xml";

.boundary="----=_Part_0_26562441.1245943290158"

JBoss-Remoting-Version: 22

User-Agent: JBossRemoting - 2.5.0.SP2 (Flounder)

Host: 127.0.0.1:8080

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Connection: keep-alive

Transfer-Encoding: chunked

277

------=_Part_0_26562441.1245943290158

Content-Type: application/xop+xml; type="text/xml"

Content-Transfer-Encoding: 8bit

Content-ID: <rootpart@...>

<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><env:Header></env:Header><env:Body><ns1:ping xmlns:ns1='http://jboss.org/test/ws/xop'><parameters xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><message>1|1</message><xopContent><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:xopContent-a64c908b-d126-494d-a5c0-fde12e181354@..."></xop:Include></xopContent></parameters></ns1:ping></env:Body></env:Envelope>

df

------=_Part_0_26562441.1245943290158

Content-Type: application/octet-stream

Content-Transfer-Encoding: binary

Content-Id: <xopContent-a64c908b-d126-494d-a5c0-fde12e181354@...>

Another plain text attachment

2b

------=_Part_0_26562441.1245943290158--

[JBoss JIRA] Created: (NETTY-186) Multipart messages cause IllegalArgumentException

2009-06-25T08:27:02Z

Multipart messages cause IllegalArgumentException
-------------------------------------------------

Key: NETTY-186
URL: https://jira.jboss.org/jira/browse/NETTY-186
Project: Netty
Issue Type: Bug
Affects Versions: 3.1.0.CR1
Reporter: Alessio Soldano
Assignee: Trustin Lee

As said on IRC, I'm getting this:

#
java.lang.IllegalArgumentException: value contains one of the following prohibited characters: \r\n\v\f: multipart/related; type="application/xop+xml"; start="<rootpart@...>";
#
start-info="text/xml";
#
boundary="----=_Part_1_12572266.1245942516794"
#
at org.jboss.netty.handler.codec.http.DefaultHttpMessage.validateHeaderValue(DefaultHttpMessage.java:144)
#
at org.jboss.netty.handler.codec.http.DefaultHttpMessage.addHeader(DefaultHttpMessage.java:62)
#
at org.jboss.ws.core.client.HTTPRemotingConnection.setAdditionalHeaders(HTTPRemotingConnection.java:392)
#
at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:262)
#
at org.jboss.ws.core.client.SOAPProtocolConnectionHTTP.invoke(SOAPProtocolConnectionHTTP.java:68)
#
at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:340)
#
at org.jboss.ws.core.jaxrpc.client.CallImpl.invokeInternal(CallImpl.java:516)
#
at org.jboss.ws.core.jaxrpc.client.CallImpl.invoke(CallImpl.java:275)
#
at org.jboss.ws.core.jaxrpc.client.PortProxy.invoke(PortProxy.java:154)
#
at $Proxy4.ping(Unknown Source)
#
at org.jboss.test.ws.jaxrpc.xop.rpclit.XOPBase.requestComplex(XOPBase.java:86)
#
at org.jboss.test.ws.jaxrpc.xop.rpclit.XOPBase.testResponseOptimized(XOPBase.java:68)

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-185) HTTP tunneling transport does not support HTTPS

2009-06-25T03:52:56Z

[ https://jira.jboss.org/jira/browse/NETTY-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-185.
-----------------------------

Resolution: Done

Done.

All HTTPS related options can be controlled via HttpTunnelingSocketChannelConfig, which is now public. Please refer to the Javadoc of HttpTunnelingSocketChannelConfig to see the list of available options.

> HTTP tunneling transport does not support HTTPS
> -----------------------------------------------
>
> Key: NETTY-185
> URL: https://jira.jboss.org/jira/browse/NETTY-185
> Project: Netty
> Issue Type: Bug
> Components: Transport
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Priority: Blocker
> Fix For: 3.1.0.GA
>
>
> HTTP tunneling client socket channel can't connect to an HTTPS server.

[JBoss JIRA] Created: (NETTY-185) HTTP tunneling transport does not support HTTPS

2009-06-25T03:08:56Z

HTTP tunneling transport does not support HTTPS
-----------------------------------------------

Key: NETTY-185
URL: https://jira.jboss.org/jira/browse/NETTY-185
Project: Netty
Issue Type: Bug
Components: Transport
Reporter: Trustin Lee
Assignee: Trustin Lee
Priority: Blocker
Fix For: 3.1.0.GA

HTTP tunneling client socket channel can't connect to an HTTPS server.

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-184) Provide NIO equivalent for ChunkedFile and ChunkedStream

2009-06-25T00:47:56Z

[ https://jira.jboss.org/jira/browse/NETTY-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-184.
-----------------------------

Resolution: Done

Done.

> Provide NIO equivalent for ChunkedFile and ChunkedStream
> --------------------------------------------------------
>
> Key: NETTY-184
> URL: https://jira.jboss.org/jira/browse/NETTY-184
> Project: Netty
> Issue Type: Feature Request
> Components: Handler
> Affects Versions: 3.1.0.CR1
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.1.0.GA
>
>
> Some users prefer NIO FileChannel and ReadableByteChannel to RandomeAccessFile and InputStream. Frederic already wrote the preliminary implementation, so I can merge it without much effort.

[JBoss JIRA] Created: (NETTY-184) Provide NIO equivalent for ChunkedFile and ChunkedStream

2009-06-25T00:45:56Z

Provide NIO equivalent for ChunkedFile and ChunkedStream
--------------------------------------------------------

Key: NETTY-184
URL: https://jira.jboss.org/jira/browse/NETTY-184
Project: Netty
Issue Type: Feature Request
Components: Handler
Affects Versions: 3.1.0.CR1
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.1.0.GA

Some users prefer NIO FileChannel and ReadableByteChannel to RandomeAccessFile and InputStream. Frederic already wrote the preliminary implementation, so I can merge it without much effort.

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-183) Client-side HTTP tunneling transport logs and swallows an exceptionCaught event.

2009-06-24T11:14:57Z

[ https://jira.jboss.org/jira/browse/NETTY-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-183.
-----------------------------

Resolution: Done

Fixed.

> Client-side HTTP tunneling transport logs and swallows an exceptionCaught event.
> --------------------------------------------------------------------------------
>
> Key: NETTY-183
> URL: https://jira.jboss.org/jira/browse/NETTY-183
> Project: Netty
> Issue Type: Bug
> Components: Transport
> Affects Versions: 3.1.0.CR1
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.1.0.GA
>
>
> If a user uses HttpTunnelingClientSocketChannel, any exception events triggered by its underlying SocketChannel implementation (e.g. origianl NIO socket transport) should be propagated to the user's ChannelHandler. However, the current implementation just logs the exception and swallows it.

[JBoss JIRA] Created: (NETTY-183) Client-side HTTP tunneling transport logs and swallows an exceptionCaught event.

2009-06-24T11:10:59Z

Client-side HTTP tunneling transport logs and swallows an exceptionCaught event.
--------------------------------------------------------------------------------

Key: NETTY-183
URL: https://jira.jboss.org/jira/browse/NETTY-183
Project: Netty
Issue Type: Bug
Components: Transport
Affects Versions: 3.1.0.CR1
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.1.0.GA

If a user uses HttpTunnelingClientSocketChannel, any exception events triggered by its underlying SocketChannel implementation (e.g. origianl NIO socket transport) should be propagated to the user's ChannelHandler. However, the current implementation just logs the exception and swallows it.

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-182) NIO server socket sometimes does not shut down

2009-06-23T19:54:56Z

[ https://jira.jboss.org/jira/browse/NETTY-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-182.
-----------------------------

Resolution: Done

Fixed at revision 1493

> NIO server socket sometimes does not shut down
> -----------------------------------------------
>
> Key: NETTY-182
> URL: https://jira.jboss.org/jira/browse/NETTY-182
> Project: Netty
> Issue Type: Bug
> Components: Transport
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Priority: Minor
> Fix For: 3.1.0.GA
>
>
> The Boss thread does not terminate itself when the server socket channel has been closed. This bug appeared when I started to use Socket.accept() instead of SocketChannel.accept(). This issue can be fixed by swallowing ClosedSelectorException and making sure channel.isBound() returns true for each loop.

[JBoss JIRA] Created: (NETTY-182) NIO server socket sometimes does not shut down

2009-06-23T19:48:56Z

NIO server socket sometimes does not shut down
-----------------------------------------------

Key: NETTY-182
URL: https://jira.jboss.org/jira/browse/NETTY-182
Project: Netty
Issue Type: Bug
Components: Transport
Reporter: Trustin Lee
Assignee: Trustin Lee
Priority: Minor
Fix For: 3.1.0.GA

The Boss thread does not terminate itself when the server socket channel has been closed. This bug appeared when I started to use Socket.accept() instead of SocketChannel.accept(). This issue can be fixed by swallowing ClosedSelectorException and making sure channel.isBound() returns true for each loop.

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-181) Backport upstream fixes for LinkedTransferQueue

2009-06-23T09:09:56Z

[ https://jira.jboss.org/jira/browse/NETTY-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-181.
-----------------------------

Resolution: Done

Done.

> Backport upstream fixes for LinkedTransferQueue
> -----------------------------------------------
>
> Key: NETTY-181
> URL: https://jira.jboss.org/jira/browse/NETTY-181
> Project: Netty
> Issue Type: Task
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.1.0.GA
>
>
> According to the changelog of the upstream LinkedTransferQueue, a bug with iterator has been fixed:
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166y/LinkedTransferQueue.java
> Although we are not experiencing the problem, it seems like a good idea to backport the fix.

[JBoss JIRA] Created: (NETTY-181) Backport upstream fixes for LinkedTransferQueue

2009-06-23T09:07:56Z

Backport upstream fixes for LinkedTransferQueue
-----------------------------------------------

Key: NETTY-181
URL: https://jira.jboss.org/jira/browse/NETTY-181
Project: Netty
Issue Type: Task
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.1.0.GA

According to the changelog of the upstream LinkedTransferQueue, a bug with iterator has been fixed:

http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166y/LinkedTransferQueue.java

Although we are not experiencing the problem, it seems like a good idea to backport the fix.

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-180) Channel.getRemoteAddress() can return null for a received MessageEvent when ExecutionHandler is in the pipeline.

2009-06-23T00:54:56Z

[ https://jira.jboss.org/jira/browse/NETTY-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-180.
-----------------------------

Resolution: Done

Actually, MessageEvent.getRemoteAddress() for DatagramChannel always contains the correct remote address, so it shouldn't be a problem.

All fixes have been checked in.

> Channel.getRemoteAddress() can return null for a received MessageEvent when ExecutionHandler is in the pipeline.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: NETTY-180
> URL: https://jira.jboss.org/jira/browse/NETTY-180
> Project: Netty
> Issue Type: Bug
> Components: Transport
> Affects Versions: 3.1.0.CR1
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.1.0.GA
>
>
> NioChannel.getLocalAddress() and getRemoteAddress() get the address information directly from SocketChannel, and therefore the state of the connection is reflected immediately. If the connection has been closed before the MessageEvent is handled by the ChannelHandler placed after ExecutionHandler, Channel.getRemoteAddress() will return null, possibly causing NPE. User will be confused about this because he or she did not receive the 'channelClosed' event yet.
> To address this issue, all socket and datagram channel implementations need to cache their remote and local addresses.
> However, Channel.isOpen(), isBound(), and isConnected() will still return false. I'm not sure if there's something I can do about this because we cannot hide and unhide the state correctly - there is no way to determine all events has been processed by all handlers.

[JBoss JIRA] Commented: (NETTY-180) Channel.getRemoteAddress() can return null for a received MessageEvent when ExecutionHandler is in the pipeline.

2009-06-23T00:44:56Z

[ https://jira.jboss.org/jira/browse/NETTY-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473362#action_12473362 ]

Trustin Lee commented on NETTY-180:
-----------------------------------

Dealing with a datagram channel are somewhat trickier because DatagramSocket can be disconnected and connected to another host again.

[JBoss JIRA] Created: (NETTY-180) Channel.getRemoteAddress() can return null for a received MessageEvent when ExecutionHandler is in the pipeline.

2009-06-23T00:19:57Z

Channel.getRemoteAddress() can return null for a received MessageEvent when ExecutionHandler is in the pipeline.
----------------------------------------------------------------------------------------------------------------

Key: NETTY-180
URL: https://jira.jboss.org/jira/browse/NETTY-180
Project: Netty
Issue Type: Bug
Components: Transport
Affects Versions: 3.1.0.CR1
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.1.0.GA

NioChannel.getLocalAddress() and getRemoteAddress() get the address information directly from SocketChannel, and therefore the state of the connection is reflected immediately. If the connection has been closed before the MessageEvent is handled by the ChannelHandler placed after ExecutionHandler, Channel.getRemoteAddress() will return null, possibly causing NPE. User will be confused about this because he or she did not receive the 'channelClosed' event yet.

To address this issue, all socket and datagram channel implementations need to cache their remote and local addresses.

However, Channel.isOpen(), isBound(), and isConnected() will still return false. I'm not sure if there's something I can do about this because we cannot hide and unhide the state correctly - there is no way to determine all events has been processed by all handlers.

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

Netty 3.1.0.CR1 released: Large Data Streaming, HTTP Performance, and Javadoc

2009-06-22T19:20:39Z

Hi community,

Netty 3.1.0.CR1, the first release candidate of 3.1 branch, has been
released.

The Netty project is an effort to provide an asynchronous, event-driven
network application framework and tools for rapid development of
maintainable, high-performance, high-scalability protocol servers and
clients.

In other words, Netty is a NIO client server framework that enables
quick and easy development of network applications such as protocol
servers and clients. It simplifies and streamlines network programming
such as TCP and UDP socket servers.

Please visit our web site to download it:

* http://www.jboss.org/netty/

As always, your feed back is more than appreciated. Please visit the
discussion forum and leave some comments and questions:

* http://www.jboss.org/netty/community.html

Alternatively, please follow us at Twitter and send a message:

* http://twitter.com/netty_project

Success Story - 100,000 Concurrent HTTP Connections
===================================================
Amir Aslihefendic was able to write a Comet server in just 1 day with
Netty, after evaluating many alternatives. His server is now serving
100,000 concurrent HTTP connections at Plurk.com. For more stories,
read his post: http://tinyurl.com/kpnjne

Do you have a story to share with us about Netty? Then please do not
hesitate to contact us - such a story will make my day!

Complete Javadoc
================
As promised, this release includes full Javadoc for all public and
protected methods. Any new features added in 3.1 should be easier to
use now. I believe the documentation can be even better with your
ongoing feed back. Please feel free to contact us if the documentation
does not tell you what you want to know about Netty or if it could be
better organized.

Large Data Streaming
====================
Writing a large file or stream in a non-blocking asynchronous framework
requires somewhat complex state management because asynchronous writes
can lead to buffer overrun and OutOfMemoryError. Therefore, data
streaming was a highly demanded feature by the community. This release
introduces ChunkedWriteHandler which makes large media streaming easier
than ever. HTTP static file server has been added as an example:
http://tinyurl.com/n95or2

HTTP Performance Improvements
=============================
The performance of HTTP decoder has been improved even further. It is
expected for most HTTP applications to experience about 10% performance
boost, although your mileage may vary.

Proxy Server Example
====================
One of the most frequently asked questions is 'how do I write a proxy
server with Netty?' Because proxy server mixes the server-side and
client-side terms for explanation, there is higher chance of confusion
during the conversation. So, I wrote a working proxy example. Enjoy:
http://tinyurl.com/qq7ghu

Upcoming Releases
=================
The next release will be 3.1.0.GA with higher stability. Please keep us
updated with any bugs, design issues, API usability feed back, and
questions.

Miscellaneous
=============
For the full changelog, please visit here:

* http://tinyurl.com/qh786q

Again, as always, your feed back is more than appreciated. Please visit
the discussion forum and feel free to leave some comments and questions:

* http://www.jboss.org/netty/community.html

Alternatively, please follow us at Twitter and send a message:

* http://twitter.com/netty_project

Cheers,
--
— Trustin Lee, http://gleamynode.net/

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

signature.asc (266 bytes) Download Attachment

— Trustin Lee, http://gleamynode.net/

[JBoss JIRA] Created: (NETTY-179) Allow a user to specify log level when creating LoggingHandler

2009-06-19T02:44:56Z

Allow a user to specify log level when creating LoggingHandler
--------------------------------------------------------------

Key: NETTY-179
URL: https://jira.jboss.org/jira/browse/NETTY-179
Project: Netty
Issue Type: Feature Request
Components: Handler
Reporter: Trustin Lee
Assignee: Trustin Lee
Priority: Trivial
Fix For: 3.1.0.CR1

It's often useful to log messages at a different level than DEBUG. Especially when using java.util.logging, which is not very convenient to configure.

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-179) Allow a user to specify log level when creating LoggingHandler

2009-06-19T02:44:56Z

[ https://jira.jboss.org/jira/browse/NETTY-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-179.
-----------------------------

Resolution: Done

Done

> Allow a user to specify log level when creating LoggingHandler
> --------------------------------------------------------------
>
> Key: NETTY-179
> URL: https://jira.jboss.org/jira/browse/NETTY-179
> Project: Netty
> Issue Type: Feature Request
> Components: Handler
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Priority: Trivial
> Fix For: 3.1.0.CR1
>
>
> It's often useful to log messages at a different level than DEBUG. Especially when using java.util.logging, which is not very convenient to configure.

[JBoss JIRA] Closed: (NETTY-178) ObjectEncoder encodes array fields incorrectly.

2009-06-18T07:28:56Z

[ https://jira.jboss.org/jira/browse/NETTY-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-178.
-----------------------------

Resolution: Done

Fixed at revision 1445

> ObjectEncoder encodes array fields incorrectly.
> -----------------------------------------------
>
> Key: NETTY-178
> URL: https://jira.jboss.org/jira/browse/NETTY-178
> Project: Netty
> Issue Type: Bug
> Components: Handler
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Priority: Critical
> Fix For: 3.1.0.CR1
>
>
> If a user tries to decode a Java object which contains an array field, he or she will see the following exception:
> java.io.InvalidClassException: failed to read class descriptor
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1567)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> at
> org.jboss.netty.handler.codec.serialization.ObjectDecoder.decode(ObjectDecoder.java:117)
> at
> org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:244)
> at
> org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
> at
> org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
> at
> org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
> at
> org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> at
> org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> at
> org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.ClassNotFoundException: [B
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> at
> org.jboss.netty.handler.codec.serialization.CompactObjectInputStream.loadClass(CompactObjectInputStream.java:100)
> at
> org.jboss.netty.handler.codec.serialization.CompactObjectInputStream.readClassDescriptor(CompactObjectInputStream.java:74)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1565)
> It is because the encoder did not serialize the class descriptor of the array field correctly.

[JBoss JIRA] Created: (NETTY-178) ObjectEncoder encodes array fields incorrectly.

2009-06-18T07:26:56Z

ObjectEncoder encodes array fields incorrectly.
-----------------------------------------------

Key: NETTY-178
URL: https://jira.jboss.org/jira/browse/NETTY-178
Project: Netty
Issue Type: Bug
Components: Handler
Reporter: Trustin Lee
Assignee: Trustin Lee
Priority: Critical
Fix For: 3.1.0.CR1

If a user tries to decode a Java object which contains an array field, he or she will see the following exception:

java.io.InvalidClassException: failed to read class descriptor
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1567)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
org.jboss.netty.handler.codec.serialization.ObjectDecoder.decode(ObjectDecoder.java:117)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:244)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
at
org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
at
org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassNotFoundException: [B
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at
org.jboss.netty.handler.codec.serialization.CompactObjectInputStream.loadClass(CompactObjectInputStream.java:100)
at
org.jboss.netty.handler.codec.serialization.CompactObjectInputStream.readClassDescriptor(CompactObjectInputStream.java:74)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1565)

It is because the encoder did not serialize the class descriptor of the array field correctly.

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-177) Ensure container integration

2009-06-18T02:04:56Z

[ https://jira.jboss.org/jira/browse/NETTY-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-177.
-----------------------------

Resolution: Done

Done

> Ensure container integration
> ----------------------------
>
> Key: NETTY-177
> URL: https://jira.jboss.org/jira/browse/NETTY-177
> Project: Netty
> Issue Type: Task
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Priority: Minor
> Fix For: 3.1.0.CR1
>
>
> Make sure all transport implementations are available via the container integration points.

[JBoss JIRA] Created: (NETTY-177) Ensure container integration

2009-06-18T02:02:57Z

Ensure container integration
----------------------------

Key: NETTY-177
URL: https://jira.jboss.org/jira/browse/NETTY-177
Project: Netty
Issue Type: Task
Reporter: Trustin Lee
Assignee: Trustin Lee
Priority: Minor
Fix For: 3.1.0.CR1

Make sure all transport implementations are available via the container integration points.

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-176) toByteBuffer() and slice() sometimes do not respect byte order

2009-06-17T01:09:56Z

[ https://jira.jboss.org/jira/browse/NETTY-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-176.
-----------------------------

Resolution: Done

Fixed.

> toByteBuffer() and slice() sometimes do not respect byte order
> --------------------------------------------------------------
>
> Key: NETTY-176
> URL: https://jira.jboss.org/jira/browse/NETTY-176
> Project: Netty
> Issue Type: Bug
> Components: Buffer
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.1.0.CR1
>
>
> Endianness of the buffer returned by ChannelBuffer.toByteBuffer(int, int) and slice(int, int) is not always equal to the original buffer's endianness.

[JBoss JIRA] Updated: (NETTY-176) toByteBuffer() and slice() sometimes do not respect byte order

2009-06-17T01:07:56Z

[ https://jira.jboss.org/jira/browse/NETTY-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee updated NETTY-176:
------------------------------

Summary: toByteBuffer() and slice() sometimes do not respect byte order (was: ByteBufferBackedBuffer.toByteBuffer() and slice() do not respect byte order)
Description: Endianness of the buffer returned by ChannelBuffer.toByteBuffer(int, int) and slice(int, int) is not always equal to the original buffer's endianness. (was: Endianness of the buffer returned by ByteBufferBackedChannelBuffer.toByteBuffer(int, int) and slice(int, int) is always BIG_ENDIAN.)

[JBoss JIRA] Created: (NETTY-176) ByteBufferBackedBuffer.toByteBuffer() and slice() do not respect byte order

2009-06-17T00:56:56Z

ByteBufferBackedBuffer.toByteBuffer() and slice() do not respect byte order
---------------------------------------------------------------------------

Key: NETTY-176
URL: https://jira.jboss.org/jira/browse/NETTY-176
Project: Netty
Issue Type: Bug
Components: Buffer
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.1.0.CR1

Endianness of the buffer returned by ByteBufferBackedChannelBuffer.toByteBuffer(int, int) and slice(int, int) is always BIG_ENDIAN.

--
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

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

Re: AbstractChannel.toString() / minor change request

2009-06-19T12:35:41Z

I actually meant 'NioAcceptedSocketChannel' is too long. :)

On 2009-06-20 오전 4:11, jasons2645 wrote:

>
> Thanks! Also, in case it makes a difference, I was suggesting adding class.getSimpleName() - not class.getName(), which I agree would be verbose in a log file. So, the toString:
>
>
>
> [id: 0x005973ea, /172.18.37.173:1978 => CO-JSTEVENS-DT/172.18.37.173:5560]
>
>
>
> Would turn into:
>
>
>
> NioAcceptedSocketChannel[id: 0x005973ea, /172.18.37.173:1978 => CO-JSTEVENS-DT/172.18.37.173:5560]
>
>
>
>
>
> ________________________________
>
> From: Trustin Lee (via Nabble) [mailto:ml-user+57722-668069880@...]
> Sent: Friday, June 19, 2009 12:03 PM
> To: Jason Stevens
> Subject: Re: AbstractChannel.toString() / minor change request
>
>
>
> I think prepending the class name takes up too much space in a log file.
> However, I concur with you that there should be some prefix that
> indicates on what transport it is running. I will take care of this
> issue in 3.1.0.CR2
>
> Thanks!
>
> On 2009-06-17 오전 5:49, jasons2645 wrote:
>
>
>>
>> Would it be possible to modify the chunk below from:
>>
>> StringBuilder buf = new StringBuilder(128);
>> buf.append("[id: 0x");
>> buf.append(getIdString());
>>
>> to something like:
>>
>> StringBuilder buf = new StringBuilder(128);
>> buf.append(getClass().getSimpleName() )
>> buf.append("[id: 0x");
>> buf.append(getIdString());
>>
>> This change would make log statements using Channel objects in their
>> messages a little more informative. Also, it would not be inconsistent with
>> other Java classes (for example, Swing's Component's toString is
>> getClass().getName() + "[" + paramString() + "]";)
>>
>> Thanks!
>
>

--
— Trustin Lee, http://gleamynode.net/

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

signature.asc (266 bytes) Download Attachment

— Trustin Lee, http://gleamynode.net/

RE: AbstractChannel.toString() / minor change request

2009-06-19T12:11:18Z

Thanks! Also, in case it makes a difference, I was suggesting adding class.getSimpleName() – not class.getName(), which I agree would be verbose in a log file. So, the toString:

[id: 0x005973ea, /172.18.37.173:1978 => CO-JSTEVENS-DT/172.18.37.173:5560]

Would turn into:

NioAcceptedSocketChannel[id: 0x005973ea, /172.18.37.173:1978 => CO-JSTEVENS-DT/172.18.37.173:5560]

From: Trustin Lee (via Nabble) [mailto:ml-user+57722-668069880@...]
Sent: Friday, June 19, 2009 12:03 PM
To: Jason Stevens
Subject: Re: AbstractChannel.toString() / minor change request

I think prepending the class name takes up too much space in a log file.
However, I concur with you that there should be some prefix that
indicates on what transport it is running. I will take care of this
issue in 3.1.0.CR2

Thanks!

On 2009-06-17 오전 5:49, jasons2645 wrote:

>
> Would it be possible to modify the chunk below from:
>
> StringBuilder buf = new StringBuilder(128);
> buf.append("[id: 0x");
> buf.append(getIdString());
>
> to something like:
>
> StringBuilder buf = new StringBuilder(128);
> buf.append(getClass().getSimpleName() )
> buf.append("[id: 0x");
> buf.append(getIdString());
>
> This change would make log statements using Channel objects in their
> messages a little more informative. Also, it would not be inconsistent with
> other Java classes (for example, Swing's Component's toString is
> getClass().getName() + "[" + paramString() + "]";)
>
> Thanks!

--
— Trustin Lee, http://gleamynode.net/

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

signature.asc (266 bytes) Download Attachment

Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/

This email is a reply to your post @ http://n2.nabble.com/AbstractChannel.toString%28%29---minor-change-request-tp3088770p3121200.html
You can reply by email or by visting the link above.

Re: AbstractChannel.toString() / minor change request

2009-06-19T11:02:28Z

--
— Trustin Lee, http://gleamynode.net/

_______________________________________________
netty-dev mailing list
netty-dev@...
https://lists.jboss.org/mailman/listinfo/netty-dev

signature.asc (266 bytes) Download Attachment

— Trustin Lee, http://gleamynode.net/

AbstractChannel.toString() / minor change request

2009-06-16T13:49:17Z

Would it be possible to modify the chunk below from:

StringBuilder buf = new StringBuilder(128);
buf.append("[id: 0x");
buf.append(getIdString());

to something like:

StringBuilder buf = new StringBuilder(128);
buf.append(getClass().getSimpleName() )
buf.append("[id: 0x");
buf.append(getIdString());

This change would make log statements using Channel objects in their messages a little more informative. Also, it would not be inconsistent with other Java classes (for example, Swing's Component's toString is getClass().getName() + "[" + paramString() + "]";)

Thanks!