You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Igor Fedorenko <if...@thinkdynamics.com> on 2002/09/06 18:49:39 UTC
Extending DefaultApplication
Hi,
I need to extend DefaultApplication in order to setup "default" security
context for blocks. I am planning to introduce a factory of Application
instances, so one can configure non-default implementation of
Application interface (JaasApplication in my case). However, I have
noticed that DefaultApplication is final and all its supporting classes
(BlockEntry, BlockInvocationHandler and alike) are package protected and
final. Would it be a problem if I relax these restructions, i.e. make
DefaultApplication non-final and make its supporting classes public
non-final as needed?
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extending DefaultApplication
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
public final class DefaultApplication => public class DefaultApplication
class BlockEntry => public final class BlockEntry
Plus a factory of Application instances.
I will include these changes into security patch (or patches) I am going
to submit week after next week.
Peter Donald wrote:
> On Sat, 7 Sep 2002 23:00, Igor Fedorenko wrote:
>
>>I need to set default security context for components (a.k.a. blocks) to
>>be used when components are *not* working on behalf of a user/external
>>system. For example I have Startable component that starts new threads
>>to monitor some external devices. When new information becomes available
>>this component calls other components and it has to provide security
>>credentials to perform these calls. Important point here is that the
>>calls are initiated from inside the system, so there is no user/external
>>system to authenticate.
>
>
> In that case we probably do need to extend application in some way. Can you
> describe your minimum requirements for this? ie What is the minimum we can
> get away with exposing?
>
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extending DefaultApplication
Posted by Peter Donald <pe...@apache.org>.
On Sat, 7 Sep 2002 23:00, Igor Fedorenko wrote:
> I need to set default security context for components (a.k.a. blocks) to
> be used when components are *not* working on behalf of a user/external
> system. For example I have Startable component that starts new threads
> to monitor some external devices. When new information becomes available
> this component calls other components and it has to provide security
> credentials to perform these calls. Important point here is that the
> calls are initiated from inside the system, so there is no user/external
> system to authenticate.
In that case we probably do need to extend application in some way. Can you
describe your minimum requirements for this? ie What is the minimum we can
get away with exposing?
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extending DefaultApplication
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
Peter Donald wrote:
> Hiya,
>
> On Sat, 7 Sep 2002 02:49, Igor Fedorenko wrote:
>
>>I need to extend DefaultApplication in order to setup "default" security
>>context for blocks. I am planning to introduce a factory of Application
>>instances, so one can configure non-default implementation of
>>Application interface (JaasApplication in my case). However, I have
>>noticed that DefaultApplication is final and all its supporting classes
>>(BlockEntry, BlockInvocationHandler and alike) are package protected and
>>final. Would it be a problem if I relax these restructions, i.e. make
>>DefaultApplication non-final and make its supporting classes public
>>non-final as needed?
>
>
> Once upon a time we did allow multiple implementations of Application. We also
> had a factory and all that. However we had quite a lot of probelsm when it
> came to maintaining compatability because we guarentee no future
> compatability for all the container classes. So I would prefer to avoid that
> if possible. Can you tell me what you need and maybe we can provide a
> mechanism for you to do what you want that we will be able to maintain.
I need to set default security context for components (a.k.a. blocks) to
be used when components are *not* working on behalf of a user/external
system. For example I have Startable component that starts new threads
to monitor some external devices. When new information becomes available
this component calls other components and it has to provide security
credentials to perform these calls. Important point here is that the
calls are initiated from inside the system, so there is no user/external
system to authenticate.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extending DefaultApplication
Posted by Peter Donald <pe...@apache.org>.
Hiya,
On Sat, 7 Sep 2002 02:49, Igor Fedorenko wrote:
> I need to extend DefaultApplication in order to setup "default" security
> context for blocks. I am planning to introduce a factory of Application
> instances, so one can configure non-default implementation of
> Application interface (JaasApplication in my case). However, I have
> noticed that DefaultApplication is final and all its supporting classes
> (BlockEntry, BlockInvocationHandler and alike) are package protected and
> final. Would it be a problem if I relax these restructions, i.e. make
> DefaultApplication non-final and make its supporting classes public
> non-final as needed?
Once upon a time we did allow multiple implementations of Application. We also
had a factory and all that. However we had quite a lot of probelsm when it
came to maintaining compatability because we guarentee no future
compatability for all the container classes. So I would prefer to avoid that
if possible. Can you tell me what you need and maybe we can provide a
mechanism for you to do what you want that we will be able to maintain.
--
Cheers,
Peter Donald
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extending DefaultApplication
Posted by Paul Hammant <Pa...@yahoo.com>.
Igor,
In your own fork, of course you can do what you like. If after some
weeks/months you are still convinced that the reason for forking is good
donate the changes back (against the then head revision) with a report
on its rationale and usage and if it is good, we'd commit it. My
observation is that you should try to make it a configurable choice via
kenerl.conf.
Regards,
- Paul
> Hi,
>
> I need to extend DefaultApplication in order to setup "default"
> security context for blocks. I am planning to introduce a factory of
> Application instances, so one can configure non-default implementation
> of Application interface (JaasApplication in my case). However, I have
> noticed that DefaultApplication is final and all its supporting
> classes (BlockEntry, BlockInvocationHandler and alike) are package
> protected and final. Would it be a problem if I relax these
> restructions, i.e. make DefaultApplication non-final and make its
> supporting classes public non-final as needed?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>