To set up for debug, you need to
1) set the jboss.aop.path system property to point to the jboss-aop.xml file
2) set -javaagent:%OUTPUT_LIB_FOLDER%\jboss-aop-jdk50.jar
While the requirement for 1) could be optimized out by the mechanism you describe, it means rewriting all the tests since things like field, constructor and array interception need weaving of the testcase class, which in turn depends on the aop.xml file being deployed before the testcase class is loaded.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997239#3997239
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997239
I have added the ability to have different advice chains when reading and writing arrays. The following snippet from the tests should explain it
| <arraybind type="READ_WRITE">
| <advice aspect="org.jboss.test.aop.array.AspectForPrecedence" name="advice"/>
| <interceptor-ref name="org.jboss.test.aop.array.TestArrayElementInterceptor"/>
| </arraybind>
| <arraybind type="READ_ONLY">
| <interceptor-ref name="org.jboss.test.aop.array.TestArrayElementReadInterceptor"/>
| </arraybind>
| <arraybind type="WRITE_ONLY">
| <interceptor-ref name="org.jboss.test.aop.array.TestArrayElementWriteInterceptor"/>
| </arraybind>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997221#3997221
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997221
We have fixed the FileDefinition class so that it does not throw an error when looking for a file that does not exist. This solved part of the stack trace problem when using the webapp with a processdefinition without a forms.xml file.
A related problem remains however. This is when the webapp is used with a processdefinition with tasks for which there is no assiciated taskform. In this case the webapp should not try to render an unexisting form to show the task information.
We will nevertheless proceed with the beta1 release.
Regards,
Koen
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997210#3997210
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997210
Please take a look at: http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/injection/
I'm rewriting the injection framework there.
Note that the JavaEE 5 client specifications already solve most of the problems you describe. With the new clients you can do: @EJB MySession session; to get a reference without JNDI calls. I don't know about the caching part. It's easier to have every injection do a JNDI call, then try to differentiate which calls won't create a new object and which calls do. The usual client application will most likely cache SLSB references anyway.
A public ServiceLocater might be nice to get references to EJB's based on interface.
With the last item you mean: having the client use services located on difference hosts? That would be cool. It's in violation with JavaEE 5 spec though so we need to clearly separate it from a regular JavaEE 5 client.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997203#3997203
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997203
I have also encountered the similar program and somewhere in the jboss code it checks whether its a single phase or two phase commit and if its two phase commit then it set some STATUS on prepare and commit.
I believe may be the reason for this is JBOSS is not able to handle the 2PC due to -
a) MySQL version of j-connector which do not support 2PC. Anything earlier than 5.0 would not be have 2PC commit capabilities.
I will be performing tests runs to cross check if this is the case. If anyone has any other view or explaination of this error, please let me know.
- Mahendra
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997188#3997188
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997188
I wouldn't suggest doing it this way....
What you should do is have your JACC deployer come after the EJB3 deployers and look for:
|
| public void deploy(DeploymentUnit unit) throws DeploymentException
| {
| Ejb3Deployment deployment = unit.getAttachment(Ejb3Deployment.class);
| if (deployment == null) return; // there is no EJB3 deployment in this file
|
Scanning is time consuming. We don't want 50 deployers doing scanning.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997140#3997140
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997140