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

You mean having annotations as objects serialized to a String? This was my first shot on it - the only difference was serialization format ( Base64 encoded binary stream ). While workable it has some drawbacks comparing to just serializing annotations to the object stream as is. Regards, Michal 26

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

Just thinking out loud, It would not be that difficult for the service classloader to return the annotation string in the form of a serialized JSON representation of the annotation provider. That way a client simply needs to recreate that annotation provider using JSON on it's end. Regards Dennis

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

In my PoC there is actually only one implementation based on RMI code downloading ( IOW RmiAnnotation has a list of URLs ). But even that enables us to get rid of httmd url handler since RmiAnnotation is verified by ProxyTrustVerifier - one thing less to remember when configuring the client :-D

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

Of course it is annotated :-) There needs to be a common "bootstrap" implementation available. I've called it RmiAnnotation that just uses a default PreferredClassProvider logic (the devil's in the details - but all is in my PoC :-) ) Regards, Michal W dniu 2014-02-25 21:27, Greg Trasuk pisz

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

How do you get the code that implements that object? Greg Trasuk On Feb 25, 2014, at 3:09 PM, Michal Kleczek wrote: >> This. I like this. How would this work, would it be an Entry, an attribute >> of the service (perhaps similar to the ServiceUI factory?). > > My PoC is attached to one of the

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

Dnia 2014-02-25, wto o godzinie 18:36 +0100, Michal Kleczek pisze: > Hmm... I don't think it is an implementation detail - codebase > annotations must be understood by every client - so the format becomes a > part of the spec. > > For example Maven based naming > (groupId:artifactId:version:cla

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

This. I like this. How would this work, would it be an Entry, an attribute of the service (perhaps similar to the ServiceUI factory?). My PoC is attached to one of the issues in Jira (I'll try to find it tomorrow once I have some more time). It was discussed some time ago on this list mainly w

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

On Feb 25, 2014, at 12:18 PM, Dennis Reedy wrote: > On Tue, Feb 25, 2014 at 12:36 PM, Michal Kleczek > wrote: > >> Hmm... I don't think it is an implementation detail - codebase annotations >> must be understood by every client - so the format becomes a part of the >> spec. >> > > Fair enoug

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

On Tue, Feb 25, 2014 at 12:36 PM, Michal Kleczek wrote: > Hmm... I don't think it is an implementation detail - codebase annotations > must be understood by every client - so the format becomes a part of the > spec. > Fair enough, it does need to be part of a specification. > > For example Mave

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

Hmm... I don't think it is an implementation detail - codebase annotations must be understood by every client - so the format becomes a part of the spec. For example Maven based naming (groupId:artifactId:version:classifier:version) is incompatible with Eclipse p2 (MANIFEST.MF OSGI metadata -

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

Michal, I agree on not standardizing on Maven (or OBR) at this point. I don't understand why you are against Maven based provisioning (Aether), its really an implementation detail. My question is really whether River should support the notion of artifacts (retrievable from some sort of repository

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

Guys, I don't think River should standardize or promote Maven based provisioning. Depending on environment there are different ways of doing it. Eclipse p2 or OBR in OSGI for example. Regards, Michal W dniu 2014-02-25 10:04, Peter pisze: So Aether standardises obtaining codebases from reposi

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

Sent from my iPhone > On Feb 25, 2014, at 4:04 AM, Peter wrote: > > So Aether standardises obtaining codebases from repository's, and there is no > dependency on Maven. It also appears to solve some big security issues. > > So this begs the question, shouldn't River be adopting this approac

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

I think switching to a different codebase provisioning method is out-of-scope for this specification. Greg Trasuk On Feb 25, 2014, at 4:04 AM, Peter wrote: > So Aether standardises obtaining codebases from repository's, and there is no > dependency on Maven. It also appears to solve some bi

Build failed in Jenkins: river-qa-refactor-solaris #29

See Changes: [peter_firmstone] System property for Reggie, ensure it is actually visible to tests. Also ensure that if property is not set that Reggie throws the correct Exception, BindException during construction and not Nu

Build failed in Jenkins: river-qa-refactor-win5 #7

See -- Started by user peter_firmstone Building remotely on windows1 in workspace Cleaning local Directory trunk java.io.IOException: remote

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

So Aether standardises obtaining codebases from repository's, and there is no dependency on Maven. It also appears to solve some big security issues. So this begs the question, shouldn't River be adopting this approach? Is it possible to use a repository, in place of the old http codebase serve