[Design of EJB 3.0] - Re: @Service and @Consumer in metadata
by alex.loubyansky＠jboss.com
I've trying to follow this idea and this is what I think the big picture should look like:
1) the spec and jboss deployment descriptors are parsed and merged into the JBossMetaData
2) the spec and jboss annotations are parsed and also merged into the JBossMetaData (this I still think should be done in one go since the source is the same unlike XML and to avoid duplicate parsing of the spec annotations)
3) merge the two instances of JBossMetaData obtained on the previous steps with the DDs as the override.
I already wrote JBoss50Creator which parses EJB3 annotations and produces JBossMetaData (not committed at the moment)
I am currently missing the step 3). So I am going to add another merge method for JBossXXXMetaData classes that will merge JBoss metadata.
Any other suggestions/ideas?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152834#4152834
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152834
17 years, 10 months
[Design of EJB 3.0] - Validation of Complete EJB2.x Views: EJB3 or Metadata?
by ALRubinger
Which component should be responsible for validating an EJB2.x View as dictated by EJBTHREE-1075?
The rules:
1) If EJBHome/EJBLocalHome is defined, at least one EJBObject/EJBLocalObject is defined.
2) If one EJBObject/EJBLocalObject is defined, an EJBHome/EJBLocalHome is defined.
3) SLSB EJB2.x Home interface returns only valid remote interface (EJBObject) from "create" method
4) SLSB EJB2.x LocalHome interface returns only valid local interface (EJBLocalObject) from "create" method
5) SFSB EJB2.x Home interface returns only valid remote interfaces (EJBObject) from "create{METHOD}" methods
6) SFSB EJB2.x LocalHome interface returns only valid local interfaces (EJBLocalObject) from "create{METHOD}" methods
Currently this is done in EJB3 Core. Should either move to Proxy or be handled by jboss-metadata.
Leaning towards EJB3 Proxy to test these conditions as they are EJB3 Spec Rules, though since jboss-metadata is already doing some checks I wonder if they should be placed together.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152830#4152830
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152830
17 years, 10 months
[Design of JBoss Remoting, Unified Invokers] - JBoss/Java API
by bedehaan
I am getting the following error when while using Eclipse/JBoss. Can anyone help in pointing me to a solution? Help is greatly appreciated.
log4j:WARN The log4j system is not properly configured!
log4j:WARN All ERROR messages will be sent to the system console until proper configuration has been detected.
com.filenet.api.exception.EngineRuntimeException: API_UNEXPECTED_JNDI_ERROR: An unexpected error occured accessing JNDI.
at com.filenet.apiimpl.util.SessionLocator.locateEJBByPath(SessionLocator.java:789)
at com.filenet.apiimpl.util.SessionLocator.findEJBSessionByPath(SessionLocator.java:724)
at com.filenet.apiimpl.util.SessionLocator.createNewSession(SessionLocator.java:510)
at com.filenet.apiimpl.util.SessionLocator.getSession(SessionLocator.java:133)
at com.filenet.apiimpl.core.IndependentObjectImpl.getObject(IndependentObjectImpl.java:153)
at com.filenet.apiimpl.core.IndependentObjectImpl.refresh(IndependentObjectImpl.java:161)
at com.filenet.api.core.Factory$Domain.fetchInstance(Factory.java:2724)
at com.ibm.filenet.edu.CEConnectionEDU.getDomainEDU(CEConnectionEDU.java:29)
at com.ibm.filenet.edu.CEConnectionEDU.main(CEConnectionEDU.java:69)
Caused by: javax.naming.CommunicationException: Could not obtain connection to any of these urls: iiop://host:12345 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server iiop:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server iiop:1099 [Root exception is java.net.UnknownHostException: iiop: iiop]]]
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.filenet.apiimpl.util.SessionLocator.locateEJBByPath(SessionLocator.java:778)
... 8 more
Caused by: javax.naming.CommunicationException: Failed to connect to server iiop:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server iiop:1099 [Root exception is java.net.UnknownHostException: iiop: iiop]]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
... 12 more
Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server iiop:1099 [Root exception is java.net.UnknownHostException: iiop: iiop]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
... 13 more
Caused by: java.net.UnknownHostException: iiop: iiop
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getByName(Unknown Source)
at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:76)
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)
... 13 more
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152827#4152827
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152827
17 years, 10 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Some observations on pinging and ponging
by timfox
Some comments on the current state of pinging and ponging.
The was it was envisioned to work was as follows, I think this is how it was orginally done too:
1) The client pings the server with a Ping, - this is a blocking call, and the server responds with a Pong. The Pong contains a boolean flag.
If the flag is true it means the session is still alive on the server (all ok).
If the flag is false it means the session has already been cleared up on the server - this might happen due to an unresponsive client or glitch in the network. (You can get spurious false failure detection on either the client or server side e.g. if the network cable is temporarily unplugged then plugged in again)
In the false case, since the server session is already dead, the client session will get cleaned up and the client side exception listener will be called.
2) Also the server needs to independently ping the client - so this is the same as 1) but the other way round.
The server sends a ping to the client (blocking) and the client returns with a pong. Again, the pong contains a boolean flag. This time if true it means the client session is still alive, if false it means the client session has been cleaned up - this can happen if there is a temporary glitch in the network.
If false, the server will clean up (close) the server side session and remove it.
Doing it this way prevents issues such as the server thinking the client is dead when it isn't or vice versa. We had quite a few problems with JBR 2 which did pinging poorly and we don't want to make the same mistakes.
This is going to need some reworking.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152821#4152821
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152821
17 years, 10 months
[Design the new POJO MicroContainer] - Re: Annotations scanning part 2
by alesj
"alesj" wrote :
| I've added a deployer that knows how to scan newly added @Bean and @BeanFactory annotations - corresponding to MC beans and beanfactories.
|
I've added this code to be able to easily remove added bean components in BeanScanningDeployer:
| public void deploy(DeploymentUnit unit, AnnotationEnvironment env) throws DeploymentException
| {
| Map<String, DeploymentUnit> components = null;
| + Set<String> beanNames = null;
|
| Set<Class<?>> beans = env.classIsAnnotatedWith(Bean.class);
| if (beans != null && beans.isEmpty() == false)
| {
| components = new HashMap<String, DeploymentUnit>();
| + beanNames = new HashSet<String>();
| mapComponents(unit, components);
|
| for (Class<?> beanClass : beans)
| @@ -107,6 +109,7 @@
| .setAutowireCandidate(bean.autowireCandidate());
|
| KernelDeploymentDeployer.addBeanComponent(unit, builder.getBeanMetaData());
| + beanNames.add(name);
| }
| else
| {
| @@ -123,6 +126,7 @@
| {
| components = new HashMap<String, DeploymentUnit>();
| mapComponents(unit, components);
| + beanNames = new HashSet<String>();
| }
|
| for (Class<?> beanFactoryClass : beanFactories)
| @@ -157,7 +161,10 @@
|
| List<BeanMetaData> bfBeans = gbfmd.getBeans();
| for (BeanMetaData bfb : bfBeans)
| + {
| KernelDeploymentDeployer.addBeanComponent(unit, bfb);
| + beanNames.add(name);
| + }
| }
| else
| {
| @@ -165,10 +172,22 @@
| log.info("BeanMetaData with such name already exists: " + bmd + ", scanned: " + beanFactoryClass);
| }
| }
| +
| + if (beanNames != null && beanNames.isEmpty() == false)
| + unit.addAttachment(getClass() + ".Beans", beanNames);
| }
| }
|
| - // TODO - undeploy!!
| + public void undeploy(DeploymentUnit unit, AnnotationEnvironment deployment)
| + {
| + @SuppressWarnings("unchecked")
| + Set<String> beanNames = unit.getAttachment(getClass() + ".Beans", Set.class);
| + if (beanNames != null)
| + {
| + for(String name : beanNames)
| + unit.removeComponent(name);
| + }
| + }
|
Can we consider this legit? :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152817#4152817
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152817
17 years, 10 months