Not sure what JDK you are running but the SunJCE (or IBMJCE) is normally installed by default. Providers are typically statically configured in the java.security file in jre/lib/security/java.security file. Should be no need to add providers dynamically.
# # List of providers and their preference orders (see above): # security.provider.1=sun.security.provider.Sun security.provider.2=sun.security.rsa.SunRsaSign security.provider.3=com.sun.net.ssl.internal.ssl.Provider security.provider.4=com.sun.crypto.provider.SunJCE . . . -- Tim -----Original Message----- From: David G. [mailto:[email protected]] Sent: Wednesday, April 04, 2012 6:44 PM To: [email protected] Subject: Re: using com.sun.* in bundles Tim, I got back and looked at my code - I'm using javax.crypto.Mac, but the problem is get getInstance("HmacSHA1") it can't find the provider, which i believe, means i need to add a provider like so: java.security.Security.addProvider(new com.sun.crypto.provider.SunJCE()); the reference to the SunJCE() is what i need from com.sun. -- David Gonzalez Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Wednesday, April 4, 2012 at 2:20 PM, David G. wrote: > Tim, > I as was using com.sun.crypto.providers.* -- thought after googling > with the classes in your email it appears these may provider the more > appropriate impl -- using getInstance() rather than looking for a > specific provider which may not be installed. > > > > On Wed, Apr 4, 2012 at 2:16 PM, Bond, Tim <[email protected] (mailto:[email protected])> wrote: > > David, are you actually trying to directly use the com.sun.* classes? > > If you need message digest or hmac you should use the > > java.security.MessageDigest or javax.crypto.Mac classes instead. You > > can specify a provider if you need using the getInstance API. > > > > -- Tim > > > > -----Original Message----- > > From: David G. [mailto:[email protected]] > > Sent: Wednesday, April 04, 2012 1:00 PM > > To: [email protected] (mailto:[email protected]) > > Subject: Re: using com.sun.* in bundles > > > > So there is no way to make a truly "portable" osgi bundle that uses the > > com.sun.crypto packages? By truly portable I mean installable via OBR > > without requiring a restart of the container? > > > > Any thoughts off the top of your head if there is another lib i can > > include/import that provides HMAC encryption? > > > > Thanks > > > > On Wed, Apr 4, 2012 at 12:13 PM, Richard S. Hall <[email protected] (mailto:[email protected])> > > wrote: > > > On 4/4/12 09:11 , David G. wrote: > > > > > > > > I am creating a bundle for felix that uses > > > > com.sun.crypto.providers.SunJCE > > > > > > > > I thought that com.sun.* was exposed to the container via the JVM, > > > > however Im getting class not found exceptions when I execute my > > > > bundle. > > > > > > > > What the best way for allowing com.sun.* packages to resolve in an > > > > OSGi Bundle under felix? (My Import-Package is *, but when i look at > > > > my bundles under felix is complains it can find com.sun.crypto. > > > > > > > > > > > > > > > > At a minimum, you need to modify > > > org.osgi.framework.system.packages.extra in conf/config.properties to > > > include the additional JVM packages you want to expose, then simply > > > make sure your bundles import them and you'll be all set. As also > > > suggested, you can create a framework fragment to add the additional > > > > > > > JVM packages too. > > > > > > -> richard > > > > > > > > > > > Im ultimately trying to get a cryptography provider so i can securely > > > > > > hash values. > > > > > > > > Thanks > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] (mailto:[email protected]) > > > > For additional commands, e-mail: [email protected] (mailto:[email protected]) > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] (mailto:[email protected]) > > > For additional commands, e-mail: [email protected] (mailto:[email protected]) > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] (mailto:[email protected]) > > For additional commands, e-mail: [email protected] (mailto:[email protected]) > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] (mailto:[email protected]) > > For additional commands, e-mail: [email protected] (mailto:[email protected]) > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
