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

[Design of JBoss jBPM] - Re: Potential enhancement to jbpm

by kukeltje

We are locally looking into adding something like a release number. Two things: - 1.2.14 as an example is difficult, as a string to decide which is newer - the processdefinition in the DB already has a long as version, couldn't we use that and do someting like MaMiBu where Ma is two positions for the major release Mi is two positions for minor release, Bu is two positions for a 'build'. 10412 being 1.4.12 and 212301 21.23.01. This would be implementable now since it only needs a xsd change and some method changes, no db change btw, Tom, I hate annotations in an attribute-value pair kind of way.... yuck... just to be able to add custom attiributes? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146343#4146343 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146343

16 years, 6 months

1
0
0 / 0

[Design of Security on JBoss] - Re: The jacc is not running; it cannot be stopped.

by anil.saldhana＠jboss.com

That message is from the JBoss Test framework. Last night, I did repackage one of the archives such that a previously undeployable test would deploy in the jacc test configuration. That is the only change I made. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146295#4146295 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146295

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - JBMETA-6, JBMETA-25 resolved jndi name

by scott.stark＠jboss.org

I still cannot get a definitive view of the jndi name to use for the resolved jndi name output from the resolving deployers because the default jndi policy is not used in the metadata layer. I resolve an ejb link to the approriate JBossSessionBeanMetaData, but its determineJndiName() result does not match what the BaseSessionProxyFactory ends up using. Here the MappedReferenceMetaDataResolverDeployer sees the resolvedJndiName to be HelloWorldBean (defaulting to the ejb-name), while the BaseSessionProxyFactory uses the PackagingBasedJndiBindingPolicy default of ee5client-test/HelloWorldBean/remote: | 2008-04-23 11:07:17,658 DEBUG [org.jboss.deployment.MappedReferenceMetaDataResolverDeployer] (RMI TCP Connection(4)-127.0.0.1) Processing unit=ee5client-test.jar, structure: | ee5client-test.ear | | +ee5client-test-client.jar | ++@EJB(helloWorldService) -> mappedName=null| resolvedJndiName=HelloWorldBean | | +ee5client-test.jar | ++EjbEndpoint:ejbName=HelloWorldBean,ejbClass=org.jboss.test.ee5client.ejb.HelloWorldBean,BusinessRemotes: [org.jboss.test.ee5client.ejb.HelloWorldService] | ++EjbEndpoint:ejbName=MessageReplierBean,ejbClass=org.jboss.test.ee5client.ejb.MessageReplierBean | | ... | | 2008-04-23 11:07:18,672 DEBUG [org.jboss.ejb3.ProxyFactoryHelper] (RMI TCP Connection(4)-127.0.0.1) Obtaining JNDI name from policy org.jboss.ejb3.jndipolicy.impl.PackagingBasedJndiBindingPolicy | 2008-04-23 11:07:18,690 DEBUG [org.jboss.ejb3.session.BaseSessionProxyFactory] (RMI TCP Connection(4)-127.0.0.1) Binding proxy for HelloWorldBean in JNDI at ee5client-test/HelloWorldBean/remote | | The jndi names of an ejb need to be available to the resolving deployer so that the metadata can be used as the defining set of info for references and dependencies. The metadata needs to have the org.jboss.ejb3.jndipolicy.DefaultJndiBindingPolicy interface with ejb3 providing the implementations. The metadata needs to be able to load the implementation as part of its determineJndiName behavior. The RemoteBindingMetaData change Alexey made was for the legacy ejb2x detached invoker bindings. The equivalent in the ejb3 container is sitting off in some aop config that is not available via the JBossMetaData info. I'm not sure if one can specify alternate jndi bindings for the remoting layer there or not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146290#4146290 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146290

16 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Solution of JBREM-954 and ramifications into UnifiedInvo

by galder.zamarreno＠jboss.com

"ron.sigal(a)jboss.com" wrote : I'm going to regurgitate all of this just to verify that I understand the issues. | | 1. We don't want Remoting turning an InterruptedException into a CannotConnectException because that has a negative effect in a clustered context. | | 2. We don't want Remoting rethrowing an InterruptedException because that could result in the application code getting an UndeclaredThrowableException. | | So, we want to wrap the InterruptedException in something, other than a CannotConnectException, that will not result in an UndeclaredThrowableException . | Is that the kernel of the matter, so far? Yeah "ron.sigal(a)jboss.com" wrote : From the point of Remoting, I agree that the current situation is misleading, but I'm slightly uncomfortable adding a RuntimeException to the API. UnitedInvokerProxy and UnitedInvokerHAProxy are controlled by JBoss, so we can handle any API changes, but for standalone Remoting users, we would be springing on them a stealth change in the API. Client.invoke() is the interface Unified invokers and others deal with and this method throws Throwable so your users have to be prepared for anything anyway... In fact, the return value of Client.invoke() can even be an Exception... "ron.sigal(a)jboss.com" wrote : Here's an alternative proposal. Remoting could turn an InterruptedException into an InterruptedIOException, which is a subclass of IOException. | | 1. You could argue that it's still an API change, but MicroSocketClientInvoker.transport() already declares that it throws an IOException, so it's just adding an IOException with a different message. | | 2. Isn't it likely that application code, EJB or otherwise, already catches and copes with IOExceptions? | | Well, I guess you could argue that an IOException would be unexpected in the case of a local EJB. | | I'm torn. | | WDYT? In EJB2, methods in remote business/home interfaces had to declare java.rmi.RemoteException, which is a subclass java.io.IOException, so your trick would work fine there. In EJB3 this is not a requirement though. "The methods of the business interface may only throw the java.rmi.RemoteException if the interface extends java.rmi.Remote.". You can still have remote business interfaces ala EJB 2.x, but not a requirement. Just annotate your business method as @Remote and done. So, in the EJB3 world, there's a strong possibility of getting a UndeclaredThrowableException. Then again, in an EJB3 world, if you have a business interface which is gonna be Remote, I'm sure you'll declare that it can throw some kind of Exception, otherwise any IOExceptions would blow as UndeclaredThrowableException. By the way, how would you turn InterruptedException into an InterruptedIOException? You can't set a cause Throwable to InterruptedIOException, so you can't really wrap IE around a InterruptedIOException, View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146264#4146264 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146264

16 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM With Seam

by jue

Does anybody know when the jBPM console on Seam will be completed? Feel like trying to reinvent the wheels if they are already working on that part., unless the next-gen console is again designed for admin/demo only... Thanks, -Jue View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146236#4146236 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146236

16 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: Element order exception

by alex.loubyansky＠jboss.com

Thanks, that's what I wanted to clarify. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146209#4146209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146209

16 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: Element order exception

by alesj

Where else to put it? As I see it, it has the same value as other jee metadata tests. I want to move away from Hibernate passing me the metadata, e.g. I can use some other EntityManager impl. And then use the right deployers: simplifying parsing, component deployer (PersistenceMD --> PersistenceUnitMDs) and real (PUMD --> BeanMetaData). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146203#4146203 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146203

16 years, 6 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Security EJB2 and dependencies

by anil.saldhana＠jboss.com

"adrian(a)jboss.org" wrote : The idea that a javabean property editor does a jndi lookup seems like a stupid | idea to me anyway. ;-) Please dial the Complaints center located at Snoqualmie Pass near Seattle for feedback on all the complaints on this thread, Adrian. Regarding the pooling tests, I think I have the solution for it. I will be checking it some bug fixes from my end today. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146202#4146202 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146202

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Annotation scanning

by adrian＠jboss.org

I just did a ** COMPLETELY UNTESTED** commit that shows the basic outline of how I think it should work. See: svn diff -c 72623 Once this works, i.e. it is tested, you can write a generic annotation deployer that runs off the module. Something like: | public GenericAnnotationDeployer extends AbstractRealDeployer<Module> | { | public GenericAnnotationDeployer() | { | super(Module.class); | setStage(DeploymentStages.POST_CLASSLOADER); | } | | public void deploy(DeploymentUnit unit, Module module) | { | module.visit(new MyVisitor()); | } | | public class MyVisitor extends ClassVisitor | { | public void visit(ResourceContext context) | { | // Annotation processing here | } | } | } | This approach has a number of advantages: 1) This is a generic classloader resource visitor that understands the classloading rules. i.e. nested roots are not processed twice, the include/exclude filters are applied, etc. 2) Although the example above visits classes it is generic enough to work for resources (or anything else you want to filter). 3) The current visit is implemented for the VFSClassLoader. But it could be done for any classloader plugged in as a Module. 4) The VFS api is not exposed through this api so there can be no complaints from other projects about JBoss dependencies. The ResourceContext exposes things like the URL, name, classLoader, InputStream, bytes of the resource which can be easily used in other projects. 5) It doesn't require any classloading to do the visit. It only requires the classloader to exist. But this could be relaxed since we only require that to include it in the ResourceContext in case somebody wants to actually do classloading. 6) The deployer can get on with doing what it does best. Processing annotations rather than worrying about classloading rules or where classes are located, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146200#4146200 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146200

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Something rotten in ejb3 deployers?

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote : Its an issue of not cleaning up the mdb inflow threads. I'm working on the ee5appclient tests. | | | | I thought I'd fixed that last week? | http://jira.jboss.org/jira/browse/JBAS-5428 | | Are you saying not all the threads have ended or that EJB3 is not deactivating the inflow correctly? It looks to me as though the inflow is not being deactivated correctly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146197#4146197 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146197

16 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2008