gnodet: ever seen SMX4 stall at startup -- very early on in the process?

edelln: will you be providing additional patches for moving the other examples or do you want me to do that?

10gertv:01 I have them almost complete - I will just update the jbi maven plugin to test them and supply you a patch

edelln: ok, thx once again for the patch

gertv: I'v seen smx4 hang intermittently when start it, but it's not very often, I'm on Linux

ffang: yeah, me too

it doesn't ever do it the first time you start it, but if you 'exit' from the console and then try again, you're bound to run into it at some point

gertv: yeah, sometimes it happen even with empty data folder

gertv: we may need raise a jira to track this issue

ffang: yeah, will do

gnodet: could you review http://svn.eu.apache.org/viewvc?view=rev&revision=677248 for me?

gnodet: did you intend to protect the factories map from concurrent access with the synchronized on bundleChanged?

gertv: is this supposed to solve the problem where smx4 hangs at startup ?

yes, i think so

yes, I think it does solve it

gnodet: the bundleChanged method was called while still in the start() method -- causing a lock on the Activator object

gertv: but if this is the case, the bundleContext will not be set correctly at the time the bundleChanged() method is called ?

which should not be a problem, as it is not used but in the stop method it seems

why not? it is set before even adding the listener

i don't follow

bundleChanged was called by the osgi framework while still in the start() metho, right ?

this is because the iteration in start() takes a long time

yes, but if you first set the bundleContext and only then add the class as a bundle listener

good point

it shouldn't get bundleChanged() callback before it has been set a bundle listener

it looks good then

meaning we have to re-release the specs ...

yep

thanks for reviewing, always appreciate a second opinion on these type of locking/concurrency issues

they're so easy to mess up

I have the examples ready to submit for smx4 but when I am building a kit just from features trunk it attempts to copy the jar file into a directory in my local repo "SU_NAME.jbi-service-unit and so when it trys to find the dependencies for the assemblies it falls over

if I go and build examples beforehand all the jars will be in my local repo

edelln: not sure I get what the problem is

the assembly should only copy over the sources and readme/pom, no?

Well this is when I do mvn install from the top of the features project

so its supposed to build examples before assembly

ok

If you delete your examples directory in your local repo and try this it will fall over when building the bridge

but it doesn't do it in that order?

gertv is giving it a try

It does but I never see the jar files for the service units been copied to my local repo - it just copies the zips

gertv needs to rebuild the maven jbi plugin again as well

edelln: ok, I see your problem now

10gertv:01 yeah and if I build the examples locally to get around this issue - it then falls over with 10Unrecognised tag: 'filtered'01

I guess this is due to the maven plugin updates

edelln: yes, the 4.0-SNAPSHOT version of the plugin is broken

it might have been before as well - smx 3.3 branch uses the released 3.2.1 version

could you raise yet another issue for it and I'll take a look as soon as I got these NPE from ESB-321 fixed?

yep!

I will put the patch together anyway as I have changed the version attribute to be a property in all the demos so when it does change we only need to change it in one place

great! we should be able to release it with plugin version 3.2.1 as well if I can't get it fixed in time anymore

سلام

10gertv: 01https://issues.apache.org/activemq/browse/SMX4-64

hi

10 gertv: 01 I added the demos and patch to https://issues.apache.org/activemq/browse/SMX4-61 so when you get a chance if you can apply them that would be great

edelln: I've just fixed the NPE thingy, so I'll do it right away

edelln: thx for the patch

great!

gertv: are you looking at SMX4-64 ?

yeah, I was just going to ping you for that

gnodet: very strange, doesn't happen if you start the build from the /examples directory

but it does fail if you start it from features root

does that ring any bells?

not yet

gnodet: I can only think of some dependency being pulled in in wrong version by a plugin defined at the root pom.xml

gnodet: but that isn't the case -- just ran both of them redirecting output and I can't see the difference there

gnodet: how does it know to use .jar? only from the ArtifactHandler registered in plexus/components.xml?

can you paste the log, i'm still downloading tons of stuff while building

those things are huge as well -- 8 MB

ran mvn with -X to get more info

what do you want to see? or do you want me to send them over to you?

what is the ".jar" you're talking about ?

well, if you run the thing from features root, it does

[INFO] Installing /home/gert/Projects/smx4/features/examples/bridge/bridge-http-su/target/bridge-http-su-4.0-m2-SNAPSHOT.jar to /home/gert/.m2/repository/org/apache/servicemix/examples/bridge/bridge-http-su/4.0-m2-SNAPSHOT/bridge-http-su-4.0-m2-SNAPSHOT.jbi-service-unit

[INFO] Installing /home/gert/Projects/smx4/features/examples/bridge/bridge-http-su/target/bridge-http-su-4.0-m2-SNAPSHOT.zip to /home/gert/.m2/repository/org/apache/servicemix/examples/bridge/bridge-http-su/4.0-m2-SNAPSHOT/bridge-http-su-4.0-m2-SNAPSHOT.zip

notice the .jbi-service-unit extension

running it from examples yields

[INFO] [install:install]

[INFO] Installing /home/gert/Projects/smx4/features/examples/bridge/bridge-http-su/target/bridge-http-su-4.0-m2-SNAPSHOT.jar to /home/gert/.m2/repository/org/apache/servicemix/examples/bridge/bridge-http-su/4.0-m2-SNAPSHOT/bridge-http-su-4.0-m2-SNAPSHOT.jar

[INFO] Installing /home/gert/Projects/smx4/features/examples/bridge/bridge-http-su/target/bridge-http-su-4.0-m2-SNAPSHOT.zip to /home/gert/.m2/repository/org/apache/servicemix/examples/bridge/bridge-http-su/4.0-m2-SNAPSHOT/bridge-http-su-4.0-m2-SNAPSHOT.zip

sounds like the maven plugin extensions are not loaded ?

have you tried adding a pluginManagement section for the jbi maven plugin in the root pom ?

yep

still no good

with the <extension>true</extensions> tag ?

<plugin>

<groupId>org.apache.servicemix.tooling</groupId>

<artifactId>jbi-maven-plugin</artifactId>

<version>${servicemix-jbi-plugin-version}</version>

<extensions>true</extensions>

</plugin>

well, there are these org.codehaus.plexus.component.repository.exception.ComponentLookupException: Component descriptor cannot be found in the component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingjbi-service-unit.

in the log file as well

but they appear for both the failing and succeeding builds

gnodet: no science involved, just 'flying by google', but...

* @parameter expression="${project.build.directory}/classes"

*/

private File serviceUnitLocation;

+

+ /**

+ * @parameter expression="${component.org.apache.maven.artifact.handler.ArtifactHandler#jbi-service-unit}"

+ */

+ private ArtifactHandler handler;

public void execute() throws MojoExecutionException, MojoFailureException {

try {

-

+ project.getArtifact().setArtifactHandler(handler);

createUnpackedInstaller();

File serviceUnitFile = new File(outputDirectory, serviceUnitName);

this seems to fix it on my machine

sounds good, but why would it only appear now ?

is there any change in maven that cause the problem ?

like I said: no science involved -- I don't have the slightest idea

ok, so you don't run into the IncompatibleClassChangeError if you use 4.0-SNAPSHOT ?

no, I have fixed that yesterday

but you do need to rebuild plugins for that

ah, haven't svn up the plugins

and they haven't been rebuilt yet at EC2 either

gnodet: do you want to dig deeper to find the root cause for the ArtifactHandler?

no

ok, so I just commit my 'thx-to-google-fix' and get it over with

i was just curious, but i don't think it's worth spending too much time on that

yeah

gertv: is there anyhting left to do on SM-1455 ? all components / shared libs depend on 3.2.1 now

or did you meant something else ?

should they depend on that for anything but testing?

the JBI API perhaps?

well, we can't remove all the dependencies right now

gnodet: could you do an svn up on the plugin to check it on your machine as well?

for example, they depend on the jbi.jaxp package

it has been extracted out of smx-core, but not released yet

so either we depend on smx-core-3.2.1, or smx-utils-3.3-SNAPSHOT

but of them are part of the container, right?

there are still a few dependencies, right

that's why smx-core is included in servicemix-shared atm

shouldn't these things go outside of containers and components in the long run?

like a servicemix-commons project to hold them?

well, maybe, but the problem is that parts of the container use those packages

so we'd really have to prune things like lightweight components

to get rid of most of the problem i think

but if we separate them out in e.g. servicemix-commons and release that

i haven't done a thorough analysis of the dependencies though

both the components and the container can depend on that

and we can reuse it for smx4 as well

would make sense for things like JAXP which is all about custom Source implementation and stuff like that iirc

yeah, it should be possible now that we don't depend on 3.3-SNAPSHOT anymore

for itesting, we still have to rely on the latest container release

gnodet: btw, the thesis student that asked about monitoring a few weeks ago is going to do his work on the JCR auditing stuff in sandbox

yay! nice :-)

guys! I rebuilt the plugins and tryed to build the kit again but I still get the same issue (windows)

edelln: did you change the version of the plugin used in the root pom.xml ?

afaik, it points to 3.2.1 and not 4.0-SNASPHOT

well, I did add the plugin the pluginmanagement here as well

let me commit that too so you can give it another go

yep its 3.2.1 as I was trying to play around fixing this as well

edelln: if you svn up, everything should be there

ok will give it another go

edelln: I do get the exception about the <filtered> element now for the first time? did you perhaps mean that one?

I just see now that it's in the same issue as the .jbi-service-unit thing

yeah! I hit that after once I had the demos builts locally

I thought they were related so put them in the one issue

no, they're not, but sorry I missed it

gertv promises to read the *entire* issue next time

that's probably because it picked up an older version of the assembly plugin somewhere/somehow

ok let me check the demos as I put a property in the root pom for the version of the assembly plugin - maybe I missed one but they all seem to be using 2.1

that should be 2.2-beta-2 instead of 2.1

we need it to handle snapshot and filtering correctly

yeah alot of the demos had 2.1 hardcode in their poms

ok, let me try to fix that

I did catch all the hardcoded versions so all you should have to change is the property in the root pom

could you svn up and give it another try?

sure

jstrachan: could you run the servicemix maven plugins build manually on the CI build box?

sure - is it not run now?

gertv: can you check if https://issues.apache.org/activemq/browse/SM-1396 is solved now ? i think that's the issue you fixed yesterday, right ?

or maybe this is unrelated, if so i'll commit the provided patch

this is unrelated, I think

ok

jstrachan: it is run, but only after the SMX4 build

and the SMX4 build is going to fail unless we have an updated snapshot version of the plugins first

smx3 or smx4?

can't we just hack the smx[3|4] shell script to change the order?

I looked at that, but it's a different shell scripts

ah ok

jstrachan wishes he'd figured out how to put the crontab into svn

the one that needs to be run is smx-mvn-plugins-pom.sh

thats run before smx4-nightly apparenlty

ok, so I misread those wacky american time zone then

current crontab: http://rafb.net/p/wI0pRj93.html

ok, thx for looking into it then

yay! I got the kit built

edelln: yay!