Bill Burke wrote:
We can just throw away any code I add later. It won't take very long..
What I am suggesting is a fairly small change. You guys are just
getting way to excited about repository implementation details. I just
I'm not focusing on implementation details, just throwing in ide
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain
> Sundstrom
> Sent: Thursday, November 14, 2002 1:04 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] MetaDataRepository Proposal
&g
Matt Munz wrote:
>> and the worst part is we have no control over it at runtime. It is
>> way simpler. You'll see.
>
>
> It sounds like you have a vision. Please continue to make the effort
> to get the rest of us into the loop. I want to "see" also, but I'd
> prefer to do so sooner rather than
Peter Fagerlund wrote:
onsdagen den 13 november 2002 kl 23.56 skrev Dain Sundstrom:
public interface MetaDataRepository {
MetaDataRepository getParent();
void setParent(MetaDataRepository parent);
Object get(Object attributeKey);
void set(Object attributeKey, Object value);
}
mayb
Bill Burke wrote:
In all honesty Dain, I don't think this is a simplification. And Hiram's
right. Attaching interfaces with the aspect framework should give you the
functionality you want here of adding read-ahead apis. How would it get
into the invocation? EasilyIts just another invocatio
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain
> Sundstrom
> Sent: Thursday, November 14, 2002 12:55 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] MetaDataRepository Proposal
>
Dain,
> and the worst part is we have no control over it at runtime. It is way
> simpler. You'll see.
It sounds like you have a vision. Please continue to make the effort to get
the rest of us into the loop. I want to "see" also, but I'd prefer to do so
sooner rather than later (not after it'
onsdagen den 13 november 2002 kl 23.56 skrev Dain Sundstrom:
public interface MetaDataRepository {
MetaDataRepository getParent();
void setParent(MetaDataRepository parent);
Object get(Object attributeKey);
void set(Object attributeKey, Object value);
}
maybe add
void setJDBCBackend(
Hiram Chirino wrote:
David,
Actually it simplifies the code. If you take a look at our interceptor
stack most have a ton of code just to load and maintain the metadata,
Yes there is alot of Metadata now. 1/2 the ton of code that we have there
is just taking XML and creating a metadata object
>
> David,
>
> Actually it simplifies the code. If you take a look at our interceptor
> stack most have a ton of code just to load and maintain the metadata,
Yes there is alot of Metadata now. 1/2 the ton of code that we have there
is just taking XML and creating a metadata objects. I think tha
David,
Actually it simplifies the code. If you take a look at our interceptor
stack most have a ton of code just to load and maintain the metadata,
and the worst part is we have no control over it at runtime. It is way
simpler. You'll see.
The easiest case for me the read ahead configuratio
Can you please give a fairly detailed use case for this idea and indicate
why it is needed rather than a static division of metadata between that
which is tied to an interceptor stack (the same for every invocation going
through the stack) and that which is specific to a particular invocation
(and
12 matches
Mail list logo
