And if there is a bit more to the methods;
Composition Problems Report:
message: No implementation found for method
method: Map doAnotherThing(String name, int value)
types: [Person,ValueComposite]
--
message: No implementation found for method
method: void doOneThing()
types: [Person,ValueComposite]
--
I am sacrificing the generics information, as it becomes very verbose.
On Wed, Mar 29, 2017 at 6:54 PM, Niclas Hedhman <nic...@hedhman.org> wrote:
> Ok,I have gotten started on this.
>
> InvalidCompositeException is the main character involved, and there are
> two major kinks involved. One is that it is somewhat difficult to continue
> without weird exception following, and the other is how, when what is
> actually thrown.
>
> So, for that latter part, I am basically checking after model is created
> in Energy4Java to see if there was any problems (aggregated into
> InvalidCompositeException) and if so, throw an AssemblyException from
> there.
>
> For the former part, I think it is just a matter of getting these problems
> and refining the handling when it happens. Important is to inspect the
> InvalidCompositeException (modelReport()) when anything goes wrong. So, in
> Energy4Java I do that, and for any exception, create a
> AssemblyReportException with the attached modelReport() for any issue, so
> one can both trace the original problems and figure out what needs to be
> done to handle the broken model without further problems.
>
> I think it is rather important to make the report as readable as possible,
> so the report for two missing method implementations (my first testcase)
> would end up something like this.
>
> Composition Problems Report:
> message: No implementation found for method
> method: doAnotherThing()
> types: [Person,ValueComposite]
> --
> message: No implementation found for method
> method: doOneThing()
> types: [Person,ValueComposite]
> --
>
> I think short names provides better readability than the FQCN everywhere.
>
> I will try to clean this up and try to get it out in the next few hours,
> in case anyone would like to try it out.
>
> WDYT?
>
> On Sat, Mar 25, 2017 at 8:24 PM, Paul Merlin <paulmer...@apache.org>
> wrote:
>
>>
>> +1000 to more insight on assembly/bootstrap failures!
>>
>> Sounds related to:
>> - Improved reporting on invalid assembly models
>> https://issues.apache.org/jira/browse/POLYGENE-48
>> - Easily report full application assembly
>> https://issues.apache.org/jira/browse/POLYGENE-49
>>
>> POLYGENE-49 is about being able to serialize an application model.
>> But it doesn't address reporting on erroneous application models.
>>
>> About startup and laziness, yes, getting as most errors as soon as
>> possible would be a win.
>> It'd be interesting to measure the impact on startup time of removing
>> that laziness, it may be reasonable.
>>
>>
>>
>>
>>
>> Le 2017-03-25 04:54, Niclas Hedhman a écrit :
>>
>>> Looking at this at the moment, and there is an "interesting" tradeoff,
>>> that
>>> we should probably discuss.
>>>
>>> A fair bit of deferred work is going on, i.e. delaying the work until it
>>> is
>>> needed, in case it is not needed, which will improve start up time quite
>>> a
>>> lot.
>>>
>>> The down-side is that the structural problem is not showing up until any
>>> time later, possibly in production.
>>>
>>> I think we should remove this "lazy loading" of classes, and check
>>> everything possible at boot time.
>>>
>>> WDAYT?
>>>
>>> Niclas
>>>
>>> On Fri, Mar 24, 2017 at 5:30 PM, Niclas Hedhman <nic...@hedhman.org>
>>> wrote:
>>>
>>> Gang,
>>>> I was just thinking;
>>>>
>>>> We want it to become more efficient to find the runtime problems. One of
>>>> the major problems is that one gets an exception after exception the
>>>> first
>>>> time we try to get going with a new project or a new subsystem in an
>>>> existing project. And this start->exception->edit->compile cycle is
>>>> tedious and not fun.
>>>>
>>>> Suggestion;
>>>> 1. Introduce a "bootstrapPhase" somewhere.
>>>> 2. Enhance ConstructionException with exact details of everything going
>>>> on.
>>>> 3. Make the ConstructionException constructor private and introduce a
>>>> public static method to be called.
>>>> 4. If Application.mode() is development or test, and bootstrapPhase is
>>>> true, then add the Exception to a ThreadLocal list, otherwise throw
>>>> exception as previously.
>>>> 5. Figure out when bootstrap phase is "over", check if there are any
>>>> Excepitons in the list, if so, generate an elaborate, machine readable
>>>> report (for tooling) and abort. Otherwise clear bootstrapPhase and
>>>> continue
>>>> as normal.
>>>>
>>>> I am not sure if all structural problems can be caught in one swoop or
>>>> not, but I am sure it would be a big improvement. Also, there might be
>>>> other Exceptions that should be involved in this as well.
>>>>
>>>> WDYT?
>>>>
>>>> Cheers
>>>> --
>>>> Niclas Hedhman, Software Developer
>>>> http://polygene.apache.org <http://zest.apache.org> - New Energy for
>>>> Java
>>>>
>>>>
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
