October 2008 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Default JNDI naming scheme in EJB3.0 and possible conflicts

by jaikiran

The current default jndi binding scheme http://www.jboss.org/community/docs/DOC-9569 doesn't take into account the module name of the EJB. For example, if i have an ear named MyApp.ear containing 2 jar files First.jar and Second.jar and both containing a bean implementation AppManagerBean: First.jar: | package org.myapp.first.impl; | | @Stateless | @Remote (org.myapp.first.AppManager.class) | public class AppManagerBean implements org.myapp.first.AppManager { | | public String getVersion() { | return "1.0"; | } | | | } | Second.jar package org.myapp.second.impl; | | | @Stateless | @Remote (org.myapp.second.AppManager.class) | public class AppManagerBean implements org.myapp.second.AppManager { | public String getVersion() { | return "2.0"; | } | | } | Then as per the default JNDI naming scheme both these beans will resolve to MyApp/AppManagerBean/remote. From what i see in the current version, only one bean (the first one) gets bound to the JNDI and the other bean does not get bound: +- MyApp (class: org.jnp.interfaces.NamingContext) | | +- AppManagerBean (class: org.jnp.interfaces.NamingContext) | | | +- remote (class: Proxy for: org.myapp.first.AppManager) | | | +- remote-org.myapp.first.AppManager (class: Proxy for: org.myapp.first.AppManager) | Shouldn't we be logging a WARN message in the logs letting the user know of this conflict? P.S: EJB3.1 spec seems to address this with the global jndi name scheme which results in a unique jndi name in these cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183029#4183029 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183029

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Addition of a

by alesj

"dimitris(a)jboss.org" wrote : you mean JBOSS_HOME/lib be the default? No, I think he means JBOSS_HOME/server/lib. See jboss system properties: - http://www.jboss.org/community/docs/DOC-10730 This makes sense, unless you have a config named 'lib'. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183021#4183021 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183021

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Addition of a

by dimitris＠jboss.org

Scott, you mean JBOSS_HOME/lib be the default? How are we going to distinguise the boot libs from the shared libs? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183017#4183017 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183017

16 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: meeting context

by alex.guizar＠jboss.com

Some topics I'd like to discuss: # Start process instances at predefined time (related to Quartz and BPMN) # Enterprise Application Integration * eMail: send and receive - e.g. task completion via email in red hat oracle apps * JMS: transfer data back and forth between process variables and message properties/body * ESB: jboss and other providers - position jBPM as the de facto "scripting" language for ESBs * Web services: borrow and improve concepts from BPEL * Databases: facilities for accessing external databases * Flat files: just mentioned for completeness # Pluggable transaction management * Internal * CMT * Seam/Spring # Rules * Rules in event actions: have rules evaluated as process events fire, or variables change * Rule-based decision node * Rule-based task assignment I already added these topics to the team meeting page. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182992#4182992 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182992

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Addition of a "standard" configuration

by scott.stark＠jboss.org

Creating a share lib with the common jboss libs seems like the best compromise relative to the full canonical server we want to do. I would have it be under server so as not to confuse server/shared as a configuration. We would need a new jboss.shared.lib.url system property defaulting to ${jboss.server.base.url}/lib View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182976#4182976 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182976

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by jbalunas＠redhat.com

one more thing that I found. This no only effects redeploying the same application, it effect deploying any other seam application. Without restarting I undeployed an application and deployed a different one with the same result. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182967#4182967 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182967

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Addition of a "standard" configuration

by dimitris＠jboss.org

We need to look into adding the configuration used for our tck testing into our distribution under a new "standard" config. The main problem is the increase in the distro by about 32mb, so one solution is to create a shared lib directory to store all the static libraries, e.g. a top level: shared/lib The various configs 'standard/all/defaul' could then point to that directory, rather than replicating the libs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182964#4182964 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182964

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by alesj

"Jay Balunas" wrote : | Here is the console logging related to this. You'll notice that the time goes from "08:56:37,914" to "09:06:05,790". This 10 minutes saw a large amount of disk usage and and memory consumption. I will also attach a subset of the server.log that corresponds to this time. | | | 08:56:37,314 INFO [EJBContainer] STOPPED EJB: com.jboss.dvd.seam.AuthenticatorAction ejbName: AuthenticatorAction | 08:56:37,381 INFO [SessionSpecContainer] Stopping jboss.j2ee:ear=jboss-seam-dvd.ear,jar=jboss-seam-dvd.jar,name=AcceptAction,service=EJB3 | 08:56:37,381 INFO [EJBContainer] STOPPED EJB: com.jboss.dvd.seam.AcceptAction ejbName: AcceptAction | 08:56:37,453 INFO [PersistenceUnitDeployment] Stopping persistence unit persistence.unit:unitName=jboss-seam-dvd.ear/jboss-seam-dvd.jar#dvdDatabase | 08:56:37,454 INFO [SessionFactoryImpl] closing | 08:56:37,454 INFO [SchemaExport] Running hbm2ddl schema export | 08:56:37,510 INFO [SchemaExport] exporting generated schema to database | 08:56:37,513 INFO [SchemaExport] schema export complete | 08:56:37,513 INFO [SessionFactoryObjectFactory] Unbinding factory from JNDI name: persistence.unit:unitName=jboss-seam-dvd.ear/jboss-seam-dvd.jar#dvdDatabase | 08:56:37,513 INFO [NamingHelper] JNDI InitialContext properties:{} | 08:56:37,513 INFO [SessionFactoryObjectFactory] Unbound factory from JNDI name: persistence.unit:unitName=jboss-seam-dvd.ear/jboss-seam-dvd.jar#dvdDatabase | 08:56:37,914 WARN [HackClassloaderMetaDataDeployer] FIXME Using loader repository config: seam.jboss.org:loader=seam-dvd for vfszip:/jboss/projects/seam/2.1.0.GA/jboss-5.0.0.CR2/server/default/deploy/jboss-seam-dvd.ear use classloading metadata not loader repository config | 09:06:05,790 WARN [EjbMetadataJndiPolicyDecoratorDeployer] Defaulting to DefaultJndiBindingPolicy of "org.jboss.metadata.ejb.jboss.jndipolicy.plugins.BasicJndiBindingPolicy" for Session Bean ShowOrdersAction | 09:06:05,790 WARN [EjbMetadataJndiPolicyDecoratorDeployer] Defaulting to DefaultJndiBindingPolicy of "org.jboss.metadata.ejb.jboss.jndipolicy.plugins.BasicJndiBindingPolicy" for Session Bean AuthenticatorAction | 09:06:05,790 WARN [EjbMetadataJndiPolicyDecoratorDeployer] Defaulting to DefaultJndiBindingPolicy of "org.jboss.metadata.ejb.jboss.jndipolicy.plugins.BasicJndiBindingPolicy" for Session Bean CheckoutAction | 09:06:05,790 WARN [EjbMetadataJndiPolicyDecoratorDeployer] Defaulting to DefaultJndiBindingPolicy of "org.jboss.metadata.ejb.jboss.jndipolicy.plugins.BasicJndiBindingPolicy" for Session Bean FullTextSearchAction | 09:06:05,791 WARN [EjbMetadataJndiPolicyDecoratorDeployer] Defaulting to DefaultJndiBindingPolicy of "org.jboss.metadata.ejb.jboss.jndipolicy.plugins.BasicJndiBindingPolicy" for Session Bean EditCustomerAction | 09:06:05,791 WARN [EjbMetadataJndiPolicyDecoratorDeployer] Defaulting to DefaultJndiBindingPolicy of "org.jboss.metadata.ejb.jboss.jndipolicy.plugins.BasicJndiBindingPolicy" for Session Bean ShoppingCartBean | 09:06:05,791 WARN [EjbMetadataJndiPolicyDecoratorDeployer] Defaulting to DefaultJndiBindingPolicy of "org.jboss.metadata.ejb.jboss.jndipolicy.plugins.BasicJndiBindingPolicy" for Session Bean AcceptAction | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182955#4182955 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182955

16 years, 2 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Mavenised build and Eclipse

by kabir.khan＠jboss.com

Well it's not really a big deal excluding those files. But do you know if it is possible to make the eclipse plugin to make Eclipse output the classes somewhere else than target/classes? It is a bit annoying having them there since every time I do a "mvn clean", a full rebuild is needed in eclipse. I tried $mvn eclipse:eclipse -DbuildOutputDirectory=eclipse-output but that did not seem to have any effect View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182954#4182954 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182954

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Runtime Metadata View

by scott.stark＠jboss.org

I have a todo to review the aop deployers to see how they can define a management view of the aspects in a deployment. We certainly need to be moving towards some annotation metadata. Both BeanMetaData and ServiceMetaData have this notion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182947#4182947 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182947

16 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2008