[Design of the JBoss EJB Container] - Re: how to configure standardjbosscmp-jdbc.xml for multiple
by ybxiang.wolf
tyr below example :
a-ds.xml -->DB_A
b-ds.xml -->DB_B
then
<?xml version="1.0" encoding="UTF-8"?>
<persistence-unit name="erp_A">
<jta-data-source>java:/MSSQLDSA</jta-data-source>
</persistence-unit>
<persistence-unit name="erp_B">
<jta-data-source>java:/MSSQLDSB</jta-data-source>
</persistence-unit>
.................................................................
@Stateless
public class CommonDAO4A implements CommonDAO4AItfLocal, CommonDAO4AItfRemote {
//erp_A is a persistence unitName
@PersistenceContext(unitName = "erp_A")
private EntityManager manager;
private static transient Logger logger = Logger.getLogger(CommonDAO.class.getName());
java.io.Serializable
public Object createObj(Object obj) {
manager.persist(obj);
return obj;
}
....
}
.................................................................
@Stateless
public class CommonDAO4B implements CommonDAO4BItfLocal, CommonDAO4BItfRemote {
//erp_A is a persistence unitName
@PersistenceContext(unitName = "erp_B")
private EntityManager manager;
private static transient Logger logger = Logger.getLogger(CommonDAO.class.getName());
java.io.Serializable
public Object createObj(Object obj) {
manager.persist(obj);
return obj;
}
....
}
............................
............................
now, you can visit two DBs according user's role.
public static CommonDAO4AItfRemote getObjDAOItfRemote() {
try {
Context jndiContext = SessionBeanUtil.getInitialContext();
Object ref = jndiContext.lookup("CommonDAO4AItfRemote");
CommonDAO4AItfRemote dao = (CommonDAO4AItfRemote) PortableRemoteObject.narrow(ref, CommonDAO4AItfRemote.class);
return dao;
} catch (Exception e) {
System.out.println("Exception:" + e);
return null;
}
}
public static CommonDAO4BItfRemote getObjDAOItfRemote() {
try {
Context jndiContext = SessionBeanUtil.getInitialContext();
Object ref = jndiContext.lookup("CommonDAO4BItfRemote");
CommonDAO4BItfRemote dao = (CommonDAO4BItfRemote) PortableRemoteObject.narrow(ref, CommonDAO4BItfRemote.class);
return dao;
} catch (Exception e) {
System.out.println("Exception:" + e);
return null;
}
}
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051616#4051616
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051616
18 years, 10 months
[Design of JBoss jBPM] - Re: gpd deployer jar
by tom.baeyens＠jboss.com
no. that is not the way that it was intended. in the case you mention, you should work with subprojects (like in the jpdl project).
each project has the same base structure and should produce 1 product. (though this can not really be the case)
so if you want to move it to a separate source folder, you should create a separate project. not just another dir next to 'main'
also, i think the class *should* go into the main console sources. it's not a separate reusable component that is used in many other components. it is a class that is used in the console. the security issue needs to be handled differently. with configuration options, good defaults and easy ways of changing the configuration. not with cluttering the development source structure.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051603#4051603
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051603
18 years, 10 months
[Design of JBoss Remoting, Unified Invokers] - Re: XPost - Remoting from unsigned applet - ClassLoader secu
by ron.sigal＠jboss.com
Hi James,
The problem in the current state of Remoting is that org.jboss.remoting.AbstractInvoker, the grandparent of all invokers, client and server, starts by creating an org.jboss.remoting.loading.ClassByteClassLoader, which can load a class locally or, if it's not available locally, load it over the network. I'm thinking that the line
| this.classbyteloader = new ClassByteClassLoader(this.getClass().getClassLoader());
|
in AbstractInvoker could be replaced by
| this.classbyteloader = getClass().getClassLoader();
|
[In reality, of course, we would want the classloader to be configurable.]
I've run this by a resident classloader expert who thought it sounded plausible. Now, for me, the problem is that I don't see a big demand for something like this, so, if there are some hidden gotcha's, I probably wouldn't put much time into it. On the other hand, if you experiment with the issue and get it to work, we could look at making the necessary changes to Remoting. It would be easy to make the classloader a configurable parameter, for example.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051568#4051568
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051568
18 years, 10 months
[Design of JBoss jBPM] - strategic ramblings
by tom.baeyens＠jboss.com
there are a number of strategic efforts that i see in the project. i would like to share them in order of my perceived importance:
* pvm. the new implementation of the updated pvm. most important improvement is that we are now designing the API and packaging to develop new node types including runtime behaviour implementation, designer icon, designer form, designer xml generation, xml parsing to object model, hibernate mappings,... This is of course towards 4.0 and still a long time out (probably Q1 2008)
* embeddability. more and more i think we should invest in documenting integration with other technologies like spring (config and transactions), enterprise, drools, web services,... this can be done on jPDL 3.x releases.
* evangelize about the realistic vision we have on the collaboration between analyst and developer. also the process virtual machine and the fact that different environments and different functions justify multiple process languages.
* language updates. just show the vision by implementing all the languages. improve jpdl, make it more embeddable (see above) and build other languages like e.g. pageflow, threadflow, ruleflow,... by just providing the best implementation for all of these, we become the consolidating process platform anyway.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051556#4051556
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051556
18 years, 10 months
[Design of JBoss ESB] - Quickstarts
by Kevin.Conner＠jboss.com
I have committed the first phase of the reworked quickstarts, the changes involved are as follows.
Each quickstart now contains *both* jbm and jbmq definitions. The appropriate definition will be automatically included in the .esb archive or deployed separately (via deploy-jms-dests) if running standalone. They also contain an appropriate deployment.xml to correctly force the deployment/undeployment order. All quickstart JMS MBeans are now prefixed with jboss.esb.quickstart.destination.
It is no longer necessary to specify the lib directory, this is calculated automatically for jbossesb-server, build/jbossesb and source hierarchies.
Building/deploying a quickstart from within the jbossesb-server hierarchy will only target the jbossesb-server. There is no need to specify the server home nor the profile being used due to an outstanding configuration issue.
Building/deploying a quickstart from within the build/jbossesb or source hierarchy can target jboss-4.0.5, jboss-4.0.5-ejb3, jboss-4.2.0 and jboss-server.
It is no longer necessary to specify the lib directory when installing the ESB into an app server. This is automatically calculated for source and build/jbossesb hierarchies.
The following combinations were tested
- jbossesb-server deploying into jbosseb-server
- jbossesb-server running standalone against jbossesb-server
- jbossesb deploying into jbossesb-server
- jbossesb deploying into jboss-4.0.5 (or jboss-4.0.5-ejb3)
- jbossesb deploying into jboss-4.2.0
- jbossesb running standalone against jbossesb-server
- jbossesb running standalone against jboss-4.0.5
- jbossesb running standalone against jboss-4.2.0
- source deploying into jbossesb-server
- source deploying into jboss-4.0.5 (and jboss-4.0.5-ejb3)
- source deploying into jboss-4.2.0
- source running standalone against jbossesb-server
- source running standalone against jboss-4.0.5
- source running standalone against jboss-4.2.0
The following quickstarts were tested
- helloworld (all combinations)
- helloworld_action (all combinations)
- helloworld_file_action (all combinations)
- helloworld_db_registration (all combinations)
- helloworld_sql_action (all combinations)
- more_action (all combinations)
- transform_CSV2XML (all combinations)
- transform_EDI2XML_Groovy_XSLT (all combinations)
- transform_XML2POJO (all combinations)
- transform_XML2XML_date_manipulation (all combinations)
- transform_XML2XML_simple (all combinations)
- simple_cbr (all combinations)
- fun_cbr (all combinations)
- scripting_groovy (all combinations)
- bpm_orchestration1 (all deployable combinations)
- jbpm_simple1 (all deployable combinations)
- static_router (all combinations)
- helloworld_ftp_action (all combinations)
- aggregator (all standalone combinations)
- business_service (jbossesb and source deploying to 4.0.5-ejb3 and 4.2.0)
The CBR tests were executed using revision 12265 of services/jbrules. The current HEAD version had conflicts due to a *third* version of antlr being included
The use of scoped JBoss Messaging in an app server environment is not supported at this time.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051555#4051555
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051555
18 years, 10 months
[Design of JBossCache] - ClusteredCacheLoader should be configured as shared?
by bstansberry＠jboss.com
Should CCL be configured as shared? It doesn't do any writes anyway, and configuring it as shared may solve some issues. Think it needs to be shared to avoid the "Major" issue noted below:
ClusteredCacheLoader.remove(Fqn, Object) does a clustered get so it can returned the removed value. Jimmy Wilson and I found this leads to a couple odd problems:
Minor:
Object being removed is in memory. Call to Cache.remove(Fqn, Object) hits CacheStoreInterceptor, which calls to CCL, which makes a call around the cluster just so it can tell CSI what the return value is. Inefficient.
Major:
Above remove() call replicates. Now on the remote node, the remove is executed. Same thing happens, except now, the "ClusteredGet" call is made by the JGroups up_thread. Call back into cluster from up_thread == deadlock until the "clustered get" times out.
Jimmy's testing whether shared=true causes problems.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051549#4051549
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051549
18 years, 10 months