Loading ...
Sorry, an error occurred while loading the content.

What am I doing wrong?

Expand Messages
  • Klöck Erwin
    Hi, I try to use JSX to serialize a Java class to xml and then to read it again. Deserialization does not have the intended result. What am I doing wrong.
    Message 1 of 23 , May 2, 2001
    • 0 Attachment
      Hi,

      I try to use JSX to serialize a Java class to xml and then to read it again.
      Deserialization does not have the intended result. What am I doing wrong.

      Thanks for your help.

      Erwin

      Here are the files I used:

      <<Ser.java>> <<Deser.java>> <<Otto.java>>
    • Brendan Macmillan
      Hi, Thanks a lot for reporting this problem - but what exactly is the problem? ... What result are you getting? It s great that you included your code (which
      Message 2 of 23 , May 3, 2001
      • 0 Attachment
        Hi,

        Thanks a lot for reporting this problem - but what exactly is the problem?

        > I try to use JSX to serialize a Java class to xml and then to read it again.
        > Deserialization does not have the intended result. What am I doing wrong.

        What result are you getting? It's great that you included your code (which
        looks fine), but the details of what you type in, what XML you get out, and a
        stacktrace of any exception would help a lot. At the moment, it's not
        obvious to me what kind of a problem you are having.


        Cheers,
        Brendan
        PS: A friend and I had a really cool idea for automatic exception reporting
        to me - this would get me a complete stacktrace for every exception (that
        occurs within JSX).

        I have written most of it... but what do people think? Is it rude to
        automatically sent reports to me?
      • craig
        ... I Think it would be great provided it was configurable. Also, maybe a messages to out or err that says it s sending a message to you. Speaking of
        Message 3 of 23 , May 3, 2001
        • 0 Attachment
          >
          > Cheers,
          > Brendan
          > PS: A friend and I had a really cool idea for automatic exception
          > reporting
          > to me - this would get me a complete stacktrace for every exception
          > (that
          > occurs within JSX).
          >
          > I have written most of it... but what do people think? Is it rude to
          > automatically sent reports to me?
          >

          I Think it would be great provided it was configurable. Also, maybe a
          messages to out or err that says it's sending a message to you.

          Speaking of exceotion reporting. It would be really cool if there was a
          way to plugin in you own error handler. I have not been able to figure
          out how to catch an exception caused by class not having a serialized
          variable that it had prior to seriailization (i.e I renamed it to
          something else)

          BTW, the latest release of JSX with String improvements is great!. I
          was may a complete swith to JSX in my application.

          Craig
        • bren@mail.csse.monash.edu.au
          Hey Craig, ... Yes... but how would the configuration be done? I really want a no-brainer solution - I was thinking of having two versions available for
          Message 4 of 23 , May 3, 2001
          • 0 Attachment
            Hey Craig,


            > > PS: A friend and I had a really cool idea for automatic exception
            > > reporting to me - this would get me a complete stacktrace for
            > > every Exception (that occurs within JSX).
            > >
            > > I have written most of it... but what do people think? Is it
            > > rude to automatically sent reports to me?

            > I Think it would be great provided it was configurable.

            Yes... but how would the configuration be done? I really want a
            no-brainer solution - I was thinking of having two versions
            available for download, one with it, the other without it... so
            that the user "configures" it, by choosing! How's that?

            Also, a simply API to switch it off. This would be in static
            fields, in the class that handles it. Something like:
            Catch2mail.off()
            Catch2mail.on()

            > Also, maybe a messages to out or err that says it's sending a
            > message to you.
            Yes, that's a good idea.

            The only hassle is that it needs to be told what your mailhost is...
            and *every* user has to do this.

            I prefer the solution of me running a server somewhere, that just
            accepts streams, and logs them to a file. Hmmm... or actually just
            mails them to me? That would give a seamless effect.

            Hey, has anybody experimented with using hotmail (etc) like that,
            to automatically log reports from an application? Presumably, you
            just sent the right HTTP requests, and it thinks you have typed it
            in from a web-browser. Like a kind of STMP server.


            > Speaking of exceotion reporting. It would be really cool if there
            > is a way to plugin in you own error handler.
            You mean plug it into JSX, specifically?

            > I have not been able to figure out how to catch an exception
            > caused by class not having a serialized variable that it had
            > prior to seriailization (i.e I renamed it to something else)

            OK, this is a common problem that I should have done something about
            ages ago. It honestly seems to be the *only* evolution of classes
            problem that ever actually occurs...

            It is very easy to solve this, by JSX simply not throwing an
            exception, and instead just discarding the information... but this
            is bad practice...

            I guess your idea is the right one - give the object itself a chance
            to handle this situation, and decide what to do with the problem...

            I expect that Java serialization already does this in some way (it
            is a really cool, cleverly designed API - though relatively unknown).
            Let me think about this... the easy way is for JSX just to throw
            an exception, which can be caught within the readObject() method
            of your class... the Exception would contain the name of the field,
            and the data within it.... I can make this exception fit the
            existing API, just by subclassing one of the exceptions already
            thrown.... (assuming they are not final).

            However, I would *much* prefer to stick with Sun's way of doing
            things... for two reasons:
            (1). I want to learn from their example. It is not always obvious
            all of the considerations that went into a design decision...
            (2). Keeping it compatible with their API means that you can trivially
            switch between them. This is important, I feel.

            However, the offshoot from JSX - Hammer - experiments with a different
            system: an Abstract Data Layer (ADL). This allows you to specify
            a mapping between field names and names in the XML.

            The Java Serialization API has another way of doing this, using
            getField and putField, but it is less elegant, because you need to
            specify it explicitly for both reading and writing. With the ADL,
            you only need to specify the mapping in one place.


            > BTW, the latest release of JSX with String improvements is great!.
            > I was may a complete swith to JSX in my application.
            Thanks!...I think? ("I was may a"?) I should have done that ages
            ago, too. I must say, there seems to have been a burst of uptake
            since that release... a lecturer in Arizona is even using it to
            demonstrate serialization in Labs!


            Cheers,
            Brendan
          • Mark Collette
            How about this idea. Create an interface LoggerIF that can receive error messages. Then create two classes that implement it: StdErrLogger, EmailLogger which
            Message 5 of 23 , May 3, 2001
            • 0 Attachment
              How about this idea. Create an interface LoggerIF that can receive error
              messages. Then create two classes that implement it: StdErrLogger,
              EmailLogger which print the errors to stdout, or email them to the
              central server, respectively. Then make you static deserialization
              mechanism have a LoggerIF reference. If it's null, then nothing happens,
              so setLogger(null) would be equivalent to Catch2mail.off(), and
              setLogger( new StdErrLogger() ) would be like Catch2mail.on(). This
              gives maximum flexibility, with the least complexity to the end user.

              Mark Collette


              bren@... wrote:
              >
              > Hey Craig,
              >
              > > > PS: A friend and I had a really cool idea for automatic exception
              > > > reporting to me - this would get me a complete stacktrace for
              > > > every Exception (that occurs within JSX).
              > > >
              > > > I have written most of it... but what do people think? Is it
              > > > rude to automatically sent reports to me?
              >
              > > I Think it would be great provided it was configurable.
              >
              > Yes... but how would the configuration be done? I really want a
              > no-brainer solution - I was thinking of having two versions
              > available for download, one with it, the other without it... so
              > that the user "configures" it, by choosing! How's that?
              >
              > Also, a simply API to switch it off. This would be in static
              > fields, in the class that handles it. Something like:
              > Catch2mail.off()
              > Catch2mail.on()
              >
              > > Also, maybe a messages to out or err that says it's sending a
              > > message to you.
              > Yes, that's a good idea.
              >
              > The only hassle is that it needs to be told what your mailhost is...
              > and *every* user has to do this.
              >
              > I prefer the solution of me running a server somewhere, that just
              > accepts streams, and logs them to a file. Hmmm... or actually just
              > mails them to me? That would give a seamless effect.
              >
              > Hey, has anybody experimented with using hotmail (etc) like that,
              > to automatically log reports from an application? Presumably, you
              > just sent the right HTTP requests, and it thinks you have typed it
              > in from a web-browser. Like a kind of STMP server.
              >
              > > Speaking of exceotion reporting. It would be really cool if there
              > > is a way to plugin in you own error handler.
              > You mean plug it into JSX, specifically?
              >
              > > I have not been able to figure out how to catch an exception
              > > caused by class not having a serialized variable that it had
              > > prior to seriailization (i.e I renamed it to something else)
              >
              > OK, this is a common problem that I should have done something about
              > ages ago. It honestly seems to be the *only* evolution of classes
              > problem that ever actually occurs...
              >
              > It is very easy to solve this, by JSX simply not throwing an
              > exception, and instead just discarding the information... but this
              > is bad practice...
              >
              > I guess your idea is the right one - give the object itself a chance
              > to handle this situation, and decide what to do with the problem...
              >
              > I expect that Java serialization already does this in some way (it
              > is a really cool, cleverly designed API - though relatively unknown).
              > Let me think about this... the easy way is for JSX just to throw
              > an exception, which can be caught within the readObject() method
              > of your class... the Exception would contain the name of the field,
              > and the data within it.... I can make this exception fit the
              > existing API, just by subclassing one of the exceptions already
              > thrown.... (assuming they are not final).
              >
              > However, I would *much* prefer to stick with Sun's way of doing
              > things... for two reasons:
              > (1). I want to learn from their example. It is not always obvious
              > all of the considerations that went into a design decision...
              > (2). Keeping it compatible with their API means that you can trivially
              > switch between them. This is important, I feel.
              >
              > However, the offshoot from JSX - Hammer - experiments with a different
              > system: an Abstract Data Layer (ADL). This allows you to specify
              > a mapping between field names and names in the XML.
              >
              > The Java Serialization API has another way of doing this, using
              > getField and putField, but it is less elegant, because you need to
              > specify it explicitly for both reading and writing. With the ADL,
              > you only need to specify the mapping in one place.
              >
              > > BTW, the latest release of JSX with String improvements is great!.
              > > I was may a complete swith to JSX in my application.
              > Thanks!...I think? ("I was may a"?) I should have done that ages
              > ago, too. I must say, there seems to have been a burst of uptake
              > since that release... a lecturer in Arizona is even using it to
              > demonstrate serialization in Labs!
              >
              > Cheers,
              > Brendan
              >
              > To unsubscribe from this group, send an email to:
              > JSX-ideas-unsubscribe@egroups.com
              >
              >
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            • craig
              ... I would prefer a static api, but then again less code for a shipping application (seperate versions) may be better. ... Yeah, fat fingers and tiny text
              Message 6 of 23 , May 3, 2001
              • 0 Attachment
                bren@... wrote:

                > Hey Craig,
                >
                > .
                >
                > Yes... but how would the configuration be done? I really want a
                > no-brainer solution - I was thinking of having two versions
                > available for download, one with it, the other without it... so
                > that the user "configures" it, by choosing! How's that?
                >
                > Also, a simply API to switch it off. This would be in static
                > fields, in the class that handles it. Something like:
                > Catch2mail.off()
                > Catch2mail.on()

                I would prefer a static api, but then again less code for a shipping
                application (seperate versions) may be better.

                >
                >
                > > Also, maybe a messages to out or err that says it's sending a
                > > message to you.
                > Yes, that's a good idea.
                >
                > The only hassle is that it needs to be told what your mailhost is...
                > and *every* user has to do this.
                >
                > I prefer the solution of me running a server somewhere, that just
                > accepts streams, and logs them to a file. Hmmm... or actually just
                > mails them to me? That would give a seamless effect.
                >
                > Hey, has anybody experimented with using hotmail (etc) like that,
                > to automatically log reports from an application? Presumably, you
                > just sent the right HTTP requests, and it thinks you have typed it
                > in from a web-browser. Like a kind of STMP server.
                >
                >
                > > Speaking of exceotion reporting. It would be really cool if there
                > > is a way to plugin in you own error handler.
                > You mean plug it into JSX, specifically?
                >
                > > I have not been able to figure out how to catch an exception
                > > caused by class not having a serialized variable that it had
                > > prior to seriailization (i.e I renamed it to something else)
                >
                > OK, this is a common problem that I should have done something about
                > ages ago. It honestly seems to be the *only* evolution of classes
                > problem that ever actually occurs...
                >
                > It is very easy to solve this, by JSX simply not throwing an
                > exception, and instead just discarding the information... but this
                > is bad practice...
                >
                > I guess your idea is the right one - give the object itself a chance
                > to handle this situation, and decide what to do with the problem...
                >
                > I expect that Java serialization already does this in some way (it
                > is a really cool, cleverly designed API - though relatively unknown).
                > Let me think about this... the easy way is for JSX just to throw
                > an exception, which can be caught within the readObject() method
                > of your class... the Exception would contain the name of the field,
                > and the data within it.... I can make this exception fit the
                > existing API, just by subclassing one of the exceptions already
                > thrown.... (assuming they are not final).
                >
                > However, I would *much* prefer to stick with Sun's way of doing
                > things... for two reasons:
                > (1). I want to learn from their example. It is not always obvious
                > all of the considerations that went into a design decision...
                > (2). Keeping it compatible with their API means that you can trivially
                >
                > switch between them. This is important, I feel.
                >
                > However, the offshoot from JSX - Hammer - experiments with a different
                >
                > system: an Abstract Data Layer (ADL). This allows you to specify
                > a mapping between field names and names in the XML.
                >
                > The Java Serialization API has another way of doing this, using
                > getField and putField, but it is less elegant, because you need to
                > specify it explicitly for both reading and writing. With the ADL,
                > you only need to specify the mapping in one place.
                >
                >
                > > BTW, the latest release of JSX with String improvements is great!.
                > > I was may a complete swith to JSX in my application.
                > Thanks!...I think? ("I was may a"?) I should have done that ages
                > ago, too. I must say, there seems to have been a burst of uptake
                > since that release... a lecturer in Arizona is even using it to
                > demonstrate serialization in Labs!

                Yeah, fat fingers and tiny text just don't mix well

                >
                >
              • bren@mail.csse.monash.edu.au
                Hi Mark, Thanks for the idea! It looks much more flexible to me, but also more complex. Maybe I don t fully get it? I ve also added some more details of what
                Message 7 of 23 , May 3, 2001
                • 0 Attachment
                  Hi Mark,

                  Thanks for the idea! It looks much more flexible to me, but also
                  more complex. Maybe I don't fully get it?

                  I've also added some more details of what I've been thinking for
                  this "catch2mail" exception reporting system. (Anyone got a better
                  name?)


                  --- In JSX-ideas@y..., Mark Collette <mcollett@s...> wrote:
                  > How about this idea. Create an interface LoggerIF that can receive
                  error
                  > messages. Then create two classes that implement it: StdErrLogger,
                  > EmailLogger which print the errors to stdout, or email them to the
                  > central server, respectively. Then make you static deserialization
                  > mechanism have a LoggerIF reference. If it's null, then nothing
                  > happens,
                  > so setLogger(null) would be equivalent to Catch2mail.off(), and
                  > setLogger( new StdErrLogger() ) would be like Catch2mail.on(). This
                  > gives maximum flexibility, with the least complexity to the end
                  > user.

                  Flexible in the sense that you could also plug in other
                  implementations later on? That's true... but I think this plug
                  idea is more complex than on() and off() methods...

                  Also, when it is "off", you would still want to see the error
                  messages on the stdout! ;-) So perhaps have "null" should
                  somehow mean that it defaults to stdout. Could do this by making
                  "LoggerIF" actually be a superclass with this (default)
                  functionality.

                  Or else it doesn't know where the setLogger() method is...
                  I think that
                  Catch2mail.off()
                  Catch2mail.on()
                  is simpler!! However, you are right that it is not flexible at all...


                  There's another aspect of this catch2mail idea that I haven't
                  mentioned. I want to make it so that it can plug into *any* GPL
                  project, with minimum hassle. In fact, the present implementation
                  can do that... you only need switch it on, and all Exceptions are
                  mailed.

                  Also, you need to write the "setLogger()" method, as well as create
                  the field (of type LoggerIF)... that's more work for the developer,
                  who is plugging "catch2mail" into his/her project.

                  An on/off API is also important, to determine *which* exceptions
                  emailed... using JSX as an example, I only want to email the
                  exceptions coming from JSX, and not any others from the user's
                  own application code!! So, what we do is: switch on() notification
                  when we enter the serialization or deserialization code, and switch
                  it off() when we leave.


                  ...but there's the problem with sending email (setting the
                  mailhost)... any ideas about that aspect?


                  Cheers,
                  Brendan
                • bren@mail.csse.monash.edu.au
                  ... The code factor is probably insignificant (less than 1 k); and so the static API could be included in both. The only real difference between the versions
                  Message 8 of 23 , May 3, 2001
                  • 0 Attachment
                    > > Yes... but how would the configuration be done? I really want a
                    > > no-brainer solution - I was thinking of having two versions
                    > > available for download, one with it, the other without it... so
                    > > that the user "configures" it, by choosing! How's that?
                    > >
                    > > Also, a simply API to switch it off. This would be in static
                    > > fields, in the class that handles it. Something like:
                    > > Catch2mail.off()
                    > > Catch2mail.on()
                    >
                    > I would prefer a static api, but then again less code for a shipping
                    > application (seperate versions) may be better.

                    The code factor is probably insignificant (less than 1 k); and so
                    the static API could be included in both.
                    The only real difference between the versions would be the
                    default setting.

                    Actually, having thought about it more, their needs to be two
                    levels of on/off setting:
                    (1). to turn the entire email report thing on or off
                    (2). to turn it on/off temporarily, depending on which section of
                    code you are in (because I'm only interested in JSX exceptions, not
                    all of the application exceptions...)

                    It also seems that in practice there would be yet another "setting"
                    - of whether it is on or off by default. I think it is important
                    to have it "on" by defualt, because the whole idea is to get as many
                    bug reports as possible! Also, it is then maximum no-brainer
                    solution. If a particular user wants to switch it off, they can do
                    so with the API... I could also offer a version with it switched off
                    by default - and see which one people prefer... that's good market
                    survery information.


                    Cheers,
                    Brendan
                    PS: could you make a guess about how much a reasonable fee would be
                    to use JSX in commercial applications (that aren't GPL)? Just to
                    give me some kind of an idea. ;-)
                  • bren@mail.csse.monash.edu.au
                    OK! This is what I was looking for, with the idea of using hotmail as a STMP server - a really rocking project, I think!
                    Message 9 of 23 , May 3, 2001
                    • 0 Attachment
                      OK! This is what I was looking for, with the idea of using hotmail
                      as a STMP server - a really rocking project, I think!
                      http://freshmeat.net/projects/httpmail/

                      With this, I should be able to automatically email stuff to a
                      hotmail account, without needing the user's mailhost. It does
                      mean that the developer of the project will need to create a
                      hotmail account, if they don't have one anyway --- but this need
                      only be done by the "one" developer, instead of by the "many"
                      users....

                      What would be perfect would be a HTTP email forwarder, that
                      automatically on-mails to the specified account. Then, the
                      developer need only add their email address in (which could be
                      anywhere, and not necessarily a hotmail account).




                      HTTPMail
                      by Dave Dunkin - Tuesday, January 30th 2001 23:26 EST

                      HTTPMail is a project whose goals are to document the HTTPMail
                      protocol, provide at least one client implementation of the HTTPMail
                      protocol, and generally allow access to Hotmail other than through
                      the Web interface.



                      Cheers,
                      Brendan
                    • Mark Collette
                      ... I meant it would be easier for the end developer (me), not you ;) ... No, someone may want it to be totally off, with only their plugin getting notified.
                      Message 10 of 23 , May 3, 2001
                      • 0 Attachment
                        On Fri, 4 May 2001 bren@... wrote:

                        > Hi Mark,
                        >
                        > Thanks for the idea! It looks much more flexible to me, but also
                        > more complex. Maybe I don't fully get it?

                        I meant it would be easier for the end developer (me), not you ;)

                        > Also, when it is "off", you would still want to see the error
                        > messages on the stdout! ;-) So perhaps have "null" should
                        > somehow mean that it defaults to stdout. Could do this by making
                        > "LoggerIF" actually be a superclass with this (default)
                        > functionality.

                        No, someone may want it to be totally off, with only their plugin getting
                        notified. Say that way I can save to binary format, or when reading in try
                        something else, or just popup an error dialog.

                        Then there are the people who want it printed to the console, then the
                        server people who want it going to a log files, then the people who aren't
                        worried about their trade secrets being sent in plaintext through hotmail
                        to some one who has not signed an NDA. This is why your class that
                        does all the magic should be abstracted away from the actual code that's
                        notified of the exception.

                        > Or else it doesn't know where the setLogger() method is...
                        > I think that
                        > Catch2mail.off()
                        > Catch2mail.on()
                        > is simpler!! However, you are right that it is not flexible at all...

                        Right, well nix my setLogger(null) idea, but still use the on() off()
                        thing. That way I can keep my one LoggerIF their, but temporarily turn it
                        on/off.

                        > There's another aspect of this catch2mail idea that I haven't
                        > mentioned. I want to make it so that it can plug into *any* GPL
                        > project, with minimum hassle. In fact, the present implementation
                        > can do that... you only need switch it on, and all Exceptions are
                        > mailed.

                        How do you get all exceptions? Is there some hook into the VM?

                        *Major Point* It should be configurable to only mail for a certain thread,
                        because an application could have 20 threads going, 19 of which may be
                        spewing exceptions that have nothing to do with JSX. If that sounds far
                        fetched, check out how to poll for data on a socket. There are two ways:
                        see if the stream is ready() /* only some streams support this */ and the
                        other way is to set the read timeout, which is implemented as an
                        exception. That means a thread doing socket IO may be making an exception
                        every few hundred millis. I'm sure there are more examples.

                        > Also, you need to write the "setLogger()" method, as well as create
                        > the field (of type LoggerIF)... that's more work for the developer,
                        > who is plugging "catch2mail" into his/her project.

                        Right but it would be your class with the setLogger() method, not the end
                        developers' methods.

                        > An on/off API is also important, to determine *which* exceptions
                        > emailed... using JSX as an example, I only want to email the
                        > exceptions coming from JSX, and not any others from the user's
                        > own application code!! So, what we do is: switch on() notification
                        > when we enter the serialization or deserialization code, and switch
                        > it off() when we leave.

                        Remember, it should be thread friendly.


                        Mark
                      • Mark Collette
                        Remember what happens every time some people find out that an application is sending their personal data over the net by default, without asking? They freak
                        Message 11 of 23 , May 3, 2001
                        • 0 Attachment
                          Remember what happens every time some people find out that an application
                          is sending their personal data over the net by default, without asking?
                          They freak out. To you and me it's a stacktrace, but to them... who knows?

                          Mark


                          On Fri, 4 May 2001 bren@... wrote:

                          >
                          > > > Yes... but how would the configuration be done? I really want a
                          > > > no-brainer solution - I was thinking of having two versions
                          > > > available for download, one with it, the other without it... so
                          > > > that the user "configures" it, by choosing! How's that?
                          > > >
                          > > > Also, a simply API to switch it off. This would be in static
                          > > > fields, in the class that handles it. Something like:
                          > > > Catch2mail.off()
                          > > > Catch2mail.on()
                          > >
                          > > I would prefer a static api, but then again less code for a shipping
                          > > application (seperate versions) may be better.
                          >
                          > The code factor is probably insignificant (less than 1 k); and so
                          > the static API could be included in both.
                          > The only real difference between the versions would be the
                          > default setting.
                          >
                          > Actually, having thought about it more, their needs to be two
                          > levels of on/off setting:
                          > (1). to turn the entire email report thing on or off
                          > (2). to turn it on/off temporarily, depending on which section of
                          > code you are in (because I'm only interested in JSX exceptions, not
                          > all of the application exceptions...)
                          >
                          > It also seems that in practice there would be yet another "setting"
                          > - of whether it is on or off by default. I think it is important
                          > to have it "on" by defualt, because the whole idea is to get as many
                          > bug reports as possible! Also, it is then maximum no-brainer
                          > solution. If a particular user wants to switch it off, they can do
                          > so with the API... I could also offer a version with it switched off
                          > by default - and see which one people prefer... that's good market
                          > survery information.
                          >
                          >
                          > Cheers,
                          > Brendan
                          > PS: could you make a guess about how much a reasonable fee would be
                          > to use JSX in commercial applications (that aren't GPL)? Just to
                          > give me some kind of an idea. ;-)
                          >
                          >
                          > To unsubscribe from this group, send an email to:
                          > JSX-ideas-unsubscribe@egroups.com
                          >
                          >
                          >
                          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                          >
                        • Brendan Macmillan
                          ... OK, you are talking about maximum configurability. People would like that. ... Well, the trick is that you don t actually get the exceptions... just
                          Message 12 of 23 , May 4, 2001
                          • 0 Attachment
                            > Right, well nix my setLogger(null) idea, but still use the on() off()
                            > thing. That way I can keep my one LoggerIF their, but temporarily turn it
                            > on/off.
                            OK, you are talking about maximum configurability. People would like that.


                            > > There's another aspect of this catch2mail idea that I haven't
                            > > mentioned. I want to make it so that it can plug into *any* GPL
                            > > project, with minimum hassle. In fact, the present implementation
                            > > can do that... you only need switch it on, and all Exceptions are
                            > > mailed.
                            >
                            > How do you get all exceptions? Is there some hook into the VM?
                            Well, the trick is that you don't actually get the exceptions... just collect
                            whatever is printed to System.err...

                            Thanks a lot for the thread reminder! I had totally forgotten about that...
                            System.err will collect output from all threads, so dealing with this will
                            not be pretty. I think it would still work reasonably well, most of the
                            time... ;-)


                            > *Major Point* It should be configurable to only mail for a certain thread,
                            > because an application could have 20 threads going, 19 of which may be
                            > spewing exceptions that have nothing to do with JSX. If that sounds far
                            > fetched, check out how to poll for data on a socket. There are two ways:
                            > see if the stream is ready() /* only some streams support this */ and the
                            > other way is to set the read timeout, which is implemented as an
                            > exception. That means a thread doing socket IO may be making an exception
                            > every few hundred millis. I'm sure there are more examples.
                            >
                            > > Also, you need to write the "setLogger()" method, as well as create
                            > > the field (of type LoggerIF)... that's more work for the developer,
                            > > who is plugging "catch2mail" into his/her project.
                            >
                            > Right but it would be your class with the setLogger() method, not the end
                            > developers' methods.
                            OK... think I am slowly getting your perspective! ;-)


                            > Remember, it should be thread friendly.
                            Yes, very good point; but I think very hard to do. Maybe there are some
                            more hooks that I don't know about yet...


                            Cheers,
                            Brendan
                          • bren@mail.csse.monash.edu.au
                            Hi Mark, ... application ... asking? ... knows? Yes, that s what I m thinking... my office mate (Greg) had a really cool idea - either have a GUI pop-up the
                            Message 13 of 23 , May 4, 2001
                            • 0 Attachment
                              Hi Mark,


                              --- In JSX-ideas@y..., Mark Collette <mark@h...> wrote:
                              >
                              > Remember what happens every time some people find out that an
                              application
                              > is sending their personal data over the net by default, without
                              asking?
                              > They freak out. To you and me it's a stacktrace, but to them... who
                              knows?

                              Yes, that's what I'm thinking... my office mate (Greg) had a
                              really cool idea - either have a GUI pop-up the first time they
                              run JSX, asking for permission; or tell them about it when they
                              download, giving them the option of having it switched on or off
                              by default. And then (this is the best part), have it print out
                              a warning that it will email stack-traces, and that they can get
                              the other version from the web-site if they don't want that...

                              Hmmm... I'd only thought of this in specific connection to JSX...
                              but for a general email notification system, the GUI would probably
                              be better... I just don't like it storing config information
                              locally (not sure why I don't like it).


                              Cheers,
                              Brendan
                            • Mark Collette
                              ... Here s an idea I just had to do it on a thread by thread basis, every thread has to turn on() itself. If it never calls on, then your System.err s
                              Message 14 of 23 , May 4, 2001
                              • 0 Attachment
                                > > Remember, it should be thread friendly.
                                > Yes, very good point; but I think very hard to do. Maybe there are some
                                > more hooks that I don't know about yet...
                                >
                                >
                                > Cheers,
                                > Brendan

                                Here's an idea I just had to do it on a thread by thread basis, every
                                thread has to turn on() itself. If it never calls on, then your System.err
                                's println() method will not log it. Oh yeah, and maybe weak references,
                                or something like that should be used, so the logger doesn't keep the
                                thread that don't call off() from being garbage collected.

                                class Something {
                                Vector m_vThreads;
                                ...
                                void on() {
                                Thread t = Thread.currentThread();
                                if( !m_vThreads.contains(t) ) m_vThreads.addElement(t);
                                // Now do rest of on()
                                }
                                void off() {
                                Thread t = Thread.currentThread();
                                m_vThreads.removeElement( t );
                                // Now do rest of off
                                }
                                }


                                Mark
                              • Mark Collette
                                That sounds like a good way to do it. If it s so small, you may want to just pack all of the code into the jar, so they don t have to download it again. Mark
                                Message 15 of 23 , May 4, 2001
                                • 0 Attachment
                                  That sounds like a good way to do it. If it's so small, you may want to
                                  just pack all of the code into the jar, so they don't have to download it
                                  again.

                                  Mark


                                  On Fri, 4 May 2001 bren@... wrote:

                                  > Hi Mark,
                                  >
                                  >
                                  > --- In JSX-ideas@y..., Mark Collette <mark@h...> wrote:
                                  > >
                                  > > Remember what happens every time some people find out that an
                                  > application
                                  > > is sending their personal data over the net by default, without
                                  > asking?
                                  > > They freak out. To you and me it's a stacktrace, but to them... who
                                  > knows?
                                  >
                                  > Yes, that's what I'm thinking... my office mate (Greg) had a
                                  > really cool idea - either have a GUI pop-up the first time they
                                  > run JSX, asking for permission; or tell them about it when they
                                  > download, giving them the option of having it switched on or off
                                  > by default. And then (this is the best part), have it print out
                                  > a warning that it will email stack-traces, and that they can get
                                  > the other version from the web-site if they don't want that...
                                  >
                                  > Hmmm... I'd only thought of this in specific connection to JSX...
                                  > but for a general email notification system, the GUI would probably
                                  > be better... I just don't like it storing config information
                                  > locally (not sure why I don't like it).
                                  >
                                  >
                                  > Cheers,
                                  > Brendan
                                  >
                                  >
                                  > To unsubscribe from this group, send an email to:
                                  > JSX-ideas-unsubscribe@egroups.com
                                  >
                                  >
                                  >
                                  > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                  >
                                • Brendan Macmillan
                                  ... Cool - yes, I didn t mention how small it was at first. Yeah - I meant that they download different versions of JSX - one with the contained package on,
                                  Message 16 of 23 , May 4, 2001
                                  • 0 Attachment
                                    > That sounds like a good way to do it. If it's so small, you may want to
                                    > just pack all of the code into the jar, so they don't have to download it
                                    > again.
                                    Cool - yes, I didn't mention how small it was at first.

                                    Yeah - I meant that they download different versions of JSX - one with the
                                    contained package on, and one with it off.

                                    I had a cooler idea: a web-service for email notification, using JSX for the
                                    object encoding scheme.

                                    This means that I don't need to design a protocol! Just make a class with
                                    the information (sender, recevier addresses, project, and message), and let
                                    JSX derive the protocol from this...

                                    To me, this seems *so* much easier than using SOAP for web-services, that it
                                    might really take off. I'd better go do it soon. ;-)


                                    Cheers,
                                    Brendan

                                    >
                                    > Mark
                                    >
                                    >
                                    > On Fri, 4 May 2001 bren@... wrote:
                                    >
                                    > > Hi Mark,
                                    > >
                                    > >
                                    > > --- In JSX-ideas@y..., Mark Collette <mark@h...> wrote:
                                    > > >
                                    > > > Remember what happens every time some people find out that an
                                    > > application
                                    > > > is sending their personal data over the net by default, without
                                    > > asking?
                                    > > > They freak out. To you and me it's a stacktrace, but to them... who
                                    > > knows?
                                    > >
                                    > > Yes, that's what I'm thinking... my office mate (Greg) had a
                                    > > really cool idea - either have a GUI pop-up the first time they
                                    > > run JSX, asking for permission; or tell them about it when they
                                    > > download, giving them the option of having it switched on or off
                                    > > by default. And then (this is the best part), have it print out
                                    > > a warning that it will email stack-traces, and that they can get
                                    > > the other version from the web-site if they don't want that...
                                    > >
                                    > > Hmmm... I'd only thought of this in specific connection to JSX...
                                    > > but for a general email notification system, the GUI would probably
                                    > > be better... I just don't like it storing config information
                                    > > locally (not sure why I don't like it).
                                    > >
                                    > >
                                    > > Cheers,
                                    > > Brendan
                                    > >
                                    > >
                                    > > To unsubscribe from this group, send an email to:
                                    > > JSX-ideas-unsubscribe@egroups.com
                                    > >
                                    > >
                                    > >
                                    > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                    > >
                                    >
                                    >
                                    > To unsubscribe from this group, send an email to:
                                    > JSX-ideas-unsubscribe@egroups.com
                                    >
                                    >
                                    >
                                    > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                    >
                                    >
                                    >
                                  • Brendan Macmillan
                                    Mark! You are totally awesome, dude! I thought there was something that I didn t get about your idea... you mean that we actually plug in the logger class
                                    Message 17 of 23 , May 4, 2001
                                    • 0 Attachment
                                      Mark!

                                      You are totally awesome, dude!

                                      I thought there was something that I didn't get about your idea... you mean
                                      that we actually plug in the "logger" class directly *into* System.err...
                                      then, we can check what thread we are, when we run, and decide what to do
                                      with it.

                                      My scratch code was just writing this to a file, and then sending it later.
                                      My colleague (Paul) has eliminated the file (haven't seen his code yet), but
                                      your concept of just plugging it *directly* in, is obvious a much neater
                                      architecture, and the correct way to do it. The ability to detect threads is
                                      just a natural consequence flowing from its correctness - I feel sure there
                                      will be others.

                                      A question: Can we subclass the reference type required for System.err? Yes,
                                      it is not final.

                                      As I said Mark, you are a totally awesome dude to come up with this totally
                                      awesome perspective - so much better than what we had been thinking, that I
                                      didn't actually see what you meant! (tho I did sense something was not 100%
                                      clear to me).

                                      It is this kind of collaboration that makes open-source rock so well. ;-)


                                      Cheers,
                                      Brendan
                                      PS: I gotta get this out really soon. This is so hot.

                                      > > > Remember, it should be thread friendly.
                                      > > Yes, very good point; but I think very hard to do. Maybe there are some
                                      > > more hooks that I don't know about yet...
                                      > >
                                      > >
                                      > > Cheers,
                                      > > Brendan
                                      >
                                      > Here's an idea I just had to do it on a thread by thread basis, every
                                      > thread has to turn on() itself. If it never calls on, then your System.err
                                      > 's println() method will not log it. Oh yeah, and maybe weak references,
                                      > or something like that should be used, so the logger doesn't keep the
                                      > thread that don't call off() from being garbage collected.
                                      >
                                      > class Something {
                                      > Vector m_vThreads;
                                      > ...
                                      > void on() {
                                      > Thread t = Thread.currentThread();
                                      > if( !m_vThreads.contains(t) ) m_vThreads.addElement(t);
                                      > // Now do rest of on()
                                      > }
                                      > void off() {
                                      > Thread t = Thread.currentThread();
                                      > m_vThreads.removeElement( t );
                                      > // Now do rest of off
                                      > }
                                      > }
                                      >
                                      >
                                      > Mark
                                      >
                                      >
                                      >
                                      > To unsubscribe from this group, send an email to:
                                      > JSX-ideas-unsubscribe@egroups.com
                                      >
                                      >
                                      >
                                      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                      >
                                      >
                                      >
                                    • Brandon K. Wiley
                                      ... If you re talking about changing the value of System.err to something else (System.err=new PrintWriter(out)), this is clever, but impossible after JDK1.2.
                                      Message 18 of 23 , May 5, 2001
                                      • 0 Attachment
                                        > I thought there was something that I didn't get about your idea... you mean
                                        > that we actually plug in the "logger" class directly *into* System.err...
                                        > then, we can check what thread we are, when we run, and decide what to do
                                        > with it.

                                        If you're talking about changing the value of System.err to something else
                                        (System.err=new PrintWriter(out)), this is clever, but impossible after
                                        JDK1.2. There was a security concern because System.err is static in some
                                        browsers an applet could modify its value and the next applet to run would
                                        have the same value for System.err (because they run in the same virtual
                                        machine). So Sun did an ugly hack and made System.err "read-only" via some
                                        kind of voodoo.

                                        This is really sad because I often find that I want to give different
                                        threads different output streams and I don't want to have to modify the
                                        classes which are already printing on System.out. Oh well.
                                      • Brendan Macmillan
                                        Hi Brandon, ... Um, I was already plugging in another class into System.err, to log to a file, and this is working in JDK 1.4... perhaps the read-only hack is
                                        Message 19 of 23 , May 5, 2001
                                        • 0 Attachment
                                          Hi Brandon,

                                          > > I thought there was something that I didn't get about your idea... you mean
                                          > > that we actually plug in the "logger" class directly *into* System.err...
                                          > > then, we can check what thread we are, when we run, and decide what to do
                                          > > with it.

                                          > If you're talking about changing the value of System.err to something else
                                          > (System.err=new PrintWriter(out)), this is clever, but impossible after
                                          > JDK1.2. There was a security concern because System.err is static in some
                                          > browsers an applet could modify its value and the next applet to run would
                                          > have the same value for System.err (because they run in the same virtual
                                          > machine). So Sun did an ugly hack and made System.err "read-only" via some
                                          > kind of voodoo.

                                          Um, I was already plugging in another class into System.err, to log to a file,
                                          and this is working in JDK 1.4... perhaps the read-only hack is for applets
                                          only?

                                          > This is really sad because I often find that I want to give different
                                          > threads different output streams and I don't want to have to modify the
                                          > classes which are already printing on System.out. Oh well.

                                          So, Mark's thread voodoo would be very handy there, too. You plug our
                                          "stream dispatch" class into System.out, after configuring it to send
                                          output from different threads to different streams (some to stdout, some logged
                                          to a file, some ignored, some sent over a socket...).

                                          I think it works. ;-)


                                          Cheers,
                                          Brendan
                                          PS: Hey Brandon, did you get my reply to your thesis? Also, can I use your
                                          kind words about JSX on the homepage (attributed to yourself: freeNet
                                          co-founder, O'Reilly author, distributed system researcher, playwright).
                                        • Brandon K. Wiley
                                          ... Wow, if this hack works again then my life suddenly got a lot better.
                                          Message 20 of 23 , May 5, 2001
                                          • 0 Attachment
                                            > Um, I was already plugging in another class into System.err, to log to a file,
                                            > and this is working in JDK 1.4... perhaps the read-only hack is for applets
                                            > only?

                                            Wow, if this hack works again then my life suddenly got a lot better.
                                          • Brendan Macmillan
                                            ... Hi Erwin, Um, you haven t followed up with the extra information I asked for... just now, I tried out your code. However, your deserialization code
                                            Message 21 of 23 , May 5, 2001
                                            • 0 Attachment
                                              > I try to use JSX to serialize a Java class to xml and then to read it again.
                                              > Deserialization does not have the intended result. What am I doing wrong.


                                              Hi Erwin,

                                              Um, you haven't followed up with the extra information I asked
                                              for... just now, I tried out your code. However, your
                                              deserialization code relies on a "Wombat" class, which you
                                              didn't include.

                                              Not sure why the Otto class is there... maybe you meant to
                                              include Wombat, but put Otto by accident?

                                              BTW: For testing, it's usually easier to not cast to
                                              a particular class, and instead test it by just serializing the object again.
                                              That way, you can see if it is the same as what
                                              you thought in the first place. Of course, the best test is
                                              to configure the object before sending, and then try to use
                                              it after it has been received. (if you leave it as the
                                              default values, then there is no evidence that the serialization
                                              worked.)... You can also play around with the XML values, by
                                              editing them directly.

                                              Your serialization code seems to work fine - it is a nice idea
                                              to take class names in from the command line, and then
                                              automatically create an xml file named after them... one
                                              suprising thing about doing it this way, is that your
                                              code expects the object to a no-arg constructor... and this
                                              is not always the case.

                                              Hope to hear from you soon!


                                              Cheers,
                                              Brendan
                                            • Brendan Macmillan
                                              OK! I now have an example web-service, using JSX. It is: connectionless multi-threaded XML-encoded It just enables you to send email from a java program,
                                              Message 22 of 23 , May 5, 2001
                                              • 0 Attachment
                                                OK! I now have an example web-service, using JSX. It is:
                                                connectionless
                                                multi-threaded
                                                XML-encoded

                                                It just enables you to send email from a java program, without
                                                configuring the mailhost. This is the bare-bones protocol
                                                it uses at the moment (just an example)
                                                <Email
                                                to="JSX-ideas@yahoogroups.com"
                                                message="Hi everyone!
                                                This thing is working now - give it a go, by checking out the
                                                attached client and data objects"/>

                                                The really nice thing is that JSX creates your protocol for
                                                you, from your class. And it then automates the encoding
                                                and parsing of it.

                                                The server took me an hour to write (just sat down after I
                                                got home from going out... pretty easy). And now that the
                                                infrastructure/container is done, another web-service would
                                                be even quicker to write.

                                                I'm going to leave this web-service running at the given
                                                address, but will probably soon move it to a different
                                                address - I will post the new address here, when it happens.

                                                Please, I'd appreciate lots of feedback on this! I think it is
                                                a potential killer application, to be able to make web-services
                                                so easily.


                                                Cheers,
                                                Brendan
                                              • paul_sijpkes@yahoo.com
                                                Yes, Brendan, I finally subscribed! I tested your web service, its very fast and seems to be stable. I had a couple of ideas for the exception mailer. I don t
                                                Message 23 of 23 , May 6, 2001
                                                • 0 Attachment
                                                  Yes, Brendan, I finally subscribed!

                                                  I tested your web service, its very fast and seems to be stable.

                                                  I had a couple of ideas for the exception mailer. I don't know if
                                                  anyone else has raised these as I haven't had time to read the full
                                                  history of discussion on this topic.

                                                  The first idea was, on top of having the warning print out to the
                                                  screen before sending, give the user a further option for a window to
                                                  pop-up asking them which actions lead to the exception.

                                                  That is, you could have a "covert" option that the user could select,
                                                  this would mail the exception without the user knowing (except for
                                                  the first time). Plus, an "overt" option that gave the user a pop-up
                                                  every time an exception was thrown.

                                                  Another idea was to account for when the user was not
                                                  connected to the internet. This is very important, particularly for
                                                  stand alone applications that require no constant internet
                                                  connection. This would require logging the exception to a file and
                                                  then asking the user if they would like to send it the next time they
                                                  either a. ran the program or b. connected to the internet. A. would
                                                  be easy to implement, b. would mean the app would need to monitor the
                                                  OS constantly.

                                                  Anyone got any more ideas?

                                                  cheers,
                                                  Paul.
                                                Your message has been successfully submitted and would be delivered to recipients shortly.