Hi all
Adam Bien has been using GlassFish and blogging about his experience.
He had some interesting suggestions for the Call Flow area that we are
considering.
Adam has some suggestions for the EJB area that I am forwarding on the
dev alias.
This can potentially be discussed in the user experience team as well.
Thanks
Harpreet
PS:
For more of Adam's blogs:
http://www.adam-bien.com/roller/page/abien?entry=glassfish_could_become_the_killer
http://www.adam-bien.com/roller/page/abien?entry=glassfish_echoes
http://www.adam-bien.com/roller/page/abien?entry=the_glassfish_netbeans_difference
>
>
> I do not know, whether you are the right person for my next idea, but
> perhaps you could forward the message:
>
> In development phase it is useful to deploy EJBs in "exploded" format.
> But I think it would be even more useful to deploy them in source
> code (similar to JSP). This would allow to work in a very agile way
> with EJBs: after saving them they would be automatically recompiled
> and deployed -> pretty much the same
> mechanism as JSPs.
>
>
> Greetings,
>
> adam
>
>
> Harpreet Singh schrieb:
>> Hi Adam
>>
>>
>>> thank you for your nice comment in my blog.
>>> Some ideas for the call-flow:
>>>
>>> 1. From my perspective it is absolutely necessary to "see" also
>>> persistent entities in the call-flow graph.
>> What do you mean by persistent entities? Can you elaborate.
>>> 2. It would be also useful to see the time of the resources (queues,
>>> JDBC, JCA etc) in the context of methods.
>> We are currently exploring the work involved for JDBC and JCA resources.
>>> 3. Perhaps it is also possible to export (persist) the call-flow
>>> information into simple XML. (so additional renderers like SVG could
>>> be build)
>> Thats an interesting thought - we are currently storing this in the
>> db and we have not exposed the db schema to outside world, as we
>> expect this to change as we evolve this functionality in the next
>> couple of releases.
>>> 4. Filter-logic: it would be useful to be able to set
>>> boundaries/time-out for tha max-execution time of a method. So
>>> violating such rules could highlight the affected methods and log
>>> them also in a separate file (I did this in the past using dynamic
>>> proxy and factories in my application code).
>>>
>> We are looking at some sort of SLA mechanism. But we have not
>> considered SLA mechanism at method level, but it does sound interesting.
>>> @Roman:
>>> The call-flow results should be also visible in netbeans. Then would
>>> be great to link the call-flow with the source-code...
>> Another good one.
>> I have forwarded your input to others in my team. We are looking at
>> bringing some of the callflow.next features up for community
>> discussion soon.
>>
>> Thanks for your comments and valuable time.
>> Regards
>> Harpreet
>>>
>>> regards,
>>>
>>> adam
>>>
>>
>
>