6:10 a.m.
Jason, I've moved the DMR lib to the console codebase:
https://github.com/jbossas/console/tree/master/standalone/src/main/java/o...
However when I invoke it the Base64 decoding fails:
https://gist.github.com/872328
Any idea what might be causing this?
/Ike
11:40 p.m.
It could be a bug in a recently contributed base64 routine on the server end. You can try
reverting back to the original base64 impl. I can look into it when I get back on the
weekend.
Sent from my iPad
On Mar 16, 2011, at 4:12 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
Jason, I've moved the DMR lib to the console codebase:
https://github.com/jbossas/console/tree/master/standalone/src/main/java/o...
However when I invoke it the Base64 decoding fails:
https://gist.github.com/872328
Any idea what might be causing this?
/Ike
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
7:47 a.m.
I can dig into this as well (since it is probably my fault!). Can you
provide the DMR string in question that you are trying to convert/encode?
Thanks,
--Jonathan
On Thu, Mar 17, 2011 at 12:40 AM, Jason Greene <jgreene(a)redhat.com> wrote:
It could be a bug in a recently contributed base64 routine on the
server
end. You can try reverting back to the original base64 impl. I can look into
it when I get back on the weekend.
Sent from my iPad
On Mar 16, 2011, at 4:12 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
> Jason, I've moved the DMR lib to the console codebase:
>
https://github.com/jbossas/console/tree/master/standalone/src/main/java/o...
>
> However when I invoke it the Base64 decoding fails:
> https://gist.github.com/872328
>
>
> Any idea what might be causing this?
>
> /Ike
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:27 a.m.
Thanks for your help Jonathan,
I've attached it to the previously created gist:
https://gist.github.com/872328
/Heiko
On Mar 17, 2011, at 1:47 PM, Jonathan Pearlin wrote:
I can dig into this as well (since it is probably my fault!). Can
you provide the DMR string in question that you are trying to convert/encode?
Thanks,
--Jonathan
On Thu, Mar 17, 2011 at 12:40 AM, Jason Greene <jgreene(a)redhat.com> wrote:
It could be a bug in a recently contributed base64 routine on the server end. You can try
reverting back to the original base64 impl. I can look into it when I get back on the
weekend.
Sent from my iPad
On Mar 16, 2011, at 4:12 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
> Jason, I've moved the DMR lib to the console codebase:
>
https://github.com/jbossas/console/tree/master/standalone/src/main/java/o...
>
> However when I invoke it the Base64 decoding fails:
> https://gist.github.com/872328
>
>
> Any idea what might be causing this?
>
> /Ike
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:12 p.m.
Hi Heiko,
Something odd is definitely going on here. First, from what I can tell
the two values you added to the gist are not equal (the plain text DMR
string to does not produce that Base64 string). Second, it appears that the
Base64 encoded string is cut off (when I decode it using some external
tools, the resultant plain text does not look like a complete string, based
on the fact that what I assume is the value "localhost" is cut off as
"loca"). Regardless, it does appear that the issue is due to the fact that
readUTF requests to read more bytes than are available in the stream.
Because the underlying Base64 stream must decode the data on the fly when
read() is called, it is possible that the requested number of bytes does not
equal the actual remaining number of bytes after decoding (this is obviously
an edge case that needs to be corrected). However, I am still not sure if
the issue is due to the stream code or the fact that the Base64 encoded
string appears to be incomplete. How was the Base64 value generated? Do
you have the original DMR string that generated it? I would like to run the
original DMR string through the Base64 encoder in the jboss-dmr project to
see what it produces to verify that we are getting well-formed Base64
encoded strings in the first place.
Thanks,
--Jonathan
On Thu, Mar 17, 2011 at 10:27 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
Thanks for your help Jonathan,
I've attached it to the previously created gist:
https://gist.github.com/872328
/Heiko
On Mar 17, 2011, at 1:47 PM, Jonathan Pearlin wrote:
I can dig into this as well (since it is probably my fault!). Can you
provide the DMR string in question that you are trying to convert/encode?
Thanks,
--Jonathan
On Thu, Mar 17, 2011 at 12:40 AM, Jason Greene <jgreene(a)redhat.com> wrote:
> It could be a bug in a recently contributed base64 routine on the server
> end. You can try reverting back to the original base64 impl. I can look into
> it when I get back on the weekend.
>
> Sent from my iPad
>
> On Mar 16, 2011, at 4:12 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
>
> > Jason, I've moved the DMR lib to the console codebase:
> >
>
https://github.com/jbossas/console/tree/master/standalone/src/main/java/o...
> >
> > However when I invoke it the Base64 decoding fails:
> > https://gist.github.com/872328
> >
> >
> > Any idea what might be causing this?
> >
> > /Ike
> > _______________________________________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
2:36 a.m.
The upper part is the operation (request) send to the http api.
the base64 part is the encoded response. you should be able to reproduce it
like this:
1.) start jboss7 in domain mode
2.) curl -H "Accept:application/dmr-encoded"
http://localhost:9990/domain-api/profile/default
But you are right, there seems to be something strange going on.
I get a different encoded string this time.
Let me double check first. Maybe the error is my side (very likely)
Ike
On Mar 18, 2011, at 2:12 AM, Jonathan Pearlin wrote:
Hi Heiko,
Something odd is definitely going on here. First, from what I can tell the two
values you added to the gist are not equal (the plain text DMR string to does not produce
that Base64 string). Second, it appears that the Base64 encoded string is cut off (when I
decode it using some external tools, the resultant plain text does not look like a
complete string, based on the fact that what I assume is the value "localhost"
is cut off as "loca"). Regardless, it does appear that the issue is due to the
fact that readUTF requests to read more bytes than are available in the stream. Because
the underlying Base64 stream must decode the data on the fly when read() is called, it is
possible that the requested number of bytes does not equal the actual remaining number of
bytes after decoding (this is obviously an edge case that needs to be corrected).
However, I am still not sure if the issue is due to the stream code or the fact that the
Base64 encoded string appears to be incomplete. How was the Base64 value generated? Do
you have the original DMR string that generated it? I would like to run the original DMR
string through the Base64 encoder in the jboss-dmr project to see what it produces to
verify that we are getting well-formed Base64 encoded strings in the first place.
Thanks,
--Jonathan
On Thu, Mar 17, 2011 at 10:27 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
Thanks for your help Jonathan,
I've attached it to the previously created gist:
https://gist.github.com/872328
/Heiko
On Mar 17, 2011, at 1:47 PM, Jonathan Pearlin wrote:
> I can dig into this as well (since it is probably my fault!). Can you provide the
DMR string in question that you are trying to convert/encode?
>
> Thanks,
>
> --Jonathan
>
> On Thu, Mar 17, 2011 at 12:40 AM, Jason Greene <jgreene(a)redhat.com> wrote:
> It could be a bug in a recently contributed base64 routine on the server end. You can
try reverting back to the original base64 impl. I can look into it when I get back on the
weekend.
>
> Sent from my iPad
>
> On Mar 16, 2011, at 4:12 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
>
> > Jason, I've moved the DMR lib to the console codebase:
> >
https://github.com/jbossas/console/tree/master/standalone/src/main/java/o...
> >
> > However when I invoke it the Base64 decoding fails:
> > https://gist.github.com/872328
> >
> >
> > Any idea what might be causing this?
> >
> > /Ike
> > _______________________________________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
9:57 p.m.
It's binary encoded data via writeExrernal on ModelNode. Reading less bytes than you
request is very common. The OS buffers in block sizes that don't always match the size
you give it.
Sent from my iPhone
On Mar 17, 2011, at 6:13 PM, Jonathan Pearlin <jpearlin1(a)gmail.com> wrote:
Hi Heiko,
Something odd is definitely going on here. First, from what I can tell the two
values you added to the gist are not equal (the plain text DMR string to does not produce
that Base64 string). Second, it appears that the Base64 encoded string is cut off (when I
decode it using some external tools, the resultant plain text does not look like a
complete string, based on the fact that what I assume is the value "localhost"
is cut off as "loca"). Regardless, it does appear that the issue is due to the
fact that readUTF requests to read more bytes than are available in the stream. Because
the underlying Base64 stream must decode the data on the fly when read() is called, it is
possible that the requested number of bytes does not equal the actual remaining number of
bytes after decoding (this is obviously an edge case that needs to be corrected).
However, I am still not sure if the issue is due to the stream code or the fact that the
Base64 encoded string appears to be incomplete. How was the Base64 value generated? Do
you have the original DMR string that generated it? I would like to run the original DMR
string through the Base64 encoder in the jboss-dmr project to see what it produces to
verify that we are getting well-formed Base64 encoded strings in the first place.
Thanks,
--Jonathan
On Thu, Mar 17, 2011 at 10:27 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
Thanks for your help Jonathan,
I've attached it to the previously created gist:
https://gist.github.com/872328
/Heiko
On Mar 17, 2011, at 1:47 PM, Jonathan Pearlin wrote:
> I can dig into this as well (since it is probably my fault!). Can you provide the
DMR string in question that you are trying to convert/encode?
>
> Thanks,
>
> --Jonathan
>
> On Thu, Mar 17, 2011 at 12:40 AM, Jason Greene <jgreene(a)redhat.com> wrote:
> It could be a bug in a recently contributed base64 routine on the server end. You can
try reverting back to the original base64 impl. I can look into it when I get back on the
weekend.
>
> Sent from my iPad
>
> On Mar 16, 2011, at 4:12 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
>
> > Jason, I've moved the DMR lib to the console codebase:
> >
https://github.com/jbossas/console/tree/master/standalone/src/main/java/o...
> >
> > However when I invoke it the Base64 decoding fails:
> > https://gist.github.com/872328
> >
> >
> > Any idea what might be causing this?
> >
> > /Ike
> > _______________________________________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5:20 p.m.
From the testing I was able to do with the string provided (and some
that I
generated), it appears that everything works fine if the Base64 encoded
string is complete. The string provided definitely appears to have been cut
off. I feel as though we are looking in the wrong place: we should try to
see if we can re-create whatever caused the response to be cut short (is it
possible that the HTML response was cut off, which caused the whole problem
or can you repeat this every time)? My suspicion is that we will find
something wrong with the encoding side.
--Jonathan
On Mon, Mar 21, 2011 at 11:49 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
Yeah, that's what I see as well.
But I cannot identify the changes that could have caused this problem.
Ike
On Mar 19, 2011, at 3:57 AM, Jason Greene wrote:
>> Second, it appears that the Base64 encoded string is cut off
6:09 p.m.
I briefly glanced at this today and will look into it more tonight, I noticed that we did
not do a dmr release upgrade for as yet, so for sure it's not the base64 routine. This
also means the flush issue is still there.
Sent from my iPhone
On Mar 21, 2011, at 5:20 PM, Jonathan Pearlin <jpearlin1(a)gmail.com> wrote:
From the testing I was able to do with the string provided (and some
that I generated), it appears that everything works fine if the Base64 encoded string is
complete. The string provided definitely appears to have been cut off. I feel as though
we are looking in the wrong place: we should try to see if we can re-create whatever
caused the response to be cut short (is it possible that the HTML response was cut off,
which caused the whole problem or can you repeat this every time)? My suspicion is that
we will find something wrong with the encoding side.
--Jonathan
On Mon, Mar 21, 2011 at 11:49 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
Yeah, that's what I see as well.
But I cannot identify the changes that could have caused this problem.
Ike
On Mar 19, 2011, at 3:57 AM, Jason Greene wrote:
>> Second, it appears that the Base64 encoded string is cut off
2:55 a.m.
please see my other email.
it's somehow related to the wrapped payload.
that's the reason why GET requests work fin with Base64 encoded responses,
but POST fails. The HTTPD doesn't unwrap POST response payload before encoding.
Why that is, still remains an open question.
Ike
On Mar 22, 2011, at 12:09 AM, Jason Greene wrote:
I briefly glanced at this today and will look into it more tonight, I
noticed that we did not do a dmr release upgrade for as yet, so for sure it's not the
base64 routine. This also means the flush issue is still there.
Sent from my iPhone
On Mar 21, 2011, at 5:20 PM, Jonathan Pearlin <jpearlin1(a)gmail.com> wrote:
> From the testing I was able to do with the string provided (and some that I
generated), it appears that everything works fine if the Base64 encoded string is
complete. The string provided definitely appears to have been cut off. I feel as though
we are looking in the wrong place: we should try to see if we can re-create whatever
caused the response to be cut short (is it possible that the HTML response was cut off,
which caused the whole problem or can you repeat this every time)? My suspicion is that
we will find something wrong with the encoding side.
>
> --Jonathan
>
> On Mon, Mar 21, 2011 at 11:49 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
>
>
> Yeah, that's what I see as well.
> But I cannot identify the changes that could have caused this problem.
>
> Ike
>
> On Mar 19, 2011, at 3:57 AM, Jason Greene wrote:
>
> >> Second, it appears that the Base64 encoded string is cut off
>
>
5:12 a.m.
maybe we should upgrade the base64 lib to 2.3.7 at the same time.
it seems to fix some issues with illegal characters.
On Mar 22, 2011, at 12:09 AM, Jason Greene wrote:
I briefly glanced at this today and will look into it more tonight, I
noticed that we did not do a dmr release upgrade for as yet, so for sure it's not the
base64 routine. This also means the flush issue is still there.
Sent from my iPhone
On Mar 21, 2011, at 5:20 PM, Jonathan Pearlin <jpearlin1(a)gmail.com> wrote:
> From the testing I was able to do with the string provided (and some that I
generated), it appears that everything works fine if the Base64 encoded string is
complete. The string provided definitely appears to have been cut off. I feel as though
we are looking in the wrong place: we should try to see if we can re-create whatever
caused the response to be cut short (is it possible that the HTML response was cut off,
which caused the whole problem or can you repeat this every time)? My suspicion is that
we will find something wrong with the encoding side.
>
> --Jonathan
>
> On Mon, Mar 21, 2011 at 11:49 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
>
>
> Yeah, that's what I see as well.
> But I cannot identify the changes that could have caused this problem.
>
> Ike
>
> On Mar 19, 2011, at 3:57 AM, Jason Greene wrote:
>
> >> Second, it appears that the Base64 encoded string is cut off
>
>
5032
days inactive
5038
days old
11 comments
3 participants
participants (3)
-
Heiko Braun -
Jason Greene -
Jonathan Pearlin