Re: [jboss-dev-forums] [JBoss Messaging Development] - Problem integrating Weblogic 8.1 JMS with Jboss 5.1
by rajsoni
rajsoni [http://community.jboss.org/people/rajsoni] replied to the discussion
"Problem integrating Weblogic 8.1 JMS with Jboss 5.1"
To view the discussion, visit: http://community.jboss.org/message/535265#535265
--------------------------------------------------------------
sure..np....Here you go....:
jms-ds.xml:
<?xml version="1.0" encoding="UTF-8"?>
<connection-factories>
<!-- ==================================================================== -->
<!-- JMS Stuff -->
<!-- ==================================================================== -->
<!--
The JMS provider loader. Currently pointing to a non-clustered ConnectionFactory. Need to
be replaced with a clustered non-load-balanced ConnectionFactory when it becomes available.
See http://jira.jboss.org/jira/browse/JBMESSAGING-843 http://jira.jboss.org/jira/browse/JBMESSAGING-843.
-->
<mbean code="org.jboss.jms.jndi.JMSProviderLoader"
name="jboss.messaging:service=JMSProviderLoader,name=JMSProvider">
<attribute name="ProviderName">DefaultJMSProvider</attribute>
<attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
<!-- <attribute name="QueueFactoryRef">weblogicjms</attribute>
<attribute name="TopicFactoryRef">weblogicjms</attribute>-->
<attribute name="FactoryRef">XAConnectionFactory</attribute>
<attribute name="QueueFactoryRef">XAConnectionFactory</attribute>
<attribute name="TopicFactoryRef">XAConnectionFactory</attribute>
<attribute name="Properties">
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.provider.url=t3://linux-soni.dev.themunicenter.com:7001
java.naming.security.authentication=none
</attribute>
</mbean>
<no-tx-connection-factory>
<jndi-name>CFX/ExternalConnectionFactory</jndi-name>
<xa-transaction />
<track-connection-by-tx />
<rar-name>sun-jms-adapter.rar</rar-name>
<!-- <connection-definition>javax.jms.QueueConnectionFactory </connection-definition>
<config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Queue</config-property> -->
<connection-definition>javax.jms.TopicConnectionFactory </connection-definition>
<config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
<config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
<config-property name="Destination" type="java.lang.String">javax.jms.Destination</config-property>
<config-property name="ConnectionURL" type="java.lang.String"><![CDATA[t3://10.9.10.164:7001/?JMSJCA.WLFACTORY=TOPIC.MARKUPMARKET&prefix=jms/destinations;JMSJCA.NoXA=true]]></config-property>
<min-pool-size>1</min-pool-size>
<max-pool-size>200</max-pool-size>
<blocking-timeout-millis>30000</blocking-timeout-millis>
<idle-timeout-minutes>3</idle-timeout-minutes>
</no-tx-connection-factory>
</connection-factories
Change to queue or topic as per your need...above...:
Change in MDB : jboss.xml:
<?xml version="1.0"?>
<!DOCTYPE jboss PUBLIC
"-//JBoss//DTD JBOSS 5.0//EN"
" http://www.jboss.org/j2ee/dtd/jboss_5_0.dtd http://www.jboss.org/j2ee/dtd/jboss_5_0.dtd">
<jboss>
<enterprise-beans>
<message-driven>
<ejb-name>MktMessageProcessorMDB</ejb-name>
<destination-jndi-name>java:/CFX/ExternalConnectionFactory</destination-jndi-name>
<local-jndi-name>local/MktMessageProcessorMDB</local-jndi-name>
<resource-adapter-name>sun-jms-adapter.rar</resource-adapter-name>
<configuration-name>JMSJCA Message Driven Bean</configuration-name>
</message-driven>
<invoker-proxy-bindings>
<invoker-proxy-binding>
<name>jmsjca-message-driven-bean</name>
<invoker-mbean>default</invoker-mbean>
<proxy-factory>org.jboss.ejb.plugins.inflow.JBossMessageEndpointFactory</proxy-factory>
<proxy-factory-config>
<activation-config>
<activation-config-property>
<activation-config-property-name>providerAdapterJNDI</activation-config-property-name>
<activation-config-property-value>java:/DefaultJMSProvider</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>ConnectionURL</activation-config-property-name>
<activation-config-property-value>t3://linux-soni.dev.themunicenter.com:7001</activation-config-property-value>
</activation-config-property>
</activation-config>
<endpoint-interceptors>
<interceptor>org.jboss.proxy.ClientMethodInterceptor</interceptor>
<interceptor>org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor</interceptor>
<interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
</endpoint-interceptors>
</proxy-factory-config>
</invoker-proxy-binding>
</invoker-proxy-bindings>
<container-configurations>
<container-configuration>
<container-name>JMSJCA Message Driven Bean</container-name>
<call-logging>false</call-logging>
<invoker-proxy-binding-name>jmsjca-message-driven-bean</invoker-proxy-binding-name>
<container-interceptors>
<interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor>
<interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
<interceptor>org.jboss.ejb.plugins.RunAsSecurityInterceptor</interceptor>
<!-- CMT -->
<interceptor transaction="Container">org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
<interceptor transaction="Container">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
<interceptor transaction="Container" metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor>
<interceptor transaction="Container">org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor</interceptor>
<!-- BMT -->
<interceptor transaction="Bean">org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor</interceptor>
<interceptor transaction="Bean">org.jboss.ejb.plugins.MessageDrivenTxInterceptorBMT</interceptor>
<interceptor transaction="Bean">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
<interceptor transaction="Bean" metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor>
<interceptor>org.jboss.resource.connectionmanager.CachedConnectionInterceptor</interceptor>
</container-interceptors>
<instance-pool>org.jboss.ejb.plugins.MessageDrivenInstancePool</instance-pool>
<instance-cache></instance-cache>
<persistence-manager></persistence-manager>
<container-pool-conf>
<MaximumSize>100</MaximumSize>
</container-pool-conf>
</container-configuration>
</container-configurations>
</jboss>
ejb-jar.xml:
<?xml version="1.0"?>
<ejb-jar>
<enterprise-beans>
<message-driven>
<ejb-name>MktMessageProcessorMDB</ejb-name>
<ejb-class>com.muni.core.messaging.mktmessageprocessor.MktMessageProcessorBean</ejb-class>
<transaction-type>Bean</transaction-type>
<acknowledge-mode>auto-acknowledge</acknowledge-mode>
<activation-config>
<activation-config-property>
<activation-config-property-name>concurrencyMode</activation-config-property-name>
<activation-config-property-value>cc</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>endpointPoolMaxSize</activation-config-property-name>
<activation-config-property-value>10</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>destination</activation-config-property-name>
<activation-config-property-value>TOPIC.MARKUPMARKET</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Topic</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>contextName</activation-config-property-name>
<activation-config-property-value>XContextName</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
</enterprise-beans>
</ejb-jar>
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535265#535265]
Start a new discussion in JBoss Messaging Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 6 months
Re: [jboss-dev-forums] [Management Development] - domain.xml work
by Emanuel Muckenhuber
Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion
"domain.xml work"
To view the discussion, visit: http://community.jboss.org/message/535264#535264
--------------------------------------------------------------
I was not really talking about overrides itself. This should be rather a generic processing extracting domain metadata fragments on a ManagedComponent level, so that they can be used for further processing. I also thought that the deployment metadata would register the namespace for overrides. However i think we should also look at different use cases which don't need a physical deployment - therefore createNewDeployment() - this would still need the meta value transformations, however we don't need to scan existing attachments
Also (d) just adding configuration would be only useful for MC Beans - the reason why this could be interesting is that ProfileService does not know in which deployment a MC bean is located to override it - so we would need to go through all MC beans and check if this fragment applies there. In this case it might be more interesting to add a way to inject a configuration fragment into your MC bean itself.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535264#535264]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 6 months
Re: [jboss-dev-forums] [Management Development] - domain.xml work
by Scott Stark
Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] replied to the discussion
"domain.xml work"
To view the discussion, visit: http://community.jboss.org/message/535262#535262
--------------------------------------------------------------
Let's take a step back and review what we support today in 5.x. We have an api that exposes ManagedComponents for the deployment metadata that has been marked up as being part of the admin interface. This provides a facade on top of the implementation details of the deployers that transform the metadata into runtime components. There is an expectation that the ManagedComponent view is stable, but there is no enforcement of this.
We have embedded JON using this API along with its own notion of components to expose the admin-console view of the ManagedComponents. this imposes something of an enforcement of the ManagedComponent since if the console breaks, jiras get raised and the incompatible change needs to be resolved.
The domain.xml notion is essentially a unification of the embedded JON component descriptions into a single metadata view to allow for simple configuration of the server via scripting, etc. As such, a given domain.xml instance is just a series of ManagedComponent property updates. I view the domain.xml as just another "user" of the profile service ManagedComponent api.
The following set of steps would each produce new sets of ManagedComponent property changes:
1. An initial domain.xml transforms the state of ManagedComponent properties from the new build state into some initial distribution state. There is a V1 repository of ManagedComponent property overrides.
2. embedded JON/JON updates provide a further set of changes. Where these properties intersect the metadata values of the domain.xml, it would have to be updated if we are going to allow direct editing of a server domain.xml. There is a V2 repository of ManagedComponent property overrides.
3. A rest client manipulates the current server domain metadata to push further updates. There is a V3 repository of ManagedComponent property overrides.
There is only one authoritative store of ManagedComponent property edits that the profileservice implementation manages. Any physical domain.xml is a filtered view of this store.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535262#535262]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 6 months
Re: [jboss-dev-forums] [Management Development] - domain.xml work
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion
"domain.xml work"
To view the discussion, visit: http://community.jboss.org/message/535257#535257
--------------------------------------------------------------
> (d) and (e) would populate the unprocessed domain.xml fragements to a MetaDataRepository in a domain scope. This is needed since we have to distribute this to the whole domain - so we cannot do system property replacement there, as system properties in some cases could be just for a single instance/node e.g. ports-01.
> Additionally we also need to populate the MetaDataRepository with default values, those have to be kept separate until the point we actually do transformations/injections of the domain metadata itself. Basically to reduce the size of the domain.xml to configuration overrides - additionally we can compare and only store changed values back to the domain.xml
IMO something other than the MDR should be created/used to achieve this. The MDR's design is in many ways incompatible with what we actually want for a domain model. As an example, the notion of scoping is the exact opposite of how an administrator expects the domain.xml to work. An entry in the domain should *override* something expressed in a deployment, not the other way around.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535257#535257]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 6 months