I have had some email problems the last few days and didn't get Paul's
response but look it up on the archives.
The full format would have been;
Composition Problems Report:
message: No implementation found for method
method: java.util.Map<java.lang.String, java.lang.Integer>
doAnotherThing(String name, int value)
types: [Person,ValueComposite]
(i.e. toString on a ParameterizedType) which I find quite annoying. Seldom
enough the package name should be needed.
Cheers
On Wed, Mar 29, 2017 at 7:13 PM, Niclas Hedhman <nic...@hedhman.org> wrote:
>
> 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
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
