Re: [tor-bugs] #24174 [Metrics/ExoneraTor]: Use an embedded Jetty in ExoneraTor

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#24174: Use an embedded Jetty in ExoneraTor
--------------------------------+------------------------------
 Reporter:  iwakeh              |          Owner:  iwakeh
     Type:  enhancement         |         Status:  needs_review
 Priority:  Medium              |      Milestone:
Component:  Metrics/ExoneraTor  |        Version:
 Severity:  Normal              |     Resolution:
 Keywords:  metrics-2017        |  Actual Points:
Parent ID:                      |         Points:
 Reviewer:                      |        Sponsor:
--------------------------------+------------------------------

Comment (by iwakeh):

 Just noticed comment:6

 Replying to [comment:6 karsten]:
 > ...
 > Different question then: if we need to include parts of embedded Tomcat,
 why don't we switch to that entirely? It's the embedded part that we're
 after, right? Or what else do we gain from picking Jetty in particular?

 We've several embedded Jetties running and they work fine.  Big projects
 like Jenkins/Hudson have been using embedded Jetty for years successfully.
 I didn't do research about the question which production system uses an
 embedded tomcat. Tomcat is more often used as separate instance or
 embedded into JBoss.  By now Tomcat is almost an application server
 getting close to glassfish and the like.
 So, using the jsp functionality from Tomcat embeddable in an embedded
 Jetty is different from using embedded Tomcat.  I find it a good sign that
 Jetty (Eclipse) uses working features others (Apache) built.

 >
 > > Here the package listing:
 > > libasm-java (5.2-2)
 > > libtomcat8-embed-java (8.5.14-1+deb9u2)
 > > libecj-java (3.11.1-1)
 >
 > Okay, that's good to know.
 >
 > > Most other technologies won't have less dependencies.
 >
 > Yeah, good point.
 >
 > > BTW, the tweaked jar only prevents a duplicate include of a service
 definiton that wouldn't cause harm, so a rather picky measurement.
 >
 > I don't fully understand the benefit from preventing this duplicate. Can
 you explain that? To be honest, I'd feel much more comfortable with a
 build process that doesn't "tweak" provided library files. It feels
 fragile.

 It only feels fragile on first sight:
 I prefer to use 'duplicate="fail"' setting for the war-task.  The tweak
 only prevents the inclusion of a duplicate service definition.  If you
 remove the 'duplicate="fail"' setting and the tweak-related lines all
 would still work as expected here.  I'd rather include this for future
 dependency additions or upgrades to have an early warning, i.e., an
 immediate failure to assemble the war with new settings, when duplicate
 classes or configurations show up and then decide knowingly which should
 take precedence or what else to do.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24174#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs