Hi all guys,
just to give a small recap:
* commons-discover, suggested by Jorg, is a totally different stuff,
implementing the SPI discovery;
* scannotation, suggested by James, is cool, btw supports a limited
subset of the proposed functionalities.
I'm still convinced that together we could re
Yeah, that's the one. I've used it a few times on side projects and
it works quite well. It lets you control exactly where on the
classpath you want to scan. Very useful! Enjoy!
On Mon, Sep 13, 2010 at 8:27 AM, Simone Tripodi
wrote:
> Hi James,
> thanks for the hint! Did you mean the project
Hi James,
thanks for the hint! Did you mean the project on SF[1]? I'll take a
deeply look at it, thanks for suggesting it!
Simo
[1] http://scannotation.sourceforge.net/
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, Sep 13, 2010 at 1:27 PM, James Carman
wrote:
> Also,
Also, take a look at the scannotation project. I've found that to be
quite useful. It's apache-licensed, too.
On Mon, Sep 13, 2010 at 4:25 AM, Simone Tripodi
wrote:
> Hi Jorg,
> nice to meet you and thanks for the hint :) Indeed, maybe the
> Discovery would be a better place... Henry, WDYT? Ma
Hi Jorg,
nice to meet you and thanks for the hint :) Indeed, maybe the
Discovery would be a better place... Henry, WDYT? Maybe it's time to
give to Discovery a new life?
Have a nice day, all the best
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, Sep 13, 2010 at 9:
Hi Simone,
Simone Tripodi wrote:
> Hi Henry!
> thanks for your interest :) I avoided even reading the Jersey source
> code for the problem you mentioned (I'm not licensing expert but AFAIK
> ASL2.0 is not compatible with Jersey's), I took the main inspiration
> from Misko Hevery's classpath-explo
Hi Henry!
thanks for your interest :) I avoided even reading the Jersey source
code for the problem you mentioned (I'm not licensing expert but AFAIK
ASL2.0 is not compatible with Jersey's), I took the main inspiration
from Misko Hevery's classpath-explorer (ASL2.0) for the ClassPath
structure/boot
I like the sound of it :)
I hope you've not used any code from Jersey though, it's license will
overrule the AL 2.0 licensing.
Hen
On Sun, Sep 12, 2010 at 7:42 AM, Simone Tripodi
wrote:
> Hi all guys,
> during my last year of work I've met a replicated behavior in
> different projects, like the
Hi all guys,
during my last year of work I've met a replicated behavior in
different projects, like the classpath analysis. Scanning the
classpath could be useful to dynamically find services implementations
or to generate custom documentation, or some other uses nobody has not
envisioned yet.
Foll
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
Hi all,
I've been getting friendly with the Bean Validation (bval) podling camp of
late, and one of the requirements of implementors of JSR303 is that they
generate annotation instances on the fly. In practice this means proxying
interfaces. It's a foregone conclusion that a JSR303 implement
32 matches
Mail list logo
