Henning,

Did you get a chance to read my follow up email and look at the changes I
made in Fulcrum?  After spending a stack of time trying to understand
Fulcrum, I think I ended up at the same point you are at, about the Avalon
components, and ditching the ServiceBroker stuff...

So, in preperation for the post 2.3 future..  Should I continue down the
path I am?  I am happy to slap in a quartz version of the scheduler as well.
(might throw in the wrapper to my JCrontab one as well ;-) ).

If we are happy with what I am doing, then I will start deleting code out of
/src/java and replacing it with the components.  My only other question
though is should all the services become components?  And any suggestions on
order...

Eric



-----Original Message-----
From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 17, 2003 3:08 PM
To: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL] Move Torque related classes to seperate turbine
module.


"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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to