I upgrade guava to 18.0 from r09 when I upgrade JDK to 1.8. But there is an error like the title.
And the same accessing restriction for method MapMaker.maximumSize.
Anyone know how to fix it.
MapMaker's caching functionalities were deprecated and moved to new com.google.common.cache package (see migration guide):
The core interface used to represent caches is Cache. In-memory caches can be configured and created using CacheBuilder, with cache entries being loaded by CacheLoader. Statistics about cache performance are exposed using CacheStats.
Right now MapMaker acts as kind of ConcurrentMapBuilder without any caching capabilities, so you should use CacheBuilder, ex.:
Cache<Integer, String> cache = CacheBuilder.newBuilder()
.maximumSize(10000)
.expireAfterWrite(10, TimeUnit.MINUTES)
.build();
Note that you could pass CacheLoader to build if you want to compute values. Also, if you need Map interface to cache, you can use Cache#asMap() view.
Related
Cache2k looks like a very promising caching implementation. Unfortunately the documentation is very limited, which is why I need some help with the following issue. I am using the latest version 0.26-BETA.
According to the documentation the cache is supposed to be created like this:
Cache<String,String> c =
CacheBuilder.newCache(String.class, String.class).build();
String val = c.peek("something");
assertNull(val);
c.put("something", "hello");
val = c.get("something");
assertNotNull(val);
c.destroy();
Unfortunately at least 2 of these methods are deprecated, including the CacheBuilder class itself. I therefore tried creating the cache like this:
org.cache2k.Cache<String, Object> newCache = Cache2kBuilder.of(String.class, Object.class)
.name(cacheKey.toString())
.entryCapacity(100000)
.eternal(true)
.build();
This however throws the "java.lang.UnsupportedOperationException: loader not set" exception.
The question therefore is: how am I supposed to build the cache so that I do not get this exception?
EDIT:
This gives me the same exception:
org.cache2k.Cache<Object, Object> newCache =
CacheBuilder.newCache(Object.class, Object.class)
.eternal(true)
.build();
EDIT #2:
Just one more note: When I copy&paste the code from the wiki page I get an error - as can be seen in the image below.
With what jdk version are you testing? I'll try just removing the <> that are causing the problem for now.
Thanks very much in advance!
Michael
Cache2k looks like a very promising caching implementation.
Thanks :)
According to the documentation the cache is supposed to be created like this
There are new interfaces in place. The deprecated one is still there to support users of old cache2k versions. That will get cleared up in the next weeks. Sorry for the confusion.
Please take a look here for the latest getting started information:
https://github.com/cache2k/cache2k/blob/master/doc/src/docs/asciidoc/user-guide/sections/_start.adoc
This however throws the "java.lang.UnsupportedOperationException: loader not set" exception.
The question therefore is: how am I supposed to build the cache so that I do not get this exception?
Short answer: Either use cache.peek() or wait for 0.27, since then it is working with cache.get() transparently.
Longer answer: In our own applications I use cache.get() only when a loader is defined and cache.peek() when no loader is defined or when I want to inspect the cache only. Reserving cache.get() only for the read through usage, seemed like a good idea. However, I reasoned that it might be a caveat for new users, so I change that behavior and align it to other cache solutions.
Answer to Edit 2:
For an untyped cache use the factory method Cache2kBuilder.forUnkownTypes(). Constructing the anonymous class is only needed for specific types.
I've got a Module A that provides authentication through users, groups and related classes. This module uses org.springframework.data:spring-data-jpa:1.6.0.RELEASE to access this data from a database. Of note might be that Module A uses a custom BaseRepository configured by extending JpaRepositoryFactoryBean, but removing this does not resolve the issue below.
A second Module B also has some classes and repositories to manage, unrelated to the Module A classes, again using spring-data-jpa for storage, but connected to a different database. This project exposes it's repositories via REST using org.springframework.data:spring-data-rest-webmvc:2.1.0.RELEASE. Module B uses the classes in module A for authenticating users, but does not manipulate those class instances nor does it store any references.
The issue I'm having now is that my module B REST APIs work flawlessly when Module A is not present (or with an older version not yet using spring-data-jpa), but when it is I present it breaks on creating self referential links with the below stacktrace:
java.lang.IllegalArgumentException: Cannot create self link for class Document! No persistent entity found!
at org.springframework.data.rest.webmvc.PersistentEntityResourceAssembler.getSelfLinkFor(PersistentEntityResourceAssembler.java:81) ~[spring-data-rest-webmvc-2.1.0.M1.jar:na]
at org.springframework.data.rest.webmvc.PersistentEntityResourceAssembler.toResource(PersistentEntityResourceAssembler.java:64) ~[spring-data-rest-webmvc-2.1.0.M1.jar:na]
at org.springframework.data.rest.webmvc.PersistentEntityResourceAssembler.toResource(PersistentEntityResourceAssembler.java:32) ~[spring-data-rest-webmvc-2.1.0.M1.jar:na]
at org.springframework.data.web.PagedResourcesAssembler.createResource(PagedResourcesAssembler.java:144) ~[spring-data-commons-1.8.0.M1.jar:na]
at org.springframework.data.web.PagedResourcesAssembler.toResource(PagedResourcesAssembler.java:96) ~[spring-data-commons-1.8.0.M1.jar:na]
at org.springframework.data.rest.webmvc.AbstractRepositoryRestController.entitiesToResources(AbstractRepositoryRestController.java:220) ~[spring-data-rest-webmvc-2.1.0.M1.jar:na]
at org.springframework.data.rest.webmvc.AbstractRepositoryRestController.resultToResources(AbstractRepositoryRestController.java:207) ~[spring-data-rest-webmvc-2.1.0.M1.jar:na]
at org.springframework.data.rest.webmvc.RepositoryEntityController.getCollectionResource(RepositoryEntityController.java:135) ~[spring-data-rest-webmvc-2.1.0.M1.jar:na]
See also: https://github.com/spring-projects/spring-data-rest/blob/master/spring-data-rest-webmvc/src/main/java/org/springframework/data/rest/webmvc/PersistentEntityResourceAssembler.java#L80
It looks to be talking to the wrong MappingContext in the RepositoryFactoryBeanSupport, even if my org.springframework.data.repository.support.Repositories contains all the repositoryBeanNames from both Module A and Module B.
Does anyone know how I can enforce the use of a particular MappingContext, perhaps through my extension of RepositoryRestMvcConfiguration?
** Edit **
Here's an GitHub repository illustrating the problem:
https://github.com/timtebeek/dual-data-jpa-rest-webmvc
It's since been reported as a bug on the data-rest project:
https://jira.spring.io/browse/DATAREST-312
This happens to me today
I was trying to query a specific Entity
I fix it creating the repository of that class
In your case it'll be
#Repository
public interface DocumentRepository extends JpaRepository<Document, Long> {
}
also doing all the needed configuration to use jpa repositories. Look here
I hope that hepls.
I have created a custom serializer for mongoDB.
I can register it and it works as expected.
However the my application sometimes throws an error because it tries to register the serializer twice.
How do I detect whether a serializer has already been registered and thus stop my application from registering a second time?
If you are using
BsonSerializer.RegisterSerializer(typeof (Type), typeSerializer);
you might get this error "there is already a serializer registered for type". Because you cannot register the same type of serializer 2 times. But you can write your own serializer and this serializer will work before default serializers.
For instance: if you want to use local DateTime instead of Utc which is default.
all you need to do is that writing a class implementing IBsonSerializationProviderand register this provider to BsonSerializer as soon as possible!
here is the sample code.
public class LocalDateTimeSerializationProvider : IBsonSerializationProvider
{
public IBsonSerializer GetSerializer(Type type)
{
return type == typeof(DateTime) ? DateTimeSerializer.LocalInstance : null;
}
}
and to be able to register
BsonSerializer.RegisterSerializationProvider(new LocalDateTimeSerializationProvider());
I hope this helps, you can also read the original documentation in here
this .net driver version of mongodb is 2.4!
TL;DR: Ig you are lazy, use BsonSerializer.LookupSerializer or BsonMemberMap.GetSerializer. To do it right, make sure the registration code is called once and only once.
The best approach to avoid this is to make sure the serializer is registered only once. It's a good idea to have some global startup code that registers anything that is global to the application once, and only once. That includes stuff like dependency injector configuration, tools like automapper and the mongodb driver. If you call this code only once and from a single point in code, you don't need to worry about thread safety, dead locks or similar troubles.
The MongoDB driver configuration settings are thread-safe, but don't assume that this is true for all software packages that you might need to configure. Also, locking can be very expensive performance wise if your code is multi-threaded, for instance in a web-application. Last but not least, that lookup you're doing might not be trivial in the first place, because some methods need to walk an entire inheritance tree.
I have 3 auto-generated soap services generated with Axis 1.4
I would like to set a proxy property only for one of them:
AxisProperties.setProperty("https.proxyHost",<some_host>)
However it looks like these properties are shared across all services under the same class loader
I cannot use the "https.nonProxyHost" since the hosts are dynamic
Thanks in advance...
After theral investigation I came to a conclusion that this cannot be done on AXIS 1.4:
Axis 1.4 has a bug:
problem with http proxy parameters caching mechanism
Basically, Axis 1.4 turns to a class called “DefaultHTTPSTransportClientProperties“ that acts as cache: If proxy host is null it will populate the host (in the cache) as an empty string.
The bug is that after the cache was set once, it cannot change.
On later versions of AXIS it is possible to setup different proxies:
AxisProperty uses the thread class loader hierarchy to deside which properties to use
If you want a specific property you should create your own class loader
Then spawn a thread on that class loader and instantiate AxisProperties with specific proxy settings
Now run the service from that thread and you will have specific properties for that class loader
I'm newly experimenting with the cryptography application block while using Autofac as the container.
As a result, I'm using the nuget package EntLibContrib 5.0 - Autofac Configurator.
With the DPAPI Symmetric Crypto Provider, I was able to encrypt/decrypt data just fine.
However, with RijndaelManaged, I receive an ActivationException:
Microsoft.Practices.ServiceLocation.ActivationException: Activation error occured while trying to get instance of type ISymmetricCryptoProvider, key "RijndaelManaged" ---> Autofac.Core.Registration.ComponentNotRegisteredException: The requested service 'RijndaelManaged (Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.ISymmetricCryptoProvider)' has not been registered. To avoid this exception, either register a component to provide the service, check for service registration using IsRegistered(), or use the ResolveOptional() method to resolve an optional dependency.
Per instructions here: http://msdn.microsoft.com/en-us/library/ff664686(v=pandp.50).aspx
I am trying to inject CryptographyManager into MyService.
My bootstrapping code looks like this:
var builder = new ContainerBuilder();
builder.RegisterEnterpriseLibrary();
builder.RegisterType<MyService>().As<IMyService>();
_container = builder.Build();
var autofacLocator = new AutofacServiceLocator(_container);
EnterpriseLibraryContainer.Current = autofacLocator;
App.config has this info defined for symmetricCryptoProviders:
name: RijndaelManaged
type: Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.HashAlgorithmProvider, Microsoft.Practices.EnterpriseLibrary.Security.Cryptography, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
algorithmType:System.Security.Cryptography.RijndaelManaged
protectedKeyFilename:[path_to_my_key]
protectedKeyProtectionScope: LocalMachine
Anyone have experience in this combination of technologies?
After some testing, I believe I may go with a Unity container instead, since I have no preference in IOC containers other than whatever I use should integrate nicely with ASP.NET MVC3 and http-hosted WCF services.
My bootstrapping code then becomes more simple:
var container = new UnityContainer()
.AddNewExtension<EnterpriseLibraryCoreExtension>();
container.RegisterType<IMyService, MyService>();
I actually wrote the Autofac EntLib configurator (with some help from some of the P&P folks). It's been tested with the exception handling block and logging block, but I haven't tried it with the cryptography stuff.
EntLib has an interesting thing where it sometimes requires registered services to be named, and I'm guessing from the exception where it says...
type ISymmetricCryptoProvider, key "RijndaelManaged"
...I'm thinking EntLib wants you to register a named service, like:
builder.Register(c =>
{
// create the HashAlgorithmProvider using
// RijndaelManaged algorithm
})
.Named<ISymmetricCryptoProvider>("RijndaelManaged");
I'm sort of guessing at the exact registration since, again, I've not got experience with it or tested it, but the idea is that EntLib is trying to register a named service whereas the actual service isn't getting registered with the name.
The RegisterEnterpriseLibrary extension basically goes through and tries to use the same algorithm that Unity uses to do the named/unnamed registrations. I'm guessing you've encountered an edge case where something's not getting handled right. EntLib is pretty well tied to Unity, even if they did try to abstract it away.
If you're not tied to Autofac, Unity is going to be your lowest-friction path forward. I like the ease of use and more lightweight nature of Autofac, and my apps are tied to it, so I needed everything to work that way; if you don't have such an affinity, might be easier to just use Unity.
Sorry that's not a super answer. EntLib wire-up in IoC is a really complex beast.