3 Replies

actually we decided with good reason against
porting the EJB sensor 1:1 from AppMon to Dynatrace. the reasoning behind
that was that it did not bring any real value and caused quite some
traffic and processing overhead. that's why we already had it disabled
by default in recent AppMon versions.

so what the AppMon EJB
sensor did was to instrument all classes that are derived from the EJB
interfaces and show calls to those classes in a separate view. we
figured that this does not provide much real value and could also be
easily achieved by custom method sensors, if desired. also this
regularly led to increased overhead due to the nodes and traffic for
this kind of information.

in Dynatrace we decided to go
another way and focus on EJBs that are called remotely (RMI, web
requests). this leads to far less "noise" as only the particularly
relevant (i.e. remotely called) EJBs show up as services.

so in general, our Dynatrace EJB support should fit most people's needs already.