Hi Bryan,
Bryan Atsatt wrote:
I think the purely private repository model works fine, where the
definitions and module instances are also private.
And, as I said in the app server thread, using the private repository
approach for web-modules literally means a repository containing a
*single def
Stanley M. Ho wrote:
Hi Bryan,
Sorry, I was sidetracked in the last two days, will follow up other
threads soon.
Bryan Atsatt wrote:
This use case seems to presume that the IDE can/will ensure that there
is only *one* consumer of the module: itself. What if a different plugin
has a dependency
Hi Bryan,
Sorry, I was sidetracked in the last two days, will follow up other
threads soon.
Bryan Atsatt wrote:
This use case seems to presume that the IDE can/will ensure that there
is only *one* consumer of the module: itself. What if a different plugin
has a dependency on it, and has already
Adrian wrote:
On Tue, 2007-06-19 at 12:17 -0700, Bryan Atsatt wrote:
But you are right, of course, that there exist more complex scenarios
that require an intermediate form of sharing. Your named domains seems
to satisfy that requirement. Can you restrict access to domains?
Not really. We ass
On Tue, 2007-06-19 at 12:17 -0700, Bryan Atsatt wrote:
> But you are right, of course, that there exist more complex scenarios
> that require an intermediate form of sharing. Your named domains seems
> to satisfy that requirement. Can you restrict access to domains?
>
Not really. We assume that if
Whoops, forgot to say one thing...
As you describe it, I would consider JBoss ClassLoader Domains to be
100% public as long as *any* application can import/subscribe/access it.
To me:
a. A public repository contains Modules that may be imported by any other.
b. A private repository contains Mo
Adrian wrote:
On Mon, 2007-06-18 at 14:09 -0700, Bryan Atsatt wrote:
So an application server would have to create, say, a private
LocalRepository instance to hold the modules of a single application.
And it would have to ensure that no other application could get it's
grubby paws on that reposi
On Mon, 2007-06-18 at 14:09 -0700, Bryan Atsatt wrote:
> So an application server would have to create, say, a private
> LocalRepository instance to hold the modules of a single application.
> And it would have to ensure that no other application could get it's
> grubby paws on that repository inst
Stanley M. Ho wrote:
Hello Bryan,
Bryan Atsatt wrote:
...
But this approach doesn't really work very well. What happens when,
moments after releasing a module, another application is deployed that
needs the same module? It gets a different instance. And that could
easily lead to ClassCastExcept
Hello Bryan,
Bryan Atsatt wrote:
...
But this approach doesn't really work very well. What happens when,
moments after releasing a module, another application is deployed that
needs the same module? It gets a different instance. And that could
easily lead to ClassCastExceptions and/or LinkageErr
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
Can you please explain the use case for releaseModule()?
If a repository instance is long-lived, the instantiated module
instances from the module definitions in the repository would be cached
for a long period of time; calling releaseModule
Hi Bryan,
Bryan Atsatt wrote:
Can you please explain the use case for releaseModule()?
If a repository instance is long-lived, the instantiated module
instances from the module definitions in the repository would be cached
for a long period of time; calling releaseModule() could help freeing
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
...
It seems to me that if we're going to follow this model, then:
1. There is a 1:1 relationship between ModuleDefinition instances and
Module instances.
ModuleSystem is the one actually handling the module instances'
instantiation, initial
Resend.
Bryan Atsatt wrote:
It seems to me that if we're going to follow this model, then:
1. There is a 1:1 relationship between ModuleDefinition instances and
Module instances.
ModuleSystem is the one actually handling the module instances'
instantiation, initialization, and release. Typic
Hi Bryan,
Bryan Atsatt wrote:
...
It seems to me that if we're going to follow this model, then:
1. There is a 1:1 relationship between ModuleDefinition instances and
Module instances.
ModuleSystem is the one actually handling the module instances'
instantiation, initialization, and release.
Resend.
Bryan Atsatt wrote:
>
> It seems to me that if we're going to follow this model, then:
>
> 1. There is a 1:1 relationship between ModuleDefinition instances and
> Module instances.
ModuleSystem is the one actually handling the module instances'
instantiation, initialization, and release.
Stanley M. Ho wrote:
Resend.
Bryan Atsatt wrote:
...
Stanley's idea was that a Repository implementation could return a
*copy* of a ModuleDefinition created by a different Repository. Such a
Repository would in fact form an isolation context. And caching Module
instances becomes trivial: each d
Resend.
Bryan Atsatt wrote:
...
Stanley's idea was that a Repository implementation could return a
*copy* of a ModuleDefinition created by a different Repository. Such a
Repository would in fact form an isolation context. And caching Module
instances becomes trivial: each definition can just hav
Glyn Normington wrote:
*Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 31/05/2007 23:52:08:
> I'd like to continue this discussion separately from the
> 291/import-by-package thread :^).
>
> To recap, the spec (sections 1.2, 6.1, 6.4) talks about using separate
> Repository instances as a mean
Bryan Atsatt <[EMAIL PROTECTED]> wrote on 31/05/2007 23:52:08:
> I'd like to continue this discussion separately from the
> 291/import-by-package thread :^).
>
> To recap, the spec (sections 1.2, 6.1, 6.4) talks about using separate
> Repository instances as a means to provide isolation for enviro
20 matches
Mail list logo
