A quick perusal of the JavaDocs and I'm unsure of the answer...
Can the Spring container be asked to emit the configuration of any beans currently loaded and managed by the container? It occurred to me that it might be useful to be able to do so, from a testing and software construction standpoint.
Another odd thought... Can I nest a Spring container inside another Spring container? The reason I ask is it would seem the easiest way to query a Spring container as to the details of it's configuration. I sort of envision a "drag and drop" capability - loading up a blank, unconfigured container and dropping beans into it - wiring them together, setting any values needed - and then asking the container to emit it's configuration.
Possibly a tool could be built to do this visually, inside of Eclipse. Not sure how needed or useful something like this would be - but it seemed like a neat idea. Sort of a here's my container, drop a bunch of beans in it, set any properties I need, wire em together - and ask the container to emit the config. Possibly have a tool to grab the config and specified beans and wrap it all up into a Jar...
Thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> On related note, there isn't any programmatic way
> to find out the current Spring 'container' version.
May be the information should be added to the jar's manifest? Currently the there's "Spring-Version: 1.0.2", but I don't know of any way to get that information at runtime. However, the attributes :
Specification-title
Specification-vendor
Specification-version
Implementation-title
Implementation-vendor
Implementation-version
Are all available at runtime from the java.lang.Package class. It would be trivial to add those to the manifest in the ant build file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just tried to get those attributes for standard jars, like mail.jar: I'm not able to make this work. Even Package.getPackages() just lists the J2SE platform library multiple times, but not any of the other jars on my classpath. How is this supposed to work?
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alternatively, we could also provide some SpringVersion class that provides a static String getVersion() accessor, simply adapting that version constant for every release.
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, according to the little experimentations I did, the information is only available for packages that contains classes. e.g. You can't get info for "org.springframework", but you can for "org.springframework.context". Also, you cannot get information for a package for which no class has been loaded yet.
Indeed, the classes were not loaded before. I've just checked that it works when I initialize at least 1 class of the respective package.
OTOH, is this really that convenient when "org.springframework" won't work (because there are no classes in it) but just "org.springframework.core" will?
I've just checked that many libraries don't come with manifest attributes but rather with some special class that carries the version: e.g. Hibernate.
The question is: What's more convenient - manifest attributes or a SpringVersion class? I guess that most people would prefer the latter. Opinions?
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, I would suggest both. The reason is that the Spring's version is easier to maintain from an Ant build file than to hardcode in java source code. So I would suggest a SpringVersion class that actually gets the version from the Manifest. That would be more convenient from both dev and user point of view, wouldn't it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just added Implementation-Title and Implementation-Version to all our distribution jars. There's also a new org.springframework.core.SpringVersion class with a String getVersion() method, for convenient access to Implementation-Version.
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have to manually include the info in the manifest file for spring.jar don't you? As I understand, the classloader gets the info from there. Not sure which packages the OP was retrieving info from, but if it's a 3rd party lib I think it must have had such a manifest.
If you can read from spring's jar file, then it's easy to find the manifest and see Spring's version. The problem is that it's not always obvious where to find that jar. For example, if you're in a webapp, you would have to know the webapp's root and look in /WEB-INF/lib/spring.jar. But in a swing GUI, then may be it's in the system classloader, then you have to look in System.getProperty("java.class.path"), but may be it's in a child ClassLoader (e.g. Eclipse plugin)? If you control the environement, may be it's ok, but it's not really a convenient solution.
Using java.lang.Package it's easy. You can get it from any class instance, e.g. ApplicationContext.class.getPackage();
Then on the package instance there's the methods :
The only reason I can see for a hard-coded version information class is that it can't be easily changed. Whereas, any mainfest could be changed accidently or intentionally.
J. Betancourt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A quick perusal of the JavaDocs and I'm unsure of the answer...
Can the Spring container be asked to emit the configuration of any beans currently loaded and managed by the container? It occurred to me that it might be useful to be able to do so, from a testing and software construction standpoint.
Another odd thought... Can I nest a Spring container inside another Spring container? The reason I ask is it would seem the easiest way to query a Spring container as to the details of it's configuration. I sort of envision a "drag and drop" capability - loading up a blank, unconfigured container and dropping beans into it - wiring them together, setting any values needed - and then asking the container to emit it's configuration.
Possibly a tool could be built to do this visually, inside of Eclipse. Not sure how needed or useful something like this would be - but it seemed like a neat idea. Sort of a here's my container, drop a bunch of beans in it, set any properties I need, wire em together - and ask the container to emit the config. Possibly have a tool to grab the config and specified beans and wrap it all up into a Jar...
Thoughts?
Spring can't currently write out XML config.
Have you looked at the Eclipse plugin? This may meet some of your requirements.
On related note, there isn't any programmatic way to find out the current Spring 'container' version.
Not sure what the use case would be for this. To output into log files for ongoing maintenance or customizations?
PicoContainer doesn't seem to have this also. HiveMind does, at least via its HiveDocs system (runtime?).
The HiveMind doc output is pretty cool.
http://jakarta.apache.org/hivemind/hivedocs/index.html
j. betancourt
> On related note, there isn't any programmatic way
> to find out the current Spring 'container' version.
May be the information should be added to the jar's manifest? Currently the there's "Spring-Version: 1.0.2", but I don't know of any way to get that information at runtime. However, the attributes :
Specification-title
Specification-vendor
Specification-version
Implementation-title
Implementation-vendor
Implementation-version
Are all available at runtime from the java.lang.Package class. It would be trivial to add those to the manifest in the ant build file.
I've just tried to get those attributes for standard jars, like mail.jar: I'm not able to make this work. Even Package.getPackages() just lists the J2SE platform library multiple times, but not any of the other jars on my classpath. How is this supposed to work?
Juergen
Alternatively, we could also provide some SpringVersion class that provides a static String getVersion() accessor, simply adapting that version constant for every release.
Juergen
Well, according to the little experimentations I did, the information is only available for packages that contains classes. e.g. You can't get info for "org.springframework", but you can for "org.springframework.context". Also, you cannot get information for a package for which no class has been loaded yet.
e.g.
System.out.println(Package.getPackage("org.springframework.context"));
org.springframework.context.ApplicationContext.class.getName();
System.out.println(Package.getPackage("org.springframework.context"));
Would result in something like:
null
package org.springframework.context
In you case, I assume you're trying to get informations on package for which no class has been loader yet?
Indeed, the classes were not loaded before. I've just checked that it works when I initialize at least 1 class of the respective package.
OTOH, is this really that convenient when "org.springframework" won't work (because there are no classes in it) but just "org.springframework.core" will?
I've just checked that many libraries don't come with manifest attributes but rather with some special class that carries the version: e.g. Hibernate.
The question is: What's more convenient - manifest attributes or a SpringVersion class? I guess that most people would prefer the latter. Opinions?
Juergen
Actually, I would suggest both. The reason is that the Spring's version is easier to maintain from an Ant build file than to hardcode in java source code. So I would suggest a SpringVersion class that actually gets the version from the Manifest. That would be more convenient from both dev and user point of view, wouldn't it?
I've just added Implementation-Title and Implementation-Version to all our distribution jars. There's also a new org.springframework.core.SpringVersion class with a String getVersion() method, for convenient access to Implementation-Version.
Juergen
You have to manually include the info in the manifest file for spring.jar don't you? As I understand, the classloader gets the info from there. Not sure which packages the OP was retrieving info from, but if it's a 3rd party lib I think it must have had such a manifest.
see http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
hth
sorry, only read the rest of this thread after I posted!
Access to version information at runtime is an interesting point. I'd encourage you to raise an issue in Jira.
>Are all available at runtime from the java.lang.Package class. It would be trivial to add those to the manifest in the ant build file.
I've seen the Package class but never seen it used. I think you can get everything in the manifest using the java.util.jar.Manifest class.
In my company I took the easy way and just auto-generate a class that hard codes version and marketecture info from build prop files.
J. Betancourt
If you can read from spring's jar file, then it's easy to find the manifest and see Spring's version. The problem is that it's not always obvious where to find that jar. For example, if you're in a webapp, you would have to know the webapp's root and look in /WEB-INF/lib/spring.jar. But in a swing GUI, then may be it's in the system classloader, then you have to look in System.getProperty("java.class.path"), but may be it's in a child ClassLoader (e.g. Eclipse plugin)? If you control the environement, may be it's ok, but it's not really a convenient solution.
Using java.lang.Package it's easy. You can get it from any class instance, e.g. ApplicationContext.class.getPackage();
Then on the package instance there's the methods :
getImplementationTitle()
getImplementationVendor()
getImplementationVersion()
getSpecificationTitle()
getSpecificationVendor()
getSpecificationVersion()
The only reason I can see for a hard-coded version information class is that it can't be easily changed. Whereas, any mainfest could be changed accidently or intentionally.
J. Betancourt