I get this too when running knime from CLI. But it seems to be just a warning. It looks ugly in the logs but the workflows are executed.
In my case the KW are not executed, it remains blocked.
I can execute KW only after PC restart.
We have the same issue and it is important for us to get rid of it, since it is flooding the log file - please KNIME tell us how to.
Thanks a lot
PS. Our project partner also has the message and workflow locked issue since 3.6 but not with 3.5
I’m also getting this on some personal work flows i run in batch mode using Knime 3.6
Is there any solution already regarding the warnings about the aries.blueprint issue in the batch mode?
Maybe KNIME can give some information what causes it and how to solve it???
I didn’t manage to find a solution…
Could you please let us know if you have a solution for this? Our Schrodinger automated documentation generation uses the below command:
knime -application org.knime.product.KNIME_BATCH_APPLICATION
to get the documentation of batch mode options and it is cluttered with these lengthy traceback.
I am not seeing the traceback in KNIME 3.7.0. Could anyone else please confirm?
Hi, my workflow also crashes due to that warning. Do you have a solution yet please?
I launch it from command prompt:
knime.exe -consoleLog -nosplash -consoleLog -nosave -reset -preferences=“D:\Users\XXX\knime-workspace\XXX.epf” -application org.knime.product.KNIME_BATCH_APPLICATION -workflowDir=“C:\Users\Public\Documents\XXX_2019-01-02v2” -destFile=“C:\Users\Public\Documents\tested.zip”
The workflows goes ok until:
ADVERTENCIA: Aries Blueprint packages not available. So namespaces will not be registered
As other people have mentioned, this is a common, and non-application-crashing log message - i see it as well, launching from the development environment and not. Unless your specific workflow actually uses nodes which use Blueprint classes directly, i don’t believe it is very likely that this is the source of your workflow crash. Could you supply the whole log from your failed run?
From what I have seen, this error doesn’t happen if you launch the KNIME GUI at some point after you installed it on the machine. In a headless environment obviously that isn’t an option. You should be able to reproduce it by installing knime on the environment and trying to run it in batch mode without ever launching the actual GUI.
EDIT: And yes, this still happens in 3.7
Hi! Thanks for such a quick answer. I removed a node that was not active nor connected but still, printing “ERROR” what was surely the cause of a bad log message.
Seems it works in spite of this error!
Its bad news if this issue is still present in 3.7. It floods our logfiles and is annoying as hell. I was hoping they fix that bug in 3.7
This is not a KNIME issue per se; Apache libraries which are a dependency of something, on which KNIME depends, have a bug that was fixed in a newer version ( see https://issues.apache.org/jira/browse/CXF-7142 ). At some point KNIME will be able to migrate to a newer version of the dependency which will hopefully move the CXF dependency (currently on 3.0.7) to a fixed version.
Did anyone find a solution how to fix this?
I got the information that this behavior is related to a problem with a third party dependency, as quaeler pointed out. Since this dependency is fixed already, I would assume KNIME is using the fixed version soon and then its solved. Maybe KNIME can comment on that.
I tested today version 3.7.1 the issues is still here
How to deal with this problem? Steal present in version 3.7
I’m not aware of any time line for the dependency to get updated in KAP.
I realize that it is ugly text noise that needs to be ignored, but is there a problem beyond that for you?
It would be great if this “ugly text noise” would vanish asap, since its hard to simply ignore it if it appears everywhere in the logs and make everything more complicated and always causing the impression to everyone who has to look at (and don’t know already) there is a big problem underneath.