Questions about setting up Apache Ignite in Docker-Compose - docker-compose

See much further down for my updated scenario...
I am experimenting with setting up Apache Ignite in our Docker-compose environment and have a few questions about Ignite and how to configure it.
What is the purpose of downloading and running the Apache Ignite binaries if I have the Maven dependencies in the project? Do I need to run Ignite as well in each module or is just having the dependencies enough?
Does each instance of an Ignite node need to have an associated configuration and how do those differ from each other?
I have a Docker-Compose file with two services, one that pulls in the Ignite container and a Java shell that lets me run/test my module. In my shell, when I am running the compose services, it appears that my test discovers the ignite service. When I run my test out of IntelliJ it does not discover the other Ignite server.
My compose services:
#Ignite
ignite:
image: apacheignite/ignite
environment:
- IGNITE_QUITE=false
#volumes:
# - ./project/src/test/resources/ignite.xml:/opt/ignite/apache-ignite-fabric/config/default-config.xml
ports:
- 11211:11211
- 47100:47100
- 47500:47500
- 49112:49112
# Java Shell
java:
image: local/java
build:
context: .
command: /bin/bash
volumes:
- .:/project
depends_on:
- ignite
ports:
- 8000:8000
- 8080:8080
- 1099:1099
My Ignite configuration I am using in the test:
<bean id="ignite.cfg"
class="org.apache.ignite.configuration.IgniteConfiguration">
<property name="discoverySpi">
<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="ipFinder">
<bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
<property name="addresses">
<list>
<!--
Explicitly specifying address of a local node to let it start and
operate normally even if there is no more nodes in the cluster.
You can also optionally specify an individual port or port range.
-->
<value>127.0.0.1</value>
<!--
IP Address and optional port range of a remote node.
You can also optionally specify an individual port.
-->
<value>127.0.0.1:47500..47509</value>
</list>
</property>
</bean>
</property>
</bean>
</property>
</bean>
My test:
#Test
//#Ignore
public void should_run_cluster()
{
try (Ignite ignite = Ignition.start("ignite2.xml"))
{
IgniteCache<Integer, String> cache = ignite.getOrCreateCache("myCacheName");
// Store keys in cache (values will end up on different cache nodes).
for (int i = 0; i < 10; i++)
{
cache.put(i, Integer.toString(i));
}
for (int i = 0; i < 10; i++)
{
System.out.println("Got [key=" + i + ", val=" + cache.get(i) + ']');
}
}
}
Depending on what I do, when running it out of IntelliJ, i seem to be able to talk to the Ignite node but it rejects the node joining the cluster.
I've tried exposing the ports (different port#'s, not exposed only internal, etc.) from the Java service but no luck.
If I try and attach my configuration to the Ignite service it completely does not work.
My end goal is to setup an environment using Docker-Compose that I can join locally for testing purposes but, eventually, move this to ECS/Fargate.
I am sure I am getting my configurations mixed up and any help would be appreciated...
----- UPDATE-----
So, i've been able to connect to Ignite from IntelliJ using localhost/127.0.0.1 and within the container network using the compose service name 'ignite.'
Is this the right way to do this? I cant see how I can use the same configuration, without using doing some token replacement (${port}), for each node because it seems I need to have a unique port value for the DiscoverySpi and the CommunicationSpi.
Also, when connecting from my client, in this case a JUnit, it takes forever to establish that initial connection.
So, my question now is if this is the right way to configure Ignite?
"Ignite" Service (in Compose):
ignite:
image: apacheignite/ignite
environment:
- IGNITE_QUIET=false
volumes:
- ./project/src/test/resources/ignite-main.xml:/opt/ignite/apache-ignite-fabric/config/default-config.xml
ports:
- 11211:11211
- 47100:47100
- 47500:47500
- 49112:49112
"Ignite" Service Configuration (ignite-main.xml):
<property name="discoverySpi">
<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="localPort" value="47500"/>
<property name="ipFinder">
<bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
<property name="addresses">
<list>
<value>localhost</value>
<value>localhost:47500</value>
</list>
</property>
</bean>
</property>
</bean>
</property>
<property name="communicationSpi">
<bean class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
<property name="localPort" value="47100"/>
</bean>
</property>
Client Ignite Configuration (ignite.xml):
<property name="discoverySpi">
<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="localPort" value="47501"/>
<property name="ipFinder">
<bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
<property name="addresses">
<list>
<value>localhost</value>
<value>localhost:47500</value>
</list>
</property>
</bean>
</property>
</bean>
</property>
<property name="communicationSpi">
<bean class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
<property name="localPort" value="47101"/>
</bean>
</property>
Client Ignite Test Case:
private static Ignite ignite;
#BeforeClass
public static void beforeAll()
{
ignite = Ignition.start("ignite.xml");
}
#AfterClass
public static void afterAll()
{
ignite.close();
}
#Test
public void should_prep_cluster()
{
IgniteCache<Integer, String> cache = ignite.getOrCreateCache("myCacheName");
// Store keys in cache (values will end up on different cache nodes).
for (int i = 0; i < 10; i++)
{
cache.put(i, Integer.toString(i));
}
for (int i = 0; i < 10; i++)
{
System.out.println("Got [key=" + i + ", val=" + cache.get(i) + ']');
}
}

As a supplement to #alamar's answer:
Since Docker Compose services launch in separate containers, you can not use localhost or 127.0.0.1 to discover server node. You can link ignite service to be able to use DNS name ignite.
Compose services:
# Ignite
ignite:
image: apacheignite/ignite
environment:
- IGNITE_QUIET=false
# volumes:
# - ./project/src/test/resources/ignite.xml:/opt/ignite/apache-ignite-fabric/config/default-config.xml
# It is not necessary to expose ports outside if they are only used inside docker-compose
# ports:
# - 11211:11211
# - 47100:47100
# - 47500:47500
# - 49112:49112
# Java Shell
java:
image: local/java
build:
context: .
command: /bin/bash
volumes:
- .:/project
links:
- ignite
ports:
- 8000:8000
- 8080:8080
- 1099:1099
Client Ignite Configuration (ignite.xml):
<property name="discoverySpi">
<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="ipFinder">
<bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
<property name="addresses">
<list>
<value>ignite:47500</value>
</list>
</property>
</bean>
</property>
</bean>
</property>

So that you can run stand-alone Ignite node with any set of modules, and e.g. run SQL against it with sqlline, or (while using peer class loading) do almost anything with connected Ignite clients to it. But then again, you can run Ignite nodes (client or server) directly from Maven projects, in this case you don't need binary distribution at all.
Yes. Aside from node properties or consistentId which is not required, they may be identical.
It's hard to say. Can you provide logs? I think that people who understand containers can check it without logs, but I can't.

Related

Unable to dynamically scale Ignite Pods in Kubernetes

We have been experimenting with the number of Ignite server pods to see the impact on performance.
One thing that we have noticed is that if the number of Ignite server pods is increased after client nodes have established communication the new pod will just fail loop with the error below.
If however the grid is destroyed (bring down all client and server nodes) and then the desired number of server nodes is launch there are no issues.
Also the above procedure is not fully dependable for anything other than launching a single Ignite server.
From reading it looks like [this stack over flow][1] post and [this documentation][2] that the issue may be that we are not launching the "Kubernetes service".
Ignite's KubernetesIPFinder requires users to configure and deploy a special Kubernetes service that maintains a list of the IP addresses of all the alive Ignite pods (nodes).
However this is the only documentation I have found and it says that it is no longer current.
Is this information still relevant for Ignite 2.11.1?
If not is there some more recent documentation?
If this service is indeed needed, are there some more concreate examples and information on setting them up?
Error on new Server pod:
[21:37:55,793][SEVERE][main][IgniteKernal] Failed to start manager: GridManagerAdapter [enabled=true, name=o.a.i.i.managers.discovery.GridDiscoveryManager]
class org.apache.ignite.IgniteCheckedException: Failed to start SPI: TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000, ackTimeout=5000, marsh=JdkMarshaller [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1#78422efb], reconCnt=10, reconDelay=2000, maxAckTimeout=600000, soLinger=0, forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null, skipAddrsRandomization=false]
at org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:281)
at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:980)
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1985)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1331)
at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1066)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:952)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:851)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:721)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690)
at org.apache.ignite.Ignition.start(Ignition.java:353)
at org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Node with the same ID was found in node IDs history or existing node in topology has the same ID (fix configuration and restart local node) [localNode=TcpDiscoveryNode [id=000e84bb-f587-43a2-a662-c7c6147d2dde, consistentId=8751ef49-db25-4cf9-a38c-26e23a96a3e4, addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, fd00:85:4001:5:f831:8cc:cd3:f863%eth0], sockAddrs=HashSet [nkw-mnomni-ignite-1-1-1.nkw-mnomni-ignite-1-1.680e5bbc-21b1-5d61-8dfa-6b27be10ede7.svc.cluster.local/fd00:85:4001:5:f831:8cc:cd3:f863:47500, /0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500], discPort=47500, order=0, intOrder=0, lastExchangeTime=1676497065109, loc=true, ver=2.11.1#20211220-sha1:eae1147d, isClient=false], existingNode=000e84bb-f587-43a2-a662-c7c6147d2dde]
at org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.duplicateIdError(TcpDiscoverySpi.java:2083)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1201)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:473)
at org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2207)
at org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
... 13 more
Server DiscoverySpi Config:
<property name="discoverySpi">
<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="ipFinder">
<bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder">
<property name="namespace" value="myNameSpace"/>
<property name="serviceName" value="myServiceName"/>
</bean>
</property>
</bean>
</property>
Client DiscoverySpi Configs:
<bean id="discoverySpi" class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="ipFinder" ref="ipFinder" />
</bean>
<bean id="ipFinder" class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
<property name="shared" value="false" />
<property name="addresses">
<list>
<value>myServiceName.myNameSpace:47500</value>
</list>
</property>
</bean>
Edit:
I have experimented more with this issue. As long as I do not deploy any clients (using the static TcpDiscoveryVmIpFinder above) I am able to scale up and down server pods without any issue. However as soon as a single client joins I am no longer able to scale the server pods up.
I can see that the server pods have ports 47500 and 47100 open so I am not sure what the issue is. Dows the TcpDiscoveryKubernetesIpFinder still need the port to be specified on the client config?
I have tried to change my client config to use the TcpDiscoveryKubernetesIpFinder below but I am getting a discovery timeout falure (see below).
<property name="discoverySpi">
<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="ipFinder">
<bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder">
<property name="namespace" value="680e5bbc-21b1-5d61-8dfa-6b27be10ede7"/>
<property name="serviceName" value="nkw-mnomni-ignite-1-1"/>
</bean>
</property>
</bean>
</property>
24-Feb-2023 14:15:02.450 WARNING [grid-timeout-worker-#22%igniteClientInstance%] org.apache.ignite.logger.java.JavaLogger.warning Thread dump at 2023/02/24 14:15:02 UTC
Thread [name="main", id=1, state=WAITING, blockCnt=78, waitCnt=3]
Lock [object=java.util.concurrent.CountDownLatch$Sync#45296dbd, ownerName=null, ownerId=-1]
at java.base#17.0.1/jdk.internal.misc.Unsafe.park(Native Method)
at java.base#17.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:211)
at java.base#17.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:715)
at java.base#17.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1047)
at java.base#17.0.1/java.util.concurrent.CountDownLatch.await(CountDownLatch.java:230)
at o.a.i.spi.discovery.tcp.ClientImpl.spiStart(ClientImpl.java:324)
at o.a.i.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2207)
at o.a.i.i.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
at o.a.i.i.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:980)
at o.a.i.i.IgniteKernal.startManager(IgniteKernal.java:1985)
at o.a.i.i.IgniteKernal.start(IgniteKernal.java:1331)
at o.a.i.i.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at o.a.i.i.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
- locked o.a.i.i.IgnitionEx$IgniteNamedInstance#57ac9100
at o.a.i.i.IgnitionEx.start0(IgnitionEx.java:1172)
at o.a.i.i.IgnitionEx.startConfigurations(IgnitionEx.java:1066)
at o.a.i.i.IgnitionEx.start(IgnitionEx.java:952)
at o.a.i.i.IgnitionEx.start(IgnitionEx.java:851)
at o.a.i.i.IgnitionEx.start(IgnitionEx.java:721)
at o.a.i.i.IgnitionEx.start(IgnitionEx.java:690)
at o.a.i.Ignition.start(Ignition.java:353)
Edit 2:
I also spoke with an admin about opening client side ports in case that was the issue. He indicated that should not be needed as clients should be able to open ephemeral ports to communicate with the server nodes.
[1]: Ignite not discoverable in kubernetes cluster with TcpDiscoveryKubernetesIpFinder
[2]: https://apacheignite.readme.io/docs/kubernetes-ip-finder
It's hard to say precisely what the root cause is, but in general it's something related to the network or domain names resolution.
A public address is assigned to a node on a startup and is exposed to other nodes for communication. Other nodes store that address and nodeId in their history. Here is what is happening: a new node is trying to enter the cluster, it connects to a random node, then this request is transferred to the coordinator. The coordinator issues TcpDiscoveryNodeAddedMessage that must circle across the topology ring and be ACKed by all other nodes. That process didn't finish during a join timeout, so the new node is trying to re-enter the topology by starting the same joining process but with a new ID. But, other nodes see that this address is already registered by another nodeId, causing the original duplicate nodeId error.
Some recommendations:
If the issue is reproducible on a regular basis, I'd recommend collecting more information by enabling DEBUG logging for the following package:
org.apache.ignite.spi.discovery (discovery-related events tracing)
Take thread dumps from affected nodes (could be done by kill -3). Check for discovery-related issues. Search for "lookupAllHostAddr".
Check that it's not DNS issue and all public addresses for your node are resolved instantly nkw-mnomni-ignite-1-1-1.nkw-mnomni-ignite-1-1.680e5bbc-21b1-5d61-8dfa-6b27be10ede7.svc.cluster.local. I was asking about the provider, because in OpenShift there seems to be a hard limit on DNS resolution time.
Check GC and safepoints.
To hide the underlying issue you can play around by increasing Ignite configuration: network timeout, join timeout, reducing failure detection timeout. But I recommend finding the real root cause instead of treating the symptoms.

Cannot get openjpa tools to run from the command line

What I did:
download and extract the latest openjpa release (3.0.0)
download the mariadb jdbc driver jar and copy it to the same directory where openjpa-all-3.0.0.jar is located
inside the same directory, create a subdirectory META_INF and a file META-INF/persistence.xml with the following contents:
<?xml version="1.0"?>
<persistence version="1.0">
<persistence-unit name="openjpa">
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<properties>
<property name="openjpa.ConnectionURL" value="jdbc:mariadb://localhost:3306/databasename"/>
<property name="openjpa.ConnectionDriverName" value="org.mariadb.jdbc.Driver"/>
<property name="openjpa.ConnectionUserName" value="dbuser"/>
<property name="openjpa.ConnectionPassword" value="dbpassword"/>
<property name="openjpa.DynamicEnhancementAgent" value="false"/>
<property name="openjpa.RuntimeUnenhancedClasses" value="supported"/>
<property name="openjpa.Log" value="SQL=TRACE"/>
<property name="openjpa.ConnectionFactoryProperties" value="PrettyPrint=true, PrettyPrintLineLength=120, PrintParameters=true, MaxActive=10, MaxIdle=5, MinIdle=2, MaxWait=60000"/>
</properties>
</persistence-unit>
create an empty directory src as a sub-directory of where the openjpa and mariadb driver jars are
ran the following command:
java -cp ./:openjpa-all-3.0.0.jar:mariadb-java-client-2.4.0.jar:openjpa-all-3.0.0.jar org.apache.openjpa.jdbc.meta.ReverseMappingTool -pkg some.package -d ./src
Instead of getting any kind of output, or an error related to generation, I get:
8 INFO [main] openjpa.Tool - The reverse mapping tool will run on the database. The tool is gathering schema information; this process may take some time. Enable the org.apache.openjpa.jdbc.Schema logging category to see messages about schema data.
Exception in thread "main" <openjpa-3.0.0-r422266:1833209 fatal user error> org.apache.openjpa.util.UserException: The persistence provider is attempting to use properties in the persistence.xml file to resolve the data source. A Java Database Connectivity (JDBC) driver or data source class name must be specified in the openjpa.ConnectionDriverName or javax.persistence.jdbc.driver property. The following properties are available in the configuration: "org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl#f248234b".
at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:71)
at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.createConnectionFactory(JDBCConfigurationImpl.java:850)
at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getConnectionFactory(JDBCConfigurationImpl.java:733)
at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDataSource(JDBCConfigurationImpl.java:879)
at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDataSource2(JDBCConfigurationImpl.java:921)
at org.apache.openjpa.jdbc.schema.SchemaGenerator.<init>(SchemaGenerator.java:86)
at org.apache.openjpa.jdbc.meta.ReverseMappingTool.run(ReverseMappingTool.java:2027)
at org.apache.openjpa.jdbc.meta.ReverseMappingTool.run(ReverseMappingTool.java:2005)
at org.apache.openjpa.jdbc.meta.ReverseMappingTool.run(ReverseMappingTool.java:1882)
at org.apache.openjpa.jdbc.meta.ReverseMappingTool$1.run(ReverseMappingTool.java:1863)
at org.apache.openjpa.lib.conf.Configurations.launchRunnable(Configurations.java:762)
at org.apache.openjpa.lib.conf.Configurations.runAgainstAllAnchors(Configurations.java:747)
at org.apache.openjpa.jdbc.meta.ReverseMappingTool.main(ReverseMappingTool.java:1858)
What am I doing wrong?
I tried variations of this, by adding -p persistence.xml#openjpa, -p #openjpa and -connectionDriverName org.mariadb.jdbc.Driver to the command line, but it made no difference.

Can the camel mongo component connect to a password protected MongoDB instance?

My target mongodb database is password protected.
I am trying to connect to it via camel, using the camel mongodb component
Based on the code I see, I'm not sure camel can take authentication into account. Is this true?
Using Camel 2.11.0, tried both Mongo Java Driver 2.11.1 and 2.9.1.
My Relevant Code:
Route:
from( "direct:input" )
.to(mongodb:myDB?database=aDB&collection=aColl&operation=save&writeConcern=SAFE" ))
AppCtx:
<bean id="myDB" class="com.mongodb.Mongo">
<constructor-arg index="0">
<bean class="com.mongodb.MongoURI">
<constructor-arg index="0"
value="mongodb://$mongodb{user}:$mongodb{passwd}#$mongodb{host}:$mongodb{port}/$mongodb{db}">
</constructor-arg>
</bean>
</constructor-arg>
Error:
org.apache.camel.component.mongodb.CamelMongoDbException:
com.mongodb.CommandFailureException: {
"serverUsed" : "redacted" ,
"errmsg" : "need to login" ,
"ok" : 0.0}
I'd hate for this to be yet another case where I can't use the component because it just isn't quite there.

Order of execution of RequestHandlers configured in Apache CXF and JAX-RS

I am in process of implementing a REST API server using Apache CXF JAX-RS v(2.30). I am using spring as container. I am thinking of making use of org.apache.cxf.jaxrs.ext.RequestHandler to implement few features like license check, authentication, authorization (All of which has custom code). My idea is to segregate this code in individual implementation classes (implementing RequestHandler) and configure it for a base REST url something like /rest/*. Being new to Apache CXF and JAX-RS, I want to understand following things.
Is this approach the right way to implement the features I want to?
If yes, then is the order in which the RequestHandlers are declared is the order of their invocation?
For example if in my definition I declare:
<beans>
<jaxrs:server id="abcRestService" address="/rest">
<jaxrs:serviceBeans>
<bean class="com.abc.api.rest.service.FooService" />
</jaxrs:serviceBeans>
<jaxrs:providers>
<ref bean="licenseFilter" />
<ref bean="authorizationFilter" />
</jaxrs:providers>
</jaxrs:server>
<bean id="licenseFilter" class="com.abc.api.rest.providers.LicenseValidator">
<!-- License check bean properties -->
</bean>
<bean id="authorizationFilter" class="com.abc.api.rest.providers.AuthorizationFilter">
<!-- authorization bean properties -->
</bean>
</beans>
then will the licenseFilter always get invoked before authorizationFilter?
I did not find a mention of invocation ordering of RequestHandlers as well as ResponseHandlers.
Thanks in advance.
Figured this out.
It gets invoked in the order of declaration of beans in <jaxrs:providers>. Thus in case mentioned in question, licenseFilter will get invoked before authorizationFilter.

Spring: problem with setter Dependence Injection

I have the following situation:
I set the beans (in applicationContext.xml) as follows:
...
<bean id="bDaoImpl" class="BDaoImpl"></bean>
<bean id="injBInA" class="ADaoImpl">
<property name="b" ref="bDaoImpl"/>
</bean>
...
Why when I use "b" in the value of the Object class ADaoImpl is null?
I have the solution. Sorry. Basically when I load the bean from application context (ApplicationContext.getBean) does not load the bean with id = "injBInA" therefore right was never carried out the injection