I'm using Fuse ESB (ServiceMix) and I've been searching all over in the hope to find a better explanation of the various headers when running the command 'osgi:list'. Namely the two columns I want to understand are 'Blueprint' and 'Spring'. I have my guesses as to what their various statuses refer to, but then other scenarios come up which make me question this.
If anyone could provide some explanation, or better, point me to some documentation that explains the various columns and their potential values, that will be most helpful.
here are the meanings of the various values that can show up in those columns:
Created - the blueprint/spring container was created and all dependencies were resolved successfully.
Creating - the bundle is in the process of being created
Destroyed - the bundle's spring/blueprint container was completely destroyed (happens after it's unregistered as a service)
Failure - the bundle's spring/blueprint container failed to start (either due to an exception or a missing dependency after the grace period expires)
Grace Period - The bundle has 1 or more unsatisfied dependencies.
Waiting - the bundle is waiting on the availability of a service that satisfies a dependency
Full documentation can be found by reading the descriptions of the constants for Blueprint. the Spring states mirror those definitions, though I can't find a good resource online for them. As for why they show up for only some bundles: they'll only have a value if the module contains either a blueprint or a spring file.
Apache ServiceMix is using Gemini Blueprint and Spring.
According to Apache website, those columns displays states of bean resolution defined in Blueprint XML and Spring XML files if they are present in the bundle.
For example Created value means that all bean dependencies have been resolved and injected.
Related
I have an application with a complex mix of #Imports and #ComponentScans.
There is a class marked as #Component that I expected not to be added to the application context, but it is, and I want to climb back the scan chain to find out why is that bean registered.
Is there any easy way I can do that e.g. by using Spring Tools 4 Eclipse's plug-in features or maybe programmatically? Googling keywords led to no result.
Enable the actuator and look at the beans endpoint (/actuator/beans).
The resource property tells you, where this bean might have been included.
As the title mentioned, I have a A component required a bean of type [SomeBean] error and I would like to know which component requires [SomeBean]. Is there a way to get more information on which bean requires the missing one?
Also, why do I get this error message? I am pretty sure that sometime missing beans generate a clearer message stating what beans require the missing ones.
Why I am asking:
I am trying to make a spring application that is similar to another (working) one, and use many similar beans. But I have trouble following the bean dependencies. So I removed one bean of the working application and run it in order to know where and how this component is used.
=> So, in general, I am looking for good ways to track bean dependencies in complex contexts.
Some time my IDE (intellij ultimate 2019) gives me some information, but here it doesn't. Maybe because the dependencies span a few packages, many being outside the application code, and use AutoConfiguration. Don't know...
If I use the spring diagram, it generates something that is not really readable (too meany beans). And the diagram is more a list of found beans structured by where there are provided, not the bean dependency diagram: my application list the beans it provides, and the autoConfig list the beans it provides. But It doesn't tell what bean of the autoConf is using which bean that my app provides. Or maybe I just don't understand how it works.
The default log configuration echoes messages to the console as they are written. By default, ERROR-level, WARN-level, and INFO-level messages are logged. You can also enable a “debug” mode by starting your application with a --debug flag.
So, indeed, you should enable that debug mode to see a more detailed log information about your error, which seems to be a missing required bean dependency.
See some more detailed info about in Spring Loggin
We've a cluster of 3 nodes running Oracle Weblogic 12.2.1.2.
Checking weblogic.Stdout log file, I've started to see tons of the following trace:
<Warning><oracle.dms.instrument><DMS-50763> <Attempt to create pre-existing noun /MY_DOMAIN/MY_CLUSTER_NODE_X/DEPLOY_NAME, of type wls_jaxrsapp_resources, with a conflicting type wls_ear.>
MY_DOMAIN is the configured domain in weblogic server, and DEPLOY_NAME is the name of my deployed war in the server.
Looking at Oracle documentation this error is described as:
DMS-50763: Attempt to create pre-existing noun {0}, of type {1}, with
a conflicting type {2}.
Cause: An attempt has been made to create a noun that already exists and has a type that is different from the current attempt to create it.
Action: Correct the code responsible for creating this noun.
Level: 1 Type: SET_AT_RUNTIME Impact: Other
This description looks confusing to me since the proposed action to solve the problem is about correcting the code, but I guess that error is related on how internally the server uses the war name for more than one resource.
I checked if there is other war or artifact deployed with the same name but it's not. Furthermore I thought that wls_ear refers to the deploy war, and wls_jaxrsapp_resources refers to some jaxb-rest resource (messages, stubs...) but I'm not even sure. I'm only guessing because I didn't find anything about it in the Oracle's documentation with this nomenclature.
Can somebody explain this error with more detail to put me in the right direction?
I'm modifying a Maven-based Liferay portlet (6.1.1) that uses Service Layer.
My needs are to add an ActiveMQ listener to the portlet (for communication with external products).
I'm trying to use integrated spring engine (3.0.7) to instance the listener.
So, to start, inside ext-sping.xml (auto managed by Liferay) I defined the following beans:
- a connection factory: org.apache.activemq.ActiveMQConnectionFactory
- a caching connection factory (org.springframework.jms.connection.CachingConnectionFactory) with targetConnectionFactory reference to previous bean.
At deploying time the error I get is:
Cannot convert value of type [org.apache.activemq.ActiveMQConnectionFactory] to
required type [javax.jms.ConnectionFactory] for property
'targetConnectionFactory': no matching editors or conversion strategy found
Obviusly org.apache.activemq.ActiveMQConnectionFactory implements javax.jms.ConnectionFactory, infact if I try to set the value by code, the deploy is done succesfully.
In my pom.xml I try to add a depenency both to activemq-core (just activemq) or activemq-all (contains also javax.jms package), but without success.
How it is possible?
Thank you
Possibly a classloader problem - the classloader loading the CachingConnectionFactory is resolving to a different javax.jms.ConnectionFactory to the one loading the ActiveMQ factory.
Run with -verbose on the command line to see which jar(s) classes are being loaded from.
I'm looking for a way to define transitive log message routing. Let's say we have an application called poly with these packages:
com.mycompany.server-common
com.mycompany.communication
com.mycompany.webservice
server-common is used by both of the 2 others. All 3 use org.hibernate as well.
Now, I like to have 1 logfile for the webservice component with all messages from com.mycompany.webservice and with those messages from com.mycompany.server-common and org.hibernate that were initiated by the webservice. And then, another coresponding file for the communication package.
My application is a war file running in tomcat, where all components run in 1 context (it comes in 1 war file). I already defined the multiple log files, but they naturally only log that what i defined statically, there is no transitive inclusion.
I would be very interested in ideas how I could achieve the desired behaviour. I already thought about using the MDC for that, but I'm not sure if that's a good idea.
Another idea was to separate the contexts, but I think in the current project state this will be hard and it does not offer the flexibility I hope for.
Any hints or discussions are appreciated.
If you set an MDC key when webservice starts serving a request and clear the MDC key at the end of the request, SiftingAppender will do what you are asking. Shout on the logback-user mailing list if you run into difficulties.