TUSCANY-2277 & validation messages

[Simon Laws <si...@googlemail.com>]

I've just checked in Ram's patch to convert validation messages (i.e. those
messages indicating that the user have provided invalid input of some form)
to resource bundles and pass them through the Monitor. We need to take
account of this change as we change or add code to do with validation.
Primarily the change;

- Pushes down a Monitor object to various parts of code that produce
validation type messages.
- Creates a problem object to hold any reported warning or error (sometimes
there a convenience error() or warning() operation has been added if there
are a lot of messages in a file)
-- Each problem is identified by an id string
-- The id string references into a resource bundle where the full message
has been moved to. There is now a resource bundle in each module that raises
validation messages
- Passes the Problem on to the Monitor object

Our default Monitor object simply passes the message to the JDK logger at
the moment but you could imagine a Monitor that collects them all together
for later analysis. Currently the majority of the exceptions that are thrown
during validation are still there so I guess we need to go through taking
out the ones that are not now absolutely necessary. The next job!

With this done we have catalogs of all of the errors/warnings that a user is
likely to come across (and examples of why the occur in the validation
itests) which should help our documentation somewhat.

Big thanks to Ram



Simon

Re: TUSCANY-2277 & validation messages

[Ramkumar R <ra...@gmail.com>]

Hi Simon,
 After introducing the monitors in various part of the code. Now I am trying
to remove the exception that are being thrown from these modules. As a first
step we are removing the exceptions that are safe to remove, by leaving the
critical exceptions like
a) IOException
b) XMLStreamException
c) PriviledegedActionException
d) and ParseConfigurationExceptions

For the above said exceptions, we need some discussion as how to handle
them.

I have now raised TUSCANY-2347 to address this issue by leaving the above
exceptions to still throw.


On 5/26/08, Ramkumar R <ra...@gmail.com> wrote:
>
> Hi Simon,
> The issue noticed in the CustomDomainBuilder and the test failures occuring
> from impl.java.ContributionResolveExceptionTestCase are now fixed. I have
> added the fix as a patch to TUSCANY-2338.
>
> The test failure noticed in
> impl.spring.UnableToResolveComponentTypeTestCase seems to be little
> complicated, initially though i thought it would be because of
> CustomDomainBuilder issue. I have posted the issue that i noticed in
> SpringImplementationProcess, requesting some help for the same.
>
>
>  On 5/24/08, Ramkumar R <ra...@gmail.com> wrote:
>>
>> Hi Simon,
>> I like to apologize for the inconvenience caused due to the huge patch
>> file for TUSCANY-2329 and for the .pom missed out in the patch.
>>
>> The remaining itests for the validation messages are now available with
>> TUSCANY-2338 along with the fix required for the test failure in
>> interfacejava.xml.ContributionResolveExceptionTestCase.
>>
>> As you mentioned the test failures for
>> impl.spring.UnableToResolveComponentTypeTestCase
>> impl.java.ContributionResolveExceptionTestCase
>>
>> are basically seen due to the issue seen in CustomDomainBuilder failing to
>> add JavaClassVisitors in the runtime. I am doing an investigation on the
>> same to provide a fix.
>>
>>
>> On 5/21/08, Simon Laws <si...@googlemail.com> wrote:
>>>
>>> On Wed, May 21, 2008 at 10:06 AM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>
>>> >
>>> >
>>> > On Tue, May 20, 2008 at 11:19 AM, Ramkumar R <ra...@gmail.com>
>>> > wrote:
>>> >
>>> >> Thanks Simon, itests for these validation messages are now available
>>> with
>>> >> TUSCANY-2329.
>>> >>
>>> >> On 5/19/08, Simon Laws <si...@googlemail.com> wrote:
>>> >> >
>>> >> > I've just checked in Ram's patch to convert validation messages
>>> (i.e.
>>> >> those
>>> >> > messages indicating that the user have provided invalid input of
>>> some
>>> >> form)
>>> >> > to resource bundles and pass them through the Monitor. We need to
>>> take
>>> >> > account of this change as we change or add code to do with
>>> validation.
>>> >> > Primarily the change;
>>> >> >
>>> >> > - Pushes down a Monitor object to various parts of code that produce
>>> >> > validation type messages.
>>> >> > - Creates a problem object to hold any reported warning or error
>>> >> (sometimes
>>> >> > there a convenience error() or warning() operation has been added if
>>> >> there
>>> >> > are a lot of messages in a file)
>>> >> > -- Each problem is identified by an id string
>>> >> > -- The id string references into a resource bundle where the full
>>> >> message
>>> >> > has been moved to. There is now a resource bundle in each module
>>> that
>>> >> > raises
>>> >> > validation messages
>>> >> > - Passes the Problem on to the Monitor object
>>> >> >
>>> >> > Our default Monitor object simply passes the message to the JDK
>>> logger
>>> >> at
>>> >> > the moment but you could imagine a Monitor that collects them all
>>> >> together
>>> >> > for later analysis. Currently the majority of the exceptions that
>>> are
>>> >> > thrown
>>> >> > during validation are still there so I guess we need to go through
>>> >> taking
>>> >> > out the ones that are not now absolutely necessary. The next job!
>>> >> >
>>> >> > With this done we have catalogs of all of the errors/warnings that a
>>> >> user
>>> >> > is
>>> >> > likely to come across (and examples of why the occur in the
>>> validation
>>> >> > itests) which should help our documentation somewhat.
>>> >> >
>>> >> > Big thanks to Ram
>>> >> >
>>> >> >
>>> >> >
>>> >> > Simon
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Thanks & Regards,
>>> >> Ramkumar Ramalingam
>>> >>
>>> > Hi Ram
>>> >
>>> > Thanks for the patch. It was a big one. In the future it would be
>>> easier to
>>> > have smaller committable chunks so we can review as you go;-)
>>> >
>>> > I had to fix up the pom file to make it work so maybe that got missed
>>> out
>>> > of the patch. Also, you seem to have you tab key configured to include
>>> tabs.
>>> > In your IDE could you change it to include four spaces instead?
>>> >
>>> > I'm going to check these changes in. Now we need to sort out what to do
>>> > about all of the exceptions that get thrown. I'll remove the validation
>>> > itests from the build temporarily while we do that.
>>> >
>>> > Regards
>>> >
>>> > Simon
>>> >
>>>
>>> Ok, the tests are checked in now but I had a few problems with some of
>>> the
>>> tests. I just commented out the assets for the time being.
>>>
>>> impl.spring.UnableToResolveComponentTypeTestCase
>>> impl.java.ContributionResolveExceptionTestCase
>>> interfacejava.xml.ContributionResolveExceptionTestCase
>>>
>>> Also it seems that some of the message conversion till needs to be done,
>>> for
>>> example,
>>>
>>> Seems that some of the underlying exceptions/log statements still need
>>> converting
>>> JavaIntrospectionHelper
>>> JavaInterfaceIntrospectorImpl
>>> etc.
>>>
>>> Maybe you fixed these but didn't make a patch?
>>>
>>> Thanks
>>>
>>> Simon
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam




-- 
Thanks & Regards,
Ramkumar Ramalingam

Re: TUSCANY-2277 & validation messages

[Ramkumar R <ra...@gmail.com>]

Hi Simon,
The issue noticed in the CustomDomainBuilder and the test failures occuring
from impl.java.ContributionResolveExceptionTestCase are now fixed. I have
added the fix as a patch to TUSCANY-2338.

The test failure noticed in impl.spring.UnableToResolveComponentTypeTestCase
seems to be little complicated, initially though i thought it would be
because of CustomDomainBuilder issue. I have posted the issue that i noticed
in SpringImplementationProcess, requesting some help for the same.


On 5/24/08, Ramkumar R <ra...@gmail.com> wrote:
>
> Hi Simon,
> I like to apologize for the inconvenience caused due to the huge patch file
> for TUSCANY-2329 and for the .pom missed out in the patch.
>
> The remaining itests for the validation messages are now available with
> TUSCANY-2338 along with the fix required for the test failure in
> interfacejava.xml.ContributionResolveExceptionTestCase.
>
> As you mentioned the test failures for
> impl.spring.UnableToResolveComponentTypeTestCase
> impl.java.ContributionResolveExceptionTestCase
>
> are basically seen due to the issue seen in CustomDomainBuilder failing to
> add JavaClassVisitors in the runtime. I am doing an investigation on the
> same to provide a fix.
>
>
> On 5/21/08, Simon Laws <si...@googlemail.com> wrote:
>>
>> On Wed, May 21, 2008 at 10:06 AM, Simon Laws <si...@googlemail.com>
>> wrote:
>>
>> >
>> >
>> > On Tue, May 20, 2008 at 11:19 AM, Ramkumar R <ra...@gmail.com>
>> > wrote:
>> >
>> >> Thanks Simon, itests for these validation messages are now available
>> with
>> >> TUSCANY-2329.
>> >>
>> >> On 5/19/08, Simon Laws <si...@googlemail.com> wrote:
>> >> >
>> >> > I've just checked in Ram's patch to convert validation messages (i.e.
>> >> those
>> >> > messages indicating that the user have provided invalid input of some
>> >> form)
>> >> > to resource bundles and pass them through the Monitor. We need to
>> take
>> >> > account of this change as we change or add code to do with
>> validation.
>> >> > Primarily the change;
>> >> >
>> >> > - Pushes down a Monitor object to various parts of code that produce
>> >> > validation type messages.
>> >> > - Creates a problem object to hold any reported warning or error
>> >> (sometimes
>> >> > there a convenience error() or warning() operation has been added if
>> >> there
>> >> > are a lot of messages in a file)
>> >> > -- Each problem is identified by an id string
>> >> > -- The id string references into a resource bundle where the full
>> >> message
>> >> > has been moved to. There is now a resource bundle in each module that
>> >> > raises
>> >> > validation messages
>> >> > - Passes the Problem on to the Monitor object
>> >> >
>> >> > Our default Monitor object simply passes the message to the JDK
>> logger
>> >> at
>> >> > the moment but you could imagine a Monitor that collects them all
>> >> together
>> >> > for later analysis. Currently the majority of the exceptions that are
>> >> > thrown
>> >> > during validation are still there so I guess we need to go through
>> >> taking
>> >> > out the ones that are not now absolutely necessary. The next job!
>> >> >
>> >> > With this done we have catalogs of all of the errors/warnings that a
>> >> user
>> >> > is
>> >> > likely to come across (and examples of why the occur in the
>> validation
>> >> > itests) which should help our documentation somewhat.
>> >> >
>> >> > Big thanks to Ram
>> >> >
>> >> >
>> >> >
>> >> > Simon
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Thanks & Regards,
>> >> Ramkumar Ramalingam
>> >>
>> > Hi Ram
>> >
>> > Thanks for the patch. It was a big one. In the future it would be easier
>> to
>> > have smaller committable chunks so we can review as you go;-)
>> >
>> > I had to fix up the pom file to make it work so maybe that got missed
>> out
>> > of the patch. Also, you seem to have you tab key configured to include
>> tabs.
>> > In your IDE could you change it to include four spaces instead?
>> >
>> > I'm going to check these changes in. Now we need to sort out what to do
>> > about all of the exceptions that get thrown. I'll remove the validation
>> > itests from the build temporarily while we do that.
>> >
>> > Regards
>> >
>> > Simon
>> >
>>
>> Ok, the tests are checked in now but I had a few problems with some of the
>> tests. I just commented out the assets for the time being.
>>
>> impl.spring.UnableToResolveComponentTypeTestCase
>> impl.java.ContributionResolveExceptionTestCase
>> interfacejava.xml.ContributionResolveExceptionTestCase
>>
>> Also it seems that some of the message conversion till needs to be done,
>> for
>> example,
>>
>> Seems that some of the underlying exceptions/log statements still need
>> converting
>> JavaIntrospectionHelper
>> JavaInterfaceIntrospectorImpl
>> etc.
>>
>> Maybe you fixed these but didn't make a patch?
>>
>> Thanks
>>
>> Simon
>>
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam




-- 
Thanks & Regards,
Ramkumar Ramalingam

Re: TUSCANY-2277 & validation messages

[Ramkumar R <ra...@gmail.com>]

Hi Simon,
I like to apologize for the inconvenience caused due to the huge patch file
for TUSCANY-2329 and for the .pom missed out in the patch.

The remaining itests for the validation messages are now available with
TUSCANY-2338 along with the fix required for the test failure in
interfacejava.xml.ContributionResolveExceptionTestCase.

As you mentioned the test failures for
impl.spring.UnableToResolveComponentTypeTestCase
impl.java.ContributionResolveExceptionTestCase

are basically seen due to the issue seen in CustomDomainBuilder failing to
add JavaClassVisitors in the runtime. I am doing an investigation on the
same to provide a fix.


On 5/21/08, Simon Laws <si...@googlemail.com> wrote:
>
> On Wed, May 21, 2008 at 10:06 AM, Simon Laws <si...@googlemail.com>
> wrote:
>
> >
> >
> > On Tue, May 20, 2008 at 11:19 AM, Ramkumar R <ra...@gmail.com>
> > wrote:
> >
> >> Thanks Simon, itests for these validation messages are now available
> with
> >> TUSCANY-2329.
> >>
> >> On 5/19/08, Simon Laws <si...@googlemail.com> wrote:
> >> >
> >> > I've just checked in Ram's patch to convert validation messages (i.e.
> >> those
> >> > messages indicating that the user have provided invalid input of some
> >> form)
> >> > to resource bundles and pass them through the Monitor. We need to take
> >> > account of this change as we change or add code to do with validation.
> >> > Primarily the change;
> >> >
> >> > - Pushes down a Monitor object to various parts of code that produce
> >> > validation type messages.
> >> > - Creates a problem object to hold any reported warning or error
> >> (sometimes
> >> > there a convenience error() or warning() operation has been added if
> >> there
> >> > are a lot of messages in a file)
> >> > -- Each problem is identified by an id string
> >> > -- The id string references into a resource bundle where the full
> >> message
> >> > has been moved to. There is now a resource bundle in each module that
> >> > raises
> >> > validation messages
> >> > - Passes the Problem on to the Monitor object
> >> >
> >> > Our default Monitor object simply passes the message to the JDK logger
> >> at
> >> > the moment but you could imagine a Monitor that collects them all
> >> together
> >> > for later analysis. Currently the majority of the exceptions that are
> >> > thrown
> >> > during validation are still there so I guess we need to go through
> >> taking
> >> > out the ones that are not now absolutely necessary. The next job!
> >> >
> >> > With this done we have catalogs of all of the errors/warnings that a
> >> user
> >> > is
> >> > likely to come across (and examples of why the occur in the validation
> >> > itests) which should help our documentation somewhat.
> >> >
> >> > Big thanks to Ram
> >> >
> >> >
> >> >
> >> > Simon
> >> >
> >>
> >>
> >>
> >> --
> >> Thanks & Regards,
> >> Ramkumar Ramalingam
> >>
> > Hi Ram
> >
> > Thanks for the patch. It was a big one. In the future it would be easier
> to
> > have smaller committable chunks so we can review as you go;-)
> >
> > I had to fix up the pom file to make it work so maybe that got missed out
> > of the patch. Also, you seem to have you tab key configured to include
> tabs.
> > In your IDE could you change it to include four spaces instead?
> >
> > I'm going to check these changes in. Now we need to sort out what to do
> > about all of the exceptions that get thrown. I'll remove the validation
> > itests from the build temporarily while we do that.
> >
> > Regards
> >
> > Simon
> >
>
> Ok, the tests are checked in now but I had a few problems with some of the
> tests. I just commented out the assets for the time being.
>
> impl.spring.UnableToResolveComponentTypeTestCase
> impl.java.ContributionResolveExceptionTestCase
> interfacejava.xml.ContributionResolveExceptionTestCase
>
> Also it seems that some of the message conversion till needs to be done,
> for
> example,
>
> Seems that some of the underlying exceptions/log statements still need
> converting
> JavaIntrospectionHelper
> JavaInterfaceIntrospectorImpl
> etc.
>
> Maybe you fixed these but didn't make a patch?
>
> Thanks
>
> Simon
>



-- 
Thanks & Regards,
Ramkumar Ramalingam

Re: TUSCANY-2277 & validation messages

[Simon Laws <si...@googlemail.com>]

On Wed, May 21, 2008 at 10:06 AM, Simon Laws <si...@googlemail.com>
wrote:

>
>
> On Tue, May 20, 2008 at 11:19 AM, Ramkumar R <ra...@gmail.com>
> wrote:
>
>> Thanks Simon, itests for these validation messages are now available with
>> TUSCANY-2329.
>>
>> On 5/19/08, Simon Laws <si...@googlemail.com> wrote:
>> >
>> > I've just checked in Ram's patch to convert validation messages (i.e.
>> those
>> > messages indicating that the user have provided invalid input of some
>> form)
>> > to resource bundles and pass them through the Monitor. We need to take
>> > account of this change as we change or add code to do with validation.
>> > Primarily the change;
>> >
>> > - Pushes down a Monitor object to various parts of code that produce
>> > validation type messages.
>> > - Creates a problem object to hold any reported warning or error
>> (sometimes
>> > there a convenience error() or warning() operation has been added if
>> there
>> > are a lot of messages in a file)
>> > -- Each problem is identified by an id string
>> > -- The id string references into a resource bundle where the full
>> message
>> > has been moved to. There is now a resource bundle in each module that
>> > raises
>> > validation messages
>> > - Passes the Problem on to the Monitor object
>> >
>> > Our default Monitor object simply passes the message to the JDK logger
>> at
>> > the moment but you could imagine a Monitor that collects them all
>> together
>> > for later analysis. Currently the majority of the exceptions that are
>> > thrown
>> > during validation are still there so I guess we need to go through
>> taking
>> > out the ones that are not now absolutely necessary. The next job!
>> >
>> > With this done we have catalogs of all of the errors/warnings that a
>> user
>> > is
>> > likely to come across (and examples of why the occur in the validation
>> > itests) which should help our documentation somewhat.
>> >
>> > Big thanks to Ram
>> >
>> >
>> >
>> > Simon
>> >
>>
>>
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>>
> Hi Ram
>
> Thanks for the patch. It was a big one. In the future it would be easier to
> have smaller committable chunks so we can review as you go;-)
>
> I had to fix up the pom file to make it work so maybe that got missed out
> of the patch. Also, you seem to have you tab key configured to include tabs.
> In your IDE could you change it to include four spaces instead?
>
> I'm going to check these changes in. Now we need to sort out what to do
> about all of the exceptions that get thrown. I'll remove the validation
> itests from the build temporarily while we do that.
>
> Regards
>
> Simon
>

Ok, the tests are checked in now but I had a few problems with some of the
tests. I just commented out the assets for the time being.

impl.spring.UnableToResolveComponentTypeTestCase
impl.java.ContributionResolveExceptionTestCase
interfacejava.xml.ContributionResolveExceptionTestCase

Also it seems that some of the message conversion till needs to be done, for
example,

Seems that some of the underlying exceptions/log statements still need
converting
JavaIntrospectionHelper
JavaInterfaceIntrospectorImpl
etc.

Maybe you fixed these but didn't make a patch?

Thanks

Simon

Re: TUSCANY-2277 & validation messages

[Simon Laws <si...@googlemail.com>]

On Tue, May 20, 2008 at 11:19 AM, Ramkumar R <ra...@gmail.com> wrote:

> Thanks Simon, itests for these validation messages are now available with
> TUSCANY-2329.
>
> On 5/19/08, Simon Laws <si...@googlemail.com> wrote:
> >
> > I've just checked in Ram's patch to convert validation messages (i.e.
> those
> > messages indicating that the user have provided invalid input of some
> form)
> > to resource bundles and pass them through the Monitor. We need to take
> > account of this change as we change or add code to do with validation.
> > Primarily the change;
> >
> > - Pushes down a Monitor object to various parts of code that produce
> > validation type messages.
> > - Creates a problem object to hold any reported warning or error
> (sometimes
> > there a convenience error() or warning() operation has been added if
> there
> > are a lot of messages in a file)
> > -- Each problem is identified by an id string
> > -- The id string references into a resource bundle where the full message
> > has been moved to. There is now a resource bundle in each module that
> > raises
> > validation messages
> > - Passes the Problem on to the Monitor object
> >
> > Our default Monitor object simply passes the message to the JDK logger at
> > the moment but you could imagine a Monitor that collects them all
> together
> > for later analysis. Currently the majority of the exceptions that are
> > thrown
> > during validation are still there so I guess we need to go through taking
> > out the ones that are not now absolutely necessary. The next job!
> >
> > With this done we have catalogs of all of the errors/warnings that a user
> > is
> > likely to come across (and examples of why the occur in the validation
> > itests) which should help our documentation somewhat.
> >
> > Big thanks to Ram
> >
> >
> >
> > Simon
> >
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
Hi Ram

Thanks for the patch. It was a big one. In the future it would be easier to
have smaller committable chunks so we can review as you go;-)

I had to fix up the pom file to make it work so maybe that got missed out of
the patch. Also, you seem to have you tab key configured to include tabs. In
your IDE could you change it to include four spaces instead?

I'm going to check these changes in. Now we need to sort out what to do
about all of the exceptions that get thrown. I'll remove the validation
itests from the build temporarily while we do that.

Regards

Simon

Re: TUSCANY-2277 & validation messages

[Ramkumar R <ra...@gmail.com>]

Thanks Simon, itests for these validation messages are now available with
TUSCANY-2329.

On 5/19/08, Simon Laws <si...@googlemail.com> wrote:
>
> I've just checked in Ram's patch to convert validation messages (i.e. those
> messages indicating that the user have provided invalid input of some form)
> to resource bundles and pass them through the Monitor. We need to take
> account of this change as we change or add code to do with validation.
> Primarily the change;
>
> - Pushes down a Monitor object to various parts of code that produce
> validation type messages.
> - Creates a problem object to hold any reported warning or error (sometimes
> there a convenience error() or warning() operation has been added if there
> are a lot of messages in a file)
> -- Each problem is identified by an id string
> -- The id string references into a resource bundle where the full message
> has been moved to. There is now a resource bundle in each module that
> raises
> validation messages
> - Passes the Problem on to the Monitor object
>
> Our default Monitor object simply passes the message to the JDK logger at
> the moment but you could imagine a Monitor that collects them all together
> for later analysis. Currently the majority of the exceptions that are
> thrown
> during validation are still there so I guess we need to go through taking
> out the ones that are not now absolutely necessary. The next job!
>
> With this done we have catalogs of all of the errors/warnings that a user
> is
> likely to come across (and examples of why the occur in the validation
> itests) which should help our documentation somewhat.
>
> Big thanks to Ram
>
>
>
> Simon
>



-- 
Thanks & Regards,
Ramkumar Ramalingam