our web application uses Spring 2.5. It consists of several modules, each of which can bring additional Spring context files, which are loaded automatically (into one application context). We want to let each module provide additional resource bundles (for I18N support).
Spring supports internationalization by registering a bean with name messageSource in the configuration file, but this assumes I know exactly what is the fully qualified name of the class or properties file that contained the translates strings. This is a problem because other modules might have their own properties files put in a different location. So I'm looking for a way to let each module define its own messageSource with its own resource bundles and I don't know how to do it.
Does anybody know the solution to this problem?
Thanks.
I have used the Message Sources in Spring for some i18n support. In my case I only needed one so it was easy to inject the one message source I needed into the service bean that I was creating.
I was hoping to see something like what I will propose later on in the Spring sources itself. But I don't see anything that will aggregate heterogeneous message sources. If all of them will be parts of a resource bundle like property files, I'm sure you could write a wrapper for ResourceBundleMessageSource that could be dynamically updated as beans were registered.
However, if you wanted to aggregate heterogeneous MessageSources, this is what I would suggest. Create an message source aggregating bean that upon loading asks the ApplicationContext for beans of type MessageSource.class. This aggregating bean can then let each source attempt to resolve the key and format the message. Depending on how many files/msg source classes you have you may want to allow the aggregating implementation to prioritize which ones it attempts to use first. If performance becomes a problem, you could also cache which source resolved which keys so that the aggregator doesn't have to guess each time.
Related
I started learning spring today and i have a question regarding what happens to the annotations when java files with annotations is compiled ?.
The reason i am asking this is because of the fundamental difference i see when we choose to use the xml approach vs the annotations approach , and what i think is the philosophy of spring. The way i understand is spring says that all your java classes can be simple pojo's and all the spring related config should be kept independent (Like xml file.)
In case of developing spring application using xml *.java files have no idea about spring container and are compiled in to .class without any spring related dependencies.
But now when we annotate the .java file and the file is compiled the compiled file now has all spring related dependencies hard baked in to it and no longer are your classes simple pojo's.
Is this correct ? I am not sure if i am missing some thing here.
Annotations can be considered as metadata of a class or its element (method, field, local variable...). When you put annotation, you don't implement any behaviour. You just give additional info on an element.
That way, Spring, which is in charge of instanciating its bean can collect the info with reflection (see also this site) and process it.
To conclude, your Spring beans still remain POJO and there is no difference with the XML way (...from that point of view) since Spring gets from annotations the information it would have got from XML .
I think you are right and your question is justifiable, that's the way how I think about it too.
Not only compiled code but also dependency on spring jars bother me. Once you use this annotations your resulting jar depends on spring library.
It's reasonable to store beans in model according to DDD but spring is some kind of infrastructure layer so I didn't like the dependency.
Even if you would use XML, it's useful for few placed to use attributes. E.g. #Required attribute which is useful to verify that linked bean was injected. So, I've decide to use constructor dependency injection to omit this attribute, see my article. I completely leave out the dependency on spring in the code.
You can probably find such mind hook for many annotation you want/force to use.
You can use annotations only for your configuration classes, without marking them actual bean classes. In such scenario if you not use spring you just not load configuration classes.
Currently, I'm working on a project which has a large number of dependencies.
During development, I sometimes have issue with some spring bean.
Normally, the stack trace can tell me the name of the bean. However, it does not shows me which context.xml file declares the bean. Moreover, it does not tell me which .jar file contains the context file and how that context file is imported into my project (I means the chain of import).
As there are many depedencies, not all context file are uses, many beans are override....
It takes me a lot of time to search the correct context file. One simple solution is to import all related project into my eclipse workspace and everything becomes horribly slow.
I'm thinking about writing a tools to speed up the process:
Given a name of spring bean / the class of bean, the tool will search in the whole class path of application and returns:
The spring context file which declares the bean.
The .jar file that contains the spring context file.
Extract the content spring context file and show it directly to user
If user provides the root spring context file, the tool will shows the import chain to the destination spring context file.
It does not take lots of time to implement this but I just wonder whether somebody has already implement it? I just don't want to reinvent the wheel.
I found the project https://github.com/julior/spring-inspector. It's interesting, but it's not what I need.
If you know a tool like the one above, I'd be very happy to know about it.
You totally should look at Intellij IDEA's great support for Spring Framework.
More information available here: http://www.jetbrains.com/idea/features/spring_framework.html
To find interesting bean in xml config you just need to click on green bean image.
Intellij IDEA is definitely worth its price.
I want to share a singleton bean across multiple war. I know sharing ApplicaitonContext using parentContextKey attribute(Example, http://blog.springsource.org/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/)
But this way instance of bean created multiple (for 2 war, 2 instance). I want only 1 instance across 2 war.
Another way, If i set some value in any POJO, it should be accessible in another war.
Reason i need this is, there are some beans(like HibernateSessionFactory, Datasource etc which are expensive) which are created multiple times(n instance for n war). Whereas i want to utilize same instance instead of creating same in different war.
Can anyone provide me solution for this?
You could achieve this by binding the objects into the global JNDI tree. That means that both WARs would have references to an object looked up in JNDI.
Hibernate allows you to use the hibernate.session_factory_name property (this may well be a good starting point. Data sources should already be looked up from JNDI.
One thing, I would not class a session factory or a data source as expensive, so you may well be saving a miniscule amount of memory in exchange for a lot of additional complexity, so I would ask myself the question on whether this is worth the additional maintenance headaches.
Spring provide a way to expose any bean (service) and these bean can be access from any other web application or any standalone application.
please refer Remoting and Web Service using Spring to get more details.
If you have a library containing Spring beans that need to be wired together before an application can use them, does it make sense to include any sort of bean configuration file in the JAR (such as the /META-INF directory)? The idea is to give the application the option of importing this into its master Spring context configuration.
There may be more than one way to wire these beans, so I could provide a bean configuration file for each of the standard ways in which you'd typically wire them together.
Or, do I force the application to wire these up explicitly?
If it helps, the specifics of my problem involve a library I created to encapsulate our product's persistence layer. It contains Service, DAO and model beans. The DAO implementations currently use Hibernate (this probably won't change). Some of the DAO implementations need different kinds of Strategy beans injected into them (database encryption logic), depending on the type of database we are deploying on (MySQL vs SQL Server, etc). So we have potentially a few different configuration scenarios. I could also provide datasource bean configurations, relying on property substitution at the app level to inject all the particulars needed by the datasource.
Thanks for your input!
In this case, it's a good idea to provide some beans files, either as examples for documentation purposes, or as fully-fledged files ready for including into a wider context.
If your beans' wiring can get complex, then you shouldn't really leave it entirely up to the library client to figure it out.
This is more of a documentation and education task, really.
I'm running eclipselink in an OSGi container and my entity classes are in their own bundle.
I have repeatedly run into the problem that Eclipselink fails to autodetect the entity classes, resulting in "Xyz is not a known entity type" messages. This is painful to debug and my somewhat helpless approach is to more or less randomly tweak configuration files until it works.
I wish I knew a more systematic approach, but I don't seem to know enough about possible reasons for the problem. What could they be? Is there an overview of what happens in autodetection and what is required for it to work?
So if you ran into the problem yourself and were able to determine one specific reason, post it here, or vote it up when you already see it. That way we could produce a list of typical issues sorted by frequency. I'll add the ones I actually solved.
Facts I know:
eclipselink uses the OSGi extender pattern to listen for bundles registering and then sets them up
it supposedly uses the class loader for the bundle that defines the persistence unit, if you're using a persistence.xml for configuration, this is the bundle where that file should be located.
The eclipselink jpa is not able to persist objects of classes that extend entity classes. Those extended classes should be entity classes by itself.
The bundle with the entity classes doesn't have the correct JPA-PersistenceUnits header in its manifest. This header is how eclipselink finds out that there is a persistence unit to be processed.
If listing your classes explictly makes it work, the wrong / missing header was not your problem.
The entity class is not listed explicitly in the configuration of the persistence unit and the persistence.xml (or whatever config mechanism you use) doesn't set the exclude-unlisted-classes parameter to false (depending on whether you run Java SE or EE, it may be true by default).
If it helps to list your classes explicitly, this may be your problem.