Well, there's an interesting development on Jenkins, in the refactoring
branch, OSX and Solaris have identical test failures.
Peter Firmstone wrote:
Sure has, that bug's responsible for the entire qa refactoring branch
and it manifests itself in different tests from time to time.
I haven't
Dennis Reedy (JIRA) wrote:
Dennis Reedy created RIVER-417:
--
Summary: com.sun.jini.outrigger.FastList fails to compile using
Java 7
Key: RIVER-417
URL: https://issues.apache.org/jira/browse/RIVER-417
Dennis Reedy wrote:
On Feb 8, 2013, at 1055PM, Peter Firmstone wrote:
Dennis Reedy (JIRA) wrote:
Dennis Reedy created RIVER-417:
--
Summary: com.sun.jini.outrigger.FastList fails to compile using
Java 7
Key: RIVER-417
On 27/01/2013 7:57 AM, Tim Blackman wrote:
On Jan 26, 2013, at 8:26 AM, Peter Firmstonej...@zeus.net.au wrote:
There are parts of Jini that depend on proprietary sun jvm namespace,
preventing it from compiling on other jvm's:
Compiling 863 source files to
An interesting point:
Q: Unicast discovery can use JERI-SSL Endpoint's but is not subject to
the unmarshalling attack, why not?
A: It doesn't use unmarshalling, instead, the connection is
authenticated before the proxy is downloaded. Discovery code already
knows the interface to expect:
Gregg Wonderly wrote:
On Jan 3, 2013, at 6:58 AM, Peter Firmstone j...@zeus.net.au wrote:
Gregg Wonderly wrote:
I too use static locator configuration because I am usually one of the
administrators across a VPN connection, and my other users are remote users,
not local
a
network infrastructure issue.
Gregg
On Jan 2, 2013, at 4:49 AM, Peter Firmstone j...@zeus.net.au wrote:
Dan Creswell wrote:
On 1 January 2013 09:48, Peter Firmstone j...@zeus.net.au wrote:
You might remember an earlier discussion on the list about
StreamServiceRegistrar:
public
Looks like a network configuration problem on solaris jenkins.
java.net.UnknownHostException: -s: -s
at java.net.InetAddress.getLocalHost(InetAddress.java:1354)
at
com.sun.jini.test.spec.discoveryservice.AbstractBaseTest.getTestLocator(AbstractBaseTest.java:2435)
at
Dan Creswell wrote:
These methods could easily return jini://host:port for standard Jini
unicast
discovery, this allows a lot more freedom for future expansion of
discovery
methods, for very little effort.
How would you see these being used in a real system? Would I want
these URL's
You might remember an earlier discussion on the list about
StreamServiceRegistrar:
public interface StreamServiceRegistrar extends ServiceRegistrar{
ResultStream lookup(ServiceTemplate tmpl, Class[] entryClasses,
int maxBatchSize, int limit) throws IOException;
}
ResultStream is
Happy new year Apache River!
.
Cheers,
Peter.
Peter Firmstone wrote:
First stage of refactoring complete.
[java] -
[java]
[java] # of tests started = 1412
[java] # of tests completed = 1412
[java] # of tests skipped = 46
[java] # of tests passed= 1412
();
}
Peter Firmstone wrote:
I've completed the first phase of refactoring, separating out the
environment setup and test run into separate interfaces as per
appended. This should allow the setup and teardown and execution of
the tests to remain separate concerns. At present all tests
not recognized
*/
int UNKNOWN = 5;
/**
* Execute the body of the test.
*
* @throws Exception if the test fails for any reason
*/
void run() throws Exception;
}
Regards,
Peter.
Peter Firmstone wrote:
Presently most tests have a lot of shared mutable state
();
}
Peter Firmstone wrote:
I've completed the first phase of refactoring, separating out the
environment setup and test run into separate interfaces as per
appended. This should allow the setup and teardown and execution of
the tests to remain separate concerns. At present all tests implement
Trunk revision 1378973 appears relatively stable, and has passed all
tests on Windows, Ubuntu and Solaris, there were 6 test falures on arm
(5 less than any other build tested).
I'm currently using a branch of revision 1378973 to refactor the qa suite.
The current trunk revision is almost
We presently have about 83 junit tests, at least 1/3 are rewritten qa
tests, so yes it is possible in test cases where you don't need services
or other infrastructure running.
On 3/12/2012 6:29 AM, Gregg Wonderly wrote:
I concur that include JUnit for unit testing would be a good thing, and
+1 Peter.
On 3/12/2012 4:35 AM, Dan Creswell wrote:
Nice to hear from you Patricia...
On 2 December 2012 10:29, Patricia Shanahanp...@acm.org wrote:
On Nov 30, 2012, at 9:43 PM, Peter Firmstone j...@zeus.net.au wrote:
On 30/11/2012 12:27 AM, Dan Creswell wrote:
On 29 November 2012 13:11, Peter Firmstonej...@zeus.net.au wrote:
The last passing trunk versions:
Jdk6 Ubuntu 1407017
Solaris x861373770
Jdk7 Ubuntu
Presently most tests have a lot of shared mutable state.
This isn't helped by the setup(QAConfig) mutator method in the Test
interface appended.
An alternative might be:
public Test setup(QAConfig config) throws Exception;
This would allow the test to return another Test object, fully
On 30/11/2012 12:27 AM, Dan Creswell wrote:
On 29 November 2012 13:11, Peter Firmstonej...@zeus.net.au wrote:
The last passing trunk versions:
Jdk6 Ubuntu 1407017
Solaris x861373770
Jdk7 Ubuntu 1379873
Windows 1373770
Revision 1373770 looks the most stable, I
On 29/11/2012 9:54 PM, Simon IJskes - QCG wrote:
On 29-11-12 12:34, Peter Firmstone wrote:
Oh, BTW, when I turned off debugging I had 6 tests fail, then after
running again only 2 tests failed; my recent patches haven't solved
concurrency issues, debugging masked it.
Sorry to hear that. I've
On 29/11/2012 10:04 PM, Simon IJskes - QCG wrote:
On 29-11-12 12:34, Peter Firmstone wrote:
I think that's wise equally I'm pondering how you cope with trunk
moving on
and breaking a bunch of your tests for which there would be fixes in
the
trunk test suite. Are you happy doing merges
On 29/11/2012 10:04 PM, Peter Firmstone wrote:
On 29/11/2012 9:54 PM, Simon IJskes - QCG wrote:
On 29-11-12 12:34, Peter Firmstone wrote:
Oh, BTW, when I turned off debugging I had 6 tests fail, then after
running again only 2 tests failed; my recent patches haven't solved
concurrency issues
I'd like to make a suggestion:
Can we have a shared skunk branch? At present we each have our own
skunk branches.
I think that what Sim was trying to achieve was a more cohesive
collaborative approach by developing in trunk, I think we could have
that with a shared skunk development
On 28/11/2012 11:50 PM, Simon IJskes - QCG wrote:
On 28-11-12 14:40, Peter Firmstone wrote:
At stable points the skunk development branch can replace trunk. We
might have a period of refactoring and bug fixing, followed by a period
of stabilisation, testing and documenting, before replacing
On 27/11/2012 10:12 PM, Simon IJskes - QCG wrote:
On 27-11-12 12:58, Peter Firmstone wrote:
When faced with difficult concurrency problems, I've had success in the
past by refactoring. Trouble with concurrency bugs; you can't always
tell where they are, consider it a brute force debugging
Ok,
The unicast socket didn't have a timeout set, the harness was stuck on
.join() waiting for the socket to close.
The tests still failing but it's no longer hanging.
Cheers,
Peter.
Peter Firmstone wrote:
Ok this time I've got 3 separate jvm stacks and a stack trace, and the
test
Peter Firmstone wrote:
Ok,
The unicast socket didn't have a timeout set, the harness was stuck on
.join() waiting for the socket to close.
The tests still failing but it's no longer hanging.
Cheers,
Peter.
I set a timeout on the socket, the test fails and exits, but now I've
got a stale
Sorry, there's so much detail it's difficult to see what's going on, and
it looks like I only pasted the Server stack, oops. The test isn't
timing out as it should, I'll run it again and grab the client stack, I
killed the test after 2 hours, so the test was definitely deadlocked.
There are
Ok this time I've got 3 separate jvm stacks and a stack trace, and the
test is deadlocked (cpu idle):
[java] Running
com/sun/jini/test/spec/lookupdiscovery/MulticastMonitorStopReplace.td
[java] Time is Sat Nov 24 16:47:24 EST 2012
[java] Starting test in separate process with
The good news, is the arm platform is now down to only 11 failing tests
(previously 294):
[java] -
[java]
com/sun/jini/test/spec/lookupdiscovery/MulticastMonitorStopReplace.td
[java] Test Failed: Test Failed:
.
A netstat output at the point when failure occurs would be very helpful
and any help is much appreciated.
Regards,
Peter.
On 22/11/2012 7:39 PM, Simon IJskes - QCG wrote:
On 22-11-12 10:18, Peter Firmstone wrote:
I tried SO_REUSEADDR on an earlier attempt, that didn't work either
On 22/11/2012 8:22 PM, Simon IJskes - QCG wrote:
On 22-11-12 11:16, Dan Creswell wrote:
See, if it wasn't on trunk, the changes would be less of a big deal.
It'd
be natural to check one's work in (whether it be an in-progress test
snapshot or otherwise), good discipline even.
Yes. I would
Reading over the comments, we all appear to be agreeing on Gregg's
approach, in that case I'll clean up LookupLocator before release, then
we can look at how we can implement a configurable deployment mechanism.
Regards,
Peter.
On 14/11/2012 8:28 PM, Dan Creswell wrote:
...
On 14 November
you need it?
Regards,
Peter.
On 14/11/2012 9:45 PM, Simon IJskes - QCG wrote:
On 14-11-12 11:50, Peter Firmstone wrote:
Reading over the comments, we all appear to be agreeing on Gregg's
approach, in that case I'll clean up LookupLocator before release, then
we can look at how we can implement
On 14/11/2012 11:00 PM, Simon IJskes - QCG wrote:
On 14-11-12 13:52, Peter Firmstone wrote:
I'm familiar with the ConstrainableLookupLocator code, I could knock it
up for you in about 10 min, I actually did this when I realised the
SocketFactory in LookupLocator wasn't being used
Presently LookupLocator is practically a URI of the form
jini://hostname:port
LookupLocator is constructed during multicast discovery at the client.
ConstrainableLookupLocator is a subclass that implements constraints.
LookupLocatorDiscovery also accepts LookupLocator to perform unicast
Simon IJskes - QCG wrote:
On 10-11-12 12:51, Peter Firmstone wrote:
Why did you not use ServerSocket.setReuseAddress(true)?
3. You can't reconnect to the same remote TCP IP address during the
TIME_WAIT period.
Which caveat are you refering to? TIME_WAIT? You mean at the client
I'm trying to solve failures on the ARM platform, for now I've changed the Reggie ServerSocket to wait for 4 minutes for the
TCP TIME_WAIT period then retry, unfortunately the port is still in use after waiting, which tends to indicate a stale process.
Reggie works in other tests, at least
Simon IJskes - QCG wrote:
On 10-11-12 21:53, Peter Firmstone wrote:
It's set to true for most Unix platforms, as far as I'm aware. If the
client side remotely closes the ServerSocket, then there's no TIME_WAIT
period, it's only when the ServerSocket is closed by the server.
I'm kinda stretched
Ubuntu x64 JDK6 is passing.
Solaris sparc JDK6 is passing.
Ubuntu x64 JDK7 one test failure:
[java] -
[java] com/sun/jini/test/spec/lookupdiscovery/MulticastMonitorAllChange.td
[java] Test Failed: Test Failed:
be to
retrieve it across an https: connection, the server is authenticated.
The https codebase server could be granted sufficient permission based
on it's URL, perhaps using RemotePolicy, or using a local policy file.
Are we going too far? Thoughts?
Cheers,
Peter.
Peter Firmstone wrote
Dan Creswell wrote:
One thing...
On 9 November 2012 10:44, Peter Firmstone j...@zeus.net.au wrote:
Motivated by Sim's suggestions:
Any objection to changing it to net.jini.io.**MarshalClassResolverSPI?
This places it right where it's needed.
Since all URI in a code base string
Simon IJskes - QCG wrote:
On 09-11-12 00:31, Peter Firmstone wrote:
Ok, because it's small I think we can consider it, can you provide the
hooks to load different providers? The non default providers themselves
can be a subproject. We need to carefully consider security since we're
making
Simon IJskes - QCG wrote:
On 09-11-12 11:44, Peter Firmstone wrote:
Motivated by Sim's suggestions:
Any objection to changing it to net.jini.io.MarshalClassResolverSPI?
Leave it near net.jini.loader.ClassLoading. I would have implemented
it in ClassLoading if i wasn't concerned about
Simon IJskes - QCG wrote:
On 09-11-12 13:49, Peter Firmstone wrote:
Simon IJskes - QCG wrote:
On 09-11-12 11:44, Peter Firmstone wrote:
Motivated by Sim's suggestions:
Any objection to changing it to net.jini.io.MarshalClassResolverSPI?
Leave it near net.jini.loader.ClassLoading. I would
Simon IJskes - QCG wrote:
On 09-11-12 13:48, Peter Firmstone wrote:
Simon IJskes - QCG wrote:
On 09-11-12 00:31, Peter Firmstone wrote:
Ok, because it's small I think we can consider it, can you provide the
hooks to load different providers? The non default providers
themselves
can
Simon IJskes - QCG wrote:
On 08-11-12 13:40, Peter Firmstone wrote:
Yes, but lets play around with it in skunk. Dan's made some valid
Indeed Dan has made valid remarks, but i really dont like skunk. Tom
suggested sub projects once. I did not see any benefits at that time.
But i think
Ok, found the problem, there's a bug on line 99 in
net.jini.loader.RiverClassLoader
You didn't really test this properly did you?
No biggy.
Too busy to help any further (2 hour road trip now).
Peter.
Peter Firmstone wrote:
Ok I've had a brief look at debugging failing tests, it's worth
Simon IJskes - QCG wrote:
On 28-10-12 15:47, Simon IJskes - QCG wrote:
On 28-10-12 15:45, Simon IJskes - QCG wrote:
On 28-10-12 15:43, Tom Hobbs wrote:
Can someone refresh my memory, please? I recall a few months ago we
were
talking about gearing up for a release. Is there any reason why we
Simon IJskes - QCG wrote:
On 01-11-12 14:35, Gerard Fulton wrote:
Sounds like the tests might need to be refactored.
Indeed. Or a revert of the patches causing the tests to fail.
Gr. Simon
Er, no, the URI patches aren't causing the tests to fail, the tests are
configured with unsupported
Simon IJskes - QCG wrote:
There are a lot URI/URL related test failures. What are we going to do
about it?
Gr. Simon
The URI strings are non compliant.
An array of URL strings separated by spaces are used for codebase
annotations, so any spaces must be escaped prior to being used in
Simon IJskes - QCG wrote:
On 20-09-12 08:37, Peter Firmstone wrote:
We need to look at how these codebase annotations are being generated,
escape any illegal characters and normalise them.
Would that involve modifying the core or just the tests?
The test harness. QAConfig I suspect
Thanks Bishnu, welcome to River!
I've had some plans with regard to internet based services, not much
implemented I'm afraid, time constraints...
1. org.apache.river.api.lookup.StreamServiceRegistrar - interface for
internet based service registrars (lookup service).
2. DNS-SRV
On 27/08/2012 10:43 AM, Dennis Reedy wrote:
On Aug 26, 2012, at 723PM, Gregg Wonderly wrote:
On Aug 26, 2012, at 5:12 PM, Dennis Reedydennis.re...@gmail.com wrote:
Gregg,
If you want to use Netbeans RCP, then why not consider making everything
OSGi-able? We are using a Netbeans RCP front
, IMO.
Cheers,
Greg.
On Thu, 2012-08-23 at 08:54, Peter Firmstone wrote:
Enabling developers to develop services in IDE's like Netbeans was the
original motivator (Gregg Wonderly), see
https://issues.apache.org/jira/browse/RIVER-336
Regards,
Peter.
On 23/08/2012 8:57 PM, Simon IJskes
On 20/08/2012 10:07 AM, GREGG WONDERLY wrote:
The point of my changes was to make it possible for arbitrary behaviors. What you
describe below, could be done as a version of the SPI.
Thanks Gregg, glad you're still participating.
That's my intent, to determine what, if anything else, is
As you know Gregg's contributed his CodebaseAccessClassLoader
alternative to RMIClassLoader.
I figure we need to review MarshalInputStream and MarshalOutputStream, a
final interface for CodebaseAccessClassLoader and expected behaviour of
Class loading.
I'm also considering class loading for
On 16/08/2012 4:02 PM, Apache Jenkins Server wrote:
Seehttps://builds.apache.org/job/River-QA-windows/53/
Well that's a milestone, that's the first time the River qa test suite
has run successfully native on Windows, without cigwin or any other
assistance.
Guess we can finally say Windows
Gregg,
Just thought I'd bring this back from previous list discussion, as it
displays some of the issues you had to overcome.
Cheers,
Peter.
Gregg Wonderly wrote:
Okay, I've done some more digging and thinking and one of the primary
issues I believe, comes down to how containers, whether
Just thought I'd get a little clarification on how
CodebaseAccessClassLoader should work and whether it needs any further
refinements or tweaks. I'm currently patching CodebaseAccessClassLoader
back into the main trunk, so it can make the next release.
All references to RMIClassLoader static
Dolan wrote:
I say file a bug against the underscore. I've fought this battle before and
lost...
http://domainkeys.sourceforge.net/underscore.html
Chris
-Original Message-
From: Peter Firmstone [mailto:j...@zeus.net.au]
Sent: Monday, August 06, 2012 7:39 AM
To:dev@river.apache.org
Subject
the underscore. I've fought this battle before
and lost...
http://domainkeys.sourceforge.**net/underscore.htmlhttp://domainkeys.sourceforge.net/underscore.html
Chris
-Original Message-
From: Peter Firmstone [mailto:j...@zeus.net.au]
Sent: Monday, August 06, 2012 7:39 AM
To:dev@river.apache.org
This is a bit of a milestone, it's the first Hudson Windows build where
no tests failed, a minor misconfiguration error spoiled it.
Cheers,
Peter.
On 5/08/2012 7:31 PM, Apache Jenkins Server wrote:
Seehttps://builds.apache.org/job/River-QA-windows/48/changes
Changes:
[peter_firmstone]
Gregg Wonderly wrote:
On Jul 7, 2012, at 8:02 AM, Peter Firmstone wrote:
These doAs methods in this case cannot elevate Permission, they can reduce
Permission to that which the Subject has in common with other code on the
stack, but it cannot be used by code to gain privilege if it uses
Getting much closer to passing all tests on Windows without cigwin.
-
-
# of tests started = 1412
# of tests started = 1412
# of tests completed = 1412
# of tests completed = 1412
# of tests skipped = 46
# of
:02 AM, Peter Firmstone wrote:
These doAs methods in this case cannot elevate Permission, they can reduce
Permission to that which the Subject has in common with other code on the
stack, but it cannot be used by code to gain privilege if it uses a custom
DomainCombiner that extends
All recent build failures appear to be related to a problem with svn,
Hudson's not updating correctly. I changed one test to perform a clean
checkout, but checkout didn't work either.
I'm running my own tests over the weekend, I'll report on the results.
Apache Jenkins Server wrote:
See
Consider a Subject ProtectionDomain that is added to the stack, instead of
Subject Principals being injected into every domain on the stack:
Subjects don't have code, they lack the ability to use one permission to gain
another, so if a ProtectionDomain representing only a Subject and its
Hmm,
Don't know what's happening here, these two tests pass on my machine.
[java] SUMMARY =
[java]
[java] com/sun/jini/test/impl/discoverymanager/BadDiscoveryListener.td
[java] Test Passed: OK
[java]
[java]
Thanks Dan Gregg,
I've been working on the overhead problem, here's a summary (will commit
the latest after tests finish):
1. Removed calls to CodeSource.implies (this causes a DNS lookup)
2. Replaced URL with URI in Policy providers (URL requires DNS lookup
and File system access)
What follows is relatively hard core security, but it's relevant to anyone
wishing to deploy on untrusted networks. I know some people don't like
discussing security issues for fear of turning off would be developers but
security isn't mandatory, however considering that River/Jini is already
By using a tool taking advantage of bytecode analysis, a developer could
first annotate the ServiceAPI interface eg: @ServiceAPI, then the
bytecode analysis could find all dependencies that exclude the jini
platform and any other interface (and it's dependencies) that declares
@ServiceAPI
Well spotted, I spoke to Peter Kriens over the phone about this in 2010
(very smart guy btw), ClassDep doesn't detect Class.forName dependencies.
A string might not be defined until runtime, so it's not something that
can be easily determined. This could become even more difficult if
dynamic
cannot be forged and the chain must lead to
the certificate used to sign the jar file.
That might scale better?
Peter.
On 18/06/2012 10:24 PM, Peter Firmstone wrote:
Until recently, I thought SPKI Certificates were only suitable for
distributed user authorisation.
Quick recap: I sign
Thanks Sim.
Cheers,
Peter.
Simon IJskes - QCG wrote:
Ok, i will try to run all jenkins jobs with 1.7.0 and see if it works
on all platforms.
On 08-06-12 01:46, Peter Firmstone wrote:
I'm using ant version 1.7.1, I can upgrade if need be.
Peter.
Tom Hobbs wrote:
Whatever version we're
Only failed tests shown. Failed tests due to missing infrastructure in
all but one case.
jtreg:
[mkdir] Created dir:
/opt/src/River_Fixed_2nd_Try/peterConcurrentPolicy/qa/jtreg/JTlib-tmp
[move] Moving 8 files to
/opt/src/River_Fixed_2nd_Try/peterConcurrentPolicy/qa/jtreg/JTlib-tmp
[java]
[java] -
[java]
[java] # of tests started = 1412
[java] # of tests completed = 1412
[java] # of tests skipped = 46
[java] # of tests passed= 1412
[java] # of tests failed= 0
[java]
[java]
Hmm, I don't see any build errors, it just appeared to time out?
I thought there were issues with building on windows?
Should we extend the timeout and see what happens?
Peter.
Apache Jenkins Server wrote:
See https://builds.apache.org/job/River-QA-windows/15/changes
Changes:
I'm removing delgate implementations from apache river, in preparation
for release, they cannot support compilation on both java 6 and 7 with
the same source code. Delegates depend on reference collections,
there's also some common security stuff, that could be broken out
separately that
Simon IJskes - QCG wrote:
On 11-02-12 12:08, Peter wrote:
I'm glad you were watching Sim, I wasn't even aware it went awry.
Did you see the emails jenkins sent?
Gr. Simon
Yeah, those were just new junit tests that were testing some
functionality I hadn't yet implemented, I figured I could
Simon IJskes - QCG wrote:
On 11-02-12 12:08, Peter wrote:
- Original message -
On 11-02-12 06:56, Peter wrote:
Lets dedicate this release to Fred Oliver, please dive in and
review recent
code changes and ask questions, make sure the javadoc makes sense.
Let's make
it the best
+1 Peter.
Dan Creswell wrote:
Stop wondering - let's do it.
On 10 February 2012 06:00, Peter Firmstone j...@zeus.net.au wrote:
I only found out today that Fred Oliver passed away on April 9, 2011.
I had emailed Fred a number of times on and off list, he was always happy
to take the time
on java.security.Policy.getPolicyNoCheck() that
ProtectionDomain.implies calls used in earlier Java releases. The code
hasn't been tested on Java 8.
I'm going to look into creating a timed reference, but for now the
Security Manager cache uses soft references.
Looks like I'm ready for a merge.
Cheers,
Peter.
Peter
Just finished a local merge of trunk and skunk/peterConcurrentPolicy,
A bit dissapointing, I've got errors and additional failures in Jtreg.
I noticed trunk has some failures also in Hudson, could this be due to
compiler optimisations? Eg, we just had the source and target changed
to Java 6.
Well, not to my knowledge, anything could be interrupting the thread
(because it's waiting) on the remote machine which is propagating it as
an IOException.
So we don't know in this case what caused the interruption, as that
stack trace is missing.
Do you have logging activated at the
You're welcome, thanks for cudos.
Cheers,
Peter.
Tom Hobbs wrote:
Well done, Peter. You're a serious work horse on River and we're
grateful for what you're getting done.
Cheers.
On Mon, Feb 6, 2012 at 7:23 AM, Peter Firmstone j...@zeus.net.au wrote:
Peter Firmstone wrote:
Good
Thanks Tom, much appreciated.
Cheers,
Peter.
Tom Hobbs wrote:
It's that time again.
Comments always welcome, due date is 8th February.
Below is the February board report for River
Apache River is a distributed computing architecture, based on the JSK
Starter Kit Source code donated by
and a few java platform limitations.
Cheers,
Peter.
Peter Firmstone wrote:
Well, I think it's possible to do most things with web based services,
using style sheets html and javascript on the client and java or
modperl on the server, usually with an SQL database behind that. What
happens
This has recently caught my interest, I've seen it before, but brushed
it aside for some reason:
www.ists.dartmouth.edu/library/16.pdf
SPKI even rates a mention in Li Gong's Inside Java 2's platform
security 2nd ed. page 144.
There is some BSD licensed software on sourceforge called JSDSI,
can't do. Looking for some of that lone
fruit to pick, is what I'm not sure about.
What kind of transactional, leased or other data services could you
imagine Jini being a key part of on the Internet?
Gregg Wonderly
On 1/27/2012 7:04 PM, Peter Firmstone wrote:
I've been thinking about
E-Speak was a services architecture based on corba, similar in some
respects to Jini. They've got some high level learnings posted at:
http://www.hpl.hp.com/techreports/2004/HPL-2004-150.html
Cheers,
Peter.
Simon IJskes - QCG wrote:
On 24-01-12 00:29, peter_firmst...@apache.org wrote:
Commenced writing a bouncy castle self signed certificate generator
to replace DSTC JCSI.
You know you can generate self signed certificates with the java jdk
keytool?
Gr. Sim
The tool used to generate two
Simon IJskes - QCG wrote:
On 24-01-12 00:29, peter_firmst...@apache.org wrote:
Commenced writing a bouncy castle self signed certificate generator
to replace DSTC JCSI.
You know you can generate self signed certificates with the java jdk
keytool?
Gr. Sim
Hmm, it uses keytool, but
Gregg Wonderly wrote:
On 1/20/2012 2:03 PM, Peter Firmstone wrote:
Has anyone got a good example for ServiceUI, I'd personally like to
remove all references to Toaster's in our documentation.
If you look at the http://startnow.dev.java.net project under the
adminui tree, you'll find
Simon IJskes - QCG wrote:
On 23-01-12 01:57, Peter Firmstone wrote:
A number of jtreg tests a failing due to expired certificates.
Are these included in the QA build on builds? Do they fail there, but
are disabled or so?
Gr. Sim
No, they've got a GPL platform library dependency, jtreg
Simon IJskes - QCG wrote:
On 23-01-12 21:56, Peter Firmstone wrote:
Simon IJskes - QCG wrote:
On 23-01-12 01:57, Peter Firmstone wrote:
A number of jtreg tests a failing due to expired certificates.
Are these included in the QA build on builds? Do they fail there, but
are disabled or so
improvement over building multiple jars
from the same batch of code using classdep-type approaches.
-jeff
On Mon, Jan 23, 2012 at 9:01 AM, Greg Trasuk tras...@stratuscom.com wrote:
On Sat, 2012-01-21 at 22:54, Peter Firmstone wrote:
Greg,
Are there any areas where you could use some help
It's the way Entries are separately serialized.
Yes you're right.
Peter.
Dan Creswell wrote:
Depends what you call a platform service but at least in the case of
both Registrar and JavaSpace the ability to custom serialise on the
client and avoid leaking classes into the server-JVM makes
301 - 400 of 522 matches
Mail list logo
