Re: ServiceDiscoveryManager lookp specification

ould pass if it returns in the waitDur time window. I think the ms time ranges you've mentioned are more appropriate, they are achievable in practise (I checked). I'll submit a patch for review. Peter. - Original message - > > Hi Peter: > > I'd certa

Re: Questions on the Maven poms...

Thanks for the reminder I'll get it uploaded before River 2.3.0 is released. The library can be found at http://sourceforge.net/projects/custard-apple/?source=directory River 2.2.1, our most recent release, doesn't depend on the library. Regards, Peter. - Original message

Re: svn commit: r1483062 - in /river/jtsk/skunk/surrogate: nbproject/project.properties src/org/apache/river/container/classloading/VirtualFileSystemClassLoader.java

due to erasure. Cheers, Peter. - Original message - > Author: gtrasuk > Date: Wed May 15 20:09:50 2013 > New Revision: 1483062 > > URL: http://svn.apache.org/r1483062 > Log: > Patch VirtualFileSystemClassLoader to work with River 2.2.1 (remove > gener

Re: Help needed - Maven artifacts.

Ditto, Should make publishing artifacts easier from now on. Cheers, Peter. - Original message - > > Awesome!  Thanks, Dennis. > > Greg. > > On Wed, 2013-05-22 at 09:16, Dennis Reedy wrote: > > Issue has been resolved, net.jini 2.2.1 artifacts are now in

Re: Don't export a service from within its contructor

Sounds like a good proposal, River 3.0. Thoughts? Peter. - Original message - > My "startnow" project on java.net, has always provide a "separation" of > construction and start of the service export.  However, the usage of that API > is > supposed to

Re: Dynamic Behavior wrt IOC in services.

Now's a great time to standardise a common subset we can all use, this is a good conversation. We're all solving similar issues, we could have something really great if we can work together. I created com.sun.jini.start.Starter out of necessity to fix unsafe publication, however this could tak

Re: Dynamic Behavior wrt IOC in services.

See inline. Cheers, Peter. - Original message - > > > Further discussion below... > > Cheers, > > Greg. > > On Mon, 2013-05-27 at 16:08, Peter wrote: > > Now's a great time to standardise a common subset we can all use, this > > is a good con

Re: Dynamic Behavior wrt IOC in services.

- Original message - > On 5/27/2013 4:45 PM, Peter wrote: > ... > > For example the last test failure on arm was caused by it. I couldn't > > reproduce it on other architectures, but arm had a high frequency of > > failure. > ... > > Could this be

Re: QA results

Greg, I've forwarded you a copy. Brian's been very helpful running tests on OSX for me. I cc'd the previous email to the list. Regards, Peter. - Original message - > > Bryan: > > I can't find your original email to Peter re these test failures on

Re: Heads-up - Trying out Maven and git for the container.

r files as previously discussed on the list. Perhaps we might have some common use cases? Regards, Peter. - Original message - > Hi all: > > As you know, I've been working for some time on a container for Jini > services.  This work started out as a Surrogate container, but has

Sync / race condition bugs.

of course be appreciated. Regards, Peter.

Help required? Re: Sync / race condition bugs

River rock solid, reliable, predictable and ready for release. Regards, Peter. - Original message - > I was hoping to announce the qa tests were sorted, having just fixed outrigger > (please peer review outrigger changes in skunk/qa-refactor), however an issue > with Reggie has d

Immutable Entry

ation, provided it occurs before sharing with other threads. It would allow Entry's to be shared safely among threads, as long as their public fields aren't mutable, eg: an array. Regards, Peter.

Re: Help required? Re: Sync / race condition bugs

(I've seen them manifest on Windows too), they come back when something unrelated is fixed, they appear to be sensitive to timing. These bugs require a superhero / genius dev. I'm finding this a frustrating long drawn out exercise. Regards, Peter. - Original message - >

Re: Immutable Entry

le to many threads. To avoid potential deadlock from dependant tasks executing out of order JERI always creates a new thread if no free threads are available in its internal thread pool. Regards, Peter. - Original message - > > On Tue, 2013-06-11 at 08:23, Peter wrote: > > I'

Re: Immutable Entry

distributed nodes, one more local copy won't hurt. I'm thinking about a best practices web page for user devs. Regards, Peter. - Original message - > > On Tue, 2013-06-11 at 08:23, Peter wrote: > > I've been thinking about how Entry objects are immutable in

Re: Immutable Entry

e issues is heartening. I did see an Oracle blog post that proposed immutable arrays as a feature in a future Java version. Thanks, Peter. - Original message - > It is very important for us to get this "publish" stuff nailed down so that > there are no problems that

Re: Immutable Entry

use a hand getting this set up, I'm bogged down at present and > don't feel like I'm making much progress.  The positive discussion about these > issues is heartening. > > I did see an Oracle blog post that proposed immutable arrays as a feature in a > future Ja

Re: Immutable Entry

re whether it's just changed timing or is directly influencing it. Please have a look and see what you think: http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/com/sun/jini/outrigger/OperationJournal.java?view=log Regards, Peter. - Original message - > > See com

Re: Fwd: River-QA-windows build leaving zombie JVMs

e I know what's causing the arm test failures, will get back to it later. Be nice to have some help tho. Cheers, Peter. - Original message - > > Original Message > Subject: River-QA-windows build leaving zombie JVMs > Date: Sat, 16 Mar 2013 10:15:26

Re: svn commit: r1511579 - in /river/jtsk/skunk/qa_refactor/trunk/src/net/jini/lookup/entry: Host.java jmx/ jmx/JMXProperty.java jmx/JMXProtocolType.java

Thanks Greg, much appreciated. Peter. - Original message - > Author: gtrasuk > Date: Thu Aug  8 04:24:55 2013 > New Revision: 1511579 > > URL: http://svn.apache.org/r1511579 > Log: > Fix RIVER-423. > Added: >    net.jini.lookup.entry.Host >    net.jin

Re: Thinking about an Apache River release.

(2.3?) branch and talk > about how to go about releasing it.  As I've said before, (speaking just > for me, not as PMC chair) I'm impressed with the amount of work that > Peter has done on concurrency practices, but the manager in me is a > little nervous about the magnitude

Re: River 2.2.2

s with Reggie's implementation regarding mutation, these only come to light are spending hours working through the code. I have considered rewriting Reggie, after an unsuccessful refactoring attempt. Regards, Peter. - Original message - > https://issues.apache.org/jira/browse/RIVER-336?

Re: [Vote] Release Apache River 2.2.2

+1 Peter. - Original message - > > Apache River 2.2.2 is a maintenance release based on the Apache River > 2.2 branch, primarily with fixes that add support for JMX entries and > publish additional artifacts to the Maven repository. > > Release Notes - River - V

Re: River Container (was surrogate container)

violates the Java memory model by exposing the service object to other threads before construction is complete. Regards, Peter. - Original message - > > On Nov 28, 2013, at 244PM, Greg Trasuk wrote: > > > > > On Nov 28, 2013, at 12:59 PM, Dennis Reedy > >

Lambda expressions

I've been looking into lambda expressions, good news folks, they are serializable, so will work with remote services. This will enable new powerfull remote end processing capabilities. It has the capacity to redefine the way services are used. Regards, Peter.

Re: Build failed in Jenkins: river-qa-refactor-arm #90

Anyone looked at the code in the failing test yet? Who can spot the race condition? I'll give you a hint; on this occassion it happens just before the test exception. This bug is a perfect example why it's important to do some housekeeping to reduce our code debt. Chee

River 3.0 beta release candidate

it is advisable that client services adopt new safe construction techniques for services and implement the new Commission interface. What's a suitable test period for client testing? Regards, Peter.

Little known facts about Remote objects

xtinction. The skunk/qa_refactor branch uses safe construction tehniques and export after construction, it's had sweeping changes made internally to classes to significantly improve Java Memory Model compliance. If you haven't checked out this branch, now's the time to do so. Regards, Peter.

Re: River 3.0 beta release candidate

ocess, so it seems to make sense to me at least that the correct approach is to allow an evaluation period. Is it possible for animal sniffer to analyse the public api? Regards, Peter. Maybe it would make sense to > split out the infrastructure services, like Reggie, Mahalo, and > Outrig

Re: River 3.0 beta release candidate

This is a fundamental change to the way services are written. Regards, Peter. - Original message - > > Assuming that there aren’t major incompatibilities, I think that would > be a “minor” version change according to our versioning policy, so we’d > be looking at the “2.3” bra

Re: River 3.0 beta release candidate

I'm happy to accept whatever release version number that the committers decide when that time comes. I think it best to narrow our focus for now on how to proceed with the release process. Regards, Peter. - Original message - > > The way that services are instantiated a

Re: Fw: Re: Jenkins - jtreg test suite

Thanks Jake, I'll set up a test build for it on the weekend. Regards, Peter. - Original message - > Please verify using buildslave "ubuntu1", minerva, with path > $HOME/tools/jtreg/latest/linux/bin/jtreg and jtreg lib path available at > $HOME/tools/jtre

Re: Little known facts about Remote objects

re starting to fail every time, rather than occassionally. Regards, Peter. - Original message - > On 12/17/2013 7:42 AM, Gregg Wonderly wrote: > ... > > As I’ve discussed here before, one of the most destructive > > activities > that has happened in the JDK, has been

Re: Little known facts about Remote objects

ion during any tests with thread dumps, the standard tests probably aren't sufficiently loading the system. Regards, Peter. - Original message - > I don't think you need to assume increased JVM optimization to explain > the phenomenon. It is typical of what happ

Re: Little known facts about Remote objects

Ok, that's definitely worth trying, I don't have suitable hardware right now, so will see if I can pick up something like a T2000. Thanks, Peter. - Original message - > We might be able to get some benefit more portably by writing a Java > program that spawns a spe

Re: River 3.0 beta release candidate

x27;s called after JMM safe construction to allow the service to start any threads and be exported. Regards, Peter. - Original message - > > The way that services are instantiated and setup is an implementation > detail.  When I think of compatibility I think of the API and the lo

Re: River 3.0 beta release candidate

o something similar, yes we can change it to WARN. A much harsher option is to throw an exception during export which breaks backward compatibility. Regards, Peter. - Original message - > "org.apache.river.api.util.Commission is an interface services should > implement&quo

Re: River 3.0 beta release candidate

Hmm, good point, Startable, makes more sense. An object can be exported using Startable. I think we should have a policy to strongly discourage exporting from constructors. Regards, Peter. - Original message - > As far as I can tell, the special properties of completing a construc

Re: River 3.0 beta release candidate

s and exporting. All our services have final fields, so Starter is more appropriate for River's own services. Regards, Peter. - Original message - > Hmm, good point, Startable, makes more sense. > > An object can be exported using Startable. > > I think we should

Re: River 3.0 beta release candidate

So based on this, we should document safe methods for exporting services, log a message using fine and reference the documentation in the message. Peter. - Original message - > Pat your comment about non final fields is interesting. > > Isn't it also the case that we

Re: River 3.0 beta release candidate

thers won't want to use this method, however it would be detrimental if we don't have such a method for those who would. Regards, Peter. - Original message - > > I feel like we’re going down a rabbit hole here when you start talking > about exporting immutable

VOTE: add Startable to Jini specification

+1 Peter. I've been going over the Exporter implementations and Exporter interface. The Exporter interface specifies that export and unexport behaviour is defined by the implementation. That means it's up to the implementation to specify whether a happens before edge occures bef

Re: VOTE: add Startable to Jini specification

Sure: http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/org/apache/river/api/util/Commission.java?view=markup The interface name will be changed to Startable as per list comments below. Regards, Peter. - Original message - > Hi Peter, > > Could you post

Re: [jira] [Commented] (RIVER-432) Jar files in svn and src distributions

have ant retrieve them as needed for jenkins tests until we work out a more permanent solution. Cheers, Peter. - Original message - > > There seems to be some debate about that in the incubator lists.  Some > people seem to think that having jars in Apache’s svn

Re: [jira] [Commented] (RIVER-432) Jar files in svn and src distributions

t; products of anyone in the source distribution (the source release). > > I've no opinion yet on if 'tool' jars belong in a binary distribution. > > Gr. Simon > > On 19-12-13 12:10, Peter wrote: > > Looking at the last paragraph in Sam's email he goes

Re: VOTE: add Startable to Jini specification

nt a public shutdown method for lifecycle management? Closeable would also be acceptable? Is there anything else you need? Regards, Peter. - Original message - > "What we need is a discussion on a more developer-friendly service > startup convention to replace ServiceStarter.&q

Re: VOTE: add Startable to Jini specification

vider Regards, Peter. - Original message - > Hopefully Startable will get enough votes to get across the line, we > need to make progress, if you care about River you'll vote for it, not > because it's the perfect solution, simply because it's an acceptable > solution

Re: VOTE: add Startable to Jini specification

before you go flaming me, food for thought: People can only judge on what they know, they cannot judge upon what they don't, fear the unknown, or learn. Regards, Peter. - Original message - > > I don’t really see a need to mess around with the existing > infrastructure s

Re: VOTE: add Startable to Jini specification

formance, there's plenty more correctness required :) Although I have been guilty of fixing some test hot spots, but not at the expense of correctness. Regards, Peter.

Re: VOTE: add Startable to Jini specification

es did you have in 2003 son? One more vote, c'mon at least one for my sense humour? Dan? No takers? Oh well... Merry Christmas, Peter. > > (c) even where there is an apparent problem, the exposure window is > very small. > > Remember an exposure window can be small

Re: VOTE: add Startable to Jini specification

an, if I didn't find it funny, I probably would have been offended given that he thinks so little of my efforts. Never mind, he won't think so poorly of it after its release. Peter. - Original message - > On 12/19/2013 10:47 PM, Peter wrote: > > - Original message

Re: VOTE: add Startable to Jini specification

Pat, I'd like to invite you back, even if it's just in an advisory capacity. I think we can all benefit from your experience. So far you've managed to explain everything so eloquently, the rest of us look like children fighting over toys. Regards, Peter. - Original messag

Re: VOTE: add Startable to Jini specification

of page and cache line > > boundaries, cannot cause failures. The downside is that it requires > > changes that are not necessarily supported by a failing test case. > > > > My own reading of River code convinced me that it was largely in an > > experimental state, with mult

Re: VOTE: add Startable to Jini specification

You just did. The blue pill. I prefer the truth, it's easier in the long run. Feel free to cast your vote. Peter. - Original message ----- > Peter, > > There's so many things wrong in there, I'm not even going to dignify this > with a response.

Re: VOTE: add Startable to Jini specification

nt it fixed. Patricia, you're much better at communicating the development concepts, can you do me a favour and put forward a vote proposal, it would be beneficial to all parties to come to some decision on the underlying issue. Regards, Peter. - Original message - > I

Re: VOTE: add Startable to Jini specification

is a Strategy 3 item, and is also an > external interface change. > > Patricia > > > On 12/21/2013 3:11 AM, Peter wrote: > > Yes it's a difficult decision, originally when I set out to fix the > > issues I found, I didn't expect to be here today, on one

Re: VOTE: add Startable to Jini specification

No problem, don't beat yourself up about it. - Original message - > > Peter - I apologize.  I had meant to keep my suggestion to cool down > off-list, but it appears that I failed to remove dev@river.apache.org > from the recipients when I replied.  > > Cheers,

Re: VOTE: add Startable to Jini specification

People may also find the following interesting: http://www.azulsystems.com/blog/cliff/2011-10-17-writing-to-final-fields-via-reflection Regards, Peter. - Original message - > > On Dec 20, 2013, at 2:49 PM, Dan Creswell wrote: > > > > BUT > > > > The cr

Re: Build failed in Jenkins: river-qa-refactor-win #34

That proves wait returning early wasn't the problem. - Original message - > See > > Changes: > > [peter_firmstone] After considerable testing using a multi threaded > Executor and Runnable tasks to CAS an AtomicLong to gene

Re: VOTE: add Startable to Jini specification

; I don’t think that there is anyone here that would do such a thing, but > sometimes it happens by mistake.  I.e. what if T2 goes to do something > on the network in the test, accessing a nonexistent DNS server which > stalls it and causes the timing to work out okay?  What if the 3.5 &g

Re: Development Process - Experimental Testing, Theoretical analysis; code auditing and Static Analysis

y experimental driven approach, like someone who's learning to program experiences. It is very good approach for learning... Do you not teach your students how to safely use final fields? > > @Peter - You’re asking the wrong question.  The right question is > whether we should h

Re: TaskManager as an ExecutorService

tation detail in com.sun.* Regards, Peter. - Original message - > > I’d like you to make a reasonable case for why TaskManager needs to be > replaced, requiring changes to many other classes that depend on > TaskManager, rather than stating what the problem is with TaskManager

Re: TaskManager as an ExecutorService

to be rewritten to accommodate this requirement. The result will be correctly ordered execution of tasks, with increased thread & memory consumption as well as significantly reduced throughput. The reduced throughput could also help mask other issues by reducing concurrency. Regards, Peter. -

Re: Development Process - Experimental Testing, Theoretical analysis; code auditing and Static Analysis

I fix this bug, now I have 35 test failures to debug. Regards, Peter. - Original message - > - Original message - > > > > @Patricia - I understand your interpretation, and I think I’ve misled > > you by including the words “concrete, observable” in my qu

Add generics to com.sun.jini.config.Config static methods

Just a nicety to remove boilerplate casts, see my recent commit to qa_refactor, svn revision 1554723 If there are any objections I'll revert this change as it isn't critical. Regards, Peter.

Re: Development Process - Experimental Testing, Theoretical analysis; code auditing and Static Analysis

You have no objections to Theoretical analysis? Now you've had a chance to review the JMM, has it changed your thoughts on Startable? Regards, Peter. - Original message - > > On Jan 4, 2014, at 6:15 PM, Peter wrote: > > > > > > > “we’re using final v

Re: TaskManager as an ExecutorService

claims it makes it possible to have complex chains of asynchronous operations. Regards, Peter. - Original message - > I think the better choice is to not try and handle failure with retry at > all.    Instead, we should use API which allows the dependent task to > know whe

Fixing ServiceDiscoveryManager WAS: Re: TaskManager as an ExecutorService

Guava jar dependency, since Guava doesn't support serialization compatibility across releases. Feel free to propose any alternative suggestions. Please raise any objections to fixing ServiceDiscoveryManager in another thread. Regards, Peter. - Original message - > Gregg, > &

Re: TaskManager as an ExecutorService

ould revolutionize lookup services. I'd be interested in your thoughts, given the issues you've faced with code downloading. Regards, Peter. - Original message - > From the very early days of Jini, I have not had good luck with > ServiceDiscoveryManager.  I actually h

Re: ServiceDiscoveryManager Task Race

ability in SDM's implementation and that's difficult to manage. Cheers, Peter. > > Patricia > > On 1/14/2014 3:32 AM, Peter Firmstone wrote: > > With TaskManager.Task.runAfter, throughput wasn't significant enough > > for this race to occur. > > >

Re: ServiceDiscoveryManager Task Race

tasks. Callbacks can be used to remove tasks from the executing tasks queue after completion, also allowing currently executing tasks to execute another task while taking precedence over pending tasks would address some of the race conditions. Regards, Peter. Regards, Peter. - Original me

Re: [jira] [Commented] (RIVER-432) Jar files in svn and src distributions

This isn't likely to happen too often, but we need to retain the ability to do so if necessary. Regards, Peter. - Original message - > >        [ > https://issues.apache.org/jira/browse/RIVER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focus

Re: [VOTE] Theory based development

o like to encourage the wider community to get involved, share your thoughts and votes, for or against. The outcome, whatever it may be, will provide certainty. Thanks & regards, Peter Firmstone. - Original message - > I am a remote expectator, but +1. > Thanks for all the

Re: [DISCUSS] Was: Re: [VOTE] Theory based development

ease. For that reason, I also reccommend reverting trunk, with the exception of Sim's recent work, which I have peer reviewed. Regards, Peter. - Original message - > Given the number of users on this mailing list, and the tiny number of > votes, it seems that many people

Re: [DISCUSS] Was: Re: [VOTE] Theory based development

pose. The problem with the tests; they've had bug fixes too, so people have trouble trusting them. The section of code you've found in Outrigger is ugly but correct, ideally sync would be the responsibility of resource but in this case it's external. Peter. - Original messag

Re: [DISCUSS] Was: Re: [VOTE] Theory based development

we expect service implementations to be thread safe (remote method invocation is performed via a thread pool), but River doesn't provide an easy way for implementors to use final fields. Services can also use static methods and writeReplace, provided they're not using the starter kit. Pe

Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development

SDM, JoinManager and Reggie. Regards, Peter. - Original message - > > I understand the sentiment, but I’m uncomfortable with the number of > changes that happened without much review between releases.  Run the > following commands: > > svn diff https://svn.apache.

Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development

o the community. Peter. - Original message - > Just to clarify, the reversions fixed problems with merging, they were > unrelated to tests. > > When I fix a failing test, I first confirm it also passes on either > other architectures or after repeated tests, or that changes

Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development

red functionality. > > Yes, there are many changes, I'm currently working on replacing > TaskManager in SDM, JoinManager and Reggie. > > Regards, > > Peter. > > - Original message - > > > > I understand the sentiment, but I’m uncomfortable with t

Qa_refactor - the positives

will never see light of day, you'll be stuck with buggy circa java 1.4 style or earlier code on modern jvm's performing new optimisations that expose these issues in deployed environments. Remember the major argument cited against is, this code has not been peer reviewed. Cheers, Peter.

Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development

I'll just keep squashing bugs... Regards, Peter. - Original message - > +1 > > I'm in agreement with Dennis on this one.  To me it makes sense to move > River forward with a nice big bang "miracle upgrade".  :-)  And adopting > this stuff in as a v3.

P2P Internet Services - no code downloads, lambda's

it should make a huge difference to our userbase, which at present appears limited. Thoughts? Peter.

Re: Proposed River Board Report for Feb 2014

+1 Peter. - Original message - > Hi all: > > The quarterly report to the board is due on Feb 12.    I have attached a > proposed report.  Please forward edits you suggest ASAP. > > Cheers, > > Greg Trasuk. > > —Begin proposed report --- > >

Re: [Vote] (RIVER-432) Jar files in svn and src distributions

+1 Peter. Note that the current build system does not support java 8. Maintaining a build system is a significant burden ( I know I had to implement Java 5 support). We will need a new build system for java 8, this looks like a step in that direction. In reality we need to adopt the build

Re: Build system and Java 8 was: Re: [Vote] (RIVER-432) Jar files in svn and src distributions

riginal message - > > Hi Peter: > > I’m not familiar with Java 8 yet.  How is the current build not > supported? > > Cheers, > > Greg. > > On Feb 11, 2014, at 5:35 AM, Peter wrote: > > > +1 Peter. > > > > Note that the current build sys

Research / experimental branch

Any takers for a research branch to exlpore recent ideas? Was thinking about a subset of Jini, just the essentials, no activation, no JRMP support, forgetting backward compatibility to allow experimentation with new ideas and considering all possibilities. Regards, Peter.

Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging

ed static fields and ProtectionDomain. Dynamic policy grant's are made to ClassLoaders, put implementation classes in the wrong ClassLoader and security is busted. Just my 20 cents. Cheers, Peter. - Original message - > Part of the decision logic for class loader structure involves pr

Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging

onship suffices. Only complex class relationships cause class loading deadlock. Regards, Peter. - Original message - > >        [ > https://issues.apache.org/jira/browse/RIVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908

Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging

- Original message - > Hi Peter, > > I'm not sure we're on the same wavelength here, I've inlined some > comments below. > > Regards > > Dennis > > On Feb 21, 2014, at 553PM, Peter wrote: > > > To minimise the chances o

Re: DiscoveryAdmin, Reggie and Unicast discovery port.

tests. > > Cheers, > > Greg. > > On Feb 21, 2014, at 7:38 PM, Peter Firmstone > wrote: > > > I'm currently getting a number of test failures where a port passed in > > by configuration is already in use.  If the port specified is 0, then > > an

Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging

p codebase server for the new River single archive container standard? Regards, Peter. - Original message - > > On Feb 22, 2014, at 1205AM, Peter wrote: > > > > > > Maven or OSGi can provision for maximum compatibility among > > > > services  and proxy&#

Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging

ve some more time). It was discussed some time ago on > this list mainly with Peter. In our previous discussion, the aim was to determine a way to ensure that no untrusted objects could be deserialised and thus prevent DOS attacks. Because ProxyTrustVerifier checks are performed after deseria

Re: RIVER-423

Can we replicate the original jar file? If we create a modular build, it would help keep this logically separate and people who currently use it will find the class files where expected. Regards, Peter. - Original message - > > They’re not in a separate jar file.  They are jus

Re: RIVER-423

Fair enough. - Original message - > Dnia 2014-02-28, pią o godzinie 12:01 +1000, Peter pisze: > > Can we replicate the original jar file? > > > > If we create a modular build, it would help keep this logically > > separate and people who currently use i

Re: River-436 - need some explanation of preferred class provider

If Util is installed locally, it will only be loaded by the application ClassLoader, since it isn't preferred. Peter. - Original message - > Folks, > while woking on the River-436 patch proposal I've came across the > scenario that I am not sure how to handle: &

Re: River-436 - need some explanation of preferred class provider

y. Cheers, Peter. - Original message - > But it will also be loaded by WrapperProxy ClassLoader, since it is > preferred there. So it will end up with ClassCastException, right? > > Regards, > Michal > > If Util is installed locally, it will only be loaded by the appl

Re: River-436 - need some explanation of preferred class provider

tion ClassLoader for maximum visibility and interoperability, rather than the proxy's child ClassLoader. > Cheers, > > Peter. > > - Original message - > > But it will also be loaded by WrapperProxy ClassLoader, since it is > > preferred there. So it will end u

Re: River-436 - need some explanation of preferred class provider

hat service api cannot be changed after deployment. We could allow Service API to be loaded on demand after deployment, if it doesn't already exist at the client, but again it cannot be changed after deployment, only added to. Cheers, Peter. - Original message - > The re

Re: River-436 - need some explanation of preferred class provider

to ClassLoader issues, I'm all ears, honestly though, ClassLoaders are a Java issue, we do our best to work around them, I'm not aware of a silver bullet. Beware of complex ClassLoader relationships, as these can lead to deadlock. Cheers, Peter. - Original message - > Greg,

  1   2   3   4   5   6   7   8   9   10   >