October 2007 - jboss-dev-forums - Jboss List Archives

[Design of AOP on JBoss (Aspects/JBoss)] - ClassLoading Module usage

by kabir.khan＠jboss.com

As discussed in Neuchatel last week, I will make the first iteration of the scoped aop stuff work on the new classloaders, using the Module hack for now, and upgrade to use metadata later. But when I deploy a sar with the following jboss-service.xml | <?xml version="1.0" encoding="UTF-8"?> | <server> | <loader-repository> | aop.loading:loader=scope1 | </loader-repository> | <mbean code="org.jboss.test.aop.scoped.ScopedTester" name="jboss.aop:name=ScopedTester1"> | <attribute name="ExpectedInterceptorValue">11</attribute> | <attribute name="ExpectedAspectValue">21</attribute> | <attribute name="MetadataSuffix">1</attribute> | </mbean> | </server> | I don't seem to get any special information from the module? | private ClassLoader getScopedClassLoader(VFSDeploymentUnit unit) | { | ... | Module module = unit.getAttachment(Module.class); | ... | String domainName = module.getDomainName(); | ClassLoaderMetaData cmd = module.getMetadata(); | // boolean parentDelegation = cmd.isJ2seClassLoadingCompliance(); | | System.out.println("****** DomainName: " + domainName + " parentDomain: " + module.getParentDomain()); | } | just gives | [STDOUT] ****** DomainName: <DEFAULT> parentDomain: null | Should I be using something other than the Domain/parentDomain, or is this broken somehow in ASS trunk? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090369#4090369 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090369

16 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: Removing classloader issues for PojoCache

by jason.greene＠jboss.com

Ah, so I am not alone here :) Ok so, off the top of my head, I can see 3 possible core cache solutions to this problem. 1) Have an option that enables lazy wrapper style serialization (like you are suggesting) using the TCL. The reason this should be optional is that any wrapper serialization usage has greater cost than a region CL (double buffering + additional synchronization). 2) Add a serialization manager which allows app registered callbacks when deserializing/serializing an Object. This is essentially the reverse of a region CL. The callback would be passed various node information that could be used to locate the correct deployment CL. 3) Both 1 + 2. A registered serialization callback could decide to use a wrapper type, which would be deserialized and automatically unwrapped by the cache layer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090357#4090357 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090357

16 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-786

by bill.burke＠jboss.com

We did it to allow getting access to EJBObject metadata, handles, and for remove. Removing them does not break EJB 2.1. I guess we could/should remove this for EJBs that do not have an interface that extends EJBObject or EJBLocalObject View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090347#4090347 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090347

16 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-786

by wolfc

There are a couple of things tied together: - getInvokedBusinessInterface returns an interface based on method signature - multiple local business interfaces doesn't work properly - EJB 3 4.7.1: generated classes - EJBTHREE-786: remove method If we take 4.7.1 literaly then we must have a proxy class for each interface that the bean has. I don't know if TCK demands such a thing. But if we want to know for sure which interface was invoked we need to have different proxies and thus different bindings. This would also resolve EJBTHREE-786. Note that in a lot of code the distinction between a local business interface and a local 2.1 interface isn't properly made. The question is does it eliminate the possiblity for a combined binding (issue 540)? Probably not, but it would make things more complicated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090344#4090344 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090344

16 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: Removing classloader issues for PojoCache

by bstansberry＠jboss.com

You think like Scott Stark. See his comments in http://www.jboss.com/index.html?module=bb&op=viewtopic&t=95862 . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090331#4090331 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090331

16 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - How to add Library to jbpm_repository?

by camunda

Hi! For the Simulation-Engine I am currently working on (http://www.camunda.com/business_process_simulation/introduction.html ) I need the DesmoJ library (http://asi-www.informatik.uni-hamburg.de/themen/sim/forschung/Simulation/...). For the moment I added the absolute URL directly to the build.properties; | lib.desmoj.version=2.1.1 | lib.desmoj.name=desmoj.jar | lib.desmoj.dir=desmoj/${lib.desmoj.version}/lib | lib.desmoj.path=${lib.desmoj.dir}/${lib.desmoj.name} | lib.desmoj.local=${local.repository}/${lib.desmoj.path} | lib.desmoj.remote=http://asi-www.informatik.uni-hamburg.de/themen/sim/forschung/Simulation/Desmo-J/download/desmoj_2.1.1.jar | and copy it to the local repos in the build.xml: |  | <mkdir dir="${local.repository}/${lib.desmoj.dir}" /> | <get src="${lib.desmoj.remote}" dest="${lib.desmoj.local}" usetimestamp="true" ignoreerrors="true" /> | This works fine :-) But it should be available via the JBoss remote repository, right? How can I get the lib there? Or leave it like I did? I haven't committed it yet, I wanted to wait for some answer... Thanks Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090321#4090321 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090321

16 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: Removing classloader issues for PojoCache

by jason.greene＠jboss.com

Yes, that would work. Although I think this functionality belongs in JBoss Cache directly. There could be some kind of deserializeOnLoad option. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090309#4090309 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090309

16 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: Removing classloader issues for PojoCache

by bstansberry＠jboss.com

Can these be stored internally in a MarshalledValue variant (i.e. lazy-demarshalling by the interceptor on the field read)? Assume the MarshalledValue variant is efficient; i.e. doesn't create a byte[] version of the object until it itself is serialized; discards the byte[] as soon as get() is called. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090265#4090265 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090265

16 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-1154 - Introduce ability to mark nodes as reside

by manik.surtani＠jboss.com

Brian does have a point. Replication need not be dealt with until we have properly replicable metadata. And as for cache loading, well, if a node is resident it won't be evicted, right? So it won't suffer the problem of not having it's resident status being lost on cache loading/activation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090262#4090262 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090262

16 years, 7 months

1
0
0 / 0

[Design of Security on JBoss] - SSO / Identity Connector decoupling?

by g.tomassoni

Newby question. I'm interested in the concepts promoted by the JBOSSSSO project. However, it seems to me that you have to build your own Identity Connector inside the jbosssso.sar directory in order to allow your-preferred-flavour authentication. Is there any provision to de-couple the ssso modules from the idm ones? This way, any update to the jbosssso module would have no impact on the home-made idm code. I think it would be effective to have a jbosssso.sar supplying the core SSO functionality, then one can write, say, a my-own.mdc directory or archive, putting into there the mdc code needed to authenticate through the wanted method/protocol. Or, being a newby, I'm simply missing the point? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090257#4090257 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090257

16 years, 7 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 October 2007