question regarding tomcat source code and dependencies

[Leo Donahue <do...@gmail.com>]

This question was spawned by two things:

I'm reading a book on Dependency Injection
The latest security announcement - reading the source for FileUploadBase.java

Some reading material suggests that one use a simple factory pattern
to move object creation dependencies to a different class.

I see where the object dependencies that FileUploadBase.java has, like
FileItemIteratorImpl, just simply place those dependent classes in the
same java source file.

I don't see a problem with that approach, should I?

Leo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] question regarding tomcat source code and dependencies

[Leo Donahue <do...@gmail.com>]

On Fri, Feb 7, 2014 at 1:50 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Leo,
>
> So... what does this all have to do with the recent security announcement?
>
> Hope that helps,
> - -chris

I thought I was black listed there for a day, or maybe it wasn't
Tomcat-list-worthy.  That thread never showed up in my inbox, but it
was in MarkMail.. Maybe gmail is having problems lately..

To answer your question, what it has to do with the announcement:  nothing.

I read the announcement, looked at the source code for that class and
started applying what I saw to what I had been reading about lately.
that is all, personal interest.

I appreciate the comments.

Leo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] question regarding tomcat source code and dependencies

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Leo,

On 2/6/14, 11:08 AM, Leo Donahue wrote:
> This question was spawned by two things:
> 
> I'm reading a book on Dependency Injection The latest security
> announcement - reading the source for FileUploadBase.java

Umm... ?

> Some reading material suggests that one use a simple factory
> pattern to move object creation dependencies to a different class.

Dependency Injection (or IoC, or any number of other names) is
different than using factories. It basically places the burden of
dependency-wiring on the DI framework and removes it entirely from the
"real" code.

Take the following example:

class SomeClass {
  public void someMethod()
  {
    Fruit fruit = new Apple();

    fruit.eat();
  }
}

That's pretty straightforward: the caller can call a method
(someMethod) and an apple is created and eaten (whatever that means).
If you want to say "well, I want to be able to eat any kind of fruit",
then you could change that into a factory:

class SomeClass {
  public void someMethod()
  {
    Fruit fruit = FruitFactory.createFruit();

    fruit.eat();
  }
}

That hasn't changed much. If you do alot of fruit-creation, and you
always use the factory, then you can switch from apples to bananas to
pears in one place and everyone is all eating the same thing. Great.
But that's not DI and it's not IoC. This is IoC:

class SomeClass {
  private Fruit _fruit;

  public Fruit getFruit() {
      return _fruit;
  }

  public void setFruit(Fruit f) {
    _fruit = f;
  }

  public void someMethod() {
    _fruit.eat();
  }
}

Then you tell the IoC container: "SomeClass requires some fruit.", and
then you either tell it exactly what fruit to use, or provide it with
some hints as to where to obtain fruits and it will wire-up the
relationships. The IoC container will create an instance of SomeClass,
fill it with fruit, and then you can call SomeMethod without ever
having to juggle the whole fruit situation at all.

> I see where the object dependencies that FileUploadBase.java has,
> like FileItemIteratorImpl, just simply place those dependent
> classes in the same java source file.
> 
> I don't see a problem with that approach, should I?

That's one way to do it. But you are talking about class design and
physical implementation, not simply class architecture and the logical
relationships between things. Inner classes are sometimes entirely
appropriate, and other times they are awkward to use, etc. For classes
expected to be used directly by client code, it's nicer for
documentation purposes to have them in separate classes (i.e. not
inner classes).

So... what does this all have to do with the recent security announcement?

Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJS9Ub8AAoJEBzwKT+lPKRYIXwQAJuH5P2kb0iuU+XhkxzyIKzb
n8wVDuWUmvnqPv5tzNEPglGB/PwxH5mywSYjvW6OUs8rcI6IUSU7S4320l60nPi8
mX14byhlJFyJ2vW8x8yDrbbqiQkbM/gopmgT6RQK64Hm8b0s5ABaudZDknvsBhIm
WHDZnTwbLlXW/yozXjKWrfumAF2qkiJcOVMrFGyfjQGhhJostGjDrWJI31ddRlkB
5EOmlIF2Gq9yAsZlFRpiENBQ2HFS05EuJCcCHcYpfBGAIxO7WqxVAdNRSyT4gZ5c
yneRmAtu6aMfbtdbx0xA1UV1ObezIOqqvH4ni1NkNvv34A6yGOh7QKDhHPd9uJ+Y
ZbLsXdOLUk1fScgegIvPxNbyggYPfNLXcyasagiO2QEG908ABr+/5lyy+B65JUeL
7Kniu25Zv6EdAijrUI+LfNc/uPI9upmu48xIFjSx0UaX9PT28uZ1UCQmjHdRHv1o
i0qERB2bBkqEdIwGeB7RtpbUTxgbojlPe8hWMR2KTaWSgCZA1/fNH6wyrFKdOA6b
2BpnRYQ1vc0d8xlauHBxbnZ5sCEzdchYjjpmCDxj0Lxk4Pi4eoaBheUX5DD5qbtU
lNWfEt3pJCvlccz0f5ULIlwtWbKUxFTFEykAiQN2hr4Pt2sJkZe3Yq8kd8cZlfYi
y+7ixJpvHwZZCD9ea1u/
=4QAZ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org