Re: classserver.jar refusing connection

[Niclas Hedhman]

- phoenix.config --
> ---
>
> // a JRMP configuration with no access control
> import org.apache.river.phoenix.*;
> import net.jini.jrmp.JrmpExporter;
> import java.rmi.activation.ActivationSystem;
>
> org.apache.river.phoenix {
> registryPort = ActivationSystem.SYSTEM_PORT;
> registryExporter = new RegistrySunExporter(registryPort);
> activatorExporter = new ActivatorSunJrmpExporter(registryPort);
> systemExporter = new SunJrmpExporter(4, registryPort);
> monitorExporter = new JrmpExporter(registryPort);
> instantiatorExporter = null;
> persistenceDirectory = "log";
> }
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: OSGi - deserialization remote invocation strategy

[Niclas Hedhman]

n't be loaded via the smart proxy bundle
> and it's package imports, except for the odd handback, which the
> client bundle should have the opportunity to resolve before
> resorting to using an annotation.

Sorry, I don't understand this statement.

> I'm not quite ready to agree it's too complex and it's unsolveable, I
> think we should at least explore it and understand it before we junk
> the idea of supporting OSGi.

If we are talking osgi<->osgi, I think there is reasonable chance to
succeed.

> Rather than utilise the Java2 class  loading I was planning to cast
> ClassLoaders to BundleReference where appropriate and utilise
> the Bundle.

My gut says that this is not needed, if you go with my initial proposal. A
Jini support bundle ends up having access to the BundleContext, from where
everything else can be reached.

> I did notice you're interpretation  of what I've written is different than
> mine, so I think I need to put some effort into communicating more
> effectively.  I think you're interpretation  of codebase annotation
> "version is fixed" ignores that the annotation is only consulted after
> determining that the current class is not available in our Bundles
> currently participating in deserialization.   It doesn't apply to resolved
> imported packages as annotations aren't used for them at all.

OR, I have been burned in class resolution in OSGi enough times to have a
feeling that it is more difficult than it seems. Any simple example I can
think of would work...

> For example, the first class we attempt to resolve during unmarshalling
> belongs to a smart proxy, the client Bundle can't find the class. Ask the
> framework to load the proxy bundle from the codebase annotation, it
> does so and resolves all necessary package imports declared in its
> manifest.  We now continue deserializing the smart proxy class fields
> with the visibility of the smart proxy's bundle.  The smart proxy may
> contain fields referencing objects resolved from its imports, we ensure
> those classes deserialize their fields with the visibility of their own
bundles.

So, the smart proxy's "bundle" is a bundle on the server side as well? The
smart proxy may also contain objects that are of a class that is not
visible... And it may be N levels deep from the "field" in the smart proxy.

> Every time we can't  resolve a class we first check if it's a handback
> or parameter from a preceeding object in the graph, thus we walk
> our graphs bundle stack.

This is probably the bit I don't understand at all. On one hand you want to
depend on OSGi framework to do the resolution, but OTOH you have something
called a "bundle stack"? What is that?

> If we still haven't resolved a class only then do we load a bundle from
> it's codebase annotation url and check it can be cast to the field
> before assigning it.  If it can't be cast to that field, we throw an
exception.

"assigning it"?  Doesn't the code in reality looks something like;

private Map map;

private void readObject( ObjectInputStream in ) {
map = (Map) in.readObject();
}

where the read object may be of a class not visible to neither the smart
proxy's classloader nor any helper? Maybe you meant that it will implicitly
thrown just by the above code.


> In the case of a non smart proxy, there is no codebase, deserialization
> will be loaded by and  rely completely on the visibility of the client
bundle.
>
> I think OSGi will be a lot less dependant on annotations than say a std
env.

Possibly... I think that largely depend on the usecase.

> Still I guess wiring may be an an option, so as Michael suggests,
annotate objects with their wiring graphs.

Ok, here is what I see being the issue at hand; you think that it is
possible to delay the bundle resolution of packages until deserialization
itself. I think that is not possible. There is a need to bring all
"non-available classes" into the client (and I think as a bundle is the
correct solution). So, pick up the bundle reference of the smart proxy, and
the bundle wiring graph of it. When the smart proxy arrives on the client,
before doing anything else, load the bundles on the client. After that, it
should be a "local JVM" problem, both to deserialize the smart proxy as
well as every object communicated over the network.

> What would we be considering if we hadn't been pre exposed to codebase
annotations?
> Standard deserialization uses one classpath, each bundle has its own
unique classpath.

It is not only about classpath. It is about class space and visibility as
well. And serialization needs to bypass visibility, just like it bypassed
other constraints before (such as bypassing constructors and initializing
final fields), and that is a separate issue than the bundle loading
mechanism.


Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: OSGi - deserialization remote invocation strategy

[Niclas Hedhman]

; 6.No attempt will be made to directly load from wired bundles, always
> rely on wires,
> otherwise we may utilise an incompatible package / bundle.
>
> Do we need a graph of the wiring from the remote end?
> During serialization (from the remote end) do we need to determine if a
> bundle has dependants and send some sort of version range information?
> When a class descriptor is read in from a stream, the class descriptor
> contains information
> about fields and it's serializable supertype class (if it exists)
> are also read in from the stream, before any field objects are read in,
> the declared field types
> are visible from the bundle of the current object being deserialized.  The
> objects that will be
> assigned to those field types must also resolve to those types.  Hence
> bundles being resolved as part
> of deserialization must favour already resolved packages for imports.
> What if a bundle requires a specific package version?  This is why the
> bundle must be given first
> attempt to resolve an objects class and rely on the bundle dependency
> resolution process.
> OSGi must be allowed to wire up dependencies, we must avoid attempting to
> make decisions about
> compatibility and use the current bundle wires instead (our stack).
>
> The BundleReference stack is designed to follow the wires (dependency
> links between bundles),
> to allow private classes to be resolved, as they're not visible from other
> bundles.
>
> We can't rely on annotations to resolve private classes, because we can't
> predict the way bundle
> dependency's are resolved in remote JVM's.
>
> General recommendations for OSGi:
> *The service should use as wide a version range as possible for
> service api.
> *It is better to create new service api in a new bundle than to evolve
> in a backward compatible manner, as
> an incremental change may not be compatible if additional classes and
> methods are missing
> from the client, that the service proxy depends on.
> *Don't split packages.
> *Private implementation classes are ok, provided they remain within
> public exported classes and don't escape, otherwise
> they may not link up properly upon deserialization.
> *The proxy should minimise the package imports it uses.
> *There must be only one compatible service api version installed
> already in the client.
> *Duplicates of incompatible versions of service api are ok.
>
> The catch is, it may not be possible to build the bundle stack without
> some programming hooks in ObjectInputStream.
>
> Unfortunately we don't have any control over OIS, the necessary hooks
> could however be added to AtomicMarshalInputStream.
>
> Cheers,
>
> Peter.
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: OSGi

[Niclas Hedhman]

Cool about the ModBus - I originated in that space, have done some smaller
work on ModBus itself, and know exactly what you are talking about. (Once I
had the ability to read 8o1 serial data from digital (meant could store a
waveform) oscilloscopes... bit 0 to the right, 1 is low... without much
trouble).

And I agree with what you say... Inexperience is damaging, and combined
with "no constraints" it is devastating. But my view is that the main
problems when it comes to adoption is two-fold;

a) Multi-platform is a big deal, except for highly specialized shops, you
can't escape this, and it is fueled by every opinion-maker out there.

b) Designing for distributed sharing is difficult, and when code and data
is "the same thing" (unlike your ModBus example) the "difficult" part
escalates quickly. When Java code implementation details (say order of
ooi.readObject() in one type) becomes the only "documented" form of the
protocol (face it, that is what happened almost always), I can't blame
architects and other decision-makers when they say "Nah, don't think so.".
And, most people speak of these things in "abstracts" instead of concrete
use-cases, which makes it impossible to argue in favor of something that
has been berated by opinion-makers (back to point a)

So, what do I do nowadays; Well, I am currently working on larger systems
and there I am firmly in the HATEOAS camp, trying to stay true to
Fielding's intents (constraints, resources,...) when describing REST soon 2
decades ago. Even hear the "script kiddies" are complaining that it is too
hard, and go with a RPC-over-HTTP-with-JSON instead.

Cheers
Niclas

On Sun, Feb 5, 2017 at 2:35 AM, Gregg Wonderly <ge...@cox.net> wrote:

>
> > On Feb 4, 2017, at 3:37 AM, Niclas Hedhman <nic...@hedhman.org> wrote:
> >
> > Gregg,
> > I know that you can manage to "evolve" the binary format if you are
> > incredibly careful and not make mistakes. BUT, that seems really hard,
> > since EVEN Sun/Oracle state that using Serilazation for "long live
> objects"
> > are highly discouraged. THAT is a sign that it is not nearly as easy as
> you
> > make it sound to be, and it is definitely different from XML/JSON as once
> > the working codebase is lost (i.e. either literally lost (yes, I have
> been
> > involved trying to restore that), or modified so much that compatibility
> > broke, which happens when serialization is not the primary focus of a
> > project) then you are pretty much screwed forever, unlike XML/JSON.
>
> I think that there is some realistic issues as you describe here.
> Certainly if the XML or JSON can be “read”, you can get some of the data
> out of it.  Java Serialization or any binary structure requires more
> knowledge to extra the “data” from.  I am not going to really argue that
> point other than to say that for sure, you have to understand the
> implications of this failure mode and do the right things up front so that
> you do have documentation, a documented serial version id plan etc.  Not
> impossible, but indeed additional “work”.
>
> >
> > Now, you may say, that is for "long lived serialized states" but we are
> > dealing with "short lived" ones. However, in today's architectures and
> > platforms, almost no organization manages to keep all parts of a system
> > synchronized when it comes to versioning. Different parts of a system is
> > upgraded at different rates. And this is essentially the same as "long
> > lived objects" ---  "uh this was serialized using LibA 1.1, LibB 2.3 and
> > JRE 1.4, and we are now at LibA 4.6, LibB 3.1 and Java 8", do you see the
> > similarity? If not, then I will not be able to convince you. If you do,
> > then ask "why did Sun/Oracle state that long-lived objects with Java
> > Serialization was a bad idea?", or were they also clueless on how to do
> it
> > right, which seems to be your actual argument.
>
> My actual argument is that “data” is “data”.  It doesn’t matter how it’s
> “structured”.  The only thing that JSON or XML has on “binary” is that you
> can “look” at it with your eyes and feel more comfortable with what you
> see.  If I typed the following two sets of byte sequences at you, what
> could you tell me about them?
>
> 00 01 00 00 00 06 01 03 00 00 00 02
> 00 01 00 00 00 06 01 04 42 28 00 00
>
> In the right context, you could tell me that this is a ModbusTCP request
> for two holding registers, 40001 and 40002.  Further, you’d look at the
> reply packet and say, it looks like the returned two registers are a
> floating point number because the first byte is 42.  Further, you could
> tell me that the float point num

Re: Serialization issues

[Niclas Hedhman]

Ok, but assuming that you are not talking about GB-sized object graphs, it
is more an issue with RMI than Serialization, because you can create
non-blocking I/O "on top", just like Jetty has non-blocking I/O "on top" of
the equally blocking Servlet API. Right? I assume that there is a similar
thing in Tomcat, because AFAIK Google AppEngine runs on Tomcat
It is not required (even it is) that the ObjectOutputStream is directly
connected to the underlying OS file descriptor. I am pretty sure that it
would be a mistake trying to re-design all software that writes to a stream
to have a non-blocking design.

Additionally, while looking into this, I came across
https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/index.html,
which might be to your interest. Not totally relevant, but still an
interesting read.

Cheers

On Sun, Feb 5, 2017 at 2:04 AM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:

> You do not have to do any IO in readObject/writeObject.
>
> The fact that you have readObject/writeObject methods means that you are
> forced to do blocking IO.
> It is simple:
>
> readObject(...) {
>   ois.defaultReadObject();
>   //the above line MUST be blocking because
>   verifyMyState();
>   //this line expects the data to be read
> }
>
> Siilarly:
>
> writeObject(ObjectOutputStream oos) {
>   oos.writeInt(whateverField);
>   //buffers full? You need to block, sorry
>   oos.writeObject(...)
>
> }
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
> I am asking what Network I/O you are doing in the readObject/writeObject
> methods. Because to me I can't figure out any use-case where that is a
> problem...
>
> On Sun, Feb 5, 2017 at 1:14 AM, "Michał Kłeczek (XPro Sp. z o. o.)" 
> <michal.klec...@xpro.biz> wrote:
>
>
> Don't know about other serialization uses but my issue with it is that it
> precludes using it in non-blocking IO.
> Sorry if I haven't been clear enough.
>
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
> And what I/O (network I/O I presume) are you doing during the serialization
> (without RMI)?
>
> On Sun, Feb 5, 2017 at 12:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)" 
> <michal.klec...@xpro.biz> <michal.klec...@xpro.biz>
>  wrote:
>
>
> It is not possible to do non-blocking as in "non blocking IO" - meaning -
> threads do not block on IO operations.
> Just google "C10K problem"
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
> I don't follow. What does readObject/writeObject got to do with blocking or
> not? You could spin up executors to do the work in parallel if you so wish.
> And why is "something else" less blocking? And what are you doing that is
> "blocking" since the "work" is (or should be) CPU only, there is limited
> (still) opportunity to do that non-blocking (whatever that would mean in
> CPU-only circumstance). Feel free to elaborate... I am curious.
>
>
>
> On Sat, Feb 4, 2017 at 8:38 PM, "Michał Kłeczek (XPro Sp. z o. o.)" 
> <michal.klec...@xpro.biz> <michal.klec...@xpro.biz> <michal.klec...@xpro.biz> 
> <michal.klec...@xpro.biz>
>  wrote:
>
>
> Unfortunately due to "writeObject" and "readObject" methods that have to
> be handled (to comply with the spec) - it is not possible to
> serialize/deserialize in a non-blocking fashion.
> So yes... - it is serialization per se.
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
> Oh, well that is not "Serialization" per se... No wonder i didn't get it.
>
> On Sat, Feb 4, 2017 at 7:20 PM, Peter <j...@zeus.net.au> <j...@zeus.net.au> 
> <j...@zeus.net.au> <j...@zeus.net.au> <j...@zeus.net.au> <j...@zeus.net.au> 
> <j...@zeus.net.au> <j...@zeus.net.au> <j...@zeus.net.au> <j...@zeus.net.au> 
> <j...@zeus.net.au> <j...@zeus.net.au> <j...@zeus.net.au> <j...@zeus.net.au> 
> <j...@zeus.net.au> <j...@zeus.net.au> wrote:
>
>
> On 4/02/2017 9:09 PM, Niclas Hedhman wrote:
>
>
> but rather with the APIs - it is inherently blocking by design.
>
> I am not sure I understand what you mean by that.
>
>
>
> He means the client thread that makes the remote call blocks waiting for
> the remote end to process the request and respond.
>
> Cheers,
>
> Peter.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: Serialization Formats, Previously: OSGi

[Niclas Hedhman]

Thumbs Up! Agree...

On Sun, Feb 5, 2017 at 1:33 AM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:

> I cannot disagree with rants about software industry state.
>
> Let's get back to technical solutions to non-technical problems. I am
> interested in providing tools - whether will be used... is a different
> story.
>
> That said...
> IMHO Jini - in all its greatness - DID NOT solve the problem of Java code
> mobility in any way.
> As has been discussed on this list several time the way how it "solved" it
> is:
> - inherently insecure (because object validation is done _after_ code
> execution)
> - is not capable of transferring complicated object graphs - hence it
> cannot be used in many different interesting scenarios.
>
> Partial solutions are worse than lack of solutions - they confuse users
> (in our case programmers) and in the end people loose interest.
>
> I am not a big fan of Java containers - be it JEE or any other (OSGI
> included)
> The industry seems to understand they are a dead end - escpecially in the
> age of Docker etc - and is moving away from them (not that in a very
> meaningful direction :) ).
>
> I have worked with OSGI for several years and it was a difficult
> relationship :)
> Today I prefer simpler solutions: "java -jar 
> my-very-complicated-and-important-service.jar"
> is the way to go.
>
> Thanks,
> Michal
>
>
>
> Niclas Hedhman wrote:
>
> (I think wrong thread, so to please Peter, I copied it all into here)
>
> Correct, it is not different. But you are missing the point; CONSTRAINTS.
> And without constraints, developers are capable of doing these good deeds
> (such as your example) and many very poor ones. The knife cuts your meat or
> butcher your neighbor... It is all about the constraints, something that
> few developers are willing to admit that makes our work better.
>
> As for the "leasable and you have..."; The problem is that you are probably
> wrong on that front too, like the OSGi community have learned the hard way.
> There are too many ways software entangle classloading. All kinds of shit
> "registers itself" in the bowels of the runtime, such as with the
> DriverManager, Loggers, URLHandlers or PermGenSpace (might be gone in Java
> 8). Then add 100s of common libraries that also does a poor job in
> releasing "permanent" resources/instances/classes... The stain sticks, but
> the smell is weak, so often we can't tell other than memory leak during
> class updates.
> And why do we have all this mess? IMHO; Lack of constraints, lack of
> lifecycle management in "everything Java" (and most languages) and lack of
> discipline (something Gregg has, and I plus 5 million other Java devs don't
> have). OSGi is not as successful as it "should" (SpringSource gave up)
> because it makes the "stain" stink really badly. OSGi introduces
> constraints and fails spectacular when we try to break or circumvent them.
>
> River as it currently stands has "solved" Java code mobility, Java leases,
> dynamic service registry with query capabilities and much more. But as with
> a lot of good technology, the masses don't buy it. The ignorant masses are
> now in Peter Deutsch's Fallacies of Distributed Computing territory,
> thinking that microservices on JAX-RS is going to save the day (it isn't, I
> am rescuing a project out of it now).
> Distributed OSGi tried to solve this problem, and AFAICT has serious
> problems to work reliably in production environments. What do I learn? This
> is hard, but every 5 years we double in numbers, so half the developer
> population is inexperienced and repeat the same mistakes again and again.
>
> Sorry for highlighting problems, mostly psychological/philosophical rather
> than technological. I don't have the answers, other than; Without
> Constraints Technology Fails. And the better the constraints are defined,
> the better likelihood that it can succeed.
>
>
>
>
> On Sat, Feb 4, 2017 at 8:59 PM, "Michał Kłeczek (XPro Sp. z o. o.)" 
> <michal.klec...@xpro.biz> wrote:
>
>
> Comments below.
>
> Niclas Hedhman wrote:
>
> see below
>
> On Sat, Feb 4, 2017 at 6:21 PM, "Michał Kłeczek (XPro Sp. z o. o.)" 
> <michal.klec...@xpro.biz> <michal.klec...@xpro.biz> wrote:
>
> Once you transfer the code with your data - the issue of code version
>
> synchronization disappears, doesn't it?
>
> It also makes the wire data format irrelevant. At least for "short lived
>
> serialized states".
>
> Only works if you have no exchange with the environment it is executing.
> And t

Re: Serialization issues

[Niclas Hedhman]

I am asking what Network I/O you are doing in the readObject/writeObject
methods. Because to me I can't figure out any use-case where that is a
problem...

On Sun, Feb 5, 2017 at 1:14 AM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:

> Don't know about other serialization uses but my issue with it is that it
> precludes using it in non-blocking IO.
> Sorry if I haven't been clear enough.
>
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
> And what I/O (network I/O I presume) are you doing during the serialization
> (without RMI)?
>
> On Sun, Feb 5, 2017 at 12:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)" 
> <michal.klec...@xpro.biz> wrote:
>
>
> It is not possible to do non-blocking as in "non blocking IO" - meaning -
> threads do not block on IO operations.
> Just google "C10K problem"
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
> I don't follow. What does readObject/writeObject got to do with blocking or
> not? You could spin up executors to do the work in parallel if you so wish.
> And why is "something else" less blocking? And what are you doing that is
> "blocking" since the "work" is (or should be) CPU only, there is limited
> (still) opportunity to do that non-blocking (whatever that would mean in
> CPU-only circumstance). Feel free to elaborate... I am curious.
>
>
>
> On Sat, Feb 4, 2017 at 8:38 PM, "Michał Kłeczek (XPro Sp. z o. o.)" 
> <michal.klec...@xpro.biz> <michal.klec...@xpro.biz>
>  wrote:
>
>
> Unfortunately due to "writeObject" and "readObject" methods that have to
> be handled (to comply with the spec) - it is not possible to
> serialize/deserialize in a non-blocking fashion.
> So yes... - it is serialization per se.
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
> Oh, well that is not "Serialization" per se... No wonder i didn't get it.
>
> On Sat, Feb 4, 2017 at 7:20 PM, Peter <j...@zeus.net.au> <j...@zeus.net.au> 
> <j...@zeus.net.au> <j...@zeus.net.au> <j...@zeus.net.au> <j...@zeus.net.au> 
> <j...@zeus.net.au> <j...@zeus.net.au> wrote:
>
>
> On 4/02/2017 9:09 PM, Niclas Hedhman wrote:
>
>
> but rather with the APIs - it is inherently blocking by design.
>
> I am not sure I understand what you mean by that.
>
>
>
> He means the client thread that makes the remote call blocks waiting for
> the remote end to process the request and respond.
>
> Cheers,
>
> Peter.
>
>
>
>
>
>
>
>
>
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: OSGi

[Niclas Hedhman]

On Sun, Feb 5, 2017 at 1:23 AM, Gregg Wonderly <ge...@cox.net> wrote:
> Okay, rant completed.

Gregg, you are probably right about the web, endless problems and sheer
will-power has made it to apparently work.


> What other details of Jini vs the Web are problem areas
> to you?  What makes the “web” better than Jini as a mobile
> code platform?  The “browser” is a platform.  The notions of
> serviceUI were developed to create a “browser” like platform
> as a starting point for services to export a complete client
> experience as a web page is today.  Are you using
> ServiceUI to take advantage of that, or do your clients
> have to create their own page or task to talk to your services?

If you are asking me personally; I have not used Jini in any meaningful way
for ~10 years now. I still think it is a fascinating concept, and have a
lot of fond memories of "impossible" achievements we did back then
(2000-2005). And no, we were not using anything beyond Reggie, and had our
own system for enabling functionality as services came up or went down. And
once we figured out all the small traps, it was smooth sailing. BUT, our
usecase didn't actually need it. And I never manage to sell Jini to anyone
else later, primarily because it demands Java clients

But Voyager was another of those incredibly fascinating technologies that I
experimented with in 1997/98 somewhere. Again, couldn't find use-cases to
use it for real, though.

In much broader terms, Data is king nowadays and anything about technology
platforms are subservient and somewhat uninteresting to decision-makers.
Sad indeed, but for a majority of us, that is what we need to deal with.

Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Serialization issues

[Niclas Hedhman]

I don't follow. What does readObject/writeObject got to do with blocking or
not? You could spin up executors to do the work in parallel if you so wish.
And why is "something else" less blocking? And what are you doing that is
"blocking" since the "work" is (or should be) CPU only, there is limited
(still) opportunity to do that non-blocking (whatever that would mean in
CPU-only circumstance). Feel free to elaborate... I am curious.



On Sat, Feb 4, 2017 at 8:38 PM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:

> Unfortunately due to "writeObject" and "readObject" methods that have to
> be handled (to comply with the spec) - it is not possible to
> serialize/deserialize in a non-blocking fashion.
> So yes... - it is serialization per se.
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
> Oh, well that is not "Serialization" per se... No wonder i didn't get it.
>
> On Sat, Feb 4, 2017 at 7:20 PM, Peter <j...@zeus.net.au> <j...@zeus.net.au> 
> wrote:
>
>
> On 4/02/2017 9:09 PM, Niclas Hedhman wrote:
>
>
> but rather with the APIs - it is inherently blocking by design.
>
> I am not sure I understand what you mean by that.
>
>
>
> He means the client thread that makes the remote call blocks waiting for
> the remote end to process the request and respond.
>
> Cheers,
>
> Peter.
>
>
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: Serialization Formats, Previously: OSGi

[Niclas Hedhman]

(I think wrong thread, so to please Peter, I copied it all into here)

Correct, it is not different. But you are missing the point; CONSTRAINTS.
And without constraints, developers are capable of doing these good deeds
(such as your example) and many very poor ones. The knife cuts your meat or
butcher your neighbor... It is all about the constraints, something that
few developers are willing to admit that makes our work better.

As for the "leasable and you have..."; The problem is that you are probably
wrong on that front too, like the OSGi community have learned the hard way.
There are too many ways software entangle classloading. All kinds of shit
"registers itself" in the bowels of the runtime, such as with the
DriverManager, Loggers, URLHandlers or PermGenSpace (might be gone in Java
8). Then add 100s of common libraries that also does a poor job in
releasing "permanent" resources/instances/classes... The stain sticks, but
the smell is weak, so often we can't tell other than memory leak during
class updates.
And why do we have all this mess? IMHO; Lack of constraints, lack of
lifecycle management in "everything Java" (and most languages) and lack of
discipline (something Gregg has, and I plus 5 million other Java devs don't
have). OSGi is not as successful as it "should" (SpringSource gave up)
because it makes the "stain" stink really badly. OSGi introduces
constraints and fails spectacular when we try to break or circumvent them.

River as it currently stands has "solved" Java code mobility, Java leases,
dynamic service registry with query capabilities and much more. But as with
a lot of good technology, the masses don't buy it. The ignorant masses are
now in Peter Deutsch's Fallacies of Distributed Computing territory,
thinking that microservices on JAX-RS is going to save the day (it isn't, I
am rescuing a project out of it now).
Distributed OSGi tried to solve this problem, and AFAICT has serious
problems to work reliably in production environments. What do I learn? This
is hard, but every 5 years we double in numbers, so half the developer
population is inexperienced and repeat the same mistakes again and again.

Sorry for highlighting problems, mostly psychological/philosophical rather
than technological. I don't have the answers, other than; Without
Constraints Technology Fails. And the better the constraints are defined,
the better likelihood that it can succeed.




On Sat, Feb 4, 2017 at 8:59 PM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:

> Comments below.
>
> Niclas Hedhman wrote:
>
> see below
>
> On Sat, Feb 4, 2017 at 6:21 PM, "Michał Kłeczek (XPro Sp. z o. o.)" 
> <michal.klec...@xpro.biz> wrote:
>
> Once you transfer the code with your data - the issue of code version
>
> synchronization disappears, doesn't it?
>
> It also makes the wire data format irrelevant. At least for "short lived
>
> serialized states".
>
> Only works if you have no exchange with the environment it is executing.
> And this is where "sandboxing" concern kicks in. What is the sandbox? In a
> web browser they try to define it to DOM + handful of other well-defined
> objects. In case of Java Serialization, it is all classes reachable from
> the loading classloader. And I think Gregg is trying to argue that if one
> is very prudent, one need to manage this well.
>
>
> But how is "exchange with the environment it is executing"
> actually different when installing code on demand from installing it in
> advance???
>
> The whole point IMHO is to shift thinking from "moving data" to "exchange
> configured software" -
> think Java specific Docker on steroids.
>
> Transferable objects allow you for example to do things like
> downloading your JDBC driver automagically without the fuss of installing
> it and managing upgrades.
> Just publish a DataSource object in your ServiceRegistrar and you are done.
> Make it leasable and you have automatic upgrades and/or reconfiguration.
>
> Thanks,
> Michal
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org/> - New Energy for Java

Re: OSGi

[Niclas Hedhman]

Oh, well that is not "Serialization" per se... No wonder i didn't get it.

On Sat, Feb 4, 2017 at 7:20 PM, Peter <j...@zeus.net.au> wrote:

> On 4/02/2017 9:09 PM, Niclas Hedhman wrote:
>
>>
>> but rather with the APIs - it is inherently blocking by design.
>>>
>> I am not sure I understand what you mean by that.
>>
>>
> He means the client thread that makes the remote call blocks waiting for
> the remote end to process the request and respond.
>
> Cheers,
>
> Peter.
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: OSGi

[Niclas Hedhman]

see below

On Sat, Feb 4, 2017 at 6:21 PM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:
> Once you transfer the code with your data - the issue of code version
synchronization disappears, doesn't it?
> It also makes the wire data format irrelevant. At least for "short lived
serialized states".

Only works if you have no exchange with the environment it is executing.
And this is where "sandboxing" concern kicks in. What is the sandbox? In a
web browser they try to define it to DOM + handful of other well-defined
objects. In case of Java Serialization, it is all classes reachable from
the loading classloader. And I think Gregg is trying to argue that if one
is very prudent, one need to manage this well.

> I fail to understand how JSON or XML changes anything here.

It doesn't. It makes the issues more visible, and more easy to recover when
something goes wrong. Java Serialization is sold "too generic" and hence
abused by everyone (myself included) and we (except Gregg and other gurus)
get burned badly somewhere along the way.

> In the end all of the arguments against Java Object Serialization boil
down to:
> "It is easy to use but if not used carefully it will bite you - so it is
too easy to use"

Well, kind of...
If you ever need to deserialize a serialVersionUid=1 with a codebase where
it is now serialVersionUid != 1, I wouldn't call it "easy to use" anymore.
Back in the days when I used this stuff heavily, I ended up never change
serialVersionUid. If I needed to refactor it enough to loose compatibility,
I would create a new class and make an adapter.

> What I do not like about Java Object Serialization has nothing to do with
the format of persistent data
> but rather with the APIs - it is inherently blocking by design.

I am not sure I understand what you mean by that.

Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: OSGi

[Niclas Hedhman]

Gregg,
I know that you can manage to "evolve" the binary format if you are
incredibly careful and not make mistakes. BUT, that seems really hard,
since EVEN Sun/Oracle state that using Serilazation for "long live objects"
are highly discouraged. THAT is a sign that it is not nearly as easy as you
make it sound to be, and it is definitely different from XML/JSON as once
the working codebase is lost (i.e. either literally lost (yes, I have been
involved trying to restore that), or modified so much that compatibility
broke, which happens when serialization is not the primary focus of a
project) then you are pretty much screwed forever, unlike XML/JSON.

Now, you may say, that is for "long lived serialized states" but we are
dealing with "short lived" ones. However, in today's architectures and
platforms, almost no organization manages to keep all parts of a system
synchronized when it comes to versioning. Different parts of a system is
upgraded at different rates. And this is essentially the same as "long
lived objects" ---  "uh this was serialized using LibA 1.1, LibB 2.3 and
JRE 1.4, and we are now at LibA 4.6, LibB 3.1 and Java 8", do you see the
similarity? If not, then I will not be able to convince you. If you do,
then ask "why did Sun/Oracle state that long-lived objects with Java
Serialization was a bad idea?", or were they also clueless on how to do it
right, which seems to be your actual argument.

And I think (purely speculative) that many people saw exactly this problem
quite early on, whereas myself I was at the time mostly in relatively small
confined and controlled environments, where up-to-date was managed. And
took me much longer to realize the downsides that are inherent.

Cheers
Niclas

On Sat, Feb 4, 2017 at 3:35 PM, Gregg Wonderly <ge...@cox.net> wrote:

>
> > On Feb 3, 2017, at 8:43 PM, Niclas Hedhman <nic...@hedhman.org> wrote:
> >
> > On Fri, Feb 3, 2017 at 12:23 PM, Peter <j...@zeus.net.au> wrote:
> >
> >>
> >> No serialization or Remote method invocation framework currently
> supports
> >> OSGi very well, one that works well and can provide security might gain
> a
> >> lot of new interest from that user base.
> >
> >
> > What do you mean by this? Jackson's ObjectMapper doesn't have problems on
> > OSGi. You are formulating the problem wrongly, and if formulated
> correctly,
> > perhaps one realizes why Java Serialization fell out of fashion rather
> > quickly 10-12 years ago, when people realized that code mobility (as done
> > in Java serialization/RMI) caused a lot of problems.
>
> I’ve seen and heard of many poorly designed pieces of software.  But, the
> serialization for Java has some very easily managed details which can
> trivially allow you to be 100% successful with the use of Serialization.
> I’ve never encountered problems with serialization.  I learned early on
> about using explicit versioning for any serialization format, and then
> providing evolution based changes instead of replacement based changes.  It
> takes some experience and thought for sure.  But, in the end, it’s really
> no different from using JSON, XML or anything else.  The format of what you
> send has to be able to change, the content which must remain in a
> compatible way has to remain accessible in the same way.  I really am
> saddened by the thought that so many people never learn about binary
> structured data in their classes or through materials they might read to
> learn about such things.
>
> What generally happens is that people forget to design extensibility into
> their data systems, and then end up with all kinds of problems.   Here’s
> some of the rules I always try to follow.
>
> 1. Remote interfaces should almost always pass non native type objects
> that wrap the data needed.  This will make sure you can seamlessly add more
> data without changing method signatures.
> 2. Always put a serial version id on your serialized classes.  Start with
> 1, and increment it as you make changes by more than just ‘1’.
> 3. When you are going to add a new value, think about how you can make
> that independent of existing serialized data.  For example, when you
> override readObject or writeObject methods, how will you make sure that
> those methods can cast the data for “this” version of the data without
> breaking past or future versions of the object.
> 4. Data values inside of serialized classes should be carefully designed
> so that there is a “not present” value that is in line with a “not
> initialized” value so that you can always insert a new format in between
> those two (see rule 2 above about leaving holes in the versions).
>
> The purpose of serializing objects is so that you can also 

Re: OSGi

[Niclas Hedhman]

The latter...

It works rather well for JavaScript in web browsers. I think that is the
most interesting "mobile code" platform to review as a starting point.

On Sat, Feb 4, 2017 at 2:54 PM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:

> Are you opposing the whole idea of sending data and code (or instructions
> how to download it) bundled together? (the spec)
> Or just the way how it is done in Java today. (the impl)
>
> If it is the first - we are in an absolute disagreement.
> If the second - I agree wholeheartedly.
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
>> FYI in case you didn't know; Jackson ObjectMapper takes a POJO structure
>> and creates a (for instance) JSON document, or the other way around. It is
>> not meant for "any object to binary and back".
>> My point was, Java Serialization (and by extension JERI) has a scope that
>> is possibly wrongly defined in the first place. More constraints back then
>> might have been a good thing...
>>
>>
>>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: OSGi

[Niclas Hedhman]

FYI in case you didn't know; Jackson ObjectMapper takes a POJO structure
and creates a (for instance) JSON document, or the other way around. It is
not meant for "any object to binary and back".
My point was, Java Serialization (and by extension JERI) has a scope that
is possibly wrongly defined in the first place. More constraints back then
might have been a good thing...



On Sat, Feb 4, 2017 at 12:36 PM, Peter <j...@zeus.net.au> wrote:

> On 4/02/2017 12:43 PM, Niclas Hedhman wrote:
>
>> On Fri, Feb 3, 2017 at 12:23 PM, Peter<j...@zeus.net.au>  wrote:
>>
>> No serialization or Remote method invocation framework currently supports
>>> OSGi very well, one that works well and can provide security might gain a
>>> lot of new interest from that user base.
>>>
>>
>> What do you mean by this? Jackson's ObjectMapper doesn't have problems on
>> OSGi. You are formulating the problem wrongly, and if formulated
>> correctly,
>> perhaps one realizes why Java Serialization fell out of fashion rather
>> quickly 10-12 years ago, when people realized that code mobility (as done
>> in Java serialization/RMI) caused a lot of problems.
>>
>
> Hmm, I didn't know that, sounds like an option for JERI.
>
>
> IMHO, RMI/Serialization's design is flawed. Mixing too many concerns in the
>> same abstraction; sandboxing w/ integration , code mobility, class
>> resolution, versioning and deserialization, with very little hooks to
>> cusomize any or all of these aspects. And these aspects should not have
>> been wrapped into one monolith.
>>
>> Further, I think the only "sane" approach in a OSGi environment is to
>> create a new bundle for the Remote environment, all codebases not part of
>> the API goes into that bundle and that the API is required to be present
>> in
>> the OSGi environment a priori. I.e. treat the Remote objects in OSGi as it
>> is treated in plain Java; one classloader, one chunk, sort out its own
>> serialization woes. Likewise for the server; treat it as ordinary RMI,
>> without any mumbo-jambo OSGi stuff to be figured out at a non-OSGi-running
>> JVM. An important difference is that in OSGi, the BundleClassLoader is not
>> (required to be) a URLClassLoader, so the Java serialization's auto
>> annotation of globally reachable URLs won't work, and one need to rely on
>> java.rmi.server.codebase property, but a bundle could watch for loaded
>> bundles and build that up for URLs that can be resolved globally.
>>
>>
>> Cheers
>>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: OSGi

[Niclas Hedhman]

On Fri, Feb 3, 2017 at 12:23 PM, Peter <j...@zeus.net.au> wrote:

>
> No serialization or Remote method invocation framework currently supports
> OSGi very well, one that works well and can provide security might gain a
> lot of new interest from that user base.


What do you mean by this? Jackson's ObjectMapper doesn't have problems on
OSGi. You are formulating the problem wrongly, and if formulated correctly,
perhaps one realizes why Java Serialization fell out of fashion rather
quickly 10-12 years ago, when people realized that code mobility (as done
in Java serialization/RMI) caused a lot of problems.

IMHO, RMI/Serialization's design is flawed. Mixing too many concerns in the
same abstraction; sandboxing w/ integration , code mobility, class
resolution, versioning and deserialization, with very little hooks to
cusomize any or all of these aspects. And these aspects should not have
been wrapped into one monolith.

Further, I think the only "sane" approach in a OSGi environment is to
create a new bundle for the Remote environment, all codebases not part of
the API goes into that bundle and that the API is required to be present in
the OSGi environment a priori. I.e. treat the Remote objects in OSGi as it
is treated in plain Java; one classloader, one chunk, sort out its own
serialization woes. Likewise for the server; treat it as ordinary RMI,
without any mumbo-jambo OSGi stuff to be figured out at a non-OSGi-running
JVM. An important difference is that in OSGi, the BundleClassLoader is not
(required to be) a URLClassLoader, so the Java serialization's auto
annotation of globally reachable URLs won't work, and one need to rely on
java.rmi.server.codebase property, but a bundle could watch for loaded
bundles and build that up for URLs that can be resolved globally.


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: OSGi

[Niclas Hedhman]

de/context.  It doesn’t matter if it is TCCL or some other
> class
> > > management scheme such as OSGi bundles.  We are talking about the same
> > > detail, just implemented in a different way.
> > > >>
> > > >>> What's more - these class loading implementations may be dynamic
> > > themselves - ie. it is a service that provides the client with a way to
> > > load its own (proxy) classes.
> > > >>>
> > > >>> In other words: "there not enough Jini in Jini itself”.
> > > >>
> > > >> I am not sure I understand where the short coming is at then.  Maybe
> > > you can illustrate with an example where TCCL fails to allow some piece
> > of
> > > code to load classes on behalf of another piece of code?
> > > >>
> > > >> In my desktop application environment, there is a abstract class
> which
> > > is used by each serviceUI to allow the desktop to know if it provides
> the
> > > ability to open into one of the above mentioned JComponent subclasses.
> > > That class is preferred and provided and resolved using the codebase of
> > the
> > > desktop client.  That class loading environment is then the place where
> > the
> > > service is finally resolved and classes created so that the proxy can
> be
> > > handed to the serviceUI component which ultimately only partially
> > resolves
> > > from the services codebase.
> > > >>
> > > >> It’s this class compatibility which needs to be lightweight.
> > > >>
> > > >>> We have _all_ the required pieces in place:
> > > >>> - dynamic code loading and execution (ClassLoaders),
> > > >>> - security model and implementation that allows restricting rights
> of
> > > the downloaded code,
> > > >>> - and a serialization/deserialization which allows sending
> arbitrary
> > > data (and yes - code too) over the wire.
> > > >>>
> > > >>> It is just the matter of glueing the pieces together.
> > > >>
> > > >> Correct, but it’s a matter of class compatibility where a client
> > > environment has to interact with a service and the serviceUI components
> > > where TCCL excels and providing the ability to create class loaders
> with
> > > the correct parent context, for Java based code.  OSGi introduces the
> > > opportunity for some extra bells and whistles.  But I don’t see that it
> > can
> > > completely eliminate the nature of TCCL and how it was intended to be
> > used.
> > > >>
> > > >>> Thanks,
> > > >>> Michal
> > > >>>
> > > >>>
> > > >>> Gregg Wonderly wrote:
> > > >>>> 
> > > >>>> I am not an OSGi user.  I am not trying to be an OSGi opponent.
> > What
> > > I am trying to say is that I consider all the commentary in those
> > articles
> > > about TCCL not working to be just inexperience and argument to try and
> > > justify a different position or interpretation of what the real problem
> > is.
> > > >>>>
> > > >>>> The real problem is that there is not one “module” concept in Java
> > > (another one is almost here in JDK 9/Jigsaw).  No one is working
> together
> > > on this, and OSGi is solving problems in a small part of the world of
> > > software.   It works well for embedded, static systems.  I think OSGi
> > > misses the mark on dynamic systems because of the piecemeal loading and
> > > resolving of classes.  I am not sure that OSGi developers really
> > understand
> > > everything that Jini can do because of the choices made (and not made)
> in
> > > the design.  The people who put Jini together had a great deal of years
> > of
> > > experience piecing together systems which needed to work well with a
> > faster
> > > degree of variability and adaptation to the environment then what most
> > > people seem to experience in their classes and work environments which
> > are
> > > locked down by extremely controlled distribution strategies which end
> up
> > > slowing development in an attempt to control everything that doesn’t
> > > actually cause quality to suffer.
> > > >>>>
> > > >>>> Gregg
> > > >>>>
> > > >>>>
> > > >>
> > > >
> > >
> > >
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: OSGi

[Niclas Hedhman]

On Mon, Jan 23, 2017 at 1:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:

> I would say fully declarative approach in OSGI would be to only annotate
with a package version range (and let the OSGI container do the resolution
- it is designed to do it efficiently).
> Of course then we have a problem with classes that are not from any
exported package but from internal bundle class path - then bundle id and
version might be necessary.
> Then of course there is a question of classes from fragment bundles -
this is totally unsolvable since AFAIK there is no way to get the fragment
information based on the class loader of a class.

Not that I grasp why it is needed, but you can get the Bundle information
from the classloader, IF the class was loaded by OSGi. OSGi defines
BundleClassLoader, so you simply cast the classloader to that, and with
that you can get the Bundle and the BundleContext, which together should be
able to give you all the meta info that you could need.

> And the main issue with this approach IMHO is that it requires a central
authority that governs the naming and versioning of bundles.

It is rather rare that Bundle management is needed. The OBR (OSGi Bundle
Repository) spec could be leveraged to resolve "package name+version" to
bundle location, and deploying an OBR capable service on a network is
relatively simple (serve a XML over HTTP).

> Approach 2 in OSGI would require annotating a class not with a bundle but
with a piece of information that would allow
> the client to download the _BundleWiring_ of the proxy - it unambiguously
specifies the class loader graph that is
> required to be recreated by the client to deserialize an object..
>
> When I tried to implement it - it appeared to me that the main issue is
that it simply makes the whole OSGI with its declarative
> dependency resolution moot - we need to totally bypass it to transfer
objects between containers anyway. So the only thing
> we actually would use from an OSGI container is its capability of
non-hierarchical class loading.

The concept of "download the proxy, both code and state" was quite novel in
1999 when I first heard of Jini. But I think it should be recognized that
it both introduces a lot of security problems as well as not being the only
way this can be done. For instance, the proxy could be an HTML page, which
downloads JavaScript which binds into a sandbox provided. I think that the
"serialized object" should not be a requirement eventually, and with that
removed, the OSGi environment can help quite considerably aiding the
dynamic nature of River.

> One step towards solving the above issues is to implement the idea of
code base annotations being objects
> implementing a well known interface - that would at least allow us to
abstract away from the exact format of
> the annotation data. But I do not have a clear idea on how to solve other
OSGI integration issues.

As Peter observed, Pax URL allows a whole bunch of URL schemes, which you
could be annotated in the serialized objects, just like URL codebases are
today. For instance, Maven "coordinates" could be in the annotations and
OSGi loads bundles on-demand. Paremus also implemented a "bundle garbage
collector" in some manner, which unloaded unused bundles eventually.

Furthermore, there are defined hooks in OSGi for the resolution of service
registration and service lookup, which I think River should exploit. There
seems to be a huge complementary intersection right there.

> The use case and the ultimate test to implement is simple - have a
listener that publishes remote events to a JavaSpace acquired dynamically
from a lookup service:
>
> class SpacePublisher implements RemoteEventListener, Serializable {
>   private final JavaSpace space;
>   public void notify(RemoteEvent evt) {
> space.write(createEntry(evt), ...);
>   }
> }
>
> It is NOT possible to do currently. It requires non-hierarchical class
loading. It is not easy to solve. It would open a whole lot of
possibilities.

I am probably too ignorant to see it; What exactly is "NOT possible" with
the above use-case snippet?


Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: OSGi

[Niclas Hedhman]

gt;>>> block of code, to use the ClassLoader passed in during construction.
>>>>> I'm
>>>>> currently investigating addong methods where ClassLoader can be passed
>>>>> in
>>>>> for OSGi.
>>>>>
>>>>> Regarding bundle structure, I've restructured the layout here (so you
>>>>> don't need to delete Groovy config):
>>>>>
>>>>> https://github.com/pfirmstone/JGDMS/tree/Maven_build/modularize/JGDMS
>>>>>
>>>>> The full commit history has been retained, so u can see all changes.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Peter.
>>>>>
>>>>> Sent from my Samsung device.
>>>>>
>>>>> Include original message
>>>>>  Original message 
>>>>> From: Bharath Kumar<bharathkuma...@gmail.com>
>>>>> Sent: 20/01/2017 09:42:38 pm
>>>>> To: dev@river.apache.org
>>>>> Subject: Re: OSGi
>>>>>
>>>>> Hello all,
>>>>>
>>>>> I have also added a package in org.apache.river bundle to create the
>>>>> river
>>>>> service in osgi environment ( Here RIver
>>>>> uses NonActivatableServiceDescriptor).
>>>>>
>>>>> package name is  org.apache.river.start.ext
>>>>>
>>>>>
>>>>> As river bundle is system fragment, i have to remove
>>>>> the groovy dependency.
>>>>> So i removed groovy files.
>>>>>
>>>>> net.jini.config.Component.groovy
>>>>>
>>>>> net.jini.config.GroovyConfig.groovy
>>>>>
>>>>>
>>>>>
>>>>> Thanks&   Regards,
>>>>>
>>>>>
>>>>> Bharath
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 20, 2017 at 3:47 PM, Bharath Kumar<
>>>>> bharathkuma...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> I missed images. Please find the zip file which has
>>>>> report.html along with
>>>>>
>>>>> images.
>>>>>>
>>>>>> On Fri, Jan 20, 2017 at 3:42 PM, Bharath Kumar<
>>>>>> bharathkuma...@gmail.com
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> I have attached the comparison report (html) between river 3.0.0
>>>>>> source
>>>>>>
>>>>>>> and org.apache.river bundle source.
>>>>>>> I made changes to those files which are in red color.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 20, 2017 at 12:45 PM, Bharath Kumar>>>>>>
>>>>>>> uma...@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks Peter,
>>>>>>>>
>>>>>>>> I have uploaded 3 bundles to github and it is available in the below
>>>>>>>> location.
>>>>>>>> https://github.com/bharathkumara/river-osgi
>>>>>>>>
>>>>>>>> It is eclipse workspace and we need bndtools eclipse
>>>>>>>>
>>>>>>>> plugin to run/debug
>>>>>>>
>>>>>> it.
>>>>>>
>>>>>>>  1. org.apache.river - River classes as system fragment bundle
>>>>>>>>  2. org.apache.river.bootstrap -  Contains code to
>>>>>>>>
>>>>>>>> start code server,
>>>>>>>
>>>>>>  export local osgi services(Remote) and publish
>>>>>>
>>>>>>> it to network, listen for
>>>>>>>
>>>>>>  river services in the network and utilities.
>>>>>>
>>>>>>>  3. org.apache.river.lookup - Lookup service as osgi bundle.
>>>>>>>>
>>>>>>>>
>>>>>>>> Using these 3 osgi bundles, I am able to start reggie and clients
>>>>>>>> can
>>>>>>>> register services and lookup using service templates.
>>>>>>>> I'll post example services later.
>>

Re: OSGi

[Niclas Hedhman]

Also, I am still on this list, and can aid with answering question in
details, but not really to put in hours to do the actual work.

The maven-bnd-plugin does most things right, but there is always a question
of hiding internal packages/classes. Instead of aiming for running 'naked'
on a blank OSGi container, I think it is generally better to start out with
something like Apache Karaf. It will provide a lot for relatively little,
incl so called wrapping of JARs into Bundles, provided by Pax URL[1]
project, which also provides URL references of various kinds for many
things. So, even if not going with Karaf, take a look at Pax URL.

And in River, there is likely to be classloading issues, and although
"Dynamic-ImportPackage" is available as a last resort, it should be
avoided. Almost always the context classloader is a "mess", and there is a
tendency of memory leaks when it is involved.


[1] https://ops4j1.jira.com/wiki/display/paxurl/Pax+URL

On Wed, Jan 18, 2017 at 11:18 AM, Peter Firmstone <
peter.firmst...@zeus.net.au> wrote:

> Any OSGi veterans willing to assist with JGDMS support for OSGi during the
> modular restructure?
>
> I've added OSGi manifests to modules, but I also need to add classpath
> manifest entry's for non osgi application compatibility, I'm using the
> bnd-maven-plugin to generate the OSGi manifests.
>
> I also want to enable using ServiceLoader  mediator manifest entry's for
> OSGi, as the use of service provider style abstractions within River are
> widespread.
>
> River also has its own service provider lookup mechanism:
> org.apache.resources.Service
>
> Then there's the use of context ClassLoader's throughout to consider.
>
> Regards,
>
> Peter.
>
> Sent from my Samsung device.
>
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: svn error with http checkout (was: Re: about 3.0 artifacts and announcement)

[Niclas Hedhman]

I don't think commit should work on http, it should only be allowed on
https.

On Fri, Jan 6, 2017 at 2:36 PM, Zsolt Kúti <la.ti...@gmail.com> wrote:

> Just made a fresh http checkout (done with IDEA). It went fine, on commit
> it asked for special credentials.
>
> Zsolt
>
> On Fri, Jan 6, 2017 at 4:24 AM, Dan Rollo <danro...@gmail.com> wrote:
>
> >  I was just trying to do a clean checkout from “trunk” to test the
> > build/release steps (and hopefully help with publishing binaries to
> > Central), but I’m getting a subversion error during checkout:
> >
> >
> > $ svn checkout http://svn.apache.org/repos/asf/river/jtsk/trunk river
> > Ariver/test
> > Ariver/test/conf
> > ...
> > Ariver/test/src/org/apache/river/concurrent/ReferenceMapTest.java
> > Ariver/test/quarantined-src/README
> > svn: E175002: GET request returned unexpected delta base:
> > /repos/asf/!svn/rvr/1726456/river/jtsk/trunk/LICENSE
> >
> > Anybody else seeing similar issues with a clean checkout using “http”
> > (anonymous) url?
> >
> >
> > For kicks, I also tried the https URL given under the ‘Developer Access’
> > section (show below), and that worked.
> > Is this expected? If so, maybe we should change the 'Anonymous access’
> URL
> > docs to use https.
> >
> > $ svn checkout https://svn.apache.org/repos/asf/river/jtsk/trunk river
> >
> >
> > -Dan
> >
> >
> >
> > From: Zsolt Kúti <la.ti...@gmail.com <mailto:la.ti...@gmail.com>>
> > Subject: about 3.0 artifacts and announcement
> > Date: January 5, 2017 at 3:51:07 PM EST
> > To: dev@river.apache.org <mailto:dev@river.apache.org>
> >
> >
> > Hi,
> >
> > Can somebody tell if our release process documentation is up-to date:
> > http://river.apache.org/dev-doc/building-a-release.html <
> > http://river.apache.org/dev-doc/building-a-release.html>
> >
> > As to the release, the last mail was:
> > http://mail-archives.apache.org/mod_mbox/river-dev/201610.
> > mbox/%3cCAK_o9cH7JPsfd_CK4-pOGb3nswH4R8jB1Kh6=
> > UTWF2c0Ge9V=w...@mail.gmail.com%3e <http://mail-archives.apache.
> > org/mod_mbox/river-dev/201610.mbox/%3cCAK_o9cH7JPsfd_CK4-
> > pOGb3nswH4R8jB1Kh6=UTWF2c0Ge9V=w...@mail.gmail.com%3e>
> >
> > The 3.0.0 release artifacts (no binary) are available from here:
> > http://www.apache.org/dyn/closer.cgi/river/ <http://www.apache.org/dyn/
> > closer.cgi/river/>
> > So nothing is against a release announcement on our website, isn't  it?
> >
> >
> > If nobody else is willing to, I can take a look into how to add our jars
> to
> > maven repo,.
> >
> > Cheers,
> > Zsolt
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: svn error with http checkout (was: Re: about 3.0 artifacts and announcement)

[Niclas Hedhman]

Works for me with SVN 1.9.5 on Linux Debian.

In principle, ASF wants all URLs to be https, but it should not impact this
case. In any event, I don't think there is anything for the River project
to do about it right now.

Cheers
Niclas

On Fri, Jan 6, 2017 at 11:52 AM, Dan Rollo <danro...@gmail.com> wrote:

> Sorry, forgot to include my subversion version info:
>
> $ svn --version
> svn, version 1.9.4 (r1740329)
>compiled Nov 15 2016, 20:35:27 on x86_64-apple-darwin15.0.0
>
> > On Jan 5, 2017, at 10:24 PM, Dan Rollo <danro...@gmail.com> wrote:
> >
> >  I was just trying to do a clean checkout from “trunk” to test the
> build/release steps (and hopefully help with publishing binaries to
> Central), but I’m getting a subversion error during checkout:
> >
> >
> > $ svn checkout http://svn.apache.org/repos/asf/river/jtsk/trunk <
> http://svn.apache.org/repos/asf/river/jtsk/trunk> river
> > Ariver/test
> > Ariver/test/conf
> > ...
> > Ariver/test/src/org/apache/river/concurrent/ReferenceMapTest.java
> > Ariver/test/quarantined-src/README
> > svn: E175002: GET request returned unexpected delta base:
> /repos/asf/!svn/rvr/1726456/river/jtsk/trunk/LICENSE
> >
> > Anybody else seeing similar issues with a clean checkout using “http”
> (anonymous) url?
> >
> >
> > For kicks, I also tried the https URL given under the ‘Developer Access’
> section (show below), and that worked.
> > Is this expected? If so, maybe we should change the 'Anonymous access’
> URL docs to use https.
> >
> > $ svn checkout https://svn.apache.org/repos/asf/river/jtsk/trunk <
> https://svn.apache.org/repos/asf/river/jtsk/trunk> river
> >
> >
> > -Dan
> >
> >
> >
> > From: Zsolt Kúti <la.ti...@gmail.com <mailto:la.ti...@gmail.com>>
> > Subject: about 3.0 artifacts and announcement
> > Date: January 5, 2017 at 3:51:07 PM EST
> > To: dev@river.apache.org <mailto:dev@river.apache.org>
> >
> >
> > Hi,
> >
> > Can somebody tell if our release process documentation is up-to date:
> > http://river.apache.org/dev-doc/building-a-release.html <
> http://river.apache.org/dev-doc/building-a-release.html>
> >
> > As to the release, the last mail was:
> > http://mail-archives.apache.org/mod_mbox/river-dev/201610.
> mbox/%3cCAK_o9cH7JPsfd_CK4-pOGb3nswH4R8jB1Kh6=
> UTWF2c0Ge9V=w...@mail.gmail.com%3e <http://mail-archives.apache.
> org/mod_mbox/river-dev/201610.mbox/%3cCAK_o9cH7JPsfd_CK4-
> pOGb3nswH4R8jB1Kh6=UTWF2c0Ge9V=w...@mail.gmail.com%3e>
> >
> > The 3.0.0 release artifacts (no binary) are available from here:
> > http://www.apache.org/dyn/closer.cgi/river/ <http://www.apache.org/dyn/
> closer.cgi/river/>
> > So nothing is against a release announcement on our website, isn't  it?
> >
> >
> > If nobody else is willing to, I can take a look into how to add our jars
> to
> > maven repo,.
> >
> > Cheers,
> > Zsolt
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: site revamp

[Niclas Hedhman]

I don't think the mobile rendering is reason to stop publishing. If I flip
the phone into landscape, then it is good enough for me, and many
commercial sites are no better.

Niclas

On Fri, Dec 30, 2016 at 9:33 PM, Zsolt Kúti <la.ti...@gmail.com> wrote:

> Hi,
>
> The issue is fixed together with the missing navbar. The only thing that
> the expanded navbar on mobile though usable is bit hard to read. I could
> not find an improvement for it.
>
> Can we get it all out?
>
> Cheers,
> Zsolt
>
> On Mon, Dec 26, 2016 at 6:39 AM, Gregg Wonderly <ge...@cox.net> wrote:
>
> > Yes that is what I also experienced on my mobile.
> >
> > Gregg
> >
> > > On Dec 23, 2016, at 7:52 AM, Niclas Hedhman <hedh...@gmail.com> wrote:
> > >
> > > On my phone (Nexus 6P) it looks like this;
> > > https://goo.gl/photos/jxVnHvoES4EtaQh5A
> > > And probably reflects what Gregg is talking about.
> > >
> > > Cheers
> > > Niclas
> > >
> > >> On Dec 23, 2016 21:40, "Gregg Wonderly" <gr...@wonderly.org> wrote:
> > >>
> > >> I am just thinking about how people use text messages to share things,
> > and
> > >> thought it might be a little problematic on mobile.
> > >>
> > >> I too am not sure that it matters, but just wanted to share what I
> saw.
> > >>
> > >> Gregg
> > >>
> > >> Sent from my iPhone
> > >>
> > >>> On Dec 23, 2016, at 12:15 AM, Zsolt Kúti <la.ti...@gmail.com> wrote:
> > >>>
> > >>> @Dan: Thanks for pointig this out: fixed
> > >>> @Gregg: Bootstrap supports responsive design, however I am not a web
> > >>> designer :-)   I am not sure how many will follow us on mobile,
> either.
> > >>> Anyway, I will take a look into it, if this can easily be fixed.
> > >>> @ all of you who liked it: thanks!
> > >>>
> > >>> Zsolt
> > >>>
> > >>>> On Fri, Dec 23, 2016 at 3:23 AM, Luis Matta <matta.l...@gmail.com>
> > >> wrote:
> > >>>>
> > >>>> Very nice, congrats (and thanks)
> > >>>>
> > >>>> On Thu, Dec 22, 2016 at 10:42 PM, Gregg Wonderly <
> gr...@wonderly.org>
> > >>>> wrote:
> > >>>>
> > >>>>> When I look at it in portrait mode on my mobile device it is a
> little
> > >> too
> > >>>>> skinny to consume easily.  The text on the water is nearly
> invisible
> > >> due
> > >>>> to
> > >>>>> lack of contrast.
> > >>>>>
> > >>>>> It is okay in landscape.   I like the content!
> > >>>>>
> > >>>>> Gregg
> > >>>>>
> > >>>>>> On Dec 22, 2016, at 1:44 PM, Geoffrey Arnold <
> > >>>> geoffrey.arn...@gmail.com>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>> Hey Zsolt, really fantastic job.  Well done!
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>> On Thu, Dec 22, 2016 at 11:24 AM, Zsolt Kúti <la.ti...@gmail.com
> >
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>> Hello,
> > >>>>>>>
> > >>>>>>> The revamped site is now staged and can be reviewed here:
> > >>>>>>> http://river.staging.apache.org/
> > >>>>>>>
> > >>>>>>> Community decides when to publish it.
> > >>>>>>>
> > >>>>>>> Cheers,
> > >>>>>>> Zsolt
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>
> > >>
> >
> >
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: site revamp

[Niclas Hedhman]

On my phone (Nexus 6P) it looks like this;
https://goo.gl/photos/jxVnHvoES4EtaQh5A
And probably reflects what Gregg is talking about.

Cheers
Niclas

On Dec 23, 2016 21:40, "Gregg Wonderly"  wrote:

> I am just thinking about how people use text messages to share things, and
> thought it might be a little problematic on mobile.
>
> I too am not sure that it matters, but just wanted to share what I saw.
>
> Gregg
>
> Sent from my iPhone
>
> > On Dec 23, 2016, at 12:15 AM, Zsolt Kúti  wrote:
> >
> > @Dan: Thanks for pointig this out: fixed
> > @Gregg: Bootstrap supports responsive design, however I am not a web
> > designer :-)   I am not sure how many will follow us on mobile, either.
> > Anyway, I will take a look into it, if this can easily be fixed.
> > @ all of you who liked it: thanks!
> >
> > Zsolt
> >
> >> On Fri, Dec 23, 2016 at 3:23 AM, Luis Matta 
> wrote:
> >>
> >> Very nice, congrats (and thanks)
> >>
> >> On Thu, Dec 22, 2016 at 10:42 PM, Gregg Wonderly 
> >> wrote:
> >>
> >>> When I look at it in portrait mode on my mobile device it is a little
> too
> >>> skinny to consume easily.  The text on the water is nearly invisible
> due
> >> to
> >>> lack of contrast.
> >>>
> >>> It is okay in landscape.   I like the content!
> >>>
> >>> Gregg
> >>>
>  On Dec 22, 2016, at 1:44 PM, Geoffrey Arnold <
> >> geoffrey.arn...@gmail.com>
> >>> wrote:
> 
>  Hey Zsolt, really fantastic job.  Well done!
> 
> 
> 
> 
> 
> > On Thu, Dec 22, 2016 at 11:24 AM, Zsolt Kúti 
> >>> wrote:
> >
> > Hello,
> >
> > The revamped site is now staged and can be reviewed here:
> > http://river.staging.apache.org/
> >
> > Community decides when to publish it.
> >
> > Cheers,
> > Zsolt
> >
> >>>
> >>>
> >>
>
>

Re: Maven Build

[Niclas Hedhman]

On Wed, Nov 16, 2016 at 8:43 PM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:

> 3. My comment about OSGi being "non-deterministic" in resolving
dependencies means that the
> same bundle installed in two different environments is going to be linked
with different dependent
> bundles. It basically means the same object graph valid in one VM
instance cannot be deserialized
> in another VM instance unless:

Well, technically speaking this is true in standard Jini classloading
approach as well, since you have no control of which classes are being used
from parent classloaders.

> a) all bundles have their dependencies specified in such a way that exact
same dependency graph
> is going to be present everywhere (meaning no Package-Imports, no version
ranges etc)

This is incorrect. You can narrow his down with additional constraints
(typically package attributes). Not very well-known feature, but completely
possible, and whether you want version ranges or not, is up to you. Again,
traditional RMI can be set up to either use versioned or non-versioned
classes, in the dynamic loading part. I don't see much of a difference.
(Sorry, I can't comment on JBoss Modules as I have no experience)

> b) all JVMs have the same set of bundles installed (ie - there is no
dynamic code downloading at all
> - the code is preloaded)

I never worked with Paremus implementation, but I vaguely recall Richard
explaining that dynamically loaded bundles would be garbage collected when
not needed anymore. Sounds like dynamic code downloading to me.

> c) classes of serialized objects are not loaded by OSGi framework class
loaders but by other
> non-related class loading framework (which is what original old OSGi-Jini
spec did)

Well, that spec was dropped in OSGi Release 4 because it could not deal
with multiple versions of classes, that Release 4 introduced. The bundle
would both require DynamicImport-Package, as well as have no means to
export "new" functionality discovered, which is why I think it was dropped
(I wasn't privvy of the discussion back then)

> d) classes of all objects in the object graph are from the same bundle
(special case of a) )

Yes, but not in itself a requirement per se.

> In general all efforts I am aware of regarding "remoting" in Java didn't
really even try to solve issues of
> dynamically downloaded code. They were based on all parties having the
same code installed and/or
> having a central authority providing a shared consistent view of all
available software.

Yes, I agree. It is an age old issue with any remoting technology, and I
think the main reason Jini didn't succeed (except for awkward initial
licensing) was that people were weary of "Java only" solutions, effectively
making Java a virus. ;-)

> I am not saying it is wrong. I am only saying that IMHO it is not
something River should do -
> it is simply a solved problem and there is not point of re-doing it (JERI
is cool but it is simply yet-
> another-RPC-stack)

JERI is cool because it tries to preserve security contexts. Yes, security
is seldom used in Java applications, mainly because we think we trust all
the code that is running. I think this assumption is slowly eroding away,
as we rely more and more on third-party code, which we can't vet in full to
see what is going on. Usage of containers is effectively taking a similar
stance at a lower level.


> Regarding JBoss Modules:
> I am not really advocating this particular library - it is just that it
is the only (non-OSGi - see above :) )
> implementation of non-hierarchical class loading that I am aware of which
is of good quality and
> actively maintained. I wouldn't want to reimplement it by myself. Thought
about ClassWorlds but it
> doesn't seem to be too active and had some performance problems in the
past. JBoss Modules
> is Apache licensed so it can be used by River.

The only thing I see in the quick browse of documentation is that it was
intended for loading JARs inside WARs inside EARs, and figure out how to
establish a working classloading mechanism inside such a cluster. Maybe I
am missing something really important, but it doesn't seem to be
particularly oriented towards ensuring the same classes being present
(which seems to be your beef with OSGi) in both JVMs.

I am not saying that your effort is bad, and I have no problem it being
donated to Apache River (or published elsewhere). I am only criticizing
your claims about OSGi, which I find to be not true.


Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Maven Build

[Niclas Hedhman]

lasses  SUCCESS [3.966s]
> > > Module :: Reggie Service Implementation .. SUCCESS [3.621s]
> > > Module :: Mahalo . SUCCESS [0.436s]
> > > Module :: Mahalo Service Download classes . SUCCESS [2.059s]
> > > Module :: Mahalo Service Implementation ... SUCCESS [4.175s]
> > > Module :: Mercury the Event Mailbox ... SUCCESS [0.497s]
> > > Module :: Mercury Service Download classes  SUCCESS [3622s]
> > > Module :: Mercury Service Implementation .. SUCCESS [3.562s]
> > > Module :: Norm  SUCCESS [0.013s]
> > > Module :: Norm Service Download classes ... SUCCESS [2.867s]
> > > Module :: Norm Service Implementation . SUCCESS [6.390s]
> > > Module :: Group ... SUCCESS [0.025s]
> > > Module :: Mahalo Service Download classes . SUCCESS [2.877s]
> > > Module :: Group Service Implementation  SUCCESS [2.037s]
> > > Module :: Tools ....... SUCCESS [0.485s]
> > > Module :: Check ConfigurationFile . SUCCESS [2.720s]
> > > Module :: Check serialversionUid .. SUCCESS [2.129s]
> > > Module :: ClassDep  SUCCESS [4.157s]
> > > Module :: Class Server . SUCCESS [3.353s]
> > > Module :: Compute message digest .. SUCCESS [1.734s]
> > > Module :: Compute httpmd codebase . SUCCESS [2.102s]
> > > Module :: Environment Check .. SUCCESS [2.837s]
> > > Module :: Jar wrapper  SUCCESS [2.179s]
> > > Module :: Preferred classes list generator  SUCCESS [2.495s]
> > > Module :: Phoenix Activation . SUCCESS [0.029s]
> > > Module :: Phoenix Download ... SUCCESS [2.685s]
> > > Module :: Phoenix  SUCCESS [4.095s]
> > > Module :: Phoenix Group ... SUCCESS [2.445s]
> > > Module :: Phoenix Init  SUCCESS [1.740s]
> > > River Distribution  SUCCESS [10.523s]
> > > 
> 
> > > BUILD SUCCESS
> > > 
> 
> > > Total time: 2:29.804s
> > > Finished at: Mon Nov 14 22:22:31 EST 2016
> > > Final Memory: 145M/247M
> > > 
> 
> > >
> > >
> > >
> > >
> >
> >
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: River revamp

[Niclas Hedhman]

I agree with Dan, and I attempted this myself many, many years ago, but at
that time there were little consensus to go that route.

Although I don't like Maven, because it is very opinionated about
everything, I think it is a big, good step in the right direction.
Personally, I would go with Gradle, since it is more supple and easier to
get to do builds that are not following the Maven model to the letter and
far less sensitive to "time" (old Maven builds just stops working after
enough time passed, unless a massive list of every plugin used is versioned
exactly). Unfortunately, I don't have enough cycles to tackle that in the
near future.

Cheers
Niclas

On Wed, Nov 16, 2016 at 9:48 AM, Dan Rollo <danro...@gmail.com> wrote:

> +1 to breaking up code into independently released modules. This would
> avoid tricky builds that re-use the same source files to produce different
> jars containing the same .class files, and it would ensure
> interdependencies are validated by build tooling. This approach would also
> avoid a “boil the ocean” syndrome where nothing can be released until it’s
> “all done”.
>
> -Dan
>
> From: Peter <j...@zeus.net.au <mailto:j...@zeus.net.au>>
> Subject: Re: River revamp
> Date: November 12, 2016 at 1:25:49 AM EST
> To: dev@river.apache.org <mailto:dev@river.apache.org>
>
>
> We could make this the basis for a new release, almost as is.  I'd need to
> create some JIRA issues to capture the changes.  This would include Secure
> serialization, which is a step towards secure IoT.
>
> However I'm also tempted to break up the codebase into modules and release
> each separately; a further step along the pathe of the secure IoT theme,
> from the root of the dependency tree.
>
> The qa test suite would remain a separate ant build.
>
> Regards,
>
> Peter.
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: River revamp

[Niclas Hedhman]

File a JIRA ticket on INFRA project should work.

Specify which SVN subtree to migrate into each repository.



On Fri, Nov 11, 2016 at 1:15 PM, Patricia Shanahan <p...@acm.org> wrote:

> What is the current process for getting a writable GIT repository within
> ASF?
>
>
> On 11/10/2016 8:25 PM, Peter wrote:
>
>> Thinking about how to proceed with code and repo...
>>
>> * I want to bring code in from an existing git repo and keep commit
>> history (I'm the only committer).  Branched off a recent version of River
>> trunk.
>> * We want to change to using a git repo for River.
>> * Start building maven style modules from the ground up, starting with
>> JERI at low level.
>> * Separate out the qa test suite (integration tests), which is an ant
>> build that only depends on jars from river build.
>> * Where should jtreg test suite ( unit and regression tests) go?  Maybe
>> with each relevant module?
>> * junit tests with appropriate module...
>>
>> Thoughts / suggestions?
>>
>> Regards,
>>
>> Peter.
>>
>> Sent from my Samsung device.
>>
>>   Include original message
>>  Original message 
>> From: Peter <j...@zeus.net.au>
>> Sent: 06/11/2016 08:23:06 pm
>> To: dev@river.apache.org
>> Subject: Re: River revamp
>>
>> Yes same pattern, some details are different for security reasons,
>> additional support is required for lower level protocols as object
>> endpoints.
>>
>> Also, for example, devices were on a 6LowPAN network, different types of
>> devices would subscribe to different multicast groups, to minimise their
>> responses, since some devices may rely on battery power, we don't want
>> them to announce their presence or respond unnecessarily as that wastes
>> power.
>>
>> There are a number of new IoT protocols being developed, I think we'll
>> need to provide some support for some to start with.
>>
>> AMQP is another interesting protocol.
>>
>> On the discovery side, in order to make a connection, the multicast
>> response will need to contain the application layer name, transport
>> layer name, contact address and port, eg:  MQTT, TCP, IP address:port.
>> Typically the nework layer will define the method of multicast.
>>
>> Cheers,
>>
>> Peter.
>>
>> On 6/11/2016 1:05 PM, Niclas Hedhman wrote:
>>
>>>  Ok, so this is more or less classic "surrogate" setup with JINI, right,
>>>  with some additional SEC stuff, right?
>>>
>>>  And that is a cool way to achieve interoperability with smaller devices
>>>  without ability to run a JVM, especially the original dream where
>>> devices
>>>  don't know about each other ahead of time (except by some interface)
>>>
>>>  I also see value where "IoT Service" doesn't bother with "Service
>>>  Registrar" in the "Jini sense" and the "IoT Device" only participate in
>>>  "Discovery" and then get a secure/trusted channel, onto which a
>>>  light-weight protocol, such as MQTT or CoAP, can be funneled in either
>>>  direction.
>>>
>>>
>>>
>>>  On Sat, Nov 5, 2016 at 2:26 PM, Peter<j...@zeus.net.au>  wrote:
>>>
>>>  Hmm lets try Ascii, hope line wrapping doesn't wreck it.
>>>>
>>>>
>>>>   |<--| Multicast request
>>>>  Multicast   |   |
>>>>  response|-->| Connection&  auth
>>>>   |   | to discovered address
>>>>  RPCSEC_GSS  |<--|
>>>>  auth|-->| RPCSEC_GSS Auth
>>>>   |   | success, request
>>>>   |   | bytes containing
>>>>   |   | service proxy
>>>>   |  Register service |
>>>>   |proxy&  attributes |--->|
>>>> Registration
>>>>   |  Mange reg lease  |<---|
>>>>   |   ||
>>>>   |   | Match
>>>>  |<-| Lookup
>>>>   |   |
>>>>  |->|
>>>>   |   ||
>>>>

Re: River revamp

[Niclas Hedhman]

Ok, so this is more or less classic "surrogate" setup with JINI, right,
with some additional SEC stuff, right?

And that is a cool way to achieve interoperability with smaller devices
without ability to run a JVM, especially the original dream where devices
don't know about each other ahead of time (except by some interface)

I also see value where "IoT Service" doesn't bother with "Service
Registrar" in the "Jini sense" and the "IoT Device" only participate in
"Discovery" and then get a secure/trusted channel, onto which a
light-weight protocol, such as MQTT or CoAP, can be funneled in either
direction.



On Sat, Nov 5, 2016 at 2:26 PM, Peter <j...@zeus.net.au> wrote:

> Hmm lets try Ascii, hope line wrapping doesn't wreck it.
>
>
> |<--| Multicast request
> Multicast   |   |
> response|-->| Connection & auth
> |   | to discovered address
> RPCSEC_GSS  |<--|
> auth|-->| RPCSEC_GSS Auth
> |   | success, request
> |   | bytes containing
> |   | service proxy
> |  Register service |
> |proxy & attributes |--->| Registration
> |  Mange reg lease  |<---|
> |   ||
> |   | Match
> |<-| Lookup
> |   |
> |->|
> |   ||
>   | Authenticate Iot Service
> |   ||
>   | with bootstrap proxy
> |   ||
>   | Grant permission to download
> |   Auth client |<--|
> and deserialize service proxy.
> |  Return service proxy |-
> ->|
> |   ||
>   | Prepare service proxy
> |<--|
> execute RPC function call
>  Function   |-->|
> with constraints
> |   ||
>   |
>IoT Device IoT Service Service Registrar
> Client
>
>
>
>
> On 5/11/2016 3:48 PM, Peter wrote:
>
>> Ok, will come back to the ascii art, I'll first attempt to attach a png.
>>
>> There's an existing Java RPC implementation LGPL, with a maven build tag
>> => oncrpc4j-2.6.0
>>
>> https://github.com/dCache/oncrpc4j
>>
>> The implementation above supports /RPCSEC_GSS/ for security, although
>> there's a client side bug at present, but fixing it will be a lot less work
>> than reimplimenting it.
>>
>> Basically RPC is the C equivalent of Java RMI.
>>
>> Cheers,
>>
>> Peter.
>>
>> On 5/11/2016 10:32 AM, Niclas Hedhman wrote:
>>
>>> Sorry, I get the feeling that too much detail thinking is still in your
>>> head. Hard for me to follow your thought process. A simple picture (ascii
>>> art would do) would go a long way...
>>>
>>> Niclas
>>>
>>> On Sat, Nov 5, 2016 at 8:04 AM, Peter<j...@zeus.net.au>  wrote:
>>>
>>> Thinking about C and power constrained devices, how about the following:
>>>>
>>>> * Write an ONC RPC java compiler, to create java code (instead of C)
>>>> client stubs.
>>>>
>>>> * Provide support for TLS and constraints.
>>>>
>>>> * Provide an IPv6 constrained device announcement (C) and discovery
>>>> (Java)
>>>> utilities.  Create a standard so other languages can be supported by
>>>> others.
>>>>
>>>> * Write a java utility and service that manages proxies, registers
>>>> discovered constrained devices with a lookup service and manages it's
>>>> lease.  This utility can generate attributes (from Configuration) and
>>>> provide a bootstrap proxy (service) to allow clients to authenticate and
>>>> obtain the smart proxy used to communicate directly with the device.
>>>>
>>>> * Provide an interface for clients to notify the utility service when a
>>>> device is down.
>>>>
>>>>

Re: River revamp

[Niclas Hedhman]

No png arrived.

On Sat, Nov 5, 2016 at 1:48 PM, Peter <j...@zeus.net.au> wrote:

> Ok, will come back to the ascii art, I'll first attempt to attach a png.
>
> There's an existing Java RPC implementation LGPL, with a maven build tag
> => oncrpc4j-2.6.0
>
> https://github.com/dCache/oncrpc4j
>
> The implementation above supports /RPCSEC_GSS/ for security, although
> there's a client side bug at present, but fixing it will be a lot less work
> than reimplimenting it.
>
> Basically RPC is the C equivalent of Java RMI.
>
> Cheers,
>
> Peter.
>
>
> On 5/11/2016 10:32 AM, Niclas Hedhman wrote:
>
>> Sorry, I get the feeling that too much detail thinking is still in your
>> head. Hard for me to follow your thought process. A simple picture (ascii
>> art would do) would go a long way...
>>
>> Niclas
>>
>> On Sat, Nov 5, 2016 at 8:04 AM, Peter<j...@zeus.net.au>  wrote:
>>
>> Thinking about C and power constrained devices, how about the following:
>>>
>>> * Write an ONC RPC java compiler, to create java code (instead of C)
>>> client stubs.
>>>
>>> * Provide support for TLS and constraints.
>>>
>>> * Provide an IPv6 constrained device announcement (C) and discovery
>>> (Java)
>>> utilities.  Create a standard so other languages can be supported by
>>> others.
>>>
>>> * Write a java utility and service that manages proxies, registers
>>> discovered constrained devices with a lookup service and manages it's
>>> lease.  This utility can generate attributes (from Configuration) and
>>> provide a bootstrap proxy (service) to allow clients to authenticate and
>>> obtain the smart proxy used to communicate directly with the device.
>>>
>>> * Provide an interface for clients to notify the utility service when a
>>> device is down.
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>>> Sent from my Samsung device.
>>>
>>>Include original message
>>>  Original message 
>>> From: Zsolt Kúti<la.ti...@gmail.com>
>>> Sent: 03/11/2016 05:37:45 pm
>>> To: dev@river.apache.org
>>> Subject: Re: River revamp
>>>
>>> A small footprint implementation of Jini's lookup service written in C,
>>> fully JCK compliant.
>>> http://www.psinaptic.com/link_files/PsiNapticTelematics.pdf
>>>
>>>
>>> A few years ago being involved in developing a streelighting management
>>> system I tried to access them to no avail.
>>>
>>> On Thu, Nov 3, 2016 at 8:09 AM, Peter<j...@zeus.net.au>  wrote:
>>>
>>> I've been conaidering that.  It should be possible to implement service
>>>> discovery in C, any serialized java bytes required for a proxy could be
>>>> stored on the device.
>>>>
>>>> So these devices are services, but not clients.
>>>>
>>>> Will respond with more soon
>>>>
>>>> Regards,
>>>>
>>>> Peter.
>>>>
>>>> Sent from my Samsung device.
>>>>
>>>>Include original message
>>>>  Original message 
>>>> From: Niclas Hedhman<nic...@hedhman.org>
>>>> Sent: 03/11/2016 12:39:33 pm
>>>> To: dev@river.apache.org
>>>> Subject: Re: River revamp
>>>>
>>>> "IoT" is a term that for this discussion is a bit too wide. The
>>>> "thermostat" runs with a kB-sized microcontroller and is
>>>>
>>> struggling to get
>>>
>>>> security features in at all, and the "home router" is typically (still)
>>>> running from a 4-8MByte flash, which is impossible to even get a Java ME
>>>> onto, so there is a lot of challenges when using "IoT"
>>>>
>>> as a blanket term.
>>>
>>>> So, I think a couple of concrete, do-able, use-cases
>>>> need to be highlighted
>>>> as examples, maybe a kind of "blue print" paper on how to
>>>> do it with River.
>>>>
>>>> I totally agree that the "mothership" model is
>>>> outrageous from a consumer's
>>>> perspective, a nasty vendor lock-in, that all vendors are
>>>>
>>> pushing for and
>>>
>>>> all consumers/users need to fight the best we can.
>>>>
>>>> A very active home automation project is called "OpenHAB", a flurry of
&g

Re: River revamp

[Niclas Hedhman]

Sorry, I get the feeling that too much detail thinking is still in your
head. Hard for me to follow your thought process. A simple picture (ascii
art would do) would go a long way...

Niclas

On Sat, Nov 5, 2016 at 8:04 AM, Peter <j...@zeus.net.au> wrote:

> Thinking about C and power constrained devices, how about the following:
>
> * Write an ONC RPC java compiler, to create java code (instead of C)
> client stubs.
>
> * Provide support for TLS and constraints.
>
> * Provide an IPv6 constrained device announcement (C) and discovery (Java)
> utilities.  Create a standard so other languages can be supported by others.
>
> * Write a java utility and service that manages proxies, registers
> discovered constrained devices with a lookup service and manages it's
> lease.  This utility can generate attributes (from Configuration) and
> provide a bootstrap proxy (service) to allow clients to authenticate and
> obtain the smart proxy used to communicate directly with the device.
>
> * Provide an interface for clients to notify the utility service when a
> device is down.
>
> Regards,
>
> Peter.
>
> Sent from my Samsung device.
>
>   Include original message
>  Original message 
> From: Zsolt Kúti <la.ti...@gmail.com>
> Sent: 03/11/2016 05:37:45 pm
> To: dev@river.apache.org
> Subject: Re: River revamp
>
> A small footprint implementation of Jini's lookup service written in C,
> fully JCK compliant.
> http://www.psinaptic.com/link_files/PsiNapticTelematics.pdf
>
>
> A few years ago being involved in developing a streelighting management
> system I tried to access them to no avail.
>
> On Thu, Nov 3, 2016 at 8:09 AM, Peter <j...@zeus.net.au> wrote:
>
> > I've been conaidering that.  It should be possible to implement service
> > discovery in C, any serialized java bytes required for a proxy could be
> > stored on the device.
> >
> > So these devices are services, but not clients.
> >
> > Will respond with more soon
> >
> > Regards,
> >
> > Peter.
> >
> > Sent from my Samsung device.
> >
> >   Include original message
> >  Original message 
> > From: Niclas Hedhman <nic...@hedhman.org>
> > Sent: 03/11/2016 12:39:33 pm
> > To: dev@river.apache.org
> > Subject: Re: River revamp
> >
> > "IoT" is a term that for this discussion is a bit too wide. The
> > "thermostat" runs with a kB-sized microcontroller and is
> struggling to get
> > security features in at all, and the "home router" is typically (still)
> > running from a 4-8MByte flash, which is impossible to even get a Java ME
> > onto, so there is a lot of challenges when using "IoT"
> as a blanket term.
> > So, I think a couple of concrete, do-able, use-cases
> > need to be highlighted
> > as examples, maybe a kind of "blue print" paper on how to
> > do it with River.
> >
> > I totally agree that the "mothership" model is
> > outrageous from a consumer's
> > perspective, a nasty vendor lock-in, that all vendors are
> pushing for and
> > all consumers/users need to fight the best we can.
> >
> > A very active home automation project is called "OpenHAB", a flurry of
> > activity, connecting just about everything from your thermostat to your
> > dog's toys. I have not looked closely at it, don't even know if it is a
> > Java project as such, but it is one of the most active projects in the
> > field of Home IoT.
> >
> > Cheers
> > Niclas
> >
> > On Wed, Nov 2, 2016 at 10:41 PM, Patricia Shanahan <p...@acm.org> wrote:
> >
> > > I think for this to work it is necessary to find out
> > where IoT people hang
> > > out, and discuss it there Do they already have a plan for a secure
> > > framework?
> > >
> > > As a potential IoT user I'm looking for two things:
> > >
> > > 1. Security.
> > >
> > > 2. Server independence.
> > >
> > > I don't want my thermostat to stop working if a server I don't control
> > > goes down or is taken out of service for any reason.
> > >
> > > I think River may be a good basis for those features.
> > >
> > >
> > > On 11/2/2016 7:22 AM, Bryan Thompson wrote:
> > >
> > >> I look at this as open source for secure IoT.  The
> need for security in
> > >> IoT
> > >> has been aptly demonstrated by recent DDOS
> > attaches based on compromised
> > >> devices.
> > >>
> > >

Re: OpenIoT Summit Feb 21-23, Portland OR

[Niclas Hedhman]

I forgot the link;
http://events.linuxfoundation.org/events/archive/2016/openiot-summit

On Sat, Nov 5, 2016 at 8:19 AM, Niclas Hedhman <nic...@hedhman.org> wrote:

> Hi,
> If River is going down the route of network security in IoT, please be
> informed that the LinuxFoundation is organizing OpenIoT next year, and that
> "Call for Papers" is now open, until Dec 10.
>
> This could be a good platform to push the new message.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

OpenIoT Summit Feb 21-23, Portland OR

[Niclas Hedhman]

Hi,
If River is going down the route of network security in IoT, please be
informed that the LinuxFoundation is organizing OpenIoT next year, and that
"Call for Papers" is now open, until Dec 10.

This could be a good platform to push the new message.


Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: River revamp

[Niclas Hedhman]

"IoT" is a term that for this discussion is a bit too wide. The
"thermostat" runs with a kB-sized microcontroller and is struggling to get
security features in at all, and the "home router" is typically (still)
running from a 4-8MByte flash, which is impossible to even get a Java ME
onto, so there is a lot of challenges when using "IoT" as a blanket term.
So, I think a couple of concrete, do-able, use-cases need to be highlighted
as examples, maybe a kind of "blue print" paper on how to do it with River.

I totally agree that the "mothership" model is outrageous from a consumer's
perspective, a nasty vendor lock-in, that all vendors are pushing for and
all consumers/users need to fight the best we can.

A very active home automation project is called "OpenHAB", a flurry of
activity, connecting just about everything from your thermostat to your
dog's toys. I have not looked closely at it, don't even know if it is a
Java project as such, but it is one of the most active projects in the
field of Home IoT.

Cheers
Niclas

On Wed, Nov 2, 2016 at 10:41 PM, Patricia Shanahan <p...@acm.org> wrote:

> I think for this to work it is necessary to find out where IoT people hang
> out, and discuss it there. Do they already have a plan for a secure
> framework?
>
> As a potential IoT user I'm looking for two things:
>
> 1. Security.
>
> 2. Server independence.
>
> I don't want my thermostat to stop working if a server I don't control
> goes down or is taken out of service for any reason.
>
> I think River may be a good basis for those features.
>
>
> On 11/2/2016 7:22 AM, Bryan Thompson wrote:
>
>> I look at this as open source for secure IoT.  The need for security in
>> IoT
>> has been aptly demonstrated by recent DDOS attaches based on compromised
>> devices.
>>
>> I do feel that interop is critical to success here.
>>
>> Do we have any lurkers from the IoT manufacturing space here?  People or
>> companies willing to invest time and resources for a secure IOT platform?
>>
>> Bryan
>>
>> On Wednesday, November 2, 2016, Peter <j...@zeus.net.au> wrote:
>>
>> Utilising most of the existing discovery code, we could use ipv6
>>> multicast, for an exported remote object (service).
>>>
>>> Then create a new class called RemoteDiscovery to discover a service
>>> dynamically, based on a name
>>>
>>> So you export a service and it becomes dynamically discoverable.
>>>
>>> It's not going to step on any Jini discovery lookup stuff and it's going
>>> to be easily deployed by new users.
>>>
>>> Then once users realise there's more on offer they can take advantage as
>>> their understanding develops.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>> Sent from my Samsung device.
>>>
>>>   Include original message
>>>  Original message 
>>> From: Niclas Hedhman <nic...@hedhman.org <javascript:;>>
>>> Sent: 02/11/2016 05:31:26 pm
>>> To: dev@river.apache.org <javascript:;>
>>> Subject: Re: River revamp
>>>
>>> To put a bit more meat on Peter's condensed list...
>>>
>>> I put forward a proposal to sever the ties between River and Jini itself,
>>> and instead re-focus River to be a a secured network transport, with
>>> optional discovery. Starting point is of course the JERI
>>> module and Peter's
>>> work to secure this transport, but in the longer term look at alternative
>>> transport formats and eventually bindings to other
>>> languages, which I think
>>> will be the major hurdle for long term acceptance (no one is Java-only
>>> nowadays).
>>>
>>> Jini's services, Reggie and so on, carries a lot of negative connotation
>>> among people who were around back then, and except for where it has been
>>> adopted, I doubt that there will be any new uptake, so instead of making
>>> Jini (and its specs) the focal point of River, make it
>>> to "Examples of what
>>> River can be used for".
>>>
>>> Another example of what can be done with River could eventually include
>>> connectors for popular platforms, such as Zookeeper, which could open
>>> avenues for new blood coming to River.
>>>
>>> Concrete things; Apache Karaf is also a very small
>>> community, yet they have
>>> managed to put together a very exciting website, and I think River
>>> community could "borrow" a lot of that work, making itself more

Re: River revamp

[Niclas Hedhman]

To put a bit more meat on Peter's condensed list...

I put forward a proposal to sever the ties between River and Jini itself,
and instead re-focus River to be a a secured network transport, with
optional discovery. Starting point is of course the JERI module and Peter's
work to secure this transport, but in the longer term look at alternative
transport formats and eventually bindings to other languages, which I think
will be the major hurdle for long term acceptance (no one is Java-only
nowadays).

Jini's services, Reggie and so on, carries a lot of negative connotation
among people who were around back then, and except for where it has been
adopted, I doubt that there will be any new uptake, so instead of making
Jini (and its specs) the focal point of River, make it to "Examples of what
River can be used for".

Another example of what can be done with River could eventually include
connectors for popular platforms, such as Zookeeper, which could open
avenues for new blood coming to River.

Concrete things; Apache Karaf is also a very small community, yet they have
managed to put together a very exciting website, and I think River
community could "borrow" a lot of that work, making itself more appealing,
promoting the new focus. I don't think much coding is needed to get this
going, but packaging might be "fixed" to make consumption of the core
functionality as easy as possible, preferably easier than that.

Once that is up-and-running starting the "reach out" to other projects,
individuals and press releases.


I hope that this will inspire some to more action.

Niclas





On Wed, Nov 2, 2016 at 2:25 PM, Peter Firmstone <peter.firmst...@zeus.net.au
> wrote:

> A discussion recently ignited on river private about revamping the project.
>
> For the benefit of the wider developer community can we restate the
> suggestions here, feel free to reword, correct, reject or suggest.  It was
> along the lines of:
>
> * Website revamp
> * Remove Jini focus, with a historical section...
> * Focus on new security features.
> * Make getting started simple, with just the bare bones basics, Extensible
> remote invocation with secure serialization.
> * Services, Javaspaces etc, become examples of what can be done with
> River, not what River  is.
>
> Regards,
>
> Peter.
>
>
>
> Sent from my Samsung device.
>
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Java.net & Kenai shutting down May 2017

[Niclas Hedhman]

Isn't OpenJDK on java.net ?? SO, is OpenJDK going to GitHub?

https://community.oracle.com/community/java/javanet-forge-sunset
https://www.infoq.com/news/2016/05/kenai-java-forges-closure
https://dzone.com/articles/javanet-and-kenai-oracle-why
http://www.i-programmer.info/news/80-java/9821-oracle-is-closing-javanet.html

On Mon, Sep 5, 2016 at 7:32 PM, Peter <j...@zeus.net.au> wrote:

> Oracle has announced that java.net and Kenai  will be shutting down in
> May 2017.
>
> Regards,
>
> Peter.
>
> Sent from my Samsung device.
>
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [VOTE] Release River from current trunk

[Niclas Hedhman]

Apache Web of Trust is pretty much an 'ultimate' signature. However,
releases are not that strict. KEYS file need to exist in SVN (which
indicates some level) and should also be published on river.apache.org
for people to check. You should also have the key uploaded to a pgp
key server, such as pgp.mit.edu.
While you are at it, choose the strongest key length possible, since
extrapolation shows that 1024 bits keys will be reasonably breakable
quite soon.

One way to get into the Apache Web of Trust (other than F2F) is to
validate authenticity from one to the other via phone/SMS. That holds
extra true for Tom, whose details are on record at ASF.

And Peter, there are other ASFers in Australia. Don't know exactly
where you are, but I wouldn't be surprised if you'll find someone
nearby. If you get counter-signed with those, and one of these travel
to a conference or otherwise gets into the larger cloud, you will be
pulled in passively.

Cheers
Niclas

On Mon, May 23, 2011 at 2:46 AM, Peter Firmstone j...@zeus.net.au wrote:
 Patricia Shanahan wrote:

 On 5/21/2011 4:21 AM, Peter Firmstone wrote:
 ...

 4. Have all committers add their signatures to the Keys file.

 ...

 Do I need to get into the Apache web of trust? If so, any suggestions for
 how to do it? I live in San Diego, but will be in London for a couple of
 weeks later in the year.

 Patricia


 To get into the Apache web of trust, you'll need to attend one of the Apache
 Developer events like ApacheCon and take your key along on a usb stick.  I'm
 a long way from any events, so it hasn't been practical for me to join it,
 but that didn't appear to be a problem with the release.

 Peter.





-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug

Environment Spec? [was; drop JDK 5 compatibility]

[Niclas Hedhman]

On Sat, Feb 12, 2011 at 8:57 AM, Peter Firmstone j...@zeus.net.au wrote:
 Note that I too develop using Java 5 language features, so I'm not placing
 any constraints on where River's headed, I accept recent developments,
 people have their goals and dropping 1.4 compatibility seems the easiest way
 to achieve them.

 I would encourage people to open their minds to the investigation of modular
 development, Java 7 and 8 are around the corner and the same thing will have
 to happen for Java 5 at some point.

Doesn't these paragraphs capture the need for a new specification? A
standardized way to specify the Minimum Runtime Requirement for the
Service Proxy, so that lookup operations can ensure that clients only
find compatible proxies...
Not only would JRE variant be needed, but potentially also OS, network
features, and if you envision Android client deployment down the line,
you would probably also like to include incl/excl of GPS, camera,
compass and other physical devices and their respective properties
(e.g. resolution, accuracy,...)

(Forgive me if I have missed this and this is already part of the core specs.)


Cheers
-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug