[JBoss/Spring Integration] - Re: Using beans from other spring module
by jussi_po
Ok, that helped and I got bit ahead.
But now, when I use those classes in another spring module, the second spring module is bind to the first modules application context. Meaning that the classes from second module are actually inside first.
2 spring modules:
core.spring
second.spring
First module(core.spring) jboss-spring.xml:
<?xml version="1.0" encoding="UTF-8" ?>
| <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" "http://www.springframework.org/dtd/spring-beans-2.0.dtd">
| <beans>
|
| <bean name="MessageManager"
| class="com.core.MessageManagerImpl">
| <property name="hibernateTemplate">
| <ref bean="hibernateTemplate" />
| </property>
| </bean>
| </beans>
The jndi config file of this(I'm not sure that I'm doing this right):
<?xml version="1.0" encoding="UTF-8" ?>
| <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" "http://www.springframework.org/dtd/spring-beans-2.0.dtd">
| <beans>
|
| <description>ParentBeanFactory=(a_spring-core)</description>
| <bean id="MessageManager"
| class="org.springframework.jndi.JndiObjectFactoryBean">
| <property name="cache">
| <value>true</value>
| </property>
| <property name="proxyInterface">
| <value>com.core.MessageManager</value>
| </property>
| <property name="jndiName">
| <value>a_spring-core</value>
| </property>
| </bean>
|
| </beans>
And then In other spring module(second.spring), I try to use the beans from the first module:
<?xml version="1.0" encoding="UTF-8" ?>
| <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" "http://www.springframework.org/dtd/spring-beans-2.0.dtd">
| <beans>
|
| <import resource="jndi_core.xml" />
| <bean name="MbloxConverter"
| class="com.converter.MbloxConverterImpl">
| <property name="messageManager">
| <ref bean="MessageManager" />
| </property>
|
| </bean>
| </beans>
This second.spring module is actually bind to the JNDI as "core.spring", and I guess it is because of the import in config file.
And also I have other module(spring) which uses the beans from both of those modules, and it won't find the bean from second.spring module.
Or should I just make a one spring module?(I prefer to keep them separate)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999453#3999453
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999453
19 years, 3 months
[JBoss Seam] - Re: Seam 1.1.0 - Injecting EJB's - Not Working
by bsmithjj
Kukeltje - you must have ESP
anonymous wrote : 15.2. Annotations for bijection
|
| The next two annotations control bijection. These attributes occur on component instance variables or property accessor methods.
|
| @In
|
| @In
|
| Specifies that a component attribute is to be injected from a context variable at the beginning of each component invocation. If the context variable is null, an exception will be thrown.
|
| @In(required=false)
|
| Specifies that a component attribute is to be injected from a context variable at the beginning of each component invocation. The context variable may be null.
|
| @In(create=true)
|
| Specifies that a component attribute is to be injected from a context variable at the beginning of each component invocation. If the context variable is null, an instance of the component is instantiated by Seam.
|
| @In(value="contextVariableName")
|
| Specifies the name of the context variable explicitly, instead of using the annotated instance variable name.
|
| @In(value="#{customer.addresses['shipping']}")
|
| Specifies that a component attribute is to be injected by evaluating a JSF EL expression at the beginning of each component invocation.
|
| *
|
| value ? specifies the name of the context variable. Default to the name of the component attribute. Alternatively, specifies a JSF EL expression, surrounded by #{...}.
| *
|
| create ? specifies that Seam should instantiate the component with the same name as the context variable if the context variable is undefined (null) in all contexts. Default to false.
| *
|
| required ? specifies Seam should throw an exception if the context variable is undefined in all contexts.
Where in this documentation is it stated that @In(create=true) results in looking up a reference to an EJB from JNDI? Maybe when create=true, and no instance of the named component (EJB) is available is any scope, then Seam takes that as a cue to look up the component (EJB) from JNDI - that's fine with me, I think that behavior should be explicitly added to the documentation; and add an example of this. I looked carefully through the documentation before posting this question ... so how do your responses help with understanding my initial issue or answer the questions subsequently posed?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999443#3999443
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999443
19 years, 3 months
[Management, JMX/JBoss] - JMX Timer Performance & Strange Issues
by thehunt
Hi all,
I have a really complex issue regarding the JMX timer and i could use some help. Based on the architecture of the Simple Schedule Provider, I developed a version of a job scheduling system for academic purposes.
This system consists of:
- an mbean provider which listens to a session EJB for registering job schedules at runtime.
- a manager which contains the JMX Timer for triggering those schedules
- a listener class whose instances catch the triggering events.
- a JMS queue where we put the objects describing the logic of each schedule in order to execute it.
- an MDB whose instances consume the objects in the queue and execute their corresponding logic.
When the timer fires a schedule, the listener catches the event and places an object message into the queue. An MDB instance is then used by the container to consume the message by executing an interface predefined method on the enclosed object.
This system makes use of the JbossCache 1.4 (TreeCache) for persistence purposes because it is supposed to be much faster than a traditional JDBC storage engine. Every time a message object is placed in the queue, this information is stored in the cache. Its meaning is that a job's repetition is under execution.
Our scheduling system can also work in a clustered Jboss environment, where the Provider , Manager (including JMX Timer) and JMS Queue act as singletons working on a single node while several instantiated MDBs on every node of the cluster are ready to consume messages pulled from the JMS queue through the cluster-wide JNDI. The cache also works in synchronous replication mode. In this way we want to achieve a load balancing regarding the load that comes from the processing of the actual logic of the various scheduled jobs.
I wont refer to other issues as fail-over etc cause they are irrelevant with my current subject but whoever wants more info on this can mail me.
Anyway, this system works just fine under normal conditions (delays lower than 100ms). However, when we started stress testing it (more than 200 -300 job executions per second) we noticed several strange issues.
I will demonstrate them through an actual example. Our jobs where simple java classes inserting a row per each execution into an in-memory JDBC table (mysql). Each row consists of timestamps (System.getTimeInMillis()) pulled at certain points of the executing process, starting at the Timer trigger firing and ending at the time the actual job started running.
Well, having these data, we noticed that delays of several seconds (up to 1 minute) occurred solely because of the JMX Timer.
row example:
shouldFireAt: 100000ms
FiredAt: 120000ms;
CachedAt: 120010ms;
MDB consumed at : 120050ms;
Started executing : 120051ms;
As far as we know the java.util.Timer can support much more than 200-300 task executions per second, jmx timer doesnt? Do these JMX Timer delays make sense to you? Keep in mind that the cpu and memory usage never exceeded 70%.
And another even more strange issue is that when working in a cluster, the delays under the same stress tests, go 300% higher! And still the only reason is the JMX timer and not the cache synchronous replication, which is absolutely crazy. How can that be? The timer is used as singleton and he has no knowledge himself that he is working in a cluster. Shouldnt i notice exactly the same FiredAt - shouldFireAt delays as if I worked in a single node environment?
I am ready to use Jprofiler to find some answers, but i am pretty sure that its the JMX Timer's bad performance that degrades the whole system's performance.
I could use some advise here.
thx in advance.
TheHunt.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999437#3999437
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999437
19 years, 3 months