Thx, for detailed explanation.
Definitely you had reasonable arguments for your choice to develop new
container. And yes it will help to avoid some conflicts.
But I hope it will be stable enough... no offend but we are going to
have lot's of fun fixing lot's of bugs related to it (just some
filling).
One more thing... is DI container would be replaceable by some
other... like Spring or it' will be solid-embedded?
Evgeny.
31 ÄÅËÁÂÒÑ 2009 Ç. 18:05 ÐÏÌØÚÏ×ÁÔÅÌØ Andrus Adamchik
<andru..bjectstyle.org> ÎÁÐÉÓÁÌ:
>
> On Dec 31, 2009, at 1:43 PM, òÑÂÉÃËÉÊ å×ÇÅÎÉÊ wrote:
>
>> But I think the right solution is to every time evaluate new versions of
>> used libraries and it's compatibility with Cayenne.
>> And if it possible - šmigrate to new versions (never lag behind life). I
>> know it is also a huge work but it's better.
>>
>> [...]
>>
>> Instead third party project is been developing for long time. Lot's of
>> optimization/bug fixes (even before we find them) is provided in new
>> versions which can be easily catch by our project.
>>
>> Actually that is why I am using Cayenne instead of creating some own
>> solution.
>
> This is all good, but consider the difference between developing an
> application and developing a framework. In the former case, you ship a
> black-box .war or .jar to the end user. Users couldn't care less what's
> inside, as long as it has familiar UI. The later case is more nuanced, and
> third-party dependency issue can't just be dismissed or dealt with by
> upgrading to the latest version of everything. (For completeness, there's a
> third group of developers well represented at Apache - container developers,
> who are allowed to get loose with deps).
>
> When we started on Cayenne back in 2001-2002, we'd use every single utility
> lib out there to make our life easier. We shipped a bunch of odd
> dependencies like commons-beanutils (cause we didn't want to implement our
> own reflection), etc. It wasn't a disaster or anything, but every now and
> then an issue would pop up in one environment or another (e.g. most
> application servers used to include the entire Apache commons-* zoo creating
> weirdest class loader issues, and still do actually).
>
> So my design preference (as a framework designer) has shifted from "import
> any third-party lib we find remotely useful" to "import nothing; if you
> absolutely have to introduce a dependency, make it optional and pluggable".
> Cache management is a good example. We don't want to re-implement OSCache or
> EHCache in Cayenne, still we don't want Cayenne tied to any of those.
> Instead we allow the users to plug them dynamically. Velocity is probably
> the only remaining piece that is not easily abstracted out.
>
> With DI we got somewhat lucky that it turned out much simpler to write than
> I expected, so we don't have a write a "Spring plugin", "Guice plugin",
> "Tapestry5 Plugin" (we may still run into issues when we start using it
> actively, but till now it was a cakewalk). So after that discovery it was a
> no brainer.
>
> Anyways, just trying to explain why we did what we did.
>
>> Also it's our fault that we are using so old Velocity version.
>
> Maybe, but then there will be at least one other library out there that
> depends on older Velocity. Either way we are putting burden on the user to
> figure it out, instead of just telling him - drop cayenne-server.jar in your
> app and you are done.
>
> Andrus
>
>
>
>
This archive was generated by hypermail 2.0.0 : Thu Dec 31 2009 - 11:13:24 EST