I did find a solution... but it opens further questions. First, the
problem/solution - whether it is a bug or not depends on design principles I
suppose...
1. From the stack trace, the class.method attempting to load
'org.apache.xbean.spring.context.v1.XBeanXmlBeanDefinitionReader'
is
'org.apache.xbean.spring.context.impl.XBeanHelper.createBeanDefinitionReader'.
2. From the source of that class, the 'version' (v1/v2) is determined by
the presence of *another* class:
String version = "2.0";
try {
Class spring20Clazz =
Class.forName("org.springframework.core.AttributeAccessorSupport");
version = "2.0";
} catch(ClassNotFoundException e) {
version = "1.2.8";
}
3. The Class.forName is throwing an exception, so the code moves on looking
for 'v1' instead of 'v2'. Since v1 is nowhere to be found in the
distribution, one might surmise that v2 was expected and therefore that the
class was expected to be found. Backtracking a bit & looking around...
4. The 'missing' class is in 'spring-core-2.5.5.jar' aka OSGi Bundle
'org.springframework.bundle.spring.core'. This Bundle is installed &
active. The package 'org.springframework.core' is exported (as expected).
5. The class checking for the 'missing' class is in 'xbean-spring-3.4.jar'
aka OSGi Bundle 'org.apache.xbean.xbean-spring'.
6. The package 'org.springframework.core' nor it's containing Bundle is
imported by 'org.apache.xbean.xbean-spring'. There is are
DynamicImport-Package's defined, but they doesn't appear to influence
anything I've encountered.
Bottom line: XBeanHelper.createBeanDefinitionReader has no visibility,
within the confines of OSGi, to the class it's trying to load.
This was verified by adding the missing package to the MANIFEST.MF file, and
we progressed... on to the next unexpected issue: another exception!
org.springframework.beans.factory.BeanDefinitionStoreException:
Unrecognized xbean namespace mapping: http://activemq.apache.org/schema/core
Hello? Should the activemq.xml file NOT be loaded via the xbean URI scheme?
[who made this a URI anyway, it's a location specifier near as I can tell].
Again, it took the URI (with the xbean prefix) just fine from the command
line.
This all leads me to suspect that trying to load a config file for ActiveMQ
via BrokerFactory within OSGi isn't the expected way to proceed. The Admin
Configuration services (particularly under Equinox) looks so very ugly, I've
been a bit shy to approach it.
Any advice is welcome.
rsitze wrote:
>
> Within an OSGi bundle, I have the following code. All required bundles
> are loaded & active.
> Verified that the URI used here works with activemq.bat from the command
> line [yes, this is under Vista].
>
> try {
> URI configURI = new
> URI("xbean:D:/Data/ActiveMQ/conf/activemq.xml");
>
> broker = BrokerFactory.createBroker(configURI);
> broker.start();
> } catch (Exception e) {
> e.printStackTrace();
> throw new Exception("failed to start MQ Broker", e);
> }
>
>
> I'm getting the (caused by) exception: java.lang.ClassNotFoundException:
> org.apache.xbean.spring.context.v1.XBeanXmlBeanDefinitionReader.
>
> thrown by BrokerFactory.createBroker(...).
>
> ...
>
--
View this message in context:
http://www.nabble.com/RFH%3A-Problem-w--BrokerFactory-in-Equinox-OSGi-tp25392287p25394210.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
