• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to disable JunitEE in production?

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm new to JunitEE and from reading the documentation it is not clear what the approach is to disable the JunitEE TestServlet in production.

JunitEE and associated test classes are being added to an existing application so that the test classes can access existing Services and infrastructure in the app that is being tested. Once the build is done it is installed in the App Server and the JunitEE tests are run. Eventually the exact same build will go to production so how do we disable it there or do we need to create a new build excluding the JunitEE jars and test classes? The preference would be not to create a new build but to somehow disable JunitEE. Otherwise we would be testing one app, re-building and essentially putting an un-tested build in production.

Any help/suggestions is appreciated.

Thanks,
Peter
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter,
Welcome to JavaRanch!

What I do to disable a test servlet is have the build comment out the part of the web.xml that has that servlet. That way the code is the same (and I don't take the risk of messing things up) and it is completely automated. If I need to be absolutely sure the servlet can't be enabled, I'll have the build delete the .class file for the servlet too. That way if someone added it back to the web.xml the application wouldn't even start up.
 
Peter Kelly
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeanne Boyarsky wrote:Peter,
Welcome to JavaRanch!

What I do to disable a test servlet is have the build comment out the part of the web.xml that has that servlet. That way the code is the same (and I don't take the risk of messing things up) and it is completely automated. If I need to be absolutely sure the servlet can't be enabled, I'll have the build delete the .class file for the servlet too. That way if someone added it back to the web.xml the application wouldn't even start up.




Jeanne,

Thanks for the suggestion! What I was hoping to do is avoid a rebuild to exclude the web.xml entry just to eliminate the chance of new/modified code being introduced by accident thru source code control issues.

What I thought of doing was possibly preventing the init method of the servlet from completing successfully if an entry from a preferences file indicated that the servlet should be disabled. I'd have to subclass the JunitEE Servlet to do that I guess but that way we could use identical builds and just modify a preferences file.

Although I'm not sure if raising an exception in the init method would just prevent that one servlet from starting or prevent the entire app from starting???

What do you think?

Thanks,
Peter
 
Catch Ernie! Catch the egg! And catch this tiny ad too:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic