September 2008 - jboss-dev-forums

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Modularising the appserver bootstrap

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : | So are these JBoss specific or not? | They have dependencies on: jboss-cl jboss-deployers jboss-vfs So, I think the answer is "no" :-) AspectDeployer will be retired in AS when I switch to the MC based aop deployers (hopefully later this week). "adrian(a)jboss.org" wrote : | I think you already fixed some of this already with the latest changes to | remove the deployment api dependency from the class pool. Yes, second step is to get rid of the ServiceMBeanSupport dependency. I have that ready locally, but I need to do another aop release before I can add that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178315#4178315 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178315

17 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - EJBTHREE-1401 Create Tests for @Remote pass-by-value within

by jaikiran

Andrew, I have started working on a testcase for EJBTHREE-1401 (Create Tests for @Remote pass-by-value within local JVM). I have a failing (simple) test case: The bean: @Stateless | @Remote (SimpleSLSBRemote.class) | public class SimpleSLSBean implements SimpleSLSBRemote | { | | /** | * Change the <code>value</code> property of the <code>simplePojo</code> | * and return the changed pojo. | * | * @param simplePojo | * @return | */ | public SimplePojo changeAndReturn(SimplePojo simplePojo) | { | if (simplePojo == null) { | return null; | } | | // change the counter value in the pojo and return the pojo | simplePojo.setValue(simplePojo.getValue() + 1); | return simplePojo; | } | | } | The testcase: | public class IntraJvmRemoteInvocationPassByValueTestCase | { | | ..... | | @Test | public void testPassByValueForMethodParameters() throws Throwable | { | // create slsb | SessionContainer slsb = Utils.createSlsb(SimpleSLSBean.class); | | // bind to jndi | Ejb3RegistrarLocator.locateRegistrar().bind(slsb.getName(), slsb); | | // get metadata | JBossSessionBeanMetaData metadata = slsb.getMetaData(); | | // Lookup the remote bean | Context ctx = new InitialContext(); | SimpleSLSBRemote remote = (SimpleSLSBRemote) ctx.lookup(metadata.getJndiName()); | | | SimplePojo localSimplePojo = new SimplePojo(); | log.info("local is " + localSimplePojo); | // set some initial value | int value = 3; | localSimplePojo.setValue(value); | // call the method on the bean | SimplePojo returnedPojo = remote.changeAndReturn(localSimplePojo); | | //Check that the returned object and the passed object are not the same | assertFalse("The object passed to the method of the remote bean and the object returned from the bean are both the same",localSimplePojo == returnedPojo); | | // Check the value in the local object has not changed because of the change | // to the object passed as the bean param | assertEquals("The object passed to a method of remote bean was modified(passed by reference)",localSimplePojo.getValue(),value); | | } | | ... | } | Here's the failure: testPassByValueForMethodParameters(org.jboss.ejb3.test.proxy.spec_3_2_1.unit.IntraJvmRemoteInvocationPassByValueTestCase) Time elapsed: 56.875 sec <<< FAILURE! | java.lang.AssertionError: The object passed to the method of the remote bean and the object returned from the bean are both the same | I looked into the code to see why this was failing. Looks like the mock SessionContainer in the proxy module does not take care of marshalling/unmarshalling the parameters. The code in the actual *SessionContainer in the core module seems to be having this functionality. 1) Should we be fixing the mock SessionContainer in the proxy? OR 2) Since we are trying to test the core functionality, should we be having this testcase within the ejb3-core instead of the proxy module? This would ensure that we are testing the actual containers and not the mocked ones. OR 3) Is there some way to get hold of the real containers in the proxy module testcases? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178314#4178314 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178314

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Testing Bootstrap Dependencies

by adrian＠jboss.org

"istudens(a)redhat.com" wrote : | Ok, but if there will be none in the deploy dir, the ear will not be able to deploy successfully, because there will be no services such as jbossweb, transaction manager etc. as I mentioned earlier. Or will the AS wait for other deployments to finish the deployment of the ear? Even if that deployments will not be in the deploy dir in that time? | Yes, that's what you are testing. If the ear is deployed first, then the ejb service, tomcat, transaction manager, etc. are deployed after, the ear should still work once everything is deployed (i.e. regardless of the order of deployment) The idea of the test is spot where this is not the case so we can fix the dependency. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178313#4178313 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178313

17 years, 6 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Modularising the appserver bootstrap

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : I see your point. Let's see what Adrian says, since it was he who originally asked me to move classpool and deployers into the AS codebase. | | Reverting this would mean moving some classes back out of AS into AOP or duplicating them in AOP. Having a separate component effectively just means the same as that, with yet another dependency to manage. | | The classes in question are: | org.jboss.aop.asintegration.jboss5.AspectDeployer | org.jboss.aop.asintegration.jboss5.VFSClassLoaderDomainRegistry | org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain | org.jboss.aop.asintegration.jboss5.VFSClassLoaderScopingPolicy So are these JBoss specific or not? If this is appserver integration then it belongs in the appserver. If this is some other integration, e.g. deployers-aop then I wouldn't have a problem with them living at that level as a separate project. As long as you are not creating a circular dependency (either really or in the release process). That doesn't mean the appserver has to use those specifc classes. Ideally, these classes should be very thin anyway. i.e. the implementation is in the aop project using agnostic policy metadata, but the specific population of the policy choices is in the deployers. I think you already fixed some of this already with the latest changes to remove the deployment api dependency from the class pool. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178309#4178309 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178309

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Towards a canonical server

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | If the deployments and their order are also to be part of the profile definition, we would need to get the BootstrapMetaData from the Bootstraps, but those don't exist without loading the profile.xml. Its not a big deal for these to be manageable initially, but what is the long term plan? | The longer term plan should be to minimise the bootstrap to only what is required to get a functional profile service. But things have leaked into the bootstrap because of "bad" dependencies. The splitting up of the bootstrap files is the first step in indentifying/reducing these dependencies so they can become more normal parts of the profile. e.g. all the JMX stuff should be in deployers rather than the bootstrap, but then you have the problem that the @JMX advice definition is too late in the process to expose all beans. aop is in the bootstrap for the same reason. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178306#4178306 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178306

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Excessive logging in AS 4.2.3 and AS 5

by adrian＠jboss.org

Yes, there are many categories that are over verbose when it comes to logging. We log at DEBUG by default because it is just too painful to get users to turn it on. But then DEBUG should only be lifecycle calls (i.e. deployment time logging and low volume logging such as thread or database connection creation) not high volume runtime logging which should be TRACE Anyway, for production usage its not rocket science to change conf/jboss-log4j.xml | <root> | <priority value ="INFO" /> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178299#4178299 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178299

17 years, 6 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: Russian doll packaging in arbitrary directories - JBAS-5

by adrian＠jboss.org

Rather than the hacky hardwiring of META-INF/WEB-INF can't you just tell it not to recurse into paths that are defined as metadata locations in the parent structure? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178294#4178294 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178294

17 years, 6 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Datasources not parsing jboss.server.data.dir

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | The correct place to fix this is in AbstractBuilder | when it constructs the ServiceTextValueMetaData. | You could argue that the Service* objects should be doing this processing with additional boolean properties on each to specify whether replacement should occur. But currently, the replacement is only done in the ServiceMetaDataParser. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178292#4178292 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178292

17 years, 6 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Datasources not parsing jboss.server.data.dir

by adrian＠jboss.org

It should not be replacing properties during the parsing. The correct place to fix this is in AbstractBuilder when it constructs the ServiceTextValueMetaData. That way it works for both xml and programmatic deployment. e.g. profile service configurations won't be parsed instead the metadata is passed in as a preexisting attachment. NOTE: It also needs doing for other things not just plain text, e.g. | <depends>${some.property:defaultDependency}</depends> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178287#4178287 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178287

17 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: UsernameToken authentication and authorization for POJO

by anil.saldhana＠jboss.com

Security Domain is very critical. Apart from the jboss-web.xml of the generated web-app having the same SD as the ejb3, there is a possibility of the web app inheriting the ear level SD if they are packaged in an ear. But we cannot rely on EARs being the deployment for the ejb3 based web services. fyi. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178284#4178284 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178284

17 years, 6 months

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 September 2008