You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Dennis Reedy <de...@gmail.com> on 2009/07/03 17:53:46 UTC
[Was: OSGi and Jini] Now -> Next Steps
Forget about OSGi for now, its a red herring for River moving out of
incubation, and frankly a bit of noise that produces the same reaction
every time it is posted. This is not to say the each technology
(combined or separate) does not have its merits/issues, its just time
to move on.
How about AR2 gets released? Take the current project structure and
tests, and release what you have. I think its a safe bet to say that
the trunk represents a stable production worthy technology (AR1
certainly is). If there is more wok to do with the testing framework,
fine. Then release AR3 shortly there-after. I'll be glad to upload the
package name changes from com.sun.jini to org.apache.river as well if
the timing is right post AR2.
On Jul 3, 2009, at 1125AM, Sam Chance wrote:
> Well said, Jukka!
>
> Gregg, I say you do something with Jini and OSGi. :-) Seriously,
> what
> about a semantic LUS? Build a way to query for Services using
> Semantic
> technologies like RDF and SPARQL. Or use Jini to manage distributed
> OSGi
> bundles (RDF 119 is Distributed OSGi). Or build an AJAX front-end for
> lifecycle management of Jini federations and services.
>
> Just some thoughts.
>
>
> On Fri, Jul 3, 2009 at 5:26 AM, Jukka Zitting
> <ju...@gmail.com>wrote:
>
>> Hi,
>>
>> On Mon, Jun 29, 2009 at 10:20 PM, Gregg Wonderly<gr...@wonderly.org>
>> wrote:
>>> What happens next is what the community decides. I'd like to play a
>> part,
>>> but to date, everything that I've found to be interesting and
>>> wanted to
>> do
>>> differently in Jini has not been that interesting to the rest of the
>>> community.
>>
>> Does it matter? Apart from the the test suite there currently is no
>> active work being done on River trunk. Anyone with the energy to back
>> up his or her proposals with solid patches gets to decide where River
>> is going. If others don't agree, they'll need to come up with
>> alternative patches that solve the same issues.
>>
>>> So, I'm setting back, waiting for something to start rolling that
>>> I am
>>> interested in, and I'll jump in to assist as best I can, as I am
>>> needed.
>>
>> That's the wrong attitude. Just get started and others will follow!
>> At
>> Apache those who do, decide.
>>
>> BR,
>>
>> Jukka Zitting
>>
>
>
>
> --
> Sam Chance
> 443-694-5293 (m)
> 410-694-0240 x108 (o)
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Elijah Menifee <el...@gmail.com>.
Thinking more about it I might be wrong about this (once again IANAL)...
That compatibly might mean if they upgraded to GPLv3 they could link to the
River stuff without breaking their GPL license, but it may not be reciprocal
allowing Appach stuff to link to it without converting to GPLv3....
>
> P.S. According to the FSF GPLv3 is license compatible with the v2 Apache
> License, so if the Kerberos stuff can be upgraded to GPLv3 ( sometimes the
> license on software states or a later version..., or if they choose to
> relicense it under GPLv3) it should be compatable.
>
> On Fri, Jul 3, 2009 at 11:41 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> ...
>
>> After that I'd like to play around with NIO and DEFLATE compression for
>> serialization and http classserver performance improvements.
>>
>> I recently stumbled across a complete Java implementation of Kerberos
>> Server and client software, I'm thinking there may be benefits for River
>> running with a default authorisation setup, however it's GPL2, so I'd have
>> to ask if it can be relicensed first.
>>
>> Cheers,
>>
>>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Iain Shigeoka <ia...@gmail.com>.
There is a similar Apache library called Mina that could be used
instead and bypass all the licensing issues.
http://mina.apache.org/
-iain
On Jul 12, 2009, at 6:26 PM, Elijah Menifee wrote:
> While doing some additional research....
>
> On Sun, Jul 12, 2009 at 6:05 PM, Elijah Menifee <elijahcmenifee@gmail.com
> >wrote:
>
>> I myself have started to play with NIO for prototyping a
>> replacement server
>> system for my company's software. While doing research on how to
>> obtain
>> SSL/TLS connections on top of the NIO framework I came across Project
>> Grizzly <https://grizzly.dev.java.net/> which is a sub component of
>> the
>> new GlassFish server, as such it is dual licensed under CDDLv1 and
>> GPLv2
>> (ClassPath exception for some parts listed at bottom of GlassFish
>> license<https://glassfish.dev.java.net/public/CDDL+GPL.html>
>> ).
>>
>
> I came across this link: http://www.apache.org/legal/3party.html#category-b
> ,
> which looks like as long as only a binary jar-dependency to use the
> Grizzly
> project along with a NOTICE about it, and a link to the the source
> form
> (link back to the grizzly projects src for the given version) that
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Elijah Menifee <el...@gmail.com>.
While doing some additional research....
On Sun, Jul 12, 2009 at 6:05 PM, Elijah Menifee <el...@gmail.com>wrote:
> I myself have started to play with NIO for prototyping a replacement server
> system for my company's software. While doing research on how to obtain
> SSL/TLS connections on top of the NIO framework I came across Project
> Grizzly <https://grizzly.dev.java.net/> which is a sub component of the
> new GlassFish server, as such it is dual licensed under CDDLv1 and GPLv2
> (ClassPath exception for some parts listed at bottom of GlassFish license<https://glassfish.dev.java.net/public/CDDL+GPL.html>
> ).
>
I came across this link: http://www.apache.org/legal/3party.html#category-b,
which looks like as long as only a binary jar-dependency to use the Grizzly
project along with a NOTICE about it, and a link to the the source form
(link back to the grizzly projects src for the given version) that
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Patrick Wright <pd...@gmail.com>.
Hi Peter
Thanks for following up and taking the time to track down the various
relevant bug ids. I'll take a look.
Regards
Patrick
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Jones <pc...@roundroom.net>.
Patrick,
Sorry for taking so long to answer your question:
On Jul 15, 2009, at 12:05 PM, Patrick Wright wrote:
> Hi Peter
>
> On Wed, Jul 15, 2009 at 5:59 PM, Peter Jones<pc...@roundroom.net> wrote:
>> Just to be clear, the "com.sun.jini.jeri.tcp.useNIO=true" mode of the
>> JERI TCP endpoint implementation still uses multiple threads to
>> dispatch remote invocations-- RMI behavior would be drastically
>> impacted if it only used a single thread for that (for reasons like
>> you describe below). It just uses a single thread for performing I/O
>> operations, at least those that "would block".
>
> Do you happen to know if there is documentation from the time when the
> NIO support was added, for example, regarding benchmarks, problems,
> etc.?
There has been some discussion about these things over the years on
mailing lists like JINI-USERS (archives still online as of now) and,
IIRC, the jini.org mailing list for the Davis project (the code name
for the jini.org project that developed the 2.0 Jini starter kit
release)-- alas, the Davis mailing list archives haven't been online
for many years, ever since jini.org stopped hosting projects, and I
don't know that they were preserved anywhere. (Maybe Jim Hurley would
know for sure?)
I no longer have many performance/benchmark notes that I had at Sun.
Some issues with the JERI NIO implementation are documented as River
bugs (filed as clones of Jini bugs in the Sun database):
http://issues.apache.org/jira/browse/RIVER-101
http://issues.apache.org/jira/browse/RIVER-102
http://issues.apache.org/jira/browse/RIVER-157
http://issues.apache.org/jira/browse/RIVER-158
The first two are much more significant than the last two.
The current JERI NIO implementation was largely written around the
same time as Java's NIO itself was being developed, for J2SE 1.4 (this
was back around when what is now JERI was part of JSR-78 intended for
J2SE 1.4), and it has changed little since then. Some of the
implementation techniques were chosen in consultation with the NIO
expert group. But I think that the Java community has learned a great
deal about how to make the best use of the NIO API in the many years
since then, and I suspect that many lessons learned could be used to
improve (or replace) existing JERI NIO code.
RIVER-101 is a case of a design choice that seems suboptimal now,
especially as the NIO implementation has evolved. RIVER-102 is a case
where more thought should be put into what seems to be a critical
performance aspect (especially for multiprocessor systems, IIRC).
Incidentally, here are some other performance-related JERI RFEs, not
specifically related to the NIO implementation mode:
http://issues.apache.org/jira/browse/RIVER-99
http://issues.apache.org/jira/browse/RIVER-103
http://issues.apache.org/jira/browse/RIVER-137
http://issues.apache.org/jira/browse/RIVER-141
http://issues.apache.org/jira/browse/RIVER-177
http://issues.apache.org/jira/browse/RIVER-280
-- Peter
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Firmstone <ji...@zeus.net.au>.
That certainly makes sense, speed up performance for network ports IO.
Peter Jones wrote:
> Just to be clear, the "com.sun.jini.jeri.tcp.useNIO=true" mode of the
> JERI TCP endpoint implementation still uses multiple threads to
> dispatch remote invocations-- RMI behavior would be drastically
> impacted if it only used a single thread for that (for reasons like
> you describe below). It just uses a single thread for performing I/O
> operations, at least those that "would block".
>
> -- Peter
>
>
> On Tue, Jul 14, 2009 at 4:12 PM, Gregg Wonderly<gr...@wonderly.org> wrote:
>
>> The Jini 2.0 software includes the ability to use NIO in the TCP endpoint.
>> This is activated by system property "com.sun.jini.jeri.tcp.useNIO". If you
>> look at TcpEndpoint and TcpServerEndpoint, you'll not find much different
>> going on. The biggest issue with a typical network "distributed" system, is
>> circular wait that can occur as systems "randomly" develop new connections
>> to other system. Using a single thread to dispatch events in a server for
>> "load handling" is not a good thing for any "work" that can have "external"
>> contact. So, the use of NIO for
>> "scalability" is find for things that don't end up interacting circularly.
>> For things that you have no idea how they will interact, it's better to
>> make sure that you have "new inbound call == new inbound thread" so that you
>> don't get into problems. It may be that there is some work that you can do
>> in a single thread, but that usually is something that a specific
>> application optimizes.
>>
>> One way to do that is to use inbound calls to "queue" work. But then you
>> need to use "callbacks" to notify the caller of the results of there
>> request, unless you design a very custom invocation layer that allows the
>> use of a "Future" or some other "signaling" mechanism to control when the
>> result is sent back to the caller.
>>
>> Gregg Wonderly
>>
>>
>
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Patrick Wright <pd...@gmail.com>.
Hi Peter
On Wed, Jul 15, 2009 at 5:59 PM, Peter Jones<pc...@roundroom.net> wrote:
> Just to be clear, the "com.sun.jini.jeri.tcp.useNIO=true" mode of the
> JERI TCP endpoint implementation still uses multiple threads to
> dispatch remote invocations-- RMI behavior would be drastically
> impacted if it only used a single thread for that (for reasons like
> you describe below). It just uses a single thread for performing I/O
> operations, at least those that "would block".
Do you happen to know if there is documentation from the time when the
NIO support was added, for example, regarding benchmarks, problems,
etc.?
Thanks
Patrick
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Jones <pc...@roundroom.net>.
Just to be clear, the "com.sun.jini.jeri.tcp.useNIO=true" mode of the
JERI TCP endpoint implementation still uses multiple threads to
dispatch remote invocations-- RMI behavior would be drastically
impacted if it only used a single thread for that (for reasons like
you describe below). It just uses a single thread for performing I/O
operations, at least those that "would block".
-- Peter
On Tue, Jul 14, 2009 at 4:12 PM, Gregg Wonderly<gr...@wonderly.org> wrote:
> The Jini 2.0 software includes the ability to use NIO in the TCP endpoint.
> This is activated by system property "com.sun.jini.jeri.tcp.useNIO". If you
> look at TcpEndpoint and TcpServerEndpoint, you'll not find much different
> going on. The biggest issue with a typical network "distributed" system, is
> circular wait that can occur as systems "randomly" develop new connections
> to other system. Using a single thread to dispatch events in a server for
> "load handling" is not a good thing for any "work" that can have "external"
> contact. So, the use of NIO for
> "scalability" is find for things that don't end up interacting circularly.
> For things that you have no idea how they will interact, it's better to
> make sure that you have "new inbound call == new inbound thread" so that you
> don't get into problems. It may be that there is some work that you can do
> in a single thread, but that usually is something that a specific
> application optimizes.
>
> One way to do that is to use inbound calls to "queue" work. But then you
> need to use "callbacks" to notify the caller of the results of there
> request, unless you design a very custom invocation layer that allows the
> use of a "Future" or some other "signaling" mechanism to control when the
> result is sent back to the caller.
>
> Gregg Wonderly
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sun, Jul 5, 2009 at 9:47 AM, Elijah Menifee<el...@gmail.com> wrote:
> Has anyone tried contacting the Oregon State University Open.Source.Lab at
> http://osuosl.org/services/hosting? On their community page they claim they
> are proud to provide custom hosting and mirror services, and List the Apache
> Software Foundation as something they host portions of
That is one of the 3 data centers (if my understanding is up to date)
that Apache is 'located at'.
Apache also sports so called "zones", which are project specific
virtualized machines. They are project's own responsibility, and no
backup or other 'maintenance' is performed by the infrastructure team
(other than setting it up).
I am unsure of the zone-availability for Incubating podlings, but I
suspect that it will be arranged. Contact infra@apache.org and post a
ticket on https://issues.apache.org/jira/browse/INFRA.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Firmstone <ji...@zeus.net.au>.
I submitted an infrastructure request; INFRA-2098 a zone for the
Kerberos KDC, I'll wait 'n see how that goes first.
Niclas Hedhman wrote:
> On Thu, Jul 9, 2009 at 5:07 AM, Gregg Wonderly<gr...@wonderly.org> wrote:
>
>> Can we have a small proxy server run as part of the test script that would
>> start it and stop it and just use localhost connections?
>>
>
> I asked Justin (ASF President) yesterday-ish, whether podlings can
> make special infrastructure requests, or whether that is limited to
> TLPs. He said that podlings are welcome (but no guarantees), and it
> would be best to contact the infrastructure team directly. See
> http://www.apache.org/dev/infra-mail.html
>
> You guys know what you need, and those guys know what can be achieved.
> So, discuss ;-)
>
>
> Cheers
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Jul 9, 2009 at 5:07 AM, Gregg Wonderly<gr...@wonderly.org> wrote:
> Can we have a small proxy server run as part of the test script that would
> start it and stop it and just use localhost connections?
I asked Justin (ASF President) yesterday-ish, whether podlings can
make special infrastructure requests, or whether that is limited to
TLPs. He said that podlings are welcome (but no guarantees), and it
would be best to contact the infrastructure team directly. See
http://www.apache.org/dev/infra-mail.html
You guys know what you need, and those guys know what can be achieved.
So, discuss ;-)
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Elijah Menifee <el...@gmail.com>.
Has anyone tried contacting the Oregon State University Open.Source.Lab at
http://osuosl.org/services/hosting? On their community page they claim they
are proud to provide custom hosting and mirror services, and List the Apache
Software Foundation as something they host portions of, perhaps they could
provide a virtual machine running squid or just a copy of squid that could
be published in DNS at testproxy.river.incubator.apache.org or something
similar then the jtreg hardcoded name could be changed to the new name?
On Fri, Jul 3, 2009 at 11:41 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Hi Elijah,
>
> To test HTTP proxy support for the net.jini.jeri.http transport
> implementation.
>
> It's listed under JIRA as issue RIVER-306
> https://issues.apache.org/jira/browse/RIVER-306
>
> Sun originally had a Squid http proxy server on their network, it's
> hostname was jiniproxy, it's hardcoded into one of the jtreg tests;
> net/jini/jeri/http/echo/EchoImpl.java
>
> I want to have all tests running before releasing AR2. In order to
> stimulate a more agile development model, were trying to make the
> integration test suite and the jtreg unit and regression tests more
> developer friendly (easier to setup and run using ant). The junit test
> framework has also been adopted recently.
>
> Once testing is working properly, I'd like to look at the implementation of
> jini over http networks based on the work that Mark Brouwer did in the Seven
> project. He made a presentation at JCM10, the slides for which are still
> available. If you want to check the Seven project out, add the following to
> your Internet host table (/etc/hosts) as DNS lookup no longer works:
>
> 62.177.181.217 www.cheiron.org scm.cheiron.org issue.cheiron.org
>
> After that I'd like to play around with NIO and DEFLATE compression for
> serialization and http classserver performance improvements.
>
> I recently stumbled across a complete Java implementation of Kerberos
> Server and client software, I'm thinking there may be benefits for River
> running with a default authorisation setup, however it's GPL2, so I'd have
> to ask if it can be relicensed first.
>
> Cheers,
>
> Peter.
>
>
> Elijah Menifee wrote:
>
>> What roll does the Squid proxy on Sun's network play on
>> building/testing/releasing AR2?
>>
>> On Fri, Jul 3, 2009 at 7:22 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>
>>
>>
>>> That's almost the plan, just want to get all the tests right first and a
>>> couple of tweaks to the build then release. It's almost ready, I've just
>>> been very busy and haven't gotten onto it yet. Not much work left
>>> though.
>>>
>>> On that subject, I'm having some trouble deciding on a solution to
>>> replace
>>> the Squid proxy server that was present on Sun's network? Any ideas?
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>>
>>
>>
>>
>
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Nic.
Niclas Hedhman wrote:
> On Sat, Jul 4, 2009 at 12:41 PM, Peter Firmstone<ji...@zeus.net.au> wrote:
>
>
>> I recently stumbled across a complete Java implementation of Kerberos Server
>> and client software, I'm thinking there may be benefits for River running
>> with a default authorisation setup, however it's GPL2, so I'd have to ask if
>> it can be relicensed first.
>>
>
> IIRC, Kerberos implementation is available in the Apache Directory
> Server project, together with many other security related protocols
> and services.
>
> Cheers
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hmm, this might be something River could be distributed with, for a
default security setup?
Triplesec, sounds good, from the website:
Two Factor Strong Authentication for the Mass Market
Do you think that your password protected web sites (or network
applications) are safe? Well, think again^
<http://news.com.com/Companies+urged+to+move+beyond+passwords/2100-1029_3-5865013.html?tag=nefd.top>.
Consensus among network security experts is that unsafe passwords is one
of the most important causes for Internet security breaches, data theft,
and even identity theft. A static password is "what you know" and it can
be easily leaked or guessed. A much more secure authentication solution
is to combine the static password with a device that you have possession
of (i.e., "what you have"). The device typically generates a random
password (called One-Time Password, or OTP) for you to use with the
static password for each login. Since only your device can generate the
OTPs to match the ones generated on the server for your account, a
hacker cannot login to your account without both the physical access to
the device and knowledge of your static password. That is an example of
"two factor" authentication. In fact, the US government mandates that
all online banking services must adopt two-factor authentication by the
end of 2006. If you run a web site with valuable and sensitive
information, would you want to be left with the inadequate static passwords?
However, in the past, moving to OTP-based two-factor authentication is
costly for web site operators and inconvenient for users. The OTP
generator device (keyfob) must be custom made, distributed, tracked, and
managed. The server side authentication software are very expensive and
difficult to integrate into existing infrastructure. As a result, OTP
solutions are only used in the most high-end online services. Well, at
least that is before Triplesec is released. *Triplesec is a low cost
strong authentication solution for web sites, VPNs, and other Internet
applications. It aims to replace today's widely used, but insecure,
static password-based solutions for the mass market.* It has some
distinct advantages over previous generations of OTP solutions.
* *Triplesec is Open Source.* That means you can use it free of
charge. However, a more important advantage of Open Source is that
the code is peer-reviewed by the large user / developer community.
For a security solution, that means less bugs and vulnerabilities.
* *Triplesec has very low barrier for user adoption.* Triplesec
allows users to use their existing mobile phone as the
authentication device (i.e., the "what you have" device). The
Triplesec mobile phone client generates the OTPs. The vast
majority of today's new phones are compatible with Triplesec and
there is no additional service to buy.
* *Triplesec is pure Java-based.* That means the Triplesec server
runs on any server platform and the client runs on almost all
mobile phones.
* *Triplesec uses the standard Kerberos protocol for
authentication.* Since Kerberos is a widely used standard
protocol, the Triplesec server can be easily integrated into the
existing security infrastructure. It has been tested against the
existing Kerberos modules bundled in Solaris, Linux, Windows and
Mac OS X.
To see Triplesec in action, please checkout our online demo^
<http://demo.safehaus.org/>. To use Triplesec to secure your
applications, please [download the server] and refer to the user /
developer guide. If you are interested in building Triplesec from source
and contributing to the project, please checkout our contributor guide.
Niclas Hedhman wrote:
> On Sat, Jul 4, 2009 at 12:41 PM, Peter Firmstone<ji...@zeus.net.au> wrote:
>
>
>> I recently stumbled across a complete Java implementation of Kerberos Server
>> and client software, I'm thinking there may be benefits for River running
>> with a default authorisation setup, however it's GPL2, so I'd have to ask if
>> it can be relicensed first.
>>
>
> IIRC, Kerberos implementation is available in the Apache Directory
> Server project, together with many other security related protocols
> and services.
>
> Cheers
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sat, Jul 4, 2009 at 12:41 PM, Peter Firmstone<ji...@zeus.net.au> wrote:
> I recently stumbled across a complete Java implementation of Kerberos Server
> and client software, I'm thinking there may be benefits for River running
> with a default authorisation setup, however it's GPL2, so I'd have to ask if
> it can be relicensed first.
IIRC, Kerberos implementation is available in the Apache Directory
Server project, together with many other security related protocols
and services.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Gregg,
I wasn't aware of that ;)
Cheers,
Peter.
Gregg Wonderly wrote:
> The Jini 2.0 software includes the ability to use NIO in the TCP
> endpoint. This is activated by system property
> "com.sun.jini.jeri.tcp.useNIO". If you look at TcpEndpoint and
> TcpServerEndpoint, you'll not find much different going on. The
> biggest issue with a typical network "distributed" system, is circular
> wait that can occur as systems "randomly" develop new connections to
> other system. Using a single thread to dispatch events in a server
> for "load handling" is not a good thing for any "work" that can have
> "external" contact. So, the use of NIO for
> "scalability" is find for things that don't end up interacting
> circularly. For things that you have no idea how they will interact,
> it's better to make sure that you have "new inbound call == new
> inbound thread" so that you don't get into problems. It may be that
> there is some work that you can do in a single thread, but that
> usually is something that a specific application optimizes.
>
> One way to do that is to use inbound calls to "queue" work. But then
> you need to use "callbacks" to notify the caller of the results of
> there request, unless you design a very custom invocation layer that
> allows the use of a "Future" or some other "signaling" mechanism to
> control when the result is sent back to the caller.
>
> Gregg Wonderly
>
> Elijah Menifee wrote:
>> I myself have started to play with NIO for prototyping a replacement
>> server
>> system for my company's software. While doing research on how to obtain
>> SSL/TLS connections on top of the NIO framework I came across Project
>> Grizzly <https://grizzly.dev.java.net/> which is a sub component of
>> the new
>> GlassFish server, as such it is dual licensed under CDDLv1 and GPLv2
>> (ClassPath exception for some parts listed at bottom of GlassFish
>> license<https://glassfish.dev.java.net/public/CDDL+GPL.html>
>> ).
>>
>> IANAL so I do not know if it is license compatible or not. If it is
>> it may
>> provide a good frame work for a low level threaded NIO server to
>> implement
>> Jini protocols on top of. My understanding is that there has been
>> work done
>> to get its transport layer to work for the Glassfish ORB. This includes
>> IIOP, not sure if it also includes RMI-IIOP, or how hard it would be
>> to get
>> the RMI-IIOP on top of their IIOP transport layer. ( I found this info
>> at Grizzly
>> Terminology
>> Blog<http://blogs.sun.com/harshag/entry/grizzly_1_7_0_terminology>).
>> I am currently evaulating it as a base server to implement my
>> company's
>> protocols on top of. Also it has been a while since I worked with Jini
>> technology (1.2.1), I assume it still uses RMI, and do not know if it
>> was
>> ever changed to support RMI-IIOP....But from what I have read it
>> should be
>> possible to implement custom protocols on top of Grizzly transport
>> layer.
>>
>> Although it has been fun learning the NIO framework, and building a
>> basic
>> threaded high-performance server has been a learning experience I am
>> still
>> only prototyping the next revision of our software. If I can get
>> Grizzly to
>> work with its SSL layer and worker thread management running our async
>> protocol and business logic I plan to pitch it to the other owners as
>> the
>> technology to use for the next major rewrite. I believe it would be a
>> better
>> solution than us maintaining our own low-level threaded NIO server,
>> thus we
>> only would have to maintain our protocol, business-logic, and
>> presentation
>> layers...
>>
>> P.S. According to the FSF GPLv3 is license compatible with the v2 Apache
>> License, so if the Kerberos stuff can be upgraded to GPLv3 (
>> sometimes the
>> license on software states or a later version..., or if they choose to
>> relicense it under GPLv3) it should be compatable.
>>
>> On Fri, Jul 3, 2009 at 11:41 PM, Peter Firmstone <ji...@zeus.net.au>
>> wrote:
>> ...
>>
>>> After that I'd like to play around with NIO and DEFLATE compression for
>>> serialization and http classserver performance improvements.
>>>
>>> I recently stumbled across a complete Java implementation of Kerberos
>>> Server and client software, I'm thinking there may be benefits for
>>> River
>>> running with a default authorisation setup, however it's GPL2, so
>>> I'd have
>>> to ask if it can be relicensed first.
>>>
>>> Cheers,
>>>
>>>
>>
>
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Gregg Wonderly <gr...@wonderly.org>.
The Jini 2.0 software includes the ability to use NIO in the TCP endpoint. This
is activated by system property "com.sun.jini.jeri.tcp.useNIO". If you look at
TcpEndpoint and TcpServerEndpoint, you'll not find much different going on. The
biggest issue with a typical network "distributed" system, is circular wait that
can occur as systems "randomly" develop new connections to other system. Using
a single thread to dispatch events in a server for "load handling" is not a good
thing for any "work" that can have "external" contact. So, the use of NIO for
"scalability" is find for things that don't end up interacting circularly. For
things that you have no idea how they will interact, it's better to make sure
that you have "new inbound call == new inbound thread" so that you don't get
into problems. It may be that there is some work that you can do in a single
thread, but that usually is something that a specific application optimizes.
One way to do that is to use inbound calls to "queue" work. But then you need
to use "callbacks" to notify the caller of the results of there request, unless
you design a very custom invocation layer that allows the use of a "Future" or
some other "signaling" mechanism to control when the result is sent back to the
caller.
Gregg Wonderly
Elijah Menifee wrote:
> I myself have started to play with NIO for prototyping a replacement server
> system for my company's software. While doing research on how to obtain
> SSL/TLS connections on top of the NIO framework I came across Project
> Grizzly <https://grizzly.dev.java.net/> which is a sub component of the new
> GlassFish server, as such it is dual licensed under CDDLv1 and GPLv2
> (ClassPath exception for some parts listed at bottom of GlassFish
> license<https://glassfish.dev.java.net/public/CDDL+GPL.html>
> ).
>
> IANAL so I do not know if it is license compatible or not. If it is it may
> provide a good frame work for a low level threaded NIO server to implement
> Jini protocols on top of. My understanding is that there has been work done
> to get its transport layer to work for the Glassfish ORB. This includes
> IIOP, not sure if it also includes RMI-IIOP, or how hard it would be to get
> the RMI-IIOP on top of their IIOP transport layer. ( I found this info
> at Grizzly
> Terminology Blog<http://blogs.sun.com/harshag/entry/grizzly_1_7_0_terminology>).
> I am currently evaulating it as a base server to implement my
> company's
> protocols on top of. Also it has been a while since I worked with Jini
> technology (1.2.1), I assume it still uses RMI, and do not know if it was
> ever changed to support RMI-IIOP....But from what I have read it should be
> possible to implement custom protocols on top of Grizzly transport layer.
>
> Although it has been fun learning the NIO framework, and building a basic
> threaded high-performance server has been a learning experience I am still
> only prototyping the next revision of our software. If I can get Grizzly to
> work with its SSL layer and worker thread management running our async
> protocol and business logic I plan to pitch it to the other owners as the
> technology to use for the next major rewrite. I believe it would be a better
> solution than us maintaining our own low-level threaded NIO server, thus we
> only would have to maintain our protocol, business-logic, and presentation
> layers...
>
> P.S. According to the FSF GPLv3 is license compatible with the v2 Apache
> License, so if the Kerberos stuff can be upgraded to GPLv3 ( sometimes the
> license on software states or a later version..., or if they choose to
> relicense it under GPLv3) it should be compatable.
>
> On Fri, Jul 3, 2009 at 11:41 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> ...
>
>> After that I'd like to play around with NIO and DEFLATE compression for
>> serialization and http classserver performance improvements.
>>
>> I recently stumbled across a complete Java implementation of Kerberos
>> Server and client software, I'm thinking there may be benefits for River
>> running with a default authorisation setup, however it's GPL2, so I'd have
>> to ask if it can be relicensed first.
>>
>> Cheers,
>>
>>
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Gregg Wonderly <ge...@cox.net>.
Yes, simply, JERI provides the abilities to plug into the whole stack through
concepts known as:
Endpoint - client and server interface to data transport over a media (network etc).
InvocationLayerFactory - Implements how Java invocation, data and results are
represented through the endpoint provided transport layer.
Constraints - specify controls for things such as security, QOS etc.
Exporter - Wraps the above three things together into something that hands you
back the thing that needs to go across the wire for someone to use remotely.
In a JavaSE-vs-JavaSE client-server relationship, all of these things "just
work". In a more restricted or non Java environment, these things provide the
layers of abstraction where you can separate Java from another language, or
otherwise circumvent something that needs to be done differently.
It really is quite powerful. I had an example coded up at one point, where a
server exported a proxy object that used the MODBUS prototol to write data to a
remote device as a the "method invocation actions" and the reply from the write,
or reads of other data values were the results returned from the invocation.
You have to be able to think in the "abstract" for these things to look like
"layers" and "pluggable" action points. But there is a lot of things possible.
The http://pastion.dev.java.net project has some example code that was used to
look into "password" based authentication. Today, I use variations on this in
my applications so that my customers can just configure users of the "system" to
allow people to use applications. Group based or User based authoriations can
then be used to control access to features of a service.
Gregg Wonderly
Peter Firmstone wrote:
> Hi Elijah,
>
> Look into JERI (part of River/Jini) before going down the RMI path, big
> improvements in security and not requiring pre compiled RMI stubs. JERI
> reuses some parts of RMI. JERI was intended as a replacement for RMI,
> however that's another story.
>
> There are significant advances made with regards to security since Jini
> 1.2.1, a significant achievement considering the problems overcome.
>
> The artice on JavaWorld: "Jini Starter Kit 2.0 tightens Jini's security
> framework" gives a good overview.
>
> Cheers,
>
> Peter.
>
> Elijah Menifee wrote:
>> I myself have started to play with NIO for prototyping a replacement
>> server
>> system for my company's software. While doing research on how to obtain
>> SSL/TLS connections on top of the NIO framework I came across Project
>> Grizzly <https://grizzly.dev.java.net/> which is a sub component of
>> the new
>> GlassFish server, as such it is dual licensed under CDDLv1 and GPLv2
>> (ClassPath exception for some parts listed at bottom of GlassFish
>> license<https://glassfish.dev.java.net/public/CDDL+GPL.html>
>> ).
>>
>> IANAL so I do not know if it is license compatible or not. If it is it
>> may
>> provide a good frame work for a low level threaded NIO server to
>> implement
>> Jini protocols on top of. My understanding is that there has been
>> work done
>> to get its transport layer to work for the Glassfish ORB. This includes
>> IIOP, not sure if it also includes RMI-IIOP, or how hard it would be
>> to get
>> the RMI-IIOP on top of their IIOP transport layer. ( I found this info
>> at Grizzly
>> Terminology
>> Blog<http://blogs.sun.com/harshag/entry/grizzly_1_7_0_terminology>).
>> I am currently evaulating it as a base server to implement my
>> company's
>> protocols on top of. Also it has been a while since I worked with Jini
>> technology (1.2.1), I assume it still uses RMI, and do not know if it was
>> ever changed to support RMI-IIOP....But from what I have read it
>> should be
>> possible to implement custom protocols on top of Grizzly transport layer.
>>
>> Although it has been fun learning the NIO framework, and building a basic
>> threaded high-performance server has been a learning experience I am
>> still
>> only prototyping the next revision of our software. If I can get
>> Grizzly to
>> work with its SSL layer and worker thread management running our async
>> protocol and business logic I plan to pitch it to the other owners as the
>> technology to use for the next major rewrite. I believe it would be a
>> better
>> solution than us maintaining our own low-level threaded NIO server,
>> thus we
>> only would have to maintain our protocol, business-logic, and
>> presentation
>> layers...
>>
>> P.S. According to the FSF GPLv3 is license compatible with the v2 Apache
>> License, so if the Kerberos stuff can be upgraded to GPLv3 ( sometimes
>> the
>> license on software states or a later version..., or if they choose to
>> relicense it under GPLv3) it should be compatable.
>>
>> On Fri, Jul 3, 2009 at 11:41 PM, Peter Firmstone <ji...@zeus.net.au>
>> wrote:
>> ...
>>
>>
>>> After that I'd like to play around with NIO and DEFLATE compression for
>>> serialization and http classserver performance improvements.
>>>
>>> I recently stumbled across a complete Java implementation of Kerberos
>>> Server and client software, I'm thinking there may be benefits for River
>>> running with a default authorisation setup, however it's GPL2, so I'd
>>> have
>>> to ask if it can be relicensed first.
>>>
>>> Cheers,
>>>
>>>
>>>
>>
>>
>
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Elijah,
Look into JERI (part of River/Jini) before going down the RMI path, big
improvements in security and not requiring pre compiled RMI stubs. JERI
reuses some parts of RMI. JERI was intended as a replacement for RMI,
however that's another story.
There are significant advances made with regards to security since Jini
1.2.1, a significant achievement considering the problems overcome.
The artice on JavaWorld: "Jini Starter Kit 2.0 tightens Jini's security
framework" gives a good overview.
Cheers,
Peter.
Elijah Menifee wrote:
> I myself have started to play with NIO for prototyping a replacement server
> system for my company's software. While doing research on how to obtain
> SSL/TLS connections on top of the NIO framework I came across Project
> Grizzly <https://grizzly.dev.java.net/> which is a sub component of the new
> GlassFish server, as such it is dual licensed under CDDLv1 and GPLv2
> (ClassPath exception for some parts listed at bottom of GlassFish
> license<https://glassfish.dev.java.net/public/CDDL+GPL.html>
> ).
>
> IANAL so I do not know if it is license compatible or not. If it is it may
> provide a good frame work for a low level threaded NIO server to implement
> Jini protocols on top of. My understanding is that there has been work done
> to get its transport layer to work for the Glassfish ORB. This includes
> IIOP, not sure if it also includes RMI-IIOP, or how hard it would be to get
> the RMI-IIOP on top of their IIOP transport layer. ( I found this info
> at Grizzly
> Terminology Blog<http://blogs.sun.com/harshag/entry/grizzly_1_7_0_terminology>).
> I am currently evaulating it as a base server to implement my
> company's
> protocols on top of. Also it has been a while since I worked with Jini
> technology (1.2.1), I assume it still uses RMI, and do not know if it was
> ever changed to support RMI-IIOP....But from what I have read it should be
> possible to implement custom protocols on top of Grizzly transport layer.
>
> Although it has been fun learning the NIO framework, and building a basic
> threaded high-performance server has been a learning experience I am still
> only prototyping the next revision of our software. If I can get Grizzly to
> work with its SSL layer and worker thread management running our async
> protocol and business logic I plan to pitch it to the other owners as the
> technology to use for the next major rewrite. I believe it would be a better
> solution than us maintaining our own low-level threaded NIO server, thus we
> only would have to maintain our protocol, business-logic, and presentation
> layers...
>
> P.S. According to the FSF GPLv3 is license compatible with the v2 Apache
> License, so if the Kerberos stuff can be upgraded to GPLv3 ( sometimes the
> license on software states or a later version..., or if they choose to
> relicense it under GPLv3) it should be compatable.
>
> On Fri, Jul 3, 2009 at 11:41 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> ...
>
>
>> After that I'd like to play around with NIO and DEFLATE compression for
>> serialization and http classserver performance improvements.
>>
>> I recently stumbled across a complete Java implementation of Kerberos
>> Server and client software, I'm thinking there may be benefits for River
>> running with a default authorisation setup, however it's GPL2, so I'd have
>> to ask if it can be relicensed first.
>>
>> Cheers,
>>
>>
>>
>
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Firmstone <ji...@zeus.net.au>.
Elijah Menifee wrote:
> I myself have started to play with NIO for prototyping a replacement server
> system for my company's software. While doing research on how to obtain
> SSL/TLS connections on top of the NIO framework
<snip>
Haven't looked into it enough yet as I'm working on the jtreg tests,
time permitting, my plan was to implement the SSL/TLS handshake using
the SSLEngine API, creating SSLServerSocketChannel and SSLSocketChannel
classes and using byte buffers for IO, id did look like lots of work!
But if someone already implemented something to make life easier & it
works, lets use that. Iain suggested Apache Mina, as it uses the Apache
License, looks interesting, reportedly easy to use and quite fast too,
hmm even has a jzlib compression filter, that can be switched off and on
dynamically, good for bandwidth limited networks, not sure if filter is
the right terminology though as filters generally remove something,
translator might have conveyed better meaning; ). Mina 1.1 is the one
to use for Java 5 or later or Mina 1 for Java 1.4 I wonder if this
would provide the opportunity to remove some existing code in River to
streamline it a bit. Thoughts anyone?
Apache Triplesec, depends on Mina too, I want to look into Triplesec to
see if that could prove useful too, later down the track.
While on the topic of Security, I recall Jim Waldo in one of his
interviews/ talks, wondering if Security has been "done right" in Jini
(River), I think he was referring to the leaving of security as a
concern for administrators (pls correct me if I'm wrong) and suggesting
programmers needing to think more about security. I personally like the
way Security is handled by proxy's, so I think that what Jim was
referring to, was perhaps the default (out of the box) settings for
security and the configurability of Security. Security is difficult,
how can we make it easier?
Your thoughts?
Cheers,
Peter.
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Elijah Menifee <el...@gmail.com>.
I myself have started to play with NIO for prototyping a replacement server
system for my company's software. While doing research on how to obtain
SSL/TLS connections on top of the NIO framework I came across Project
Grizzly <https://grizzly.dev.java.net/> which is a sub component of the new
GlassFish server, as such it is dual licensed under CDDLv1 and GPLv2
(ClassPath exception for some parts listed at bottom of GlassFish
license<https://glassfish.dev.java.net/public/CDDL+GPL.html>
).
IANAL so I do not know if it is license compatible or not. If it is it may
provide a good frame work for a low level threaded NIO server to implement
Jini protocols on top of. My understanding is that there has been work done
to get its transport layer to work for the Glassfish ORB. This includes
IIOP, not sure if it also includes RMI-IIOP, or how hard it would be to get
the RMI-IIOP on top of their IIOP transport layer. ( I found this info
at Grizzly
Terminology Blog<http://blogs.sun.com/harshag/entry/grizzly_1_7_0_terminology>).
I am currently evaulating it as a base server to implement my
company's
protocols on top of. Also it has been a while since I worked with Jini
technology (1.2.1), I assume it still uses RMI, and do not know if it was
ever changed to support RMI-IIOP....But from what I have read it should be
possible to implement custom protocols on top of Grizzly transport layer.
Although it has been fun learning the NIO framework, and building a basic
threaded high-performance server has been a learning experience I am still
only prototyping the next revision of our software. If I can get Grizzly to
work with its SSL layer and worker thread management running our async
protocol and business logic I plan to pitch it to the other owners as the
technology to use for the next major rewrite. I believe it would be a better
solution than us maintaining our own low-level threaded NIO server, thus we
only would have to maintain our protocol, business-logic, and presentation
layers...
P.S. According to the FSF GPLv3 is license compatible with the v2 Apache
License, so if the Kerberos stuff can be upgraded to GPLv3 ( sometimes the
license on software states or a later version..., or if they choose to
relicense it under GPLv3) it should be compatable.
On Fri, Jul 3, 2009 at 11:41 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
...
> After that I'd like to play around with NIO and DEFLATE compression for
> serialization and http classserver performance improvements.
>
> I recently stumbled across a complete Java implementation of Kerberos
> Server and client software, I'm thinking there may be benefits for River
> running with a default authorisation setup, however it's GPL2, so I'd have
> to ask if it can be relicensed first.
>
> Cheers,
>
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Firmstone <ji...@zeus.net.au>.
That would be Ideal, avoids the hassles testing from behind firewalls
etc, provided it is still a valid test case. Anyone have experience
with PAW (pro-active web filter) written in Java?
Anyone want to jump in & help?
Cheers,
Peter.
Gregg Wonderly wrote:
> Can we have a small proxy server run as part of the test script that
> would start it and stop it and just use localhost connections?
>
> Gregg Wonderly
>
> Peter Firmstone wrote:
>> Hi Elijah,
>>
>> To test HTTP proxy support for the net.jini.jeri.http transport
>> implementation.
>>
>> It's listed under JIRA as issue RIVER-306
>> https://issues.apache.org/jira/browse/RIVER-306
>>
>> Sun originally had a Squid http proxy server on their network, it's
>> hostname was jiniproxy, it's hardcoded into one of the jtreg tests;
>> net/jini/jeri/http/echo/EchoImpl.java
>>
>> I want to have all tests running before releasing AR2. In order to
>> stimulate a more agile development model, were trying to make the
>> integration test suite and the jtreg unit and regression tests more
>> developer friendly (easier to setup and run using ant). The junit
>> test framework has also been adopted recently.
>>
>> Once testing is working properly, I'd like to look at the
>> implementation of jini over http networks based on the work that Mark
>> Brouwer did in the Seven project. He made a presentation at JCM10,
>> the slides for which are still available. If you want to check the
>> Seven project out, add the following to your Internet host table
>> (/etc/hosts) as DNS lookup no longer works:
>>
>> 62.177.181.217 www.cheiron.org scm.cheiron.org issue.cheiron.org
>>
>> After that I'd like to play around with NIO and DEFLATE compression
>> for serialization and http classserver performance improvements.
>>
>> I recently stumbled across a complete Java implementation of Kerberos
>> Server and client software, I'm thinking there may be benefits for
>> River running with a default authorisation setup, however it's GPL2,
>> so I'd have to ask if it can be relicensed first.
>>
>> Cheers,
>>
>> Peter.
>>
>> Elijah Menifee wrote:
>>> What roll does the Squid proxy on Sun's network play on
>>> building/testing/releasing AR2?
>>>
>>> On Fri, Jul 3, 2009 at 7:22 PM, Peter Firmstone <ji...@zeus.net.au>
>>> wrote:
>>>
>>>
>>>> That's almost the plan, just want to get all the tests right first
>>>> and a
>>>> couple of tweaks to the build then release. It's almost ready,
>>>> I've just
>>>> been very busy and haven't gotten onto it yet. Not much work left
>>>> though.
>>>>
>>>> On that subject, I'm having some trouble deciding on a solution to
>>>> replace
>>>> the Squid proxy server that was present on Sun's network? Any ideas?
>>>>
>>>> Cheers,
>>>>
>>>> Peter.
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Gregg Wonderly <gr...@wonderly.org>.
Can we have a small proxy server run as part of the test script that would start
it and stop it and just use localhost connections?
Gregg Wonderly
Peter Firmstone wrote:
> Hi Elijah,
>
> To test HTTP proxy support for the net.jini.jeri.http transport
> implementation.
>
> It's listed under JIRA as issue RIVER-306
> https://issues.apache.org/jira/browse/RIVER-306
>
> Sun originally had a Squid http proxy server on their network, it's
> hostname was jiniproxy, it's hardcoded into one of the jtreg tests;
> net/jini/jeri/http/echo/EchoImpl.java
>
> I want to have all tests running before releasing AR2. In order to
> stimulate a more agile development model, were trying to make the
> integration test suite and the jtreg unit and regression tests more
> developer friendly (easier to setup and run using ant). The junit test
> framework has also been adopted recently.
>
> Once testing is working properly, I'd like to look at the implementation
> of jini over http networks based on the work that Mark Brouwer did in
> the Seven project. He made a presentation at JCM10, the slides for
> which are still available. If you want to check the Seven project out,
> add the following to your Internet host table (/etc/hosts) as DNS lookup
> no longer works:
>
> 62.177.181.217 www.cheiron.org scm.cheiron.org issue.cheiron.org
>
> After that I'd like to play around with NIO and DEFLATE compression for
> serialization and http classserver performance improvements.
>
> I recently stumbled across a complete Java implementation of Kerberos
> Server and client software, I'm thinking there may be benefits for River
> running with a default authorisation setup, however it's GPL2, so I'd
> have to ask if it can be relicensed first.
>
> Cheers,
>
> Peter.
>
> Elijah Menifee wrote:
>> What roll does the Squid proxy on Sun's network play on
>> building/testing/releasing AR2?
>>
>> On Fri, Jul 3, 2009 at 7:22 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>
>>
>>> That's almost the plan, just want to get all the tests right first and a
>>> couple of tweaks to the build then release. It's almost ready, I've
>>> just
>>> been very busy and haven't gotten onto it yet. Not much work left
>>> though.
>>>
>>> On that subject, I'm having some trouble deciding on a solution to
>>> replace
>>> the Squid proxy server that was present on Sun's network? Any ideas?
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>
>>
>
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Elijah,
To test HTTP proxy support for the net.jini.jeri.http transport
implementation.
It's listed under JIRA as issue RIVER-306
https://issues.apache.org/jira/browse/RIVER-306
Sun originally had a Squid http proxy server on their network, it's
hostname was jiniproxy, it's hardcoded into one of the jtreg tests;
net/jini/jeri/http/echo/EchoImpl.java
I want to have all tests running before releasing AR2. In order to
stimulate a more agile development model, were trying to make the
integration test suite and the jtreg unit and regression tests more
developer friendly (easier to setup and run using ant). The junit test
framework has also been adopted recently.
Once testing is working properly, I'd like to look at the implementation
of jini over http networks based on the work that Mark Brouwer did in
the Seven project. He made a presentation at JCM10, the slides for
which are still available. If you want to check the Seven project out,
add the following to your Internet host table (/etc/hosts) as DNS lookup
no longer works:
62.177.181.217 www.cheiron.org scm.cheiron.org issue.cheiron.org
After that I'd like to play around with NIO and DEFLATE compression for
serialization and http classserver performance improvements.
I recently stumbled across a complete Java implementation of Kerberos
Server and client software, I'm thinking there may be benefits for River
running with a default authorisation setup, however it's GPL2, so I'd
have to ask if it can be relicensed first.
Cheers,
Peter.
Elijah Menifee wrote:
> What roll does the Squid proxy on Sun's network play on
> building/testing/releasing AR2?
>
> On Fri, Jul 3, 2009 at 7:22 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>
>> That's almost the plan, just want to get all the tests right first and a
>> couple of tweaks to the build then release. It's almost ready, I've just
>> been very busy and haven't gotten onto it yet. Not much work left though.
>>
>> On that subject, I'm having some trouble deciding on a solution to replace
>> the Squid proxy server that was present on Sun's network? Any ideas?
>>
>> Cheers,
>>
>> Peter.
>>
>>
>
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Elijah Menifee <el...@gmail.com>.
What roll does the Squid proxy on Sun's network play on
building/testing/releasing AR2?
On Fri, Jul 3, 2009 at 7:22 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> That's almost the plan, just want to get all the tests right first and a
> couple of tweaks to the build then release. It's almost ready, I've just
> been very busy and haven't gotten onto it yet. Not much work left though.
>
> On that subject, I'm having some trouble deciding on a solution to replace
> the Squid proxy server that was present on Sun's network? Any ideas?
>
> Cheers,
>
> Peter.
>
Re: [Was: OSGi and Jini] Now -> Next Steps
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dennis Reedy wrote:
> Forget about OSGi for now, its a red herring for River moving out of
> incubation, and frankly a bit of noise that produces the same reaction
> every time it is posted. This is not to say the each technology
> (combined or separate) does not have its merits/issues, its just time
> to move on.
>
> How about AR2 gets released? Take the current project structure and
> tests, and release what you have. I think its a safe bet to say that
> the trunk represents a stable production worthy technology (AR1
> certainly is). If there is more wok to do with the testing framework,
> fine. Then release AR3 shortly there-after. I'll be glad to upload the
> package name changes from com.sun.jini to org.apache.river as well if
> the timing is right post AR2.
That's almost the plan, just want to get all the tests right first and a
couple of tweaks to the build then release. It's almost ready, I've
just been very busy and haven't gotten onto it yet. Not much work left
though.
On that subject, I'm having some trouble deciding on a solution to
replace the Squid proxy server that was present on Sun's network? Any
ideas?
Cheers,
Peter.
>
>
> On Jul 3, 2009, at 1125AM, Sam Chance wrote:
>
>> Well said, Jukka!
>>
>> Gregg, I say you do something with Jini and OSGi. :-) Seriously, what
>> about a semantic LUS? Build a way to query for Services using Semantic
>> technologies like RDF and SPARQL. Or use Jini to manage distributed
>> OSGi
>> bundles (RDF 119 is Distributed OSGi). Or build an AJAX front-end for
>> lifecycle management of Jini federations and services.
>>
>> Just some thoughts.
>>
>>
>> On Fri, Jul 3, 2009 at 5:26 AM, Jukka Zitting
>> <ju...@gmail.com>wrote:
>>
>>> Hi,
>>>
>>> On Mon, Jun 29, 2009 at 10:20 PM, Gregg Wonderly<gr...@wonderly.org>
>>> wrote:
>>>> What happens next is what the community decides. I'd like to play a
>>> part,
>>>> but to date, everything that I've found to be interesting and
>>>> wanted to
>>> do
>>>> differently in Jini has not been that interesting to the rest of the
>>>> community.
>>>
>>> Does it matter? Apart from the the test suite there currently is no
>>> active work being done on River trunk. Anyone with the energy to back
>>> up his or her proposals with solid patches gets to decide where River
>>> is going. If others don't agree, they'll need to come up with
>>> alternative patches that solve the same issues.
>>>
>>>> So, I'm setting back, waiting for something to start rolling that I am
>>>> interested in, and I'll jump in to assist as best I can, as I am
>>>> needed.
>>>
>>> That's the wrong attitude. Just get started and others will follow! At
>>> Apache those who do, decide.
>>>
>>> BR,
>>>
>>> Jukka Zitting
>>>
>>
>>
>>
>> --
>> Sam Chance
>> 443-694-5293 (m)
>> 410-694-0240 x108 (o)
>
>