"Eric Pugh" <[EMAIL PROTECTED]> writes:
>Hi all,
>I have been watching the large numbers of posts about not being able to
>build Turbine due to the Torque plugin problems. And while granted, it is
>an issue with Maven, I also want to remove the torque jars from my
>project.xml since I don't use Turbine's security or the scheduler service.
>However, this causes problems because Turbine needs Torque, even when you
>don't use it.
Yes. Because we have some unwanted dependencies.
>What is stopping us from removing the security code and scheduler service
>from Turbine, and putting them in Fulcrum's core? Is it because we are
>trying to get to 2.3? Or because no one has tackled the effort? it seems
>that now that Torque has been Avalonized (thanks henning) that we should do
>the same with the components that use Torque.
-1
Turbine 2.3 won't use Fulcrum. Post-2.3, maybe. But then we will
remove much of this dependency anyway.
>I am willing to signup my name next to this, but I need some confirmation
>that this is the path we want, and that we will remove the code from Turbine
>that is in Fulcrum.
I see a quite different future. I see many of our services being
converted into Avalon-based components and Turbine having some
embedded container to run these services instead of its current
cumbersome ServiceManager / ServiceBroker core.
Personally, I want a clean abstraction of the Security System which
allows really different security concepts like JAAS to be pluggable
into Turbine.
The scheduler service isn't really a needed service, unfortunately it
uses the assembler broker to build it's classes, so we might do some
creative lobotomy here. I repeatedly hear talk about the "Quarz
scheduler" that seems to be an Avalon component so if this works fine
in our future container, well, let's drop the Scheduler Service.
>As an aside, the duplicated code in Turbine and Fulcrum means that in
>Eclipse, when I popup my imports, I am constantly guessing which jar to
>import my classes from, Turbine or Fulcrum!
That's a problem of your IDE. I refuse to start bending the code just
to please a single IDE. If your IDE can't distinguish between classes
from different packages and/or projects, well, start getting another
one.
>On a related note, when can we remove the Criteria object from the
>interfaces for security like UserManager? I would be willing to live with
Yes. Post-2.3. Personally I plan a radically different approach in
slimming down what the Turbine core need from Security Service (which
isn't much) and then retrofit the Security Service to implement just
this interface. After that, you can simply pull Security Service
(which is a mess anyway) out and re-plug a new security concept.
>Criteria just being an Object, not a criteria, and casting it one way in
>DBUserManager, and another way in PassiveUserManager. Heck, then if we had
>HibernateUserManager then the criteria object could be a Hibernate HQL
>query!
Right.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
