[Design of EJB 3.0] - Re: Move Interceptors and Tests back into AS5 Workspace
by ALRubinger
Thanks for moving this topic, Anil. Just don't continue to oblige me when I get cranky; you'll set a precedent. ;)
"anil.saldhana(a)jboss.com" wrote : a) the ejb3 interceptors need to be back in AS/trunk/ejb3 module.
I'll leave this one for the other guys.
"anil.saldhana(a)jboss.com" wrote : b) the ejb3 tests that require AS should ideally be in AS/trunk/testsuite or AS/trunk/ejb3
As it stands, we've got very little in the way of true Unit Tests. What we *do* have is a comprehensive series of integration tests written in JUnit, and at the moment, these are dependent upon AS for its execution environment.
So the direction in which I'd like to head is double-pronged:
1) Make a habit of extracting out business logic into easily-testable units, build up a Unit Test Suite.
For instance:
public performInvocation(){
|
| // Some code ...
|
| String someInvocationMetadata = Invocation.A_THREADLOCAL.get();
| // Do some stuff to "someInvocationMetadata"
|
| // Proceed ...
|
| }
The above isn't easily testable; it depends on doing some logic to a variable obtained from an invocation/environment context.
In contrast, if we start to extract this out into an injectable manner, we can test it:
public performInvocation(){
|
| // Some code ...
|
| String someInvocationMetadata = Invocation.A_THREADLOCAL.get();
| this.adjustInvocationMetadata(someInvocationMetadata);
|
| // Proceed ...
|
| }
|
| public adjustInvocationMetadata(String someInvocationMetadata){
|
| // Logic
|
| }
|
...and now we can mock up the invocation metadata in a Unit Test.
What this gets us in the end is a series of tests that will execute blazingly fast; we can easily push-button the Unit Tests in the IDE or from the CL and get back results without waiting for a full integration test run locally or in continuous integration.
2. Unbind Integration Tests from AS Where Possible
As we push forward with EJB3 Embedded, we'll be able to remove the dependency on AS for the majority of the integration tests, and leave only a few "AS-Specific Integration" Integration Tests.
So looking forward, it'd be great to do most of our functional- and specifications-related EJB3 Integration Tests in JUnit running EJB3 Embedded, with only a few tests for both EJB3 Standalone and EJB3 Deployers/AS to run through those areas. It's *here* that I think Anil's suggestion to put the tests within the EJB3 Module of AS is applicable, but only for the AS-specific ones.
Yet another reason to push through the Embedded Project; I'm really excited about that one and I think it's something the community will find beneficial - people love bootstrapping stuff into their Tomcat runtime.
In the meantime, a deprioritized project at which I've been chipping away is a Mavenized version of our TestSuite; at the moment we're still delegating this portion off to the legacy Ant scripts.
Would love to see more open discussion about the future of our testing practices here.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135297#4135297
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135297
18 years, 1 month
[Design of the JBoss EJB Container] - Re: Question about Remoting, Marshalling, and EJBs
by galder.zamarreno＠jboss.com
Re 1: I haven't seen any customer asking for this.
Re 2: why would InvocationMarshaller need to be used when sending back a response from the server to the client? transaction propagation is a one way system, from client to server whereas encryption works both ways. I don't think we should marshall unnecessary data.
Ron, if you do this, bear in mind the unified invoker unit tests I added based on mock remoting objects. They're standalone and fast to execute :). Let me know if you need a hand to fit in any tests you create for this within AS codebase.
In fact, one of the things I didn't get around to doing was creating remoting mock objects so that IM and IU were used. Marshalling happens too down the stack in remoting and cannot be mocked easily (i.e. mock objects to achieve this would be far too complicated), so ended up repeating the code from IM, IU in the tests. Please bear in mind this and let me know if you can think of a better way to set up Remoting mock objects for this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135257#4135257
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135257
18 years, 1 month
[Design the new POJO MicroContainer] - Re: JarEntry as VFS root does not return empty vfspath
by scott.stark＠jboss.org
"mstruk" wrote :
| So the idea of a fix is (correct me if I'm wrong):
|
| a) get rid of setPathName()
| b) pass JARVFSContextUnitTestCase . testPathIsEmptryForJarEntryAsRoot
| c) don't break any tests
|
|
| First question, since VFS is such a central component, and I don't want to commit something that will break things for others - is the 'don't break any tests' a reasonable enough criteria for code 'commitability' or should I also at least make sure jboss5 default config runs with the new jboss-vfs.jar, or is there something else I should check as well?
|
| "mstruk" wrote :
| | The second question, is there any VFS documentation? There's API class diagram on wiki, and there's some javadoc, but that's all I could find.
| |
| javadocs and tests are all that exists currently.
|
| "mstruk" wrote :
| | vfsPath for example, what is its contract? Based on test cases, the contract seems to be:
| |
| | "vfsPath is a full path name relative to context root path"
| |
| Correct.
|
| "mstruk" wrote :
| | JarEntry as VFS root fails to stick to this contract, and that is the essence of this bug.
| |
|
| We have a number of issues with relying on the jdk jar classes, the JarEntry naming, jar: urls not supporting nested jars, JarFile not being serializable, JarFile requiring a java.io.File are the issue off of the top of my head.
|
| Not using the JarEntry name, removing AbstractVirtualFileHandler.setFileName, and fixing the existing usage of setFileName may work, but I suspect we need to redo how we handle jars to not rely on JarFile.
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135181#4135181
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135181
18 years, 1 month
[Design the new POJO MicroContainer] - JarEntry as VFS root does not return empty vfspath
by mstruk
Hi,
I've been looking at http://jira.jboss.com/jira/browse/JBVFS-4?rc=1 to get it fixed and get acquainted with VFS in the process.
I figure the current quick fix is called a hack because transient field vfsPath in AbstractVirtualFileHandler.java set through setPathName() only keeps it's value until it's serialized/deserialized. setPathName() should not exist at all, and AbstractVirtualFileHandler should contain enough information to properly lazy-init vfsPath.
So the idea of a fix is (correct me if I'm wrong):
a) get rid of setPathName()
b) pass JARVFSContextUnitTestCase . testPathIsEmptryForJarEntryAsRoot
c) don't break any tests
First question, since VFS is such a central component, and I don't want to commit something that will break things for others - is the 'don't break any tests' a reasonable enough criteria for code 'commitability' or should I also at least make sure jboss5 default config runs with the new jboss-vfs.jar, or is there something else I should check as well?
The second question, is there any VFS documentation? There's API class diagram on wiki, and there's some javadoc, but that's all I could find.
vfsPath for example, what is its contract? Based on test cases, the contract seems to be:
"vfsPath is a full path name relative to context root path"
JarEntry as VFS root fails to stick to this contract, and that is the essence of this bug.
For example, if full path name is: /dir1/jar2.jar!/org/jboss/someclass
and context root path is /dir1/jar2.jar!/
then vfsPath is: org/jboss/someclass
And code for it is very simple:
fullPathName.substring(contextPath.length());
If naming scheme is consistently applied, then it's all very clean and simple.
AbstractVirtualFileHandler currently has access to context root (context.getRootURI()), parent path name (parent.getPathName()), and name.
>From this information intuitively (and that's how the code is currently written) you get pathName by putting together parent's pathName and 'name'. The problem is that contract for 'name' apparently is not consistent with the naming scheme.
In our case 'name' is not empty - it contains the name of the jar file.
Question: is this expected and proper behaviour - that 'name' is not consistent with the naming scheme - that in this case it is not empty, but contains the name of the jar file?
If this is proper behaviour, then maybe we need to provide extra information to AbstractVirtualFileHandler, because I don't know if we can properly generate pathName from existing information.
If it's not proper behaviour, then we simply fix 'name' (all the code that passes bad name to file handler constructor) to conform to the contract and pathName will automatically get fixed.
Feedback appreciated,
Cheers,
- marko
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135178#4135178
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135178
18 years, 1 month