On 10-11-12 00:07, Peter Firmstone wrote:
tried developing experimental code directly in trunk unsuccessfully. I
think we need to clarify our development processes.
Lightweight.
Only commit code that compiles.
(s)he who breaks the build fixes the build. idem testing.
No jumbo patches. No ju
Simon IJskes - QCG wrote:
On 09-11-12 13:48, Peter Firmstone wrote:
Simon IJskes - QCG wrote:
On 09-11-12 00:31, Peter Firmstone wrote:
Ok, because it's small I think we can consider it, can you provide the
hooks to load different providers? The non default providers
themselves
can be a subp
Simon IJskes - QCG wrote:
On 09-11-12 13:49, Peter Firmstone wrote:
Simon IJskes - QCG wrote:
On 09-11-12 11:44, Peter Firmstone wrote:
Motivated by Sim's suggestions:
Any objection to changing it to net.jini.io.MarshalClassResolverSPI?
Leave it near net.jini.loader.ClassLoading. I would ha
On 09-11-12 13:48, Peter Firmstone wrote:
Simon IJskes - QCG wrote:
On 09-11-12 00:31, Peter Firmstone wrote:
Ok, because it's small I think we can consider it, can you provide the
hooks to load different providers? The non default providers themselves
can be a subproject. We need to carefull
On 09-11-12 13:49, Peter Firmstone wrote:
Simon IJskes - QCG wrote:
On 09-11-12 11:44, Peter Firmstone wrote:
Motivated by Sim's suggestions:
Any objection to changing it to net.jini.io.MarshalClassResolverSPI?
Leave it near net.jini.loader.ClassLoading. I would have implemented
it in ClassL
Simon IJskes - QCG wrote:
On 09-11-12 11:44, Peter Firmstone wrote:
Motivated by Sim's suggestions:
Any objection to changing it to net.jini.io.MarshalClassResolverSPI?
Leave it near net.jini.loader.ClassLoading. I would have implemented
it in ClassLoading if i wasn't concerned about leaving
Simon IJskes - QCG wrote:
On 09-11-12 00:31, Peter Firmstone wrote:
Ok, because it's small I think we can consider it, can you provide the
hooks to load different providers? The non default providers themselves
can be a subproject. We need to carefully consider security since we're
making it p
Dan Creswell wrote:
One thing...
On 9 November 2012 10:44, Peter Firmstone wrote:
Motivated by Sim's suggestions:
Any objection to changing it to net.jini.io.**MarshalClassResolverSPI?
This places it right where it's needed.
Since all URI in a code base string will reside in one ClassLo
On 09-11-12 11:44, Peter Firmstone wrote:
Motivated by Sim's suggestions:
Any objection to changing it to net.jini.io.MarshalClassResolverSPI?
Leave it near net.jini.loader.ClassLoading. I would have implemented it
in ClassLoading if i wasn't concerned about leaving mature classes
untouched.
One thing...
On 9 November 2012 10:44, Peter Firmstone wrote:
> Motivated by Sim's suggestions:
>
> Any objection to changing it to net.jini.io.**MarshalClassResolverSPI?
>
> This places it right where it's needed.
>
> Since all URI in a code base string will reside in one ClassLoader, all
> cla
Motivated by Sim's suggestions:
Any objection to changing it to net.jini.io.MarshalClassResolverSPI?
This places it right where it's needed.
Since all URI in a code base string will reside in one ClassLoader, all
classes in that ClassLoader must use the same provider. For instance an
osgi:,
On 09-11-12 00:31, Peter Firmstone wrote:
Ok, because it's small I think we can consider it, can you provide the
hooks to load different providers? The non default providers themselves
can be a subproject. We need to carefully consider security since we're
making it possible for downloaded code
Simon IJskes - QCG wrote:
On 08-11-12 13:40, Peter Firmstone wrote:
Yes, but lets play around with it in skunk. Dan's made some valid
Indeed Dan has made valid remarks, but i really dont like skunk. Tom
suggested sub projects once. I did not see any benefits at that time.
But i think it mi
You are probably aiming at a scheme based dispatching of classloader URI.
Cool feature! Shall we put this in an implementation of RiverClassLoaderSpi?
i meant, deriving, extending.
I like the sub-projects idea.
Greg.
Jini Technology Starter Kit - Our current deliverable.
On Thu, 2012-11-08 at 08:12, Simon IJskes - QCG wrote:
> On 08-11-12 13:40, Peter Firmstone wrote:
>
> > Yes, but lets play around with it in skunk. Dan's made some valid
>
> Indeed Dan has made valid
ed environment?
>>>
>>
>> You are probably aiming at a scheme based dispatching of classloader URI.
>> Cool feature! Shall we put this in an implementation of RiverClassLoaderSpi?
>>
>> schemes like: maven:, system:, http:, codeservice: spring to mind.
>>
>&
On 8 November 2012 13:12, Simon IJskes - QCG wrote:
> On 08-11-12 13:40, Peter Firmstone wrote:
>
> Yes, but lets play around with it in skunk. Dan's made some valid
>>
>
> Indeed Dan has made valid remarks, but i really dont like skunk. Tom
> suggested sub projects once. I did not see any bene
On 08-11-12 13:40, Peter Firmstone wrote:
Yes, but lets play around with it in skunk. Dan's made some valid
Indeed Dan has made valid remarks, but i really dont like skunk. Tom
suggested sub projects once. I did not see any benefits at that time.
But i think it might be helpful right now.
feature! Shall we put this in an implementation of
RiverClassLoaderSpi?
schemes like: maven:, system:, http:, codeservice: spring to mind.
Yes, but lets play around with it in skunk. Dan's made some valid
points, I think we should use the simple implementation for now that
solves the imme
On 08-11-12 12:19, Dan Creswell wrote:
I don't want to be harsh but as a group we seemingly spend a lot of time
thinking about all sorts of cool things we could do given we've already
done this or that other thing.
How about we do a few small steps in some promising (like valuable to our
commun
implementation of
RiverClassLoaderSpi?
schemes like: maven:, system:, http:, codeservice: spring to mind.
On 8 November 2012 10:51, Peter Firmstone wrote:
> I've been quite busy lately so haven't been able to contribute much to
> discussion.
>
> However I've some thoughts on RMIClassLoaderSPI / RiverClassLoaderSPI /
> CodebaseAccessClassLoader and finally ha
I've been quite busy lately so haven't been able to contribute much to
discussion.
However I've some thoughts on RMIClassLoaderSPI / RiverClassLoaderSPI /
CodebaseAccessClassLoader and finally had some time to write them down.
Notably RiverClassLoaderSPI solves t
On 10/27/2012 3:31 AM, Simon IJskes - QCG wrote:
On 26-10-12 23:49, Gregg Wonderly wrote:
I wonder if Peter pulled it out when some of the other stuff he was
pushing into the build created some problems late last year? Humm,
it should be in there.
I will take a look at it.
I've taken a short
- Original message -
> The problem with RMIClassLoaderSPI is that you can't replace it's
> implementation
> except through the use of command line property values. This is not a
> workable
> solution for many different reasons in many different environments. So, just
> putting in Codeb
On 26-10-12 23:49, Gregg Wonderly wrote:
I wonder if Peter pulled it out when some of the other stuff he was
pushing into the build created some problems late last year? Humm,
it should be in there.
I will take a look at it.
I've taken a shortcut, and reduced the impact a little bit. Is a Sp
On 26-10-12 23:49, Gregg Wonderly wrote:
The problem with RMIClassLoaderSPI is that you can't replace it's
implementation except through the use of command line property
values. This is not a workable solution for many different reasons
in many different environments. So, just putting in
Codeba
The problem with RMIClassLoaderSPI is that you can't replace it's
implementation except through the use of command line property values. This is
not a workable solution for many different reasons in many different
environments. So, just putting in CodebaseAccessClassLoader as it sits, should
On 26-10-12 17:41, Gregg Wonderly wrote:
I believe the patches shown there have been put in place now have
they not? Peter was working on this a while back, and I thought that
I'm not sure. Could you check? I've in the mean time implemented the
Spi, and it works for me. I was bitten by the ex
I believe the patches shown there have been put in place now have they not?
Peter was working on this a while back, and I thought that as least one person
had put the changes into place for his private code base so that he could now
trivially integrate with a JavaEE container.
What I did was a
On 26-10-12 01:07, Simon IJskes - QCG wrote:
On 26-10-12 00:56, Greg Trasuk wrote:
Isn't there already java.rmi.server.RMIClassLoaderSpi that
net.jini.loader.pref.PreferredClassProvider implements? What would a
River-specific provider interface add?
RMIClassLoaderSpi is used for instance in
On 26-10-12 00:56, Greg Trasuk wrote:
Isn't there already java.rmi.server.RMIClassLoaderSpi that
net.jini.loader.pref.PreferredClassProvider implements? What would a
River-specific provider interface add?
RMIClassLoaderSpi is used for instance in java webstart (javafx) to
initialize if with
Isn't there already java.rmi.server.RMIClassLoaderSpi that
net.jini.loader.pref.PreferredClassProvider implements? What would a
River-specific provider interface add?
Cheers,
Greg.
On Thu, 2012-10-25 at 18:36, Simon IJskes - QCG wrote:
> Anybody objects, is interested in a RiverClassL
Anybody objects, is interested in a RiverClassLoaderSpi that makes it
possible to intercept calls to the RMIClassLoader ?
34 matches
Mail list logo
