[Design of POJO Server] - Re: Russian dolls and implicit deployment ordering
by adrian＠jboss.org
"bill.burke(a)jboss.com" wrote :
| 3) Expand our JNDI implementation so that it could be hooked into the MC's controller. So, when things get bound into JNDI, the kernel is notified and could unblock a JNDI dependency. THis is just an idea.
|
You can do this now with a KernelRegistryPlugin
| <bean name="JNDIPlugin" class="org.jboss.naming.JNDIPlugin">
| <property name="environment"><!-- jndi config here --></property>
| </bean>
|
| public class JNDIPlugin implements KernelRegistryPlugin
| {
| private Properties environment;
|
| public void setEnvironment(Properties environment)
| {
| this.environment = environment;
| }
|
| public KernelRegistryEntry getEntry(Object name)
| {
| if (name instanceof String == false)
| return null;
|
| InitialContext context;
| if (environment != null)
| context = new InitialContext(environment);
| else
| context = new InitialContext();
|
| try
| {
| Object o = context.lookup(name);
| if (o == null)
| return null;
| else
| return new AbstractKernelRegistry(o);
| }
| finally
| {
| context.close();
| }
| }
| }
|
This has some advantages:
1) It works with any jndi implementation
2) It works with remote jndi implementation
3) It doesn't require any work from anybody else
It has lots of disadvantages:
1) Namespace conflicts, e.g. jndi name matches a bean name
2) It is going to be slow for remote jndi
3) There is nothing that initiates a recheck when jndi bindings appear or disappear
(although implementing jndi events api might facilitate this?)
4) You can only depend on the thing existing,
i.e. there are two states NOT_INSTALLED and INSTALLED
5) Probably some others? :-)
I much prefer the idea of using AOP (decorators) to handle jndi binding.
| @JNDIBinding(...)
| public class MyClass
|
| or
|
| <bean ...>
| <annotation>@JNDIBinding(name="whatever")</annotation>
| </bean>
|
Because:
1) You can change what the jndi binding action means in different environments,
e.g. JBoss or Tomcat, without changing the configuration
2) It enables all sorts of other useful features, like not even binding into
jndi at all (for client usage) until the barrier service says "open the gates"
we're ready to go.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037086#4037086
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037086
18 years, 11 months
[Design of POJO Server] - Russian dolls and implicit deployment ordering
by bill.burke＠jboss.com
I don't think creating a pluggable implicit deployment ordering policy is what we should be spending our time on. Russian dolls and other implicit deployent policies are just hiding some of the inherent problems that exist in our code. Specifically, that too many components are using JNDI to obtain references to external services. If we fixed this problem, I don't think we would need to write implicit ordering policies.
So how do we fix it?
1) We need a registration deployer as well a parsing and real deployer. Why? Take EJB. @EJB usually does not have any more information for its reference other than the interface type it wants to inject. This is why the EJB deployer is broken up into 2 separate deployers. The Registration Deployer extracts basic metadata like EJB name, exposed business interfaces and registers an unstarted EJB container with an EJB registry. This is needed so that other EJB containers that have an @EJB reference can locate the "real" EJB container bean they depend on and create a kernel dependency. @PersistenceUnit references have similar issues.
2) Stop using JNDI to inject components. Any component that uses a datasource is a culprit. MDB/JMS connector and their destination/connector dependencies are also a culprit. We tried to solve the datasource problem in the EJB container by trying to create a kernel/JMX ObjectName from the datasource JNDI name provided so that we could create a hard dependency. This becomes a problem when JCA gets refactored as we have to write adapters for each JCA implementation to generate these dependencies. So, what I'm saying is that I think the approach of guessing the kernel name based on the JNDI name is too fragile and JCA needs to provide an SPI to give us this capability.
3) Expand our JNDI implementation so that it could be hooked into the MC's controller. So, when things get bound into JNDI, the kernel is notified and could unblock a JNDI dependency. THis is just an idea.
4) Create a JNDI reference bean that polls JNDI for a specific entry, and when it is available triggers a state change in the MC Controller for beans depending on that entry.
I don't think solution #2 is going to solve every JNDI dependency problem. Sometimes, specifically in MDB land, we will be working with thirdparty components and not be able to create a hard kernel dependency because the thirdparty components. #3 is a good option, but may not solve corner cases where a component depends on an external JNDI implementation (i.e. LDAP). #4 maybe the best solution as it could probably even be backported to 4.x.
Thoughts?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037060#4037060
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037060
18 years, 11 months
[Design of JBoss jBPM] - Re: Commands: Maybe result should be part of the Command-Obj
by camunda
Hi Tom,
anonymous wrote :
| by keeping object, we still can use the suggested approach, but we don't force it on all the commands.
|
Thats right. But you also loose the typed interface (sorry, I like it very much if the compiler tells me errors, and not the ClassCastExceptions).
The problem with JavaDoc is, it is not garanteed to have correct informations there. You have no way to check that automatically. Because we are tied to Java 1.4, we can also not introduce some Annotation which specifies the return value, which is somehow also ok, I think.
anonymous wrote :
| with this you introduce the overhead of introducing a typed member for the result in *all* the commands, while the map containing multiple results was only needed for a few.
|
I think, this overhead is really small. Normally, I have only some longs or Strings in the Command as a parameter...
Maybe one other advantage could be, if you really have some asynchronous messaging architecture, where you just fire the command and get the result back later, there it woul dbe a real advantage to have all the parameters together with the result. But okay, in this scenario, you can build a easy workaround, I know....
But one argument at the moment is maybe, the Interface is already released with jbpm 3.2. Changing it now is maybe not the best idea.
I have the problem at the moment, how to return a ProcessInstance TOGETHER with all the logs, so I think, I will return the Command itself in the GetProcessInstanceCommand, ok? Or you prefer the Map?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037028#4037028
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037028
18 years, 11 months
[Design of JBossCache] - JDBC Cache Loader issues
by swami_venkat
Hi,
we are using JDBC Cache loader as a read only cache. We are pre-loading all the data at the server startup. But we observe that every time we make cache request for reading data in the cache, the configured jdbc cache loader performs a database query (Select sql statement). Initially we thought that it is trying to fetch data for the first time, however behaviour repeats for the subsequent requests.
Can you please explain why the jdbc cache loader behaves in this manner and how to avoid repeated reads to the database.
Further we are seeing a drastic drop in the number of requests that can be handled by the server(75%). Whereas the primary purpose of the cache is to increase the performance. Your help will be very timely.
The cache configuration used is as follows,
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== -->
<!-- -->
<!-- Sample TreeCache Service Configuration -->
<!-- -->
<!-- ===================================================================== -->
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration -->
<!-- ==================================================================== -->
jboss:service=Naming
jboss:service=TransactionManager
<!--
Configure the TransactionManager
-->
com.hp.tpf.cos.runtime.TPFCoSTxManagerLookup
<!--
Isolation level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
READ_COMMITTED
<!--
Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
-->
REPL_SYNC
<!--
Just used for async repl: use a replication queue
-->
false
<!--
Replication interval for replication queue (in ms)
-->
0
<!--
Max number of elements which trigger replication
-->
0
<!-- Name of cluster. Needs to be the same for all clusters, in order
to find each other
-->
My-Cluster
<!-- JGroups protocol stack properties. Can also be a URL,
e.g. file:/home/bela/default.xml
-->
<!-- UDP: if you have a multihomed machine,
set the bind_addr attribute to the appropriate NIC IP address, e.g bind_addr="192.168.0.2"
-->
<!-- UDP: On Windows machines, because of the media sense feature
being broken with multicast (even after disabling media sense)
set the loopback attribute to true -->
<UDP mcast_addr="224.1.2.3" mcast_port="45566"
ip_ttl="64" ip_mcast="true"
mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
loopback="false" bind_addr="15.76.223.149"/>
<PING timeout="2000" num_initial_members="3"
up_thread="false" down_thread="false"/>
<MERGE2 min_interval="10000" max_interval="20000"/>
<!-- <FD shun="true" up_thread="true" down_thread="true" />-->
<FD_SOCK/>
<VERIFY_SUSPECT timeout="1500"
up_thread="false" down_thread="false"/>
<pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
max_xmit_size="8192" up_thread="false" down_thread="false"/>
<UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"
down_thread="false"/>
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="false" down_thread="false"/>
<FRAG frag_size="8192"
down_thread="false" up_thread="false"/>
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
shun="true" print_local_addr="true"/>
<pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>
<!--
Whether or not to fetch state on joining a cluster
-->
true
<!--
The max amount of time (in milliseconds) we wait until the
initial state (ie. the contents of the cache) are retrieved from
existing members in a clustered environment
-->
5000
<!--
Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
10000
<!-- Max number of milliseconds to wait for a lock acquisition -->
15000
<!-- Name of the eviction policy class. Not supported now. -->
<!--
org.jboss.cache.loader.bdbje.BdbjeCacheLoader
c:\tmp\bdbje
true
/
-->
<!--
org.jboss.cache.loader.FileCacheLoader
/tmp
true
/
-->
<!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
false
<!-- comma delimited FQNs to preload -->
/
<!-- are the cache loaders shared in a cluster? -->
true
<!-- we can now have multiple cache loaders, which get chained -->
<!-- the 'cacheloader' element may be repeated -->
org.jboss.cache.loader.JDBCCacheLoader
<!-- same as the old CacheLoaderConfig attribute -->
cache.jdbc.table.name=TPFCoSProvCache
cache.jdbc.table.create=false
cache.jdbc.table.drop=false
cache.jdbc.fqn.column=fqn
cache.jdbc.fqn.type=varchar(255)
cache.jdbc.node.column=node
cache.jdbc.node.type=blob
cache.jdbc.parent.column=parent
cache.jdbc.driver=oracle.jdbc.OracleDriver
cache.jdbc.url=jdbc:oracle:thin:@msdp1.india.hp.com:1521:TPFDB
cache.jdbc.user=dharani
cache.jdbc.password=dharani
<!-- whether the cache loader writes are asynchronous -->
false
<!-- only one cache loader in the chain may set fetchPersistentState to true.
An exception is thrown if more than one cache loader sets this to true. -->
false
<!-- determines whether this cache loader ignores writes - defaults to false. -->
false
<!-- if set to true, purges the contents of this cache loader when the cache starts up.
Defaults to false. -->
false
<!-- Uncomment to get a graphical view of the TreeCache MBean above -->
<!-- -->
<!-- jboss.cache:service=TreeCache-->
<!-- jboss.cache:service=TreeCache-->
<!-- -->
Thanks & Regards,
Swami
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036736#4036736
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036736
18 years, 12 months
[Design of JBoss Eclipse IDE (dev)] - How to Lookup a session bean from a Javaclass/Servlet/jsp wi
by AnuSree
Hi,
I have written stateless session bean in EJB 3.0 Project(JBoss 4.0.5) using JBossIDE for Eclipse,Version: 2.0.0,Build id: 2.0.0.Beta2
And then packaged into calculator.jar
Then i have created a Application client and calculator.jar is added to it's library.
This is the code for SesionBean
package trail.bean;
|
| import javax.ejb.Remote;
| import javax.ejb.Stateless;
| import trail.bean.Calculator;
| import org.jboss.annotation.ejb.RemoteBinding;
|
| @Remote ({Calculator.class})
| @RemoteBinding (jndiBinding="EJB3Trail/Calculator")
| public @Stateless class CalculatorBean implements Calculator {
| public double calculate(int start, int end, double growthrate, double saving) {
| System.out.println("Inside calculate");
| double tmp = Math.pow(1. + growthrate / 12., 12. * (end - start) + 1);
| double val=saving * 12. * (tmp - 1) / growthrate;
| System.out.println("return Value:"+val);
| return saving * 12. * (tmp - 1) / growthrate;
| }
| }
This is the code for Main.Java in App Client
| import java.text.NumberFormat;
| import javax.naming.InitialContext;
| import trail.bean.*;
|
|
| public class Main {
| public static void main(String[] args) {
|
| Calculator cal = null;
|
| try {
| InitialContext ctx = new InitialContext();
| cal = (Calculator) ctx.lookup("EJB3Trail/Calculator");
| //cal=(Calculator)ctx.lookup(Calculator.class.getName());
|
| } catch (Exception e) {
| System.out.println("-----------------Exception inside Lookup:"+e);
| e.printStackTrace();
| }
| }
|
|
My problem is while running the Main.java it showing Error messge like this
Exception inside Lookup:javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:284)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at Main.main(Main.java:18)
Can anybody Help Me.How to Lookup a session bean from a Javaclass/Servlet/jsp with JBoss Server.I'm very new to JBoss and Eclipse
this code work well with SUN AppServer
Thanks for any help.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036683#4036683
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036683
18 years, 12 months