gertv: hi

Do you know, if I can have 2 sessions on one activeMQConnection?

and one listenerContainer a and 2 destination on it?

2 sessions on 1 connection: yes

2 destinations on a listenerCOntainer: don't know -- I don't think so

so, you think, that I must to create 2 containers?

yeah, I think so

ok\

which isn't too bad -- it's just two fields in the abstractauditor

both containers can have the same connectionFactory or I must create 2 connectionFactory with the same broker URL

gnodet: ping

gertv: pong

gnodet: did you take a look at the changes I committed this morning to make servicemix-bean independent of SMX3?

gnodet: are they ok for you?

gnodet: and I think there is a problem with your fix for SM-1524 in trunk

gertv: how so ? it seems to work ...

gnodet: this fix works fine for branch, but in trunk, with the async handling, we shouldn't be disposing the working memory at that point in time imho

ah, ok, i missed that

gnodet: there still is a call to helper.update() for a consumer exchange

we should set up a test case for the async stuff i guess

we should set up a test case that evaluates the rules for a DONE InOUt messageExchange

everything else is being tested asynchronously

that was supported in the original code and is no longer working after your fix I think

yeah, i see the problem

btw, could you have a look at my comment on https://issues.apache.org/activemq/browse/SM-1515 ?

I was actually going to refactor this by adding a DroolsExecutionContext to hold the drools listeners and workingmemory

instead of holding on to the JbiHelper and having to wire that to everything else

yeah, that's a mistake I think

I added this first and only then did I discover the fix you made on trunk

so I backported your fix to branch (for an iona issue) but I should have removed this again

btw, were you talking about http://svn.apache.org/viewvc?view=rev&revision=690139 ? it seems there's no code change at all, just modified imports

yeah, it's all about modifying imports, isn't it

yeah, so i don't have any problems with that, it should be very low risk

gertv is trying to find the commit for the changes to -core and -utils

so are you looking at the drools stuff or do you want me to handle it ?

this is what I did to the -utils to make this working

http://svn.apache.org/viewvc?view=rev&revision=690130

gertv: the MessageExchangeListener is a copy or a move ?

that's a copy

ok

and I extended the old one of the new copy

so old beans hanging around with customers implementing the old interface will also be matched

yeah

btw, i don't see the commit on servicemix-core, have you commit it already ?

no, I just noticed it's still outstanding

and has checkstyle errors :(

k

for the drools stuff - I can do it if you want, it's up to you

with servicemix-bean done, I don't expect to much of problem with the other components actually

gnodet: matching changes for -core are in http://svn.apache.org/viewvc?view=rev&revision=690162

i'm deep in servicemix-http right now, so i may not have much time today for the drools stuff

and for SM-1515, feel free to remove that or reopen/assign the issue for me to do it

ok, I'll cover that then

and I guess you take care of SM-1515 while you're at it?

well, i don't see the need for the override in the soap case

no, as I said, that's a mistake on my behalf

I found that feature on the old endpoints and reproduced that

i just need to make sure the SoapAction header is correctly set

ok

only then to discover you made the other fix

i've reassigned SM-1524 to you and SM-1515 to myself

thx

btw, i think the old MessageExchangeListener interface should be empty no

s/no/now

yeah, definitely

and I also missed adding some more deprecated's apparently

hello

every one

tommorw is weekend

time is so speed

gnodet: ping

gertv: pong

gnodet: how about the jsr181 component? it now has the ability to inject the JBIContainer into the POJO

gnodet: since it's getting kind of deprecated, it's probably not worth spending too much time on that

yeah, we can defer that a bit i guess

we could use introspection somehow to avoid having a strong reference to smx3

we already do

Method mth = pojo.getClass().getMethod("setContainer", new Class[] {JBIContainer.class });

mth.invoke(pojo, new Object[] {container });

if this is what you mean?

no, we need to avoid the JBIContainer import from the Jsr181Endpoint, else it won't load in servicemix 4

at least not with an osgi packaging

though it work with the jbi one

but since it is deprecated for smx4, can't we add this component to an extra/deprecated folder

and also add servicemix-core there as a bundle?

that's a possibility

or only add the JBI packaged component to the extra/deprecated

not adding it with osgi packaging at all

the jbi component mandates servicemix-shared ...

right... so we add it as an osgi bundle and mention in the readme how to osgi -s the 3.3 servicemix-core

so we don't need the latter for building the smx4 kit, but people can still use jsr181

and we have notified them that they should be starting to use the CXF components

gnodet: what about the wsn PublisherComponent?

gnodet: that uses the lightweight component way of working, apparently

yes it is

we should rewrite one for smx4 at some point

gnodet: do you think many users are using the JBIContainer.getComponent() directly?

gnodet: I'd like to rename it to getComponentMBean and add a real getComponent() that returns the Component directly

gnodet: instead of inventing a fake interface like ComponentHolder or ComponentWrapper to implement on the ComponentMBeanImpl

gnodet: or I can implement the few additional methods that aren't being delegated already on the ComponentMBeanImpl to make it implement Component?

gertv: you want to give access to the javax.jbi.Component ? i think it's wrapped so I'm not sure it it would work

yeah, that's my problem

it's wrapped in the ComponentMBeanImpl

so to avoid the dependency on the ComponentMBeanImpl, I could add another interface like ComponentWrapper

gertv: have you seen the Container class in org.apache.servicemix.common ?

now I have ;)

I added an interface Container for the same reasons

you suggest I remove the interface and implement the getClientFactory() and getComponent() here too?

i guess it depends what we want to port to smx4

the getComponent would only be used by the http managed servlet ?

not sure if this class will ever be used in servicemix 4 ...

that's the only place where we really need it right now

we have a few other places that do the same routine

get the container -> get the mbean -> get the component

but those are either in tests or in the container itself

outside servicemix-core ?

yeah

so the above servlet is only used when embedding smx3 in a war

i think we should aim to make the components as much independant on smx jbi container, rather than implementing some common interface (which would then tie them to either smx3/smx4, but would still be tied to smx somehow)

yeah, that would be the next step I guess

once we get rid of the compile-time dependencies, we should check why and if we really need the dependencies on the custom API

that's the reason I put the API like stuff in separate package

i'm really more worried about runtime dependencies rather than compile-time dependencies

i see

we should be depending on any custom API really - right?

only the pure JBI API and our own SL

it might be ok to provide additional features if you use the component on smx though

and that we could use the custom API for -- but I agree we should get rid of those as a runtime dependency too

yeah

for example the CxfSeProxyFactoryBean is a problem (and the jsr181 one too)

yep, it is

perhaps I should mark the custom API parts in -utils deprecated then?

and open a subsequent issue to factor that out after the builds have been properly split?

although it would be nice to have e.g. a custom API for talking JBI to SMX3 and SMX4

like the client API

but we should still factor out things like the Container interface

i don't think the client api is heavily used

it was leaking memory until quite recently and no one noticed that

(the DONE status was not sent for InOut exchanges)

is that the question we had a few weeks back on the mailing list then?

i don't recall

i found the problem when writing unit tests

http://cwiki.apache.org/SM/discussion-forums.html#nabble-td18962632

well, I did recommend the API a few times in the past on questions on the mailing list

so it's a good thing it got fixed

btw dumb question - why does the smx4 maven plugins only build in the 'all' profile?

i.e. who would try build that without using the profile?

jstrachan: what pom.xml are you looking at?

jstrachan: Hi!

jgenender: hey!

Good to see ya ;-)

gertv: just tried to build https://svn.apache.org/repos/asf/servicemix/maven-plugins/.../trunk and scratched my head a bit why nothing built

jgenender: you too! :)

jstrachan: looks like chirino_m added the profile

jstrachan: the commit comment for it is "Can't seem to be able to use the release plugin in a non-reactor mode, so move the module declarations into a profile"

jstrachan: just made the profile active by default -- this should be enough to avoid people scratching their heads over it ;)

yay