[Design of POJO Server] - Re: Scoping of war/jar file embedded in sar service archives
by scott.stark＠jboss.org
"adinn" wrote :
| I worked out by trial and error that removing the classpath entries in the war file manifest solves the class duplication problem. I assume this is because the war class loader grabs its own copy of classes in the the jars (recursively) mentioned in the classpath rather than delegating to the sar loader.
|
Yes, the default war model is to use any class in its classpath before delegating to the parent unless either the web deployer or a jboss-web.xml changes this.
"adinn" wrote :
| I did not actually need to remove the jar classpath entries to fix the problem and assume this would not be strictly necessary since the entries only reference jars contained within the same sar i.e. they do not intercede between the loader of the referencing class and some other loader. Is that a valid assumption or was I just lucky? I'll still remove the classpath entries anyway -- the app works fine without them.
|
Its doubtful the jar classpath entries have any affect as the referenced jars are already part of the deployment classpath. No reason to remove them.
"adinn" wrote :
| I don't know whether this needs to be documented as a bug, change of behaviour or just useful thing someone might want to know some day. Anyway, it probably ought to be noted somewhere where AS users or the support team can find it (well, it is noted here at least :-)
|
I just want to understand what the difference is. It sounds like the war manifest classpath behavior has changed, but if anything I would expect that in jbossas5 the war manifest was ignored while what you describe appears to be the opposite; that 4.X/5.0.BetaX were not using the war manifest classpath. I think we have gone around on whether the war manifest classpath should be picked up or not.
At this point I just want to reproduce the issue in a unit test. If I can't tweak my current example I'll need to get your deployment to see what exactly is happening.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163931#4163931
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163931
17 years, 9 months
[Design the new POJO MicroContainer] - New AOP deployers almost ready
by kabir.khan＠jboss.com
I have almost completed the new AOP deployers. The aim was to install the AOP artifacts via MC beans rather than directly into the aspect manager as was the case previously. Locally, with my changes here I am able to get the full AOP testsuite passing. I have yet to try out ejb3-interceptors-aop.xml, which I will look at on Monday.
Before I can upgrade AS trunk I need to do another AOP release, then we need a release of MC (aop-mc-int). Once upgraded in AS, and switched over to use the new deployers the following two things apply to all jboss-aop.xml files used in AS
1) The aop namespace must be defined, so the contents of the file must be as follows:
| <?xml version="1.0" encoding="UTF-8"?>
| <aop xmlns="urn:jboss:aop-beans:1.0">
| ...
| </aop>
|
2) interceptors can only be defined at the top level. We don't support:
| <?xml version="1.0" encoding="UTF-8"?>
| <aop xmlns="urn:jboss:aop-beans:1.0">
| <bind pointcut="all(@Test1)">
| <interceptor class="MyInterceptor"/>
| </bind>
| <bind pointcut="all(@Test2)">
| <interceptor class="MyInterceptor"/>
| </bind>
| </aop>
|
instead you must use the alternative syntax (which is similar to how aspects/advice-bindings work)
| <?xml version="1.0" encoding="UTF-8"?>
| <aop xmlns="urn:jboss:aop-beans:1.0">
| <interceptor class="MyInterceptor"/>
| <bind pointcut="all(@Test1)">
| <interceptor-ref name="MyInterceptor"/>
| </bind>
| <bind pointcut="all(@Test2)">
| <interceptor-ref name="MyInterceptor"/>
| </bind>
| </aop>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163921#4163921
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163921
17 years, 9 months
[Design of JBossCache] - Re: Custom data versions
by bstansberry＠jboss.com
(Apologies in advance; I'm relying on recollection a lot in this post as the JBC refactor has erased my old knowledge of how to quickly verify how things work. Going to take some time to rebuild.)
Let me modify your use case a bit to reflect what actually happens:
6. Server 2 uses putForExternalRead to put V1 in cache, which with invalidation causes no cluster-wide traffic
In this case, from a simplistic point of view one of two things will happen on Server 2 in step 6:
a) the PFER arrives first, adds a node, and then the invalidation message invalidates it. This is fine.
b) the invalidation message from Server 1 arrives first, so the PFER call sees an existing (tombstone) node and immediately returns. IIRC, the tombstone has a limited life so some later PFER can succeed; i.e. there is no need for the PFER to analyze the tombstone's data version to see if it's allowed to resurrect it. So this seems fine.
I'm saying simplistic here because I'm assuming all the locking impls enforce the PFER semantic of never overwriting an existing node.
If we convert your case to use replication instead of invalidation, all remains the same except step 5 is a replication message and
6. Server 2 uses putForExternalRead to put V1 in cache, which generates a cluster-wide PFER:
In this case:
a) on Server 2 the PFER arrives first, adds a node, and then the replicated update message overwrites it. This is fine. With respect to the replicated PFER message on other nodes, either:
i) the PFER arrives first, and then the replicated update overwrites it
ii) the replicated update arrives first and the replicated PFER sees the existing node and aborts.
b) on Server 2 the replicated update message arrives first so the PFER sees an existing node and aborts.
That all seems fine as well.
I think the "abort if node exists" design of PFER serves us well here. Probably we need to think more about conflicts between updates rather than between PFER. Although in that case I would expect one or the other tx to fail before the JBC synchronization's beforeCompletion call.
Bottom line, I'm slooooowly moving toward thinking this DataVersion stuff is not needed for the Hibernate case. And fully expect to be proven wrong. :-) If having DataVersion isn't seriously perturbing the code base, I recommend leaving it in with a JIRA to remove it before 3.0.0.CR1/late beta. That serves notice to the community that it might go while giving us time to think long and hard about it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163896#4163896
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163896
17 years, 9 months
[Design the new POJO MicroContainer] - Re: Bug in Microcontainer - Errors from DependencyInfo/Item
by alesj
I've added a test - BadDependencyInfoTestCase - that checks every method of DependencyInfo/Item, throwing an exception after a number of invocations.
There is a few issues I found in AbstractController.
1) trivial one - suppressed
Dependency info in install method
| DependencyInfo dependencies = context.getDependencyInfo();
| if (trace)
| {
| String dependsOn = "[]";
| if (dependencies != null)
| {
| try
| {
| Set<DependencyItem> set = dependencies.getIDependOn(null);
| if (set != null)
| dependsOn = set.toString();
| }
| catch (Throwable t)
| {
| log.warn("Exception getting dependencies: " + t);
| dependsOn = null;
| }
| }
| if (dependsOn != null)
| log.trace("Dependencies for " + name + ": " + dependsOn);
|
2) moving to error - no uninstall since we're in uninstall
| DependencyInfo dependencies = context.getDependencyInfo();
| if (dependencies != null)
| {
| try
| {
| Set<DependencyItem> dependsOnMe = dependencies.getDependsOnMe(null);
| if (dependsOnMe.isEmpty() == false)
| {
| for (DependencyItem item : dependsOnMe)
| {
| if (item.isResolved())
| {
| ControllerState dependentState = item.getDependentState();
| if (dependentState == null || dependentState.equals(fromState))
| {
| if (item.unresolved(this))
| {
| ControllerContext dependent = getContext(item.getName(), null);
| if (dependent != null)
| {
| ControllerState whenRequired = item.getWhenRequired();
| if (whenRequired == null)
| whenRequired = ControllerState.NOT_INSTALLED;
| if (isBeforeState(dependent.getState(), whenRequired) == false)
| uninstallContext(dependent, whenRequired, trace);
| }
| }
| }
| }
| }
| }
| }
| catch (Throwable error)
| {
| log.error("Error resolving dependencies for " + fromState.getStateString() + ": " + context.toShortString(), error);
| // Not much else we can do - no uninstall, since we are at uninstall ;-)
| errorContexts.put(context.getName(), context);
| context.setError(error);
| }
| }
|
3) Currently not testing this:
| for (Method method : methods)
| {
| // Should we suppress this?
| if ("getLifecycleCallbacks".equals(method.getName()))
| continue;
|
If handleInstallLifecycleCallbacks throws exception ((in initial incrementState)) on DependencyInfo::getLifecycleCallbacks(), it gets caught, but re-thrown:
| boolean ok = incrementState(context, trace);
| if (ok)
| {
| try
| {
| registerControllerContext(context);
| }
| catch (Throwable t)
| {
| // This is probably unreachable? But let's be paranoid
| ok = false;
| throw t;
| }
| }
| if (ok)
| {
| resolveContexts(trace);
| }
| else
| {
| errorContexts.remove(context);
| throw context.getError();
| }
|
Should we add context-2-error-handling code to this method?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163867#4163867
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163867
17 years, 9 months
[Design of JBoss ESB] - Re: Wise based soap client for esb
by maeste
"jeffdelong" wrote : Thanks, I will look for your updates in a couple weeks.
|
Hi Jeff,
finally I fond an hour to put my hand on my workspace code to add support fot custom JAXWS handlers.
I just committed changes and a new quickstart sample demonstrating ho to use it (webservice_consumer_wise4).
In a nutshell you can add your own JAXWS handler adding (more than one) this property to org.jboss.soa.esb.actions.soap.wise.SOAPClient action in jboss-esb.xml
| <property name="custom-handlers" value="cutomClass1;CusomClass2" />
|
|
At the moment custom handlers are supposed to have default constructor and WISE Action instantiate them using reflection. Other solutions cold be evaluated in future (like have an handler object somewhere in the message for example).
If you have chance, give it a run and let me know what do you think about.
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163863#4163863
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163863
17 years, 9 months