I've removed the code setting this bus property. When it was initially
introduced few years back I believe a single factory was supporting
multiple endpoints, hence it was needed at a time.
Thanks, Sergey
On 20/06/16 20:49, Sergey Beryozkin wrote:
Setting providers directly on a bus is a CXF optimization which was done
mainly to help in cases where there are many jaxrs:server endpoints
needing to share the same providers. It is not required to set the
providers on the bus. Unless you have 3+ or even more jaxrs endpoints
then the optimization is minimalistic. Simply refer to the same
providers from the endpoints and the clients directly.
The fact that the same bus is also used for per-request clients causes
side-effects (this indeed will need to be addressed) and as I said you
can have jaxrs:clients using their own Buses, while still referring to
the same shared providers from within jaxrs:client/jaxrs:providers.
Also rather than creating a new client per every request you can inject
a thread-safe client and use this single client.
The client interceptor code looks ok if it is what you prefer to do.
Sergey
On 20/06/16 19:41, [email protected] wrote:
Yes Sergey. You are right. Client is created for every request. And this
being the case, a new marker entry (factory hashCoded) is added
everytime,
although they are not used or, referred elsewhere. It looks like a CXF
defect.
Regarding the providers, we need the providers on both hosted services as
well as clients (i.e. shared). So, your suggestion of registering the
providers only for clients does not help.
If you feel the mentioned issue is a defect, could you suggest a
work-around
solution for now?
Although I have tested a custom interceptor to do the clean-up of these
entries, I need your review to see if it would impact any part of the CXF
framework. Please find the source code below.
*Java code*
/public class PurgeFactoryHashcodeInterceptor extends
AbstractPhaseInterceptor<Message> {
public PurgeFactoryHashcodeInterceptor() {
super(Phase.PREPARE_SEND);
addBefore(MessageSenderInterceptor.class.getName());
}
@Override
public void handleMessage(Message message) throws Fault {
cleanUpBusProperties();
}
@Override
public void handleFault(Message message) throws Fault {
cleanUpBusProperties();
}
private void cleanUpBusProperties() {
Bus bus =
SpringContextProvider.getApplicationContext().getBean(Bus.class);
Map<String,Object> origBusPropMap = bus.getProperties();
for(Map.Entry<String,Object> busPropEntry :
origBusPropMap.entrySet()) {
if(busPropEntry.getKey().startsWith("bus.providers.set.")) {
origBusPropMap.remove(busPropEntry.getKey());
}
}
}
}/
*Spring configuration*
/<bean id="purgeFtryHashcodeInterceptor"
class="com.mycompany.ws.interceptor.PurgeFactoryHashcodeInterceptor" />
<cxf:bus>
<cxf:properties>
<entry key="org.apache.cxf.jaxrs.bus.providers">
<list>
<ref
bean="throwableExceptionMapper" />
<ref bean="customFilter1" />
</list>
</entry>
</cxf:properties>
<cxf:outInterceptors>
<ref bean="purgeFtryHashcodeInterceptor" />
</cxf:outInterceptors>
</cxf:bus>/
--
View this message in context:
http://cxf.547215.n5.nabble.com/Unwanted-bunch-of-Bus-Provider-objects-in-HashMap-occupying-large-volumes-of-heap-memory-tp5769515p5769607.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
