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

[Design of EJB 3.0] - Re: Injection of Security Domain annotation into the contain

by scott.stark＠jboss.org

The JBossMetaData.securityDomain should be the authoritative source for this info. What is the plan on replacing the deprecated container.resolveAnnotation(SecurityDomain.class) with accessing the JBossMetaData.securityDomain value? We also need to map the @SecurityDomain annotation onto the metadata model. The jboss-metadata does not process the jboss-ejb3-ext-api annotations. Are we going to integrate the ejb3 annotation into its annotation processing? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135693#4135693 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135693

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Field injection

by kabir.khan＠jboss.com

| if (o instanceof org.jboss.aop.proxy.container.AspectManaged) | { | //It is a proxy | } | else if (this instanceof org.jboss.aop.Advised) | { | //It is woven | } | else | { | //Plain class | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135687#4135687 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135687

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: how crucial are exception handlers ?

by tom.baeyens＠jboss.com

"estaub" wrote : I meant that it should be easy for someone to understand where the transaction edges are, without digging into the implementation of each delegation class. So part of this is a designer UI issue, but the engine has to behave in a way that the designer UI can predict. Someone modifying the process shouldn't need to exhaustively study the behavior of every component already in the process in order to understand where it will rollback to if an error occurs. [On the other hand, it's very reasonable to expect someone adding a node to understand its transaction semantics.] | I don't see a good way on how transactions could be visualized in the graphical process designer. The default behaviour of jBPM is simple. As long as the process itself is executing, this is done synchrnously (in the same thread) and hence in the same transaction. This is good in case the processing inbetween the wait states is minimal. For most workflows that include human tasks and other wait states, it usually is a perfect default. For some kind of batch processes, people will probably want the opposite default. Namely that the transaction is committed after each activity and automatically the next activity should start in a new transaction. I'm thinking of supporting this in jPDL 4 by allowing the user to specify/overwrite the default async continuation behaviour on the process level. "estaub" wrote : is it valid to have an Activity that is not an ExternalActivity, yet waits for an external event? I hope not | You are correct. It is not. Wait states *have* to implement external activity. If an activity can ever get into a wait state, then an external activity has to be implemented. the naming comes from the fact that the driver for propagating the execution is external to the process during a wait state. Let me know if you think there is something left which is not rigorous. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135686#4135686 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135686

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Field injection

by alesj

"kabir.khan(a)jboss.com" wrote : | The proxy is a subclass of the class AND contains a reference to the wrapped object. | Calling a method on the proxy delegates to a method in the wrapped object. | Setting a field on the proxy does not get reflected in the wrapped object, and setting a field in the wrapped object does not get reflected in the proxy since the proxy and the wrapped object are different instances. We can detect if the target is plain pojo (probably trivial via some AOP specific interface check) or if it's aspectized but woven (this probably also already exists), else throwing an error saying user cannot do field injection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135680#4135680 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135680

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Silent failover on broken jar file

by alesj

"scott.stark(a)jboss.org" wrote : I don't know what file.isFile() api your talking about, VirtualFile or java.io.File. So looking for this statement in the vfs codebase, I find it in FileSystemContext.createVirtualFileHandler. and there it is java.io.File.isFile(). So for that usage, yes, we know whether its an unpacked jar or not. For that IOException, I don't know why we fall back to treating the corrupt jar as a non-structured file. | Yeah, sorry about that - not being precise enough. That's the code I'm talking about. ;-) Beats me too why we would do that. I did a simple fix, at least providing some more info in that debug msg. But I think we should just fail. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135679#4135679 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135679

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Silent failover on broken jar file

by scott.stark＠jboss.org

I don't know what file.isFile() api your talking about, VirtualFile or java.io.File. So looking for this statement in the vfs codebase, I find it in FileSystemContext.createVirtualFileHandler. and there it is java.io.File.isFile(). So for that usage, yes, we know whether its an unpacked jar or not. For that IOException, I don't know why we fall back to treating the corrupt jar as a non-structured file. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135665#4135665 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135665

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Field injection

by kabir.khan＠jboss.com

"alesj" wrote : | Or what's the difference between invoking method vs. field via reflection on the AOP proxy? The proxy is a subclass of the class AND contains a reference to the wrapped object. Calling a method on the proxy delegates to a method in the wrapped object. Setting a field on the proxy does not get reflected in the wrapped object, and setting a field in the wrapped object does not get reflected in the proxy since the proxy and the wrapped object are different instances. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135659#4135659 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135659

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Generalizing dependency injection

by scott.stark＠jboss.org

"wolfc" wrote : Business interfaces can be implemented by multiple beans, so there must be a clarifier in between. | + "ejb/" + vfsPath + local-interface name + "/" + ejbName should work. | | If we then get a non-deterministic injection we can throw an exception. | Why not reverse it a bit: | + "ejb/" + local-interface name + vfsPath + "/" + ejbName | then traversal is a bit easier in case multiple jars within one ear contain the same interface. Working through the resolution implementation more, we want a simple lookup to resolve a reference, so the ejbName of the providing cannot be part of at least one form of the key. That is an unknown element from the point of view of the referencer. We need multiple keys for each provider, some of which may be non-unique. | @EJB(beanInterface=X.class) | translates to a lookup of the provider "ejb/X". If we have multiple providers of the X interface, only the first to be processed would be the provider? If we want to fail an attempt at injection of a non-unique provider, we would have to track the duplicate providers to thrown an exception with the duplicates. | @EJB(beanInterface=X.class, name="XBean") | translates to a lookup of "ejb/X/XBean". The ejb-name is only unique within an ejb-jar, so here again we can have duplicates sources matching this key. | @EJB(beanInterface=X.class, name="XBean#some.jar") | translates to a lookup of "ejb/X/some.jar/XBean". This is the only guaranteed unique key within a deployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135656#4135656 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135656

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Silent failover on broken jar file

by alesj

"alesj" wrote : "scott.stark(a)jboss.org" wrote : Not being able to create a JarHandler can mean its an unpacked jar or a corrupt archive. How do you tell the difference? | | | I think we should be able to check for an unpacked jar pretty easily, right? | But we already do that: | if (file.isFile() && JarUtils.isArchive(file.getName())) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135647#4135647 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135647

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Silent failover on broken jar file

by scott.stark＠jboss.org

No, actually we can't. You would have to have the notion of a compressed directory to do this. This concept does not exist in the VFS api, so there is no distinction between a directory and an archive. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135645#4135645 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135645

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008