On Mar 23, 2009, at 2:58 PM, Antoine Delvaux wrote:
Hi Candido, Roman and others,
For me this kind of issue is to be solved by proper packaging, not by some notes
in the admin guide, it's not convenient. Isn't it the reason why we have
advanced packaging tools like RPM and DEB?
I totally agree with you, but, for the time being we should include this specific constraint within the documentation, because if someone is installing an AS now, he should know that.
This probably needs more researching on how to do it but I think it should be
something like:
- having the AS package not containing but depending on a bouncycastle lib package,
- proving 2 bouncycastle lib packages, one for JRE1.5, another for JRE 1.6 (or
refer to some sources that provide those packages),
- having a dependency of bouncycastle lib to the proper JRE they rely on.
It sounds a good plan. My concern is if we can specify JRE1.5 or JRE1.6 in a generic way for all RPM-based distributions or, by the other hand, each distribution has a different name for Java 1.5 or Java 1.6, which it doesn't make easier that solution. Has anyone had any experience with this situation?
Regards
Then, we'll have the correct bouncycastle lib installed, whatever the JRE we
have. And we won't need any notice in the admin guide.
Can any expert in RPM and/or DEB confirm?
Antoine.
Le 23/03/09 12:34, Roman Lapacz a écrit :
Hi Candido,
Candido Rodriguez Montes wrote:
Is there a newer version of that library which works correctly with
java 1.6?
Yes, there is. But it's not inside the packages provided for
installing the AS. Should we create packages for different Java 1.X
versions?
I understand that there is backward compatibility and the library of
newest version can not be used on Java 1.5. That is why you suggest to
create a separate package for Java 1.6. Am I right?
I would say yes but Szymon might have opposite view on this because of
need of complete formal testing (I guess there is a problem with testers)
Does the problem touch only AS or also authN component used by java
pS services?
I guess the problem is only in AS because other pS-services deployed
at those machines are using the authN component and it's working :-).
that's great
Fausto has also found that the official documentation says that it
can be installed under Java 1.5 or superior (could you provide us
which document? I couldn't find that info :( ).
https://svn.perfsonar.net/svn/perfsonar/trunk/perfsonar-doc/manuals/perfsonar-mdm/perfSONAR-MDM-3.1_Admin_Guide_1.4.pdf
see subsection 2.5 the table
So, my question is... shall I put that constraint inside the package
definition or only in the documentation? I'm not sure about the
answer and I'd like to hear your opinion...
You mean constraint of java version or bouncycastle lib version? I
believe the doc should include that information.
Constraint of java version as AS is deployed with an specific version
of bouncycastle. Should we ask Gina to update the doc?
In my opinion yes but let's wait what others will say.
Roman
--
Antoine Delvaux Systems Engineer
DANTE Tel: +44.1223371300
http://www.dante.net Fax: +44.1223371371
PGP fingerprint: DC65 0D8B 6938 9229 33C3 18CA 4EB6 09D3 A333 3378
