You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by geecxf <am...@ge.com> on 2013/05/01 16:49:17 UTC
Problems with http conduit declared in OSGi spring configuration
I've noticed some less than ideal behavior when I declare an HTTP conduit in
the spring configuration of an OSGi bundle. Let's say I have configured an
HTTP conduit in META-INF/spring/module-context.xml:
<bean id="cxf" class="org.apache.cxf.bus.spring.SpringBus" />
<jaxws:client
name="{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService"
/>
<http:conduit name="https://localhost:.*">
<http:client ConnectionTimeout="3000000"
ReceiveTimeout="3000000" />
<http:tlsClientParameters
disableCNCheck="true">
<sec:keyManagers keyPassword="password">
<sec:keyStore type="JKS" password="password"
resource="certs/myKeystore.jks" />
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="JKS" password="password"
resource="certs/myTruststore.jks" />
</sec:trustManagers>
</http:tlsClientParameters>
</http:conduit>
<jaxws:client name="{http://ws.apache.org/axis2}wso2carbon-sts" />
<http:conduit name="https://5.42.75.33:.*">
<http:tlsClientParameters
disableCNCheck="true">
<sec:trustManagers>
<sec:keyStore type="jks" password="password"
resource="certs/myTruststore.jks" />
</sec:trustManagers>
</http:tlsClientParameters>
</http:conduit>
Upon either start-up of the container or first deploy of the bundle I will
get all manner of javax.net.ssl.SSLHandshakeException from clients that
should use the conduit. However, if I either restart the bundle, or
uninstall it then install it again, the exceptions are not thrown again and
the clients connect successfully to their target endpoints. This happens no
matter what kind of CXF client I use. Be it a simple WebClient,
org.apache.cxf.endpoint.Client, or an STSClient.
Thinking it was a timing issue, I went as far as to separate the CXF
configuration from the other beans. I put the configuration in a separate
XML file and loaded it in code through a bundle context before any client
code executes. However, I still see the same behavior.
If anyone could help explain this behavior or at least provide me with some
input on what I could try next to troubleshoot the problem I would really
appreciate it.
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring
configuration
Posted by geecxf <am...@ge.com>.
Unfortunately, this does not work. First, I misspoke in my previous post. The
"depends-on" attribute would have to be in the bean with the client code
that requires the http conduit not the other way around. However, even if I
do that using a configuration like the one below:
<bean id="consumer" class="com.example.AuthConsumer"
init-method="init" depends-on="conduit,client">
</bean>
<bean id="cxf" class="org.apache.cxf.bus.spring.SpringBus" />
<jaxws:client
id="client"
name="{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService"
/>
<http:conduit id="conduit" name="https://localhost:.*">
<http:client ConnectionTimeout="3000000"
ReceiveTimeout="3000000" />
<http:tlsClientParameters
disableCNCheck="true">
<sec:keyManagers keyPassword="password">
<sec:keyStore type="JKS" password="password"
resource="certs/myKeystore.jks" />
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="JKS" password="password"
resource="certs/myTruststore.jks" />
</sec:trustManagers>
</http:tlsClientParameters>
</http:conduit>
I get the following problem:
Exception in thread "SpringOsgiExtenderThread-16"
org.springframework.beans.factory.BeanIsAbstractException: Error creating
bean with name 'conduit': Bean definition is abstract
at
org.springframework.beans.factory.support.AbstractBeanFactory.checkMergedBeanDefinition(AbstractBeanFactory.java:1209)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:278)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:284)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:69)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:355)
at
org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:132)
at java.lang.Thread.run(Thread.java:722)
Which I can't quite explain. Any ideas?
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727026.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring
configuration
Posted by geecxf <am...@ge.com>.
I'm using a combination of cxf feature files. The dosgi stuff is loaded
separately from those. I'll try debugging with the break points Dan
suggested first. Creating a simple example is something I'm less
enthusiastic about doing because its both time consuming and there are no
guarantees I could reproduce what I am seeing.
You see, while the container is fundamentally Karaf, I am building on top of
a platform that others have tweaked and loaded with many additional bundles.
Still if I can't make heads or tails from debugging more then I'll go that
route.
It would be great if there was some way to provide a trace of all CXF
related operations and dump those to a file. Perhaps a feature like that
would shed some light on the situation?
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727362.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring configuration
Posted by Christian Schneider <ch...@die-schneider.net>.
Are you using the cxf feature file for karaf?
At the end of the list I see the dosgi bundles which might indicate you
are using the dosgi multibundle distro.
The cxf features are definately the better options as they are better
tested.
Apart from that I currently have no idea. It would be ideal if you could
create a project that shows the problem and upload it on github or
similar. So we can directly test and debug ourself.
Christian
Am 06.05.2013 21:07, schrieb geecxf:
> I'm using Karaf,
>
> The run levels for CXF are:
> [ 146] [Active ] [Created ] [ ] [ 40] Apache CXF API (2.7.3)
> [ 147] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
> Core (2.7.3)
> [ 148] [Active ] [ ] [ ] [ 40] Apache CXF Runtime
> Management (2.7.3)
> [ 149] [Active ] [Created ] [ ] [ 40] Apache CXF Karaf
> Commands (2.7.3)
> [ 151] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime WS
> Policy (2.7.3)
> [ 152] [Active ] [ ] [ ] [ 40] Apache CXF Runtime XML
> Binding (2.7.3)
> [ 153] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
> SOAP Binding (2.7.3)
> [ 154] [Active ] [ ] [ ] [ 40] Apache CXF Runtime
> JAXB DataBinding (2.7.3)
> [ 155] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime WS
> Addressing (2.7.3)
> [ 156] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime WS
> Reliable Messaging (2.7.3)
> [ 157] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
> HTTP Transport (2.7.3)
> [ 158] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
> Simple Frontend (2.7.3)
> [ 159] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
> JAX-WS Frontend (2.7.3)
> [ 160] [Active ] [ ] [ ] [ 40] Apache CXF Runtime WS
> MetadataExchange (2.7.3)
> [ 162] [Active ] [ ] [ ] [ 40] Apache CXF Runtime WS
> Security (2.7.3)
> [ 163] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
> HTTP Jetty Transport (2.7.3)
> [ 165] [Active ] [ ] [ ] [ 40] Apache CXF JAX-RS
> Extensions: Providers (2.7.3)
> [ 166] [Active ] [ ] [ ] [ 40] Apache CXF JAX-RS
> Extensions: Search (2.7.3)
> [ 167] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
> JAX-RS Frontend (2.7.3)
> [ 168] [Active ] [ ] [ ] [ 40] Apache CXF RS XML
> Security (2.7.3)
> [ 169] [Active ] [ ] [ ] [ 40] Apache CXF Runtime
> Aegis Databinding (2.7.3)
> [ 171] [Active ] [ ] [ ] [ 40] Apache CXF Runtime
> XmlBeans DataBinding (2.7.3)
> [ 173] [Active ] [ ] [ ] [ 120] Apache CXF STS Core
> (2.7.3)
> [ 174] [Active ] [ ] [ ] [ 40] Apache CXF Runtime
> Security functionality (2.7.3)
> [ 188] [Active ] [ ] [Started] [ 80] CXF dOSGi Remote
> Service Admin Implementation (1.3.1)
> [ 189] [Active ] [ ] [ ] [ 80] CXF dOSGi Topology
> Manager (1.3.1)
>
> The run level for the bundle that creates the CXF bus is 100 the run level
> for the bundle that creates and consumes the web service is 120. Let me know
> if you need more information.
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727305.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Problems with http conduit declared in OSGi spring
configuration
Posted by geecxf <am...@ge.com>.
I'm using Karaf,
The run levels for CXF are:
[ 146] [Active ] [Created ] [ ] [ 40] Apache CXF API (2.7.3)
[ 147] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
Core (2.7.3)
[ 148] [Active ] [ ] [ ] [ 40] Apache CXF Runtime
Management (2.7.3)
[ 149] [Active ] [Created ] [ ] [ 40] Apache CXF Karaf
Commands (2.7.3)
[ 151] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime WS
Policy (2.7.3)
[ 152] [Active ] [ ] [ ] [ 40] Apache CXF Runtime XML
Binding (2.7.3)
[ 153] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
SOAP Binding (2.7.3)
[ 154] [Active ] [ ] [ ] [ 40] Apache CXF Runtime
JAXB DataBinding (2.7.3)
[ 155] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime WS
Addressing (2.7.3)
[ 156] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime WS
Reliable Messaging (2.7.3)
[ 157] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
HTTP Transport (2.7.3)
[ 158] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
Simple Frontend (2.7.3)
[ 159] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
JAX-WS Frontend (2.7.3)
[ 160] [Active ] [ ] [ ] [ 40] Apache CXF Runtime WS
MetadataExchange (2.7.3)
[ 162] [Active ] [ ] [ ] [ 40] Apache CXF Runtime WS
Security (2.7.3)
[ 163] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
HTTP Jetty Transport (2.7.3)
[ 165] [Active ] [ ] [ ] [ 40] Apache CXF JAX-RS
Extensions: Providers (2.7.3)
[ 166] [Active ] [ ] [ ] [ 40] Apache CXF JAX-RS
Extensions: Search (2.7.3)
[ 167] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime
JAX-RS Frontend (2.7.3)
[ 168] [Active ] [ ] [ ] [ 40] Apache CXF RS XML
Security (2.7.3)
[ 169] [Active ] [ ] [ ] [ 40] Apache CXF Runtime
Aegis Databinding (2.7.3)
[ 171] [Active ] [ ] [ ] [ 40] Apache CXF Runtime
XmlBeans DataBinding (2.7.3)
[ 173] [Active ] [ ] [ ] [ 120] Apache CXF STS Core
(2.7.3)
[ 174] [Active ] [ ] [ ] [ 40] Apache CXF Runtime
Security functionality (2.7.3)
[ 188] [Active ] [ ] [Started] [ 80] CXF dOSGi Remote
Service Admin Implementation (1.3.1)
[ 189] [Active ] [ ] [ ] [ 80] CXF dOSGi Topology
Manager (1.3.1)
The run level for the bundle that creates the CXF bus is 100 the run level
for the bundle that creates and consumes the web service is 120. Let me know
if you need more information.
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727305.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring
configuration
Posted by geecxf <am...@ge.com>.
Dan, as you suggested, I put various break points in
org.apache.cxf.configuration.spring.ConfigurerImpl. What I discovered is
that if I put my cxf HTTPConduit definitions in the main spring
configuration, when configureBean() is called the application context is in
a different bundle than expected.
To make the scenario more concrete lets say that I have two bundles:
1. A "producer" bundle that creates a cxf bus for the purpose of hosting web
services that are registered with our platform.
2. A "consumer" bundle (at a higher run level) that launches clients which
consume services that the "producer" bundle manages.
What is happening is that when configureBean() is called for HTTPConduits
that are declared in the spring configuration file of the "consumer" bundle
the application context is the "producer" bundle.
However, if I modify the "consumer" bundle to load the configuration from a
separate configuration file in a bundle and application context aware class
like so:
String[] configs = new String[]
{
"classpath:META-INF/spring/cxf-context.xml" //$NON-NLS-1$
};
OsgiBundleXmlApplicationContext appContext = new
OsgiBundleXmlApplicationContext(configs,
AuthConsumer.applicationContext);
appContext.setBundleContext(AuthConsumer.bundleContext);
appContext.refresh();
Then whenever configureBean() is called the application context is in the
"consumer" bundle as expected.
I hope I am making myself clear since this is confusing to explain. I also
hope it helps explain what is going on well enough that you or someone else
can think of some ways why this is happening and how to get around them.
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727445.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring configuration
Posted by Daniel Kulp <dk...@apache.org>.
On May 6, 2013, at 12:48 PM, geecxf <am...@ge.com> wrote:
> There's something about the logic of that explanation that does not make
> sense to me (though I'll readily admit that may very well be due to my
> ignorance on the matter).
>
> You say that the bundle might be picking up the wrong bus. But why would the
> bundle pick up the right bus on a restart? Why would it pick up the right
> bus if I deliberately load the configuration through the bundle context?
> When I step through the code, there's only one bus.
If there is not a bus available in whatever the current context is (blueprint, spring, etc…) that would then have it injected, many of the API's call BusFactory.getThreadDefaultBus() (which may, in turn, call getDefaultBus()). In that case, if some other bundle or some other event had triggered the creation of a Bus, it may get that bus instead.
On a restart, things may just be happening in a different order (or in parallel, that's somewhat important as blueprint will start bundles in parallel by default. In that case, could be unpredicable).
> What is evident from debugging the code is that the conduit is created AFTER
> the client calls are made, after the WebClient is created, after the init
> method that contains the client code is executed, and after the bean that
> contains that init method is instantiated. It's clearly a timing issue and
> probably one that is easy to reproduce by simply creating a bean with an
> init method that uses an http conduit declared in the same Spring
> configuration file.
No, because you cannot create a HTTPConduit object in Spring. http:conduit is abstract. Spring does not create them.
> Is there any insight at all on the order of execution of these things? Are
> beans in a Spring configuration file created before or after the cxf
> configuration beans are processed?
Again, this is not something I've (or apparently others) have seen before. If you are unwilling to create a simple test case to show the problem, I'm not sure how much more we can help. You'll need to dig into the code to figure things out. Only thing I can suggest is a breakpoint in org.apache.cxf.configuration.spring.ConfigurerImpl to which conduits are being configured and which ApplicationContext is being used for that.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Problems with http conduit declared in OSGi spring configuration
Posted by Christian Schneider <ch...@die-schneider.net>.
Could this be a race condition on startup?
CXF is not handling OSGi dynamics very well. For example if you start
the cxf bundles and your user bundle on the same start level then cxf
core might have started but cxf http transport not when the user bundle
starts.
In that case the cxf bus would probably not detect that there is a http
transport and fail to start the user bundle.
It is the same with the configs. If the configs are read by config admin
after the cxf bus is started then they will not be used.
In Apache Karaf the start levels are tuned to first start fileinstall
and config admin, then all cxf bundles and only then the user bundles.
I did not find the environment where you use CXF in the mails. Is it
Karaf or something different?
Christian
Am 06.05.2013 18:48, schrieb geecxf:
> There's something about the logic of that explanation that does not make
> sense to me (though I'll readily admit that may very well be due to my
> ignorance on the matter).
>
> You say that the bundle might be picking up the wrong bus. But why would the
> bundle pick up the right bus on a restart? Why would it pick up the right
> bus if I deliberately load the configuration through the bundle context?
> When I step through the code, there's only one bus.
>
> What is evident from debugging the code is that the conduit is created AFTER
> the client calls are made, after the WebClient is created, after the init
> method that contains the client code is executed, and after the bean that
> contains that init method is instantiated. It's clearly a timing issue and
> probably one that is easy to reproduce by simply creating a bean with an
> init method that uses an http conduit declared in the same Spring
> configuration file.
>
> Is there any insight at all on the order of execution of these things? Are
> beans in a Spring configuration file created before or after the cxf
> configuration beans are processed?
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727299.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Problems with http conduit declared in OSGi spring
configuration
Posted by geecxf <am...@ge.com>.
There's something about the logic of that explanation that does not make
sense to me (though I'll readily admit that may very well be due to my
ignorance on the matter).
You say that the bundle might be picking up the wrong bus. But why would the
bundle pick up the right bus on a restart? Why would it pick up the right
bus if I deliberately load the configuration through the bundle context?
When I step through the code, there's only one bus.
What is evident from debugging the code is that the conduit is created AFTER
the client calls are made, after the WebClient is created, after the init
method that contains the client code is executed, and after the bean that
contains that init method is instantiated. It's clearly a timing issue and
probably one that is easy to reproduce by simply creating a bean with an
init method that uses an http conduit declared in the same Spring
configuration file.
Is there any insight at all on the order of execution of these things? Are
beans in a Spring configuration file created before or after the cxf
configuration beans are processed?
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727299.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring configuration
Posted by Daniel Kulp <dk...@apache.org>.
I think you'll need to spend some time to create a small test case. I have no idea what would cause this. depends-on would definitely not matter as Spring NEVER would create any of the Conduits. Those are only ever created within code and then passed into spring to be configured. Thus, it seems like the HTTP ConduitFactory/Transport is picking up the wrong bus somehow and we'd need to see how/where the Bus's are being created.
Dan
On May 6, 2013, at 12:07 PM, geecxf <am...@ge.com> wrote:
> Yes, I actually came to that conclusion as well as I mentioned in the two
> previous replies:
>
> "The "depends-on" attribute would have to be in the bean with the client
> code that requires the http conduit not the other way around."
>
> I also mentioned in my previous two messages that even if I put a
> "depends-on" attribute in the right place, I get the following error:
>
> "Exception in thread "SpringOsgiExtenderThread-16"
> org.springframework.beans.factory.BeanIsAbstractException: Error creating
> bean with name 'conduit': Bean definition is abstract"
>
> Perhaps I'm not being clear enough. If there is any information you need to
> help clarify this point please let me know.
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727294.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Problems with http conduit declared in OSGi spring
configuration
Posted by geecxf <am...@ge.com>.
Yes, I actually came to that conclusion as well as I mentioned in the two
previous replies:
"The "depends-on" attribute would have to be in the bean with the client
code that requires the http conduit not the other way around."
I also mentioned in my previous two messages that even if I put a
"depends-on" attribute in the right place, I get the following error:
"Exception in thread "SpringOsgiExtenderThread-16"
org.springframework.beans.factory.BeanIsAbstractException: Error creating
bean with name 'conduit': Bean definition is abstract"
Perhaps I'm not being clear enough. If there is any information you need to
help clarify this point please let me know.
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727294.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring configuration
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 06/05/13 16:44, Daniel Kulp wrote:
>
> On May 6, 2013, at 11:32 AM, geecxf<am...@ge.com> wrote:
>
>> Thanks for your response Daniel. However, I'm not sure whether what you are
>> suggesting is to solve the original problem or if you pointing out another
>> issue with the configuration?
>
> It may solve it, not sure. Basically, the config for the conduit is saved in the Bus. If it's picking up the wrong bus somehow, that would cause the issue. The fact that you are creating a separate bus MIGHT be part of the issue.
>
> That all said, a test case is the best option.
>
>
And in this case we actually do not want to set a depends-on attribute
as I implied originally, I see the examples in CXF tests of the
endpoints 'depending' on Jetty httpj:engine, so it kind of rang a bell
with me when I was suggesting that...
Cheers, Sergey
Re: Problems with http conduit declared in OSGi spring
configuration
Posted by geecxf <am...@ge.com>.
You are right that the SpringBus bean was not necessary. However, it does not
solve the original problem. My understanding of the SpringBus was that if a
bus already existed, it would not create a new one but rather provide you
with a way to configure the existing bus. I see now that it is not even
necessary if a bus was already created in a previously loaded bundle.
The main problem still remains. Spring creates the object instances that use
the conduit before the conduit is actually created and thus the calls they
make fail the first time the bundle loads. On a restart the conduits all
ready exist and the calls complete successfully.
Any other thoughts on how to solve this problem?
D
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727293.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring configuration
Posted by Daniel Kulp <dk...@apache.org>.
On May 6, 2013, at 11:32 AM, geecxf <am...@ge.com> wrote:
> Thanks for your response Daniel. However, I'm not sure whether what you are
> suggesting is to solve the original problem or if you pointing out another
> issue with the configuration?
It may solve it, not sure. Basically, the config for the conduit is saved in the Bus. If it's picking up the wrong bus somehow, that would cause the issue. The fact that you are creating a separate bus MIGHT be part of the issue.
That all said, a test case is the best option.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Problems with http conduit declared in OSGi spring
configuration
Posted by geecxf <am...@ge.com>.
Thanks for your response Daniel. However, I'm not sure whether what you are
suggesting is to solve the original problem or if you pointing out another
issue with the configuration?
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727290.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring configuration
Posted by Daniel Kulp <dk...@apache.org>.
On May 6, 2013, at 11:03 AM, geecxf <am...@ge.com> wrote:
> I did try the "depends-on" and it did not work. I posted this earlier but am
> copy/pasting it here again:
>
> =========================
> Unfortunately, this does not work. First, I misspoke in my previous post.
> The "depends-on" attribute would have to be in the bean with the client code
> that requires the http conduit not the other way around. However, even if I
> do that using a configuration like the one below:
>
> <bean id="consumer" class="com.example.AuthConsumer"
> init-method="init" depends-on="conduit,client">
> </bean>
>
> <bean id="cxf" class="org.apache.cxf.bus.spring.SpringBus" />
Remove that line. There should be no need to specify a bus like that.
Dan
>
> <jaxws:client
> id="client"
> name="{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService"
> />
>
>
> <http:conduit id="conduit" name="<a
> href="https://localhost:.*&quot;&gt;">https://localhost:.*">
> <http:client ConnectionTimeout="3000000"
> ReceiveTimeout="3000000" />
> <http:tlsClientParameters
> disableCNCheck="true">
> <sec:keyManagers keyPassword="password">
> <sec:keyStore type="JKS" password="password"
> resource="certs/myKeystore.jks" />
> </sec:keyManagers>
> <sec:trustManagers>
> <sec:keyStore type="JKS" password="password"
> resource="certs/myTruststore.jks" />
> </sec:trustManagers>
> </http:tlsClientParameters>
> </http:conduit>
>
>
> I get the following problem:
>
> Exception in thread "SpringOsgiExtenderThread-16"
> org.springframework.beans.factory.BeanIsAbstractException: Error creating
> bean with name 'conduit': Bean definition is abstract
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.checkMergedBeanDefinition(AbstractBeanFactory.java:1209)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:278)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:284)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
> at
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:69)
> at
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:355)
> at
> org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
> at
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320)
> at
> org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:132)
> at java.lang.Thread.run(Thread.java:722)
>
>
> Which I can't quite explain. Any ideas?
> ========================
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727286.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Problems with http conduit declared in OSGi spring
configuration
Posted by geecxf <am...@ge.com>.
I did try the "depends-on" and it did not work. I posted this earlier but am
copy/pasting it here again:
=========================
Unfortunately, this does not work. First, I misspoke in my previous post.
The "depends-on" attribute would have to be in the bean with the client code
that requires the http conduit not the other way around. However, even if I
do that using a configuration like the one below:
<bean id="consumer" class="com.example.AuthConsumer"
init-method="init" depends-on="conduit,client">
</bean>
<bean id="cxf" class="org.apache.cxf.bus.spring.SpringBus" />
<jaxws:client
id="client"
name="{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService"
/>
<http:conduit id="conduit" name="<a
href="https://localhost:.*&quot;&gt;">https://localhost:.*">
<http:client ConnectionTimeout="3000000"
ReceiveTimeout="3000000" />
<http:tlsClientParameters
disableCNCheck="true">
<sec:keyManagers keyPassword="password">
<sec:keyStore type="JKS" password="password"
resource="certs/myKeystore.jks" />
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="JKS" password="password"
resource="certs/myTruststore.jks" />
</sec:trustManagers>
</http:tlsClientParameters>
</http:conduit>
I get the following problem:
Exception in thread "SpringOsgiExtenderThread-16"
org.springframework.beans.factory.BeanIsAbstractException: Error creating
bean with name 'conduit': Bean definition is abstract
at
org.springframework.beans.factory.support.AbstractBeanFactory.checkMergedBeanDefinition(AbstractBeanFactory.java:1209)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:278)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:284)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:69)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:355)
at
org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:132)
at java.lang.Thread.run(Thread.java:722)
Which I can't quite explain. Any ideas?
========================
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727286.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring configuration
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 06/05/13 15:44, geecxf wrote:
> Hi Sergey,
>
> Just wondering if you had any thoughts on the new information I posted?
I suggested in my previous reply that a 'depends-on' attribute can make
a difference, can you try that attribute please ?
For JAX-WS you can also set a "createdFromAPI" attribute and it will
lead to the actual proxies being created only when requested - the same
will be supported for jaxrs:clients shortly
Cheers, Sergey
>
> Thanks.
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727282.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring
configuration
Posted by geecxf <am...@ge.com>.
Hi Sergey,
Just wondering if you had any thoughts on the new information I posted?
Thanks.
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727282.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring configuration
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 01/05/13 16:20, geecxf wrote:
> Apparently, I spoke to soon. If I load the cxf configuration for my OSGi
> bundle in the following manner:
>
> String[] configs = new String[]
> {
> "classpath:META-INF/spring/cxf-context.xml"
> //$NON-NLS-1$
> };
> OsgiBundleXmlApplicationContext appContext = new
> OsgiBundleXmlApplicationContext(configs, AuthConsumer.applicationContext);
> appContext.setBundleContext(AuthConsumer.bundleContext);
> appContext.refresh();
>
> I see no errors on deployment or startup of the application. Thus, the only
> conclusion I can come to is that the beans that run my client tests are
> created before the http conduit if they are in the same spring configuration
> file. But how do I stop that from happening if I only want to use one file?
> I can't insert a "depends-on" attribute in the conduit definition so there
> is no way for me to tell spring to create the http conduit before creating
> the bean that runs the clients which depend on the conduit.
>
> Does anyone out there have any ideas on how to fix this problem besides the
> solution that I found?
>
>
I can see both jaxws and jaxrs clients can use a "depends-on" attribute,
try that please
Cheers, Sergey
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727012.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problems with http conduit declared in OSGi spring
configuration
Posted by geecxf <am...@ge.com>.
Apparently, I spoke to soon. If I load the cxf configuration for my OSGi
bundle in the following manner:
String[] configs = new String[]
{
"classpath:META-INF/spring/cxf-context.xml"
//$NON-NLS-1$
};
OsgiBundleXmlApplicationContext appContext = new
OsgiBundleXmlApplicationContext(configs, AuthConsumer.applicationContext);
appContext.setBundleContext(AuthConsumer.bundleContext);
appContext.refresh();
I see no errors on deployment or startup of the application. Thus, the only
conclusion I can come to is that the beans that run my client tests are
created before the http conduit if they are in the same spring configuration
file. But how do I stop that from happening if I only want to use one file?
I can't insert a "depends-on" attribute in the conduit definition so there
is no way for me to tell spring to create the http conduit before creating
the bean that runs the clients which depend on the conduit.
Does anyone out there have any ideas on how to fix this problem besides the
solution that I found?
--
View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727012.html
Sent from the cxf-user mailing list archive at Nabble.com.