On Jul 21, 2010, at 8:16 AM, James Carman wrote:
> On Wed, Jul 21, 2010 at 9:14 AM, Matt Benson wrote:
>> That's why I had thought the flyweight would carry a reference to his object
>> as well as to his container. If the container is no longer accessible by
>> virtue of its static mapping be
On Wed, Jul 21, 2010 at 9:14 AM, Matt Benson wrote:
> That's why I had thought the flyweight would carry a reference to his object
> as well as to his container. If the container is no longer accessible by
> virtue of its static mapping being held only weakly, game over.
>
Yeah, but what happe
On Jul 21, 2010, at 7:10 AM, James Carman wrote:
> The one problem with creating an instance is that the flyweight needs
> to be able to get back to his "home" to reconstitute the object. If
> it's some instance floating around, that's harder.
>
That's why I had thought the flyweight would car
The one problem with creating an instance is that the flyweight needs
to be able to get back to his "home" to reconstitute the object. If
it's some instance floating around, that's harder.
On Tue, Jul 20, 2010 at 2:43 PM, James Carman
wrote:
> On Tue, Jul 20, 2010 at 2:36 PM, Matt Benson wrote:
On Wed, Jul 21, 2010 at 3:50 AM, Jörg Schaible wrote:
> Can you elaborate? UUID transports simply two long values as data in the
> object stream.
>
As I said, I "figured." I guess I never really looked into it. I
guess two longs do make a light (object that is). Sorry, couldn't
resist.
--
Hi James,
James Carman wrote:
> On Tue, Jul 20, 2010 at 4:37 PM, Jörg Schaible
> wrote:
>> Interesting idea, but keep the UUID, no need for String conversion ...
>> ;-)
>>
>
> I figured the UUID was more "heavyweight" as far as serialization was
> concerned. So, that's why I usually just conve
On Tue, Jul 20, 2010 at 4:37 PM, Jörg Schaible wrote:
> Interesting idea, but keep the UUID, no need for String conversion ... ;-)
>
I figured the UUID was more "heavyweight" as far as serialization was
concerned. So, that's why I usually just convert them to Strings.
--
James Carman wrote:
> On Tue, Jul 20, 2010 at 1:51 PM, Matt Benson wrote:
>> Not quite. I would like to move the RecordedInvocation class to some
>> sort of support package where it can be reused beyond InvocationRecorder,
>> e.g. in the code I'll be working on. Perhaps a rename of the class to
On Tue, Jul 20, 2010 at 2:36 PM, Matt Benson wrote:
> I know what you mean; it's potentially not that much code. Maybe start in
> the sandbox and, once everything's working satisfactorily, decide what to do
> with it? As for memory, what if you actually put the map of flyweight
> id:instance
On Jul 20, 2010, at 1:01 PM, James Carman wrote:
> On Tue, Jul 20, 2010 at 1:51 PM, Matt Benson wrote:
>> Not quite. I would like to move the RecordedInvocation class to some sort
>> of support package where it can be reused beyond InvocationRecorder, e.g. in
>> the code I'll be working on.
On Jul 20, 2010, at 1:01 PM, James Carman wrote:
[SNIP]
> I have also been thinking a bit about
> how to best create proxies to things that have to be looked up (such
> as Spring beans) when they're deserialized. Basically, you need to
> use the writeReplace()/readResolve() mechanism so that you
On Tue, Jul 20, 2010 at 1:51 PM, Matt Benson wrote:
> Not quite. I would like to move the RecordedInvocation class to some sort of
> support package where it can be reused beyond InvocationRecorder, e.g. in the
> code I'll be working on. Perhaps a rename of the class too, though I'm not
> sur
On Jul 20, 2010, at 10:44 AM, James Carman wrote:
> On Tue, Jul 20, 2010 at 11:05 AM, Matt Benson wrote:
>> Yep, 3.0... we'd need to get a snapshot published from [lang], which should
>> be dead easy now that we're using Nexus in the parent POM.
>>
>
> I say go for it.
I'll put that in the m
On Tue, Jul 20, 2010 at 11:05 AM, Matt Benson wrote:
> Yep, 3.0... we'd need to get a snapshot published from [lang], which should
> be dead easy now that we're using Nexus in the parent POM.
>
I say go for it. As for the recording stuff, have you committed your
changes? Is the recording not w
On Jul 20, 2010, at 9:55 AM, James Carman wrote:
> On Tue, Jul 20, 2010 at 10:49 AM, Matt Benson wrote:
>> So how do you feel about making [lang] a dependency to use its reflection
>> util classes for [proxy] 2?
>>
>
> I've never been one to be averse to using dependencies, but there are
> fo
On Tue, Jul 20, 2010 at 10:49 AM, Matt Benson wrote:
> So how do you feel about making [lang] a dependency to use its reflection
> util classes for [proxy] 2?
>
I've never been one to be averse to using dependencies, but there are
folks who would rather copy code rather than add a dependency if
On Jul 14, 2010, at 10:22 PM, James Carman wrote:
> On Wed, Jul 14, 2010 at 11:07 PM, Matt Benson wrote:
>> I believe that's the code I originally pulled in [lang] for TypeUtils.
>> However, since the latest contributions I've merged, the [lang] one now far
>> surpasses the handling in [proxy].
Hi James,
James Carman wrote:
> Well, the proxy code needs a bit of work. First, I'd say, I need to
> rollback the serializability requirement for all generated proxies.
Huh? At least JDK and CGLIB generated proxies are always serializable, you
have no choice.
- Jörg
---
On Wed, Jul 14, 2010 at 11:07 PM, Matt Benson wrote:
> I believe that's the code I originally pulled in [lang] for TypeUtils.
> However, since the latest contributions I've merged, the [lang] one now far
> surpasses the handling in [proxy]. So I know the recording is there, but I
> hadn't tracke
On Jul 14, 2010, at 9:15 PM, James Carman wrote:
Well, the proxy code needs a bit of work. First, I'd say, I need to
rollback the serializability requirement for all generated proxies.
It's easy enough to make your proxies serializable if you just add
java.io.Serializable to the list of classe
Well, the proxy code needs a bit of work. First, I'd say, I need to
rollback the serializability requirement for all generated proxies.
It's easy enough to make your proxies serializable if you just add
java.io.Serializable to the list of classes/interfaces you want
proxied (I'll put in a test cas
James,
What's the status of the genericized proxy 2.0 branch? I think the code I
talked about yesterday is basically a fancy way to describe building an
Interceptor. So proxy might be a good home for it. It's not really limited to
annotations anyway, though I could see providing a subclass
22 matches
Mail list logo
