[JBoss Seam] - Support for remotely deployed EJBs
by wv-javacoder
We found that Seam currently has only weak support for remotely located EJBs. The only way to get to a remotely located EJB reference is to use a façade or a factory, which forces us to write unnecessary glue code. A typical use case would be a stateless SOA service, which is usually deployed remotely. This remote service might not even use Seam.
We would like to see Seam support component declarations for interfaces + jndi-name in components.xml (as opposed to class + jndi-name). This would allow Seam to find remote components, which could be referenced through the EL. Obviously no in-/outjection would work, which is usually not required for stateless remote services.
Any thoughts on that idea? Shall we open a feature request in JIRA?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041393#4041393
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041393
19 years, 1 month
[Persistence, JBoss/CMP, Hibernate, Database] - EntiyBean is reloaded during transaction with commit-option
by smeier
Hi all,
I recently changed the commit-option for my entiy-beans from A to D with a refresh-period of 10 seconds. Since then I sometimes experience unreproducable errors in data import service (which essentially reads in some files, performs some checks and then writes the data to persistent storage via EntityBeans). After some investigation I was able to create a test case which resembles the error I'm experiencing (at least I think so).
My test goes like this: in a stateless session bean (with @ejb.transaction type="Required")
- I load an entity bean (findByPrimaryKey)
- modify one of it's fields (set from "oldvalue" to "newvalue")
- print the value of the previously modified field (it says "newvalue")
- sleep 20 seconds
- print the value of the previously modified field (it now says "oldvalue")
- check the value in the database after the transaction completes (it says "newvalue")
So in the end the new value has successfully been written to the database but since the field in the entity bean has been reset, computations that are using the value of this field in the remainder of the transaction might yield to wrong results.
Now here's my question: Is this the expected behaviour? As you might guess I don't think it is. http://wiki.jboss.org/wiki/Wiki.jsp?page=CMPFlushAgeOutStoreNotFlushed says the following about cache invalidation:
anonymous wrote : if the instance is in use, it will be removed and passivated at the end of the transaction it is used in
|
Any help is greatly appreciated.
Best regards,
Stefan
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041391#4041391
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041391
19 years, 1 month
[JBossWS] - Re: Problem with Context for WSAddressing in Jaxrpc and Jaxw
by Pires da Silva
thanks for answer.
I noticed this morning you used up-to-date jars for running your samples , jars that you retrieved from web sites (force.thirdparty.get property in your build.xml), so concerning Jaxws version -with @resource WebServiceContext- I just copied the jars jaxb-api and jaxb-impl instead of the previous older jars of Jboss AS 4.2.0.CR2 and it is ok, injection of WebServiceContext is working.
I mentioned there are lots of jars retrieved that way. From now I don't know exactly how to constitute a clean environment for our deployment.
I think it is better to use last version Jboss-1.2.0.SP1 (or may be next Jboss-1.2.1.GA) than version Jboss-1.0.3 I was previously working with.
So I'm using Jboss 4.0.2.CR2 with Jboss-1.2.0.SP1.
I'm using WSAddressing for session management, if possible HTTPS and basic authentication (which is easy through context if I remember well), MTOM to get/post binary content. To avoid interoperability problems in the previous version we delivered, we specified our API only through the description of the SOAP messages exchanged; I don't know from the moment how to constitude a SOAP message with a binary part (i.e. to be sent through MTOM instead of SOAP with attachments).
Do you thing it is possible without risks to propose our API as a web service instead of specifying the soap messages?
I will write a source code then generate the wsdl so I ask you if the generated wsdl will be compatible with any clients based on any web services stack?
Our deployment must be done soon so I'm asking you the versions appropriate of JbossAS and JbossWS.
Thanks a lot
CPires
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041387#4041387
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041387
19 years, 1 month
[Management, JMX/JBoss] - Re: SNMP adapter issue
by Pop Octavian
Hi,
I want to set the community string for SNMP traps.
The commnuity value for the traps I receive, using KIWI, is "public", this is a default value as far as I know. I want to change the community string to another value changing the readCommunity or writeCommunity from jboss-service.xml.
The only attributes I found in jboss-sevice.xml related to community are readCommunity and writeCommunity.
Is this right, or these two attributes are refering to something else?
If I am wrong, can you give me a hint how can I set the community string for traps?
Below is the jboss-service.xml i am using.
Best regards.
| <service>
|
| <!-- A simple trap receiver that acts as an SNMP Manager -->
| <mbean code="org.jboss.jmx.adaptor.snmp.trapd.TrapdService"
| name="jboss.jmx:name=SnmpAgent,service=trapd,type=logger">
|
| <attribute name="Port">1162</attribute>
| <attribute name="WriteCommunity">ssss</attribute>
| <attribute name="ReadCommunity">aaaaa</attribute>
|
| </mbean>
|
| <!-- The SNMP adaptor MBean -->
| <mbean code="org.jboss.jmx.adaptor.snmp.agent.SnmpAgentService"
| name="jboss.jmx:name=SnmpAgent,service=snmp,type=adaptor">
|
| <attribute name="RequestHandlerClassName">org.jboss.jmx.adaptor.snmp.agent.RequestHandlerImpl</attribute>
| <attribute name="RequestHandlerResName">/attributes.xml</attribute>
| <attribute name="TrapFactoryClassName">org.jboss.jmx.adaptor.snmp.agent.TrapFactorySupport</attribute>
| <attribute name="NotificationMapResName">/notifications.xml</attribute>
| <attribute name="ManagersResName">/managers.xml</attribute>
| <attribute name="HeartBeatPeriod">10</attribute>
| <attribute name="Port">1162</attribute>
| <attribute name="DynamicSubscriptions">false</attribute>
| <attribute name="WriteCommunity">ssss</attribute>
| <attribute name="ReadCommunity">aaaaa</attribute>
|
| <attribute name="SubscriptionList">
| <subscription-list>
| <!-- Monitor events from SNMP adaptor itself -->
| <mbean name="jboss.jmx:name=SnmpAgent,service=snmp,type=adaptor">
| <notification type="jboss.snmp.agent.coldstart"/>
| </mbean>
| <!-- Monitor timer for heartbeat events -->
| <mbean name="jboss.jmx:name=SnmpAgent,service=timer,type=heartbeat">
| <notification type="jboss.snmp.agent.heartbeat"/>
| <attribute name="WriteCommunity">ssss</attribute>
| <attribute name="ReadCommunity">aaaaa</attribute>
| </mbean>
|
| <!-- Valid JMX ObjectName patterns may be used as well, for example
| <mbean name="*:service=invoker,*">
|
| will subscribe to all matching mbeans for all notification types
| notification types can be used for simple prefix matching, e.g.
| <notification type="JMX.mbean">
|
| matches both JMX.mbean.registered and JMX.mbean.unregistered -->
|
| </subscription-list>
| </attribute>
|
| <depends optional-attribute-name="TimerName">
| <mbean code="javax.management.timer.Timer"
| name="jboss.jmx:name=SnmpAgent,service=timer,type=heartbeat"/>
| </depends>
| </mbean>
|
| <!-- Defines the system information as specified in rfc-1213
| iso.org.dod.internet.mgmt.mib-2.system.* -->
| <mbean code="org.jboss.jmx.adaptor.snmp.system.MIB2SystemGroupService"
| name="jboss.jmx:name=SnmpAgent,service=MIB2SystemGroup">
|
| <attribute name="SysLocation">In The Matrix</attribute>
| <attribute name="SysDescr">Central Computer</attribute>
| <attribute name="SysContact">Agent Smith</attribute>
| <!-- attribute name="SysName"></attribute> set internally to serverConfig@hostAddress-->
| <depends optional-attribute-name="SnmpAgent">
| jboss.jmx:name=SnmpAgent,service=snmp,type=adaptor
| </depends>
| </mbean>
|
| <!-- Used for internal testing - ignore
| <mbean code="org.jboss.jmx.adaptor.snmp.test.NotificationProducerService"
| name="jboss.jmx:name=SnmpAgent,service=notification,type=producer"/>
| -->
| </service>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041384#4041384
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041384
19 years, 1 month