Separation of Presentation and Business Tiers with Spring

Hi there,

In my just-completed project, I was working getting distributed transactions working.

We implemented this using JBoss's Arjuna Transaction Manager, and Spring's declarative transaction boundaries.

Our request sequence looked like:

browser -> secured servlet -> 'wafer-thin' SLSB -> spring TX-aware proxy -> request-handler POJO

What this meant is that we had a WAR to serve our secured servlet and an EAR to serve our SLSB.

Our SLSB had a static initialiser block to bootstrap our Spring application context.

I don't like the mix of technologies, but I do like the separation of presentation and business tiers, which could reside on different physical locations.

I would be interested to know what others propose to separate tiers when using Spring?

From stackoverflow

• Requiring an EJB3 app server just for a SLSB that is a facade doesn't seem like it's worth the effort to me. There is no reason you couldn't just remove that and have your servlet work directly with Spring. You can add the ContextLoaderListener to the WAR to load your ApplicationContext and then WebApplicationContextUtils to get at it. Alternatively you could use SpringMVC, Struts or other web technologies if you need to do more than what the Servlet on its own will allow for.

• A pretty typical approach is to define a web tier, a service tier and a DAO tier, and attach transactional semantics to the service tier. The service tier might be a bunch of POJOs with @Transactional annotations, for example. The web tier might be Spring Web MVC controllers. In this approach, the web tier is essentially adapting the service tier to HTTP. Good separation and no need for SLSBs here.

  One area of debate though is with respect to the domain objects, like Employee or PurchaseOrder or whatever. These span application tiers and one thing that seems to be happening with annotations is that the domain objects get annotations that are tied to specific tiers. So you might have ORM annotations here but then use the same domain object as a form-backing bean as a way to avoid parallel domain/form object classes. Some people object to that as violating architectural separation of concerns.

  toolkit : thanks Willie, unfortunately I cannot mark you both correct... +1

How do I concisely implement multiple similar unit tests in the Python unittest framework?

I'm implementing unit tests for a family of functions that all share a number of invariants. For example, calling the function with two matrices produce a matrix of known shape.

I would like to write unit tests to test the entire family of functions for this property, without having to write an individual test case for each function (particularly since more functions might be added later).

One way to do this would be to iterate over a list of these functions:

import unittest
import numpy

from somewhere import the_functions
from somewhere.else import TheClass

class Test_the_functions(unittest.TestCase):
  def setUp(self):
    self.matrix1 = numpy.ones((5,10))
    self.matrix2 = numpy.identity(5)

  def testOutputShape(unittest.TestCase):
     """Output of functions be of a certain shape"""
     for function in all_functions:
       output = function(self.matrix1, self.matrix2)
       fail_message = "%s produces output of the wrong shape" % str(function)
       self.assertEqual(self.matrix1.shape, output.shape, fail_message)

if __name__ == "__main__":
  unittest.main()

I got the idea for this from Dive Into Python. There, it's not a list of functions being tested but a list of known input-output pairs. The problem with this approach is that if any element of the list fails the test, the later elements don't get tested.

I looked at subclassing unittest.TestCase and somehow providing the specific function to test as an argument, but as far as I can tell that prevents us from using unittest.main() because there would be no way to pass the argument to the testcase.

I also looked at dynamically attaching "testSomething" functions to the testcase, by using setattr with a lamdba, but the testcase did not recognize them.

How can I rewrite this so it remains trivial to expand the list of tests, while still ensuring every test is run?

From stackoverflow

• You could use a metaclass to dynamically insert the tests. This works fine for me:

  import unittest
  
  class UnderTest(object):
  
      def f1(self, i):
          return i + 1
  
      def f2(self, i):
          return i + 2
  
  class TestMeta(type):
  
      def __new__(cls, name, bases, attrs):
          funcs = [t for t in dir(UnderTest) if t[0] == 'f']
  
          def doTest(t):
              def f(slf):
                  ut=UnderTest()
                  getattr(ut, t)(3)
              return f
  
          for f in funcs:
              attrs['test_gen_' + f] = doTest(f)
          return type.__new__(cls, name, bases, attrs)
  
  class T(unittest.TestCase):
  
      __metaclass__ = TestMeta
  
      def testOne(self):
          self.assertTrue(True)
  
  if __name__ == '__main__':
      unittest.main()
  

  saffsd : Thanks, this works. Only one slight quirk, nose is unable to see the testcases added by the metaclass. Any suggestions?

  Dustin : I'm not familiar with nose. This adds the methods to the class, so I'm not sure what nose could be doing to miss them. I'd be interesting to find out what its magic is, though.

  Matt Joiner : cutting it bit fine with the use of `f` in the __new__ there, it's a bit obscure

• Metaclasses is one option. Another option is to use a TestSuite:

  import unittest
  import numpy
  import funcs
  
  # get references to functions
  # only the functions and if their names start with "matrixOp"
  functions_to_test = [v for k,v in funcs.__dict__ if v.func_name.startswith('matrixOp')]
  
  # suplly an optional setup function
  def setUp(self):
      self.matrix1 = numpy.ones((5,10))
      self.matrix2 = numpy.identity(5)
  
  # create tests from functions directly and store those TestCases in a TestSuite
  test_suite = unittest.TestSuite([unittest.FunctionTestCase(f, setUp=setUp) for f in functions_to_test])
  
  
  if __name__ == "__main__":
  unittest.main()
  

  Haven't tested. But it should work fine.

  saffsd : unittest.main() doesn't automatically pick this up, and neither does nose. Also, FunctionTestCase calls setUp without arguments, and the functions_to_test need to be wrapped in something that asserts the test.

• Here's my favorite approach to the "family of related tests". I like explicit subclasses of a TestCase that expresses the common features.

  class MyTestF1( unittest.TestCase ):
      theFunction= staticmethod( f1 )
      def setUp(self):
          self.matrix1 = numpy.ones((5,10))
          self.matrix2 = numpy.identity(5)
      def testOutputShape( self ):
          """Output of functions be of a certain shape"""
          output = self.theFunction(self.matrix1, self.matrix2)
          fail_message = "%s produces output of the wrong shape" % (self.theFunction.__name__,)
          self.assertEqual(self.matrix1.shape, output.shape, fail_message)
  
  class TestF2( MyTestF1 ):
      """Includes ALL of TestF1 tests, plus a new test."""
      theFunction= staticmethod( f2 )
      def testUniqueFeature( self ):
           # blah blah blah
           pass
  
  class TestF3( MyTestF1 ):
      """Includes ALL of TestF1 tests with no additional code."""
      theFunction= staticmethod( f3 )
  

  Add a function, add a subclass of MyTestF1. Each subclass of MyTestF1 includes all of the tests in MyTestF1 with no duplicated code of any kind.

  Unique features are handled in an obvious way. New methods are added to the subclass.

  It's completely compatible with unittest.main()

  muhuk : I like this object-oriented solution. "Explicit is better than implicit"

  saffsd : I don't like this because it introduces a whole heap of duplicated code. Since each of the functions is meant to observe the same invariant being tested, I'd like a way to express exactly this without having to lump them into a single testcase. Perhaps I should? Thanks for the suggestion though.

  S.Lott : Refactor common code up into a superclass. That's what superclasses are for. Your "common test" is precisely why we have superclasses and subclasses.

  saffsd : The issue is that it doesn't refactor. I'm working with classification algorithms, and I'm modelling each as a function with two input matrices and one output matrix. Most of these functions are not even python, they're thin wrappers. Perhaps I should assert inside rather than test outside?

  S.Lott : @saffsd: "it doesn't refactor"? What is "it? I'm talking about refactoring the tests into a single common superclass so each function has a subclass that assures that common features of the function have common methods in a test.

• The problem with this approach is that if any element of the list fails the test, the later elements don't get tested.

  If you look at it from the point of view that, if a test fails, that is critical and your entire package is invalid, then it doesn't matter that other elements won't get tested, because 'hey, you have an error to fix'.

  Once that test passes, the other tests will then run.

  Admittedly there is information to be gained from knowledge of which other tests are failing, and that can help with debugging, but apart from that, assume any test failure is an entire application failure.

  saffsd : I recognize that, but another counter-argument is that if you are running tests in a batch, say overnight, you want to know where all of the failures are, not just the first one.

• If you're already using nose (and some of your comments suggest you are), why don't you just use Test Generators, which are the most straightforward way to implement parametric tests I've come across:

  For example:

  from binary_search import search1 as search
  
  def test_binary_search():
      data = (
          (-1, 3, []),
       (-1, 3, [1]),
       (0,  1, [1]),
       (0,  1, [1, 3, 5]),
       (1,  3, [1, 3, 5]),
       (2,  5, [1, 3, 5]),
       (-1, 0, [1, 3, 5]),
       (-1, 2, [1, 3, 5]),
       (-1, 4, [1, 3, 5]),
       (-1, 6, [1, 3, 5]),
       (0,  1, [1, 3, 5, 7]),
       (1,  3, [1, 3, 5, 7]),
       (2,  5, [1, 3, 5, 7]),
       (3,  7, [1, 3, 5, 7]),
       (-1, 0, [1, 3, 5, 7]),
       (-1, 2, [1, 3, 5, 7]),
       (-1, 4, [1, 3, 5, 7]),
       (-1, 6, [1, 3, 5, 7]),
       (-1, 8, [1, 3, 5, 7]),
      )
  
      for result, n, ns in data:
       yield check_binary_search, result, n, ns
  
  def check_binary_search(expected, n, ns):
      actual = search(n, ns)
      assert expected == actual
  

  Produces:

  $ nosetests -d
  ...................
  ----------------------------------------------------------------------
  Ran 19 tests in 0.009s
  
  OK
  

• The above metaclass code has trouble with nose because nose's wantMethod in its selector.py is looking at a given test method's __name__, not the attribute dict key.

  To use a metaclass defined test method with nose, the method name and dictionary key must be the same, and prefixed to be detected by nose (ie with 'test_').

  # test class that uses a metaclass
  class TCType(type):
      def __new__(cls, name, bases, dct):
          def generate_test_method():
              def test_method(self):
                  pass
              return test_method
  
          dct['test_method'] = generate_test_method()
          return type.__new__(cls, name, bases, dct)
  
  class TestMetaclassed(object):
      __metaclass__ = TCType
  
      def test_one(self):
          pass
      def test_two(self):
          pass
  

• You don't have to use Meta Classes here. A simple loop fits just fine. Take a look at the example below:

  import unittest
  class TestCase1(unittest.TestCase):
      def check_something(self, param1):
          self.assertTrue(param1)
  
  def _add_test(name, param1):
      def test_method(self):
          self.check_something(param1)
      setattr(TestCase1, 'test_'+name, test_method)
      test_method.__name__ = 'test_'+name
  
  for i in range(0, 3):
      _add_test(str(i), False)
  

  Once the for is executed the TestCase1 has 3 test methods that are supported by both the nose and the unittest.

  Matt Joiner : yeah i find metaclasses for purposes of "instrumenting" single-use classes never flies well, this is a much better approach.

When would you use the mediator design pattern

As the title states when would you recommend the use of the mediator design pattern and where do you see it used incorrectly?

From stackoverflow

• I have used it to deal with swing apps.

  When I'm building a GUI I don't like each control know each other because that would require subclassing.

  Instead I have a Main object whose contains the listener and the widgets and let it mediate between the different controls, buttons, textfields etc.

• Use a mediator when the complexity of object communication begins to hinder object reusability. This type of complexity often appears in view instances, though it could really be anywhere.

  Misuse of a mediator can result in crippling the interfaces of the mediator's colleague classes.

  It seems a little funny to talk about misusing a pattern. If your implementation follows the pattern, then you've used the pattern. Otherwise, you haven't. In other words, if your mediator is doing something else, then it probably isn't a mediator. Patterns are defined by what they do, what they in fact are. The names of things are simply labels.

  The real question to ask yourself is whether your implementation of a pattern fulfills the pattern's promises for your design. The mediator pattern aims to encapsulate complex inter-object communication when it is becoming unmanageable. If it hasn't accomplished this, or hasn't done it very well, you could say that a mediator is being misused. At some point, it becomes a value judgement.

  OscarRyz : 1+ for the answer

  hhafez : could you give more details on the misuse? Thanks

  keparo : (added a note above)

• The mediator is also basically what an event-pump is. A very common pattern in GUI's and Games.

  Also I've used mediator before to communicate among very dispar systems, and legacy frameworks.

Oracle checking existence before deletion in a trigger

I have analyzed a hibernate generated oracle database and discovered that a delete of a row from a single table will spawn the firing of 1200+ triggers in order to delete the related rows in child tables. The triggers are all auto-generated the same - an automatic delete of a child row without checking for existence first. As it is impossible to predict which child tables will actually have related rows, I think a viable solution to preventing the firing of the cascaded delete down a deeply branched completely empty limb, would be to check for the existence of a related row before attempting to delete. In other dbms', I could simply state " if exists....." before deleting. Is there a comparable way to do this in oracle?

From stackoverflow

• You can query the special dba_objects table: 

  DECLARE 
  X    NUMBER;
  BEGIN
      SELECT COUNT(*) INTO X FROM DBA_OBJECTS WHERE OBJECT_TYPE = 'TRIGGER' AND OBJECT_NAME = 'YOUR_TRIGGER_NAME_HERE';
      IF X = 0 THEN
          --Trigger doesn't exist, OK to delete...
      END IF;
  END;
  

• If possible, modify and setup your DB tables appropriately. - Involve a DBA if you have one at your disposal.

  You need to use Foreign Key constraints and cascade deletes. This eliminates the need for triggers, etc...

• "delete of a row from a single table will spawn the firing of 1200+ triggers" Are these statement or row level triggers ? If the latter, they'll only fire if a row is deleted. Say you have a BEFORE DELETE trigger on customers to delete the customers orders, and a BEFORE DELETE trigger on orders to delete order items. If the customer has no orders, and the orders table trigger is a row level trigger, then it will not fire the delete from order items.

  "check for the existence of a related row before attempting to delete" Probably no benefit. In fact it would do more work having a SELECT followed by a DELETE.

  Of course the Hibernate logic is broken. The deleting session will only see (and try to delete) committed transactions. If FRED has inserted an order for the customer, but it is not committed, JOHN's delete (through the trigger) won't see it or try to delete it. It will however still 'succeed' and try to delete the parent customer. If you have actually got your foreign key constraints enabled in the database, Oracle will kick in. It will wait until FRED commits, then reject the delete as it has a child. If the foreign key constraints aren't in place, you have an order for a non-existent customer. This is why you should have this sort of business logic enforced in the database.

• **select * from Tab where Tname = "TABLENAME"

  <

  If this query returns any row then table exist else Not**

threadlocal variables in a servlet

Are the threadlocals variables global to all the requests made to the servlet that owns the variables?

I am using resin for the server.

Thanks for awnser.

I think I can make my self more clear.

The specific Case:

I want to:

• initialize a static variable when the request starts the execution.
• be able to query the value of the variable in the further executions of methods called from the servlet in a thread safety way until the request ends the execution

From stackoverflow

• I think they are global to all requests made with that specific thread only. Other threads get other copies of the thread-local data. This is the key point of thread-local storage: http://en.wikipedia.org/wiki/Thread-local_storage#Java.

  Unless you check the appropriate option in the servlets config, the servlet container will use your servlet with multiple threads to handle requests in parallel. So effectively you would have separate data for each thread that's up serving clients.

  If your WebApplication isn't distributed (runs on multiple Java Virtual Machines), you can use the ServletContext object to store shared data across requests and threads (be sure to do proper locking then).

  Julie : Indeed. On a previous project, I stored a user's ticket in their session, and created a filter to transfer the ticket from the session to a thread local to make sure that a user's authentication state was always available to the thread processing the request.

• Threadlocal variables are always defined to be accessed globally, since the point is to transparently pass information around a system that can be accessed anywhere. The value of the variable is bound to the thread on which it is set, so even though the variable is global, it can have different values depending on the thread from which it is accessed.

  A simple example would be to assign a user identity string to a thread in a thread local variable when the request is received in the servlet. Anywhere along the processing chain of that request (assuming it is on the same thread in the same VM), the identity can be retrieved by accessing this global variable. It would also be important to remove this value when the request is processed, since the thread will be put back in a thread pool.

• Like Adiel says, the proper way to do this is probably to use the request context (i.e. HttpServletRequest), not to create a ThreadLocal. While it's certainly possible to use a ThreadLocal here, you have to be careful to clean up your thread if you do that, since otherwise the next request that gets the thread will see the value associated with the previous request. (When the first request is done with the thread, the thread will go back into the pool and so the next request will see it.) No reason to have to manage that kind of thing when the request context exists for precisely this purpose.

  sehugg : You could also use a servlet filter to manage the ThreadLocal, at least the creation/cleanup would be in one place.

• Short answer: Yes.
  A bit longer one: This is how Spring does its magic. See RequestContextHolder (via DocJar).

  Caution is needed though - you have to know when to invalidate the ThreadLocal, how to defer to other threads and how (not) to get tangled with a non-threadlocal context.

  Or you could just use Spring...

How do you specify a where clause on data returned from a .Include in an Entity Framework query?

Given the following database table hierarchy:

Region
------
RegionId
RegionName

Country
-------
CountryId
RegionId
CountryName

Destination
-----------
DestinationId
CountryId
DestinationName

Venue
-----
VenueId
DestinationId
VenueName

I have the following Entity Framework query:

var result = from region in context.Region.Include("Country.Destination.Venue") 
select region

which will return all rows from all tables (outer join)

Is it possible to introduce a where clause so that only rows where the venue is not null are included (or use an inner join) ?

Thanks

From stackoverflow

• Try this. It should return the results you are looking for: only regions that have a corresponding venue.

      var result = from region in context.Region.Include(Country.Destination.Venue)
                   let v = (from ctry in region.Country
                           join dest in context.Destination
                           on ctry.CountryId
                           equals dest.CountryId
                           into destGroup
                     from dests in destGroup
                     join ven in context.Venue
                     on dests.DestinationId
                     equals ven.DestinationId
                     into venGroup
                           select ctry).Any()
                   where v == true
                   select region;
  

  Alan Heywood : Thanks, I tried this however it brings back all regions in the case that there is an associated Country and Destination but no associated Venue.

  YeahStu : Ok. You might be right. I tested this on a sample app here but I only had three tables to play with, not four. I hope this shows an example of what you might try though.

How to Check for Image in Cache Using Silverlight

I am creating a basic image browsing application using Silverlight. Depending on the user's connection speed, some images may take time to appear once they click on the thumb nail. I would like to show a progress bar while it is being downloaded. I have this part done.

However, if the image is already in the cache (viewing a previous image), I'd rather not have the progress bar flash up and then disappear. Is there a way to see if a particular file is in the cache before I display my progress bar?

From stackoverflow

• After thinking about it for a while, I did come up with one solution, though it wasn't what I was originally intending.

  I am using the WebClient class to get my image file. I attach to the DownloadProgressChanged event. If the image has already been downloaded, then the ProgressPercentage is immediately 100.

  So instead of making the ProgressBar visibile when I call OpenReadAsync and making it invisible when the Completed event is fired, I set the visibility in the DownloadProgressChanged event handler.