configuration of interceptors

[marc.fleury]

Hi, you are right. I am using "call(* packageName->*(..))".

The following is the code that is causing the exception. When I remove conn.close(), the exception is not thown.


MessageConnection conn = null;
String url = "sms://" + getAttribute() + ":134";

try {
conn = (MessageConnection) Connector.open(url);
TextMessage msg = (TextMessage) conn
.newMessage(MessageConnection.TEXT_MESSAGE);
msg.setPayloadText(text.toString());
conn.send(msg);

} catch (Exception e) {
//e.printStackTrace();
throw new IllegalStateException("Not allowed to send SMS");
} finally {
if (conn != null) {
try {
conn.close();
} catch (Exception e) {
if (com.xxx.xxxxxx.Debug.getDebugLevel() != com.xxx.xxxxxx.Debug.DBG_NONE)
e.printStackTrace();

}
}
}

Thanks.

[marc.fleury]

>
> I'm a little confused about one part of this...
>
> I thought the plan was to turn our current ejb interceptors
> into mbean interceptors and the Containers into fancy
> MBeanInvokers (If I remember correctly, anyway the top thing

well what we really need is JMX access to the configuration of the stack and the interceptors. That "Aspect" configuration of that stack is
something we want dynamically invocable -> JMX. The point I am now
seeing is while the EJB is an MBean, there are a lot of use cases where the JMX MBean is overkill. I was thinking that pojos would need to live in JMX. I don't think so anymore. What need to live in JMX is the configuration/factories etc not the actual linked chain. note that since we are thinking about MMB for the Pojo, these pojos would still be invocable through the bus, a pre-requisite for the microkernel.

> on the mbean interceptor stack). If this is correct, the
> ServerInterceptors would be behind the target MBean and not
> part of this new factory.
>
> This would look more like
> clientproxy -> client-interceptor-stack ->
> serverproxy -> targetMbean -> mbean-interceptor-stack

yes if we want the Pojos to be invocable through the JMX bus by default. Something we should look into in fact as that is the basis for the microkernel design.

The BIG advantage of putting the JMX stack in the middle is that we would be able to make the AOP framework "microkernel" ready, meaning that we can maintain the actual aspect implementation independently of the proxy client calling it. Really just like we do with EJBs.. this is a BIG plus.

> In any case, I think all the stack factories should be mbeans
> as Hiram mentions.

sure

marc f

[marc.fleury]

> > Its more like
> >
> > DynamicProxy -> interceptor stack -> Target MBean
> >
>
> That should be easy with the stuff I just commited.

This IS the stuff you just commited. There is no independent maintanance of the parts, which is what JMX would bring to the party if we made the targetMBean an MMBean

> > and be the bridge between Aspects and MBeans, but lets keep
> Aspects a
> > separate, lightweight framework.
>
> It's currently implemented like that.. seperate nice and
> light weight. The only dependency it currently has is on the
> org.jboss.proxy.compiler.* package. So we could take my
> stuff and the org.jboss.proxy.compiler.* stuff and make it
> and standalone module that can provide an interceptor stack
> to any POJO.

Let's kick a small Aspect/JBoss (Aspect on JBoss) project and see if it flies. I realize it is oriented to the user with multiple inheritance and we are figuring out the backend system part for microkernel behavior (if it bring anything).

> > - You could prepend or append an interceptor to an individual chain.
>
> So if you change a chain configuration when would it take
> effect on a proxy that was using the previous configuration??

well that is what we do with EJB and the detaching in JMX. For *detyped
interceptors* we can dynamically add them to the flow of calls without interuption of the client code whatsoever. This is powerful and with many application domains. Monitoring is one such example where we would add the interceptor for metrics dynamically turn it on and off to all calls coming in if we so wanted. This is powerful. Security is another one. This is done without disruption to the proxy.

For the case of *typed interceptors* and the multiple inheritance mumbo jumbo (sorry to make fun of it, I am not the one to say if people will use it or not, I think it is kind of cool but cute) then we cannot add these interceptors transparently as in the java language dynamic proxy there is no way to dynamically add an interface.

I believe that with JDK1.4 there are ways to dynamically replace the code for a reference and we would have VB.

marc f

[marc.fleury]

>
> Its more like
>
> DynamicProxy -> interceptor stack -> Target MBean
>
> There should be no concept of server or client.

That is the way it is in the codebase he commited. I do have a reservation about it. Essentially these proxies are non remote. While it may be ok in some cases I argue that the framework would be more powerful if we added the capacity to add client/server behavior to the component.

I am not fanatic as to how to do it, for example instead of configuring at creation time we could delay the insertion of an invoker to the time it actually travel (i.e. work in the externalizeObject and add the InvokerInterceptor there. I would argue that it is however a configuration issue as you need to specify the stack of client side ones. Most of the cases would be inVM I agree. This is a reason for having the straight invocation with no remote invoker or configuration by default.

> We have totaly freedom as far as MBean XML config files go, right?
>
> Here was my idea for an Aspect framework. I drew up the API
> while in Germany. The features were:
>
> - Interceptors could be services/singletons OR instantiated per chain.

ok

> - You could prepend or append an interceptor to the chain
> globally at runtime

yes very important. I think that this dynamicity is important.

> - You could prepend or append an interceptor to an individual chain.
> - DynamicProxies would have a generic Aspect interface

In the framework commited there is this notion that we ask the "aspect" for its interface and we give it to the Dynamic Proxy. What this achieve for "typed interceptors" is in fact multiple inheritance of **implementation**. Wow when you think about it, we are rebuilding the multiple inheritance model with Dynamic proxies instead of the single inheritance. For those that prefer to use typed interfaces this is great. Multiple inheritance of implementation is one of the aspects of aspect programming, the other (more real?) is the transparent adding of behavior to *existing* interfaces by "detyped interceptors" that just
expose the invoke.

So be precise on what the DP should have as an interface that can communicate with the "aspect". I would argue for a "HttpSession" like API to set variable in the invocation.

Just so that we are clear on definitions, it seems to be that in your mind
1 aspect = sum of N interceptors

> interface AspectManager
> {
> void createChain(String name);
> void registerInterceptorSingleton(String name, Interceptor
> interceptor);

ok

> // These methods globally modify the chain of any Aspect in
> system with the given name
> void prependAspect(String chainname, String
> interceptorName, Class clazz, Element metadata);
> void appendAspect(String chainname, String interceptorName,
> Class clazz, Element metadata);
> void prependAspect(String chainname, String singletonName);
> void appendAspect(String chainname, String singletonName);
>
> void removeAspect(String chainname, String interceptorName);
>
>
> /**
> * Given any old object, make it Aspect Oriented.
> * metadata could hold InvocationContext-like information
> */
> Aspect metamorphisis(String chainName, Class[] interfaces,
> Element metadata, Object targetObject);

I think we need to clearly expose the modifications. Adding interfaces to a running proxy is no good, so we can't really add typed aspects (stand alone invocation paths) but we can modify detyped aspects as chain modification in that case I believe the API is good.

> /**
> * No target object, useful for remote invocations.
> * metadata could hold InvocationContext-like information
> like MBean name to invoke on
> * and stuff like that.
> */
> Aspect createAspect(String chainName, Class[] interfaces,
> Element metadata); }

Yep

> /**
> * Every DynamicProxy would implement this interface
> */
> interface Aspect
> {
> String getAspectName();
>
> /**
> * Allows you to detach this particular aspect
> */
> void setAspectName(String newName);
>
> Object[] getInterceptors();
> Interceptor findInterceptor(String name);
>
> Object getTargetObject();
>
> }
>
>
> So, XML would look something like this. An AspectChain MBean
> would create chains within the AspectManager. Add a new
> keyword to XML <aspect-chain>. This would give the deployer a
> reference to the name of the interceptor chain to use. The
> Deployer would create a Proxy via the AspectManager with this
> chain name and register this Proxy with the MBeanServer.

ok

> name="MyMBean">
> <!-- add new keyword -->
> <aspect-chain>jboss.AspectChains:name=SomeOldChain</aspect-chain>
>
>
> name="jboss.AspectChains:name=ClientProxyChain>
>
> <aspect-chain>
> name="Transaction"
> type="instance"
> class="org.jboss.proxy.TransactionInterceptor"
> />
> <!--
> name="JRMPInvokerProxy"
> type="singleton"
> />
> </aspect-chain>
>
>

configure default for the singleton behavior, by default I would use the instance one.

I would also add you generic configuration information for the interceptors. IN the body of the interceptor chain.

marc f

[marc.fleury]

> > Its more like
> >
> > DynamicProxy -> interceptor stack -> Target MBean
> >
>
> That should be easy with the stuff I just commited.

This IS the stuff you just commited. There is no independent maintanance of the parts, which is what JMX would bring to the party if we made the targetMBean an MMBean

> > and be the bridge between Aspects and MBeans, but lets keep
> Aspects a
> > separate, lightweight framework.
>
> It's currently implemented like that.. seperate nice and
> light weight. The only dependency it currently has is on the
> org.jboss.proxy.compiler.* package. So we could take my
> stuff and the org.jboss.proxy.compiler.* stuff and make it
> and standalone module that can provide an interceptor stack
> to any POJO.

Let's kick a small Aspect/JBoss (Aspect on JBoss) project and see if it flies. I realize it is oriented to the user with multiple inheritance and we are figuring out the backend system part for microkernel behavior (if it bring anything).

> > - You could prepend or append an interceptor to an individual chain.
>
> So if you change a chain configuration when would it take
> effect on a proxy that was using the previous configuration??

well that is what we do with EJB and the detaching in JMX. For *detyped
interceptors* we can dynamically add them to the flow of calls without interuption of the client code whatsoever. This is powerful and with many application domains. Monitoring is one such example where we would add the interceptor for metrics dynamically turn it on and off to all calls coming in if we so wanted. This is powerful. Security is another one. This is done without disruption to the proxy.

For the case of *typed interceptors* and the multiple inheritance mumbo jumbo (sorry to make fun of it, I am not the one to say if people will use it or not, I think it is kind of cool but cute) then we cannot add these interceptors transparently as in the java language dynamic proxy there is no way to dynamically add an interface.

I believe that with JDK1.4 there are ways to dynamically replace the code for a reference and we would have VB.

marc f

[marc.fleury]

> Its more like
>
> DynamicProxy -> interceptor stack -> Target MBean
>

That should be easy with the stuff I just commited.

> There should be no concept of server or client.
>
> I also believe the interceptor chain, Aspect Oriented framework should
> be a generic framework and should work with any type of Object. It
> should be core to JMX. Sure, the MBeanDeployer could look at some XML
> and be the bridge between Aspects and MBeans, but lets keep Aspects a
> separate, lightweight framework.

It's currently implemented like that.. seperate nice and light weight. The only dependency it currently has is on the org.jboss.proxy.compiler.* package. So we could take my stuff and the org.jboss.proxy.compiler.* stuff and make it and standalone module that can provide an interceptor stack to any POJO.

+ this should run on 1.2 JVM since the Proxy classes are BECL generated.

>
> We have totaly freedom as far as MBean XML config files go, right?
>
> Here was my idea for an Aspect framework. I drew up the API while in
> Germany. The features were:
>
> - Interceptors could be services/singletons OR instantiated per chain.

My current implementation forces them to be singletons. But I don't think this should be a major issue.

> - You could prepend or append an interceptor to the chain globally at
> runtime
> - You could prepend or append an interceptor to an individual chain.

So if you change a chain configuration when would it take effect on a proxy that was using the previous configuration??

> - DynamicProxies would have a generic Aspect interface

I like the Aspect interface Idea.

>
>
>
> interface AspectManager
> {
> void createChain(String name);
> void registerInterceptorSingleton(String name, Interceptor
> interceptor);
>
> // These methods globally modify the chain of any Aspect in system
> with the given name
> void prependAspect(String chainname, String interceptorName, Class
> clazz, Element metadata);
> void appendAspect(String chainname, String interceptorName, Class clazz,
> Element metadata);
>
> void prependAspect(String chainname, String singletonName);
> void appendAspect(String chainname, String singletonName);
>
> void removeAspect(String chainname, String interceptorName);
>
>
> /**
> * Given any old object, make it Aspect Oriented.
> * metadata could hold InvocationContext-like information
> */
> Aspect metamorphisis(String chainName, Class[] interfaces, Element
> metadata, Object targetObject);
>
> /**
> * No target object, useful for remote invocations.
> * metadata could hold InvocationContext-like information like
> MBean name to invoke on
> * and stuff like that.
> */
> Aspect createAspect(String chainName, Class[] interfaces, Element
> metadata);
> }
>
> /**
> * Every DynamicProxy would implement this interface
> */
> interface Aspect
> {
> String getAspectName();
>
> /**
> * Allows you to detach this particular aspect
> */
> void setAspectName(String newName);
>
> Object[] getInterceptors();
> Interceptor findInterceptor(String name);
>
> Object getTargetObject();
>
> }
>
>
> So, XML would look something like this. An AspectChain MBean would
> create chains within the AspectManager. Add a new keyword to XML
> <aspect-chain>. This would give the deployer a reference to the name
> of the interceptor chain to use. The Deployer would create a Proxy
> via the AspectManager with this chain name and register this Proxy
> with the MBeanServer.
>
> name="MyMBean">
> <!-- add new keyword -->
> <aspect-chain>jboss.AspectChains:name=SomeOldChain</aspect-chain>
>
>
> name="jboss.AspectChains:name=ClientProxyChain>
>
> <aspect-chain>
> name="Transaction"
> type="instance"
> class="org.jboss.proxy.TransactionInterceptor"
> />
> <!--
> name="JRMPInvokerProxy"
> type="singleton"
> />
> </aspect-chain>
>
>
>
> name="jboss.AspectChains:name=EJBProxyChain">
>
> <aspect-chain>
> name="TxInterceptorCMT"
> type="instance"
> class="org.jboss.proxy.TxInterceptorCMT"
> />
> name="EntityLock"
> type="instance"
> class="org.jboss.proxy.EntityLockInterceptor"
> />
> <!-- etc... -->
> </aspect-chain>
>
>
>

Looks cool. I'll send you the javadocs for what I commited to CVS today. My stuff is lacking on the JMX features. Anyways.. I'm glad we are all exited about this kinda stuff.

Regards,
Hiram

[marc.fleury]

REPOST FROM HIRAM

> > Ok I imagine a client invocation chain will look like:
> >
> > clientproxy -> client-interceptor-stack ->
> > serverproxy -> server-interceptor-stack -> targetMbean
>
> not quite there is no typed serverproxy in the middle just a straight
> invoke() stack.
>
> The server/client nature just appear do to a invoker in the JBoss
> sense.
>

Yeah. I forgot.. David reminded me in his email.

>
> so...
>
> > Would doing some think like this satisfy you client-server
> > requirments? :
> >
> > serverproxy = factory.createAspect("server-interceptor-stack",
> > targetMbean); clientproxy =
> > factory.createAspect("client-interceptor-stack", serverproxy
> > );
> >
>
> so... no that would be overkill as you introduce an additional Dynamic
> Proxy in the middle. Right now there are straight invoke().
>

right again.

> The point of the separation is that you may want travelling proxies
> and you may want inVM proxies all the time. While our client/server
> separation works today as inVM proxies (we have the EJB proxies
> working this way).
>
> It needs to be a construct in the factory whether you want
> distributable proxies or standalone. Note that the full client/server
> merged with no distribution would cover both cases however.
>
> > files. If we
> > provide a JMX interface to the factory so that you can view/update
> > stack configurations, would that satisfy your requirement "to have
> > these puppies
> > manageable."
>
> It is a bit more deep than that. I am really looking for a central
> repository of that name-> configuration mapping and a way to interact
> with it, clearly JMX is the way to go and it needs to be centralized.

I thought thats kinda what I said. The Factory right now manages the
name->configuration mapping. We need and uber cool JMX MBean that
name->allows us
to manipulate those configurations.

> Don't worry about it for now. Bill and I are thinking about that
> centralization. There also needs to be a callback in the interceptors
> for configuration changes. This dynamicity of configuration is
> completely missing from the current codebase and the EJB spec in
> general. This would take care of that.

You need to expand on this a little.. a small use case maybe.
>
> Gents I really think we got it this time. This is the end of our
> journey... the real AOP framework in JBoss. 10 years of industry
> dominance... a monopoly in the making
>

wow that gives me the tingles..

[marc.fleury]

REPOST FROM BILL BURKE

Its more like

DynamicProxy -> interceptor stack -> Target MBean

There should be no concept of server or client.

I also believe the interceptor chain, Aspect Oriented framework should be a generic framework and should work with any type of Object. It should be core to JMX. Sure, the MBeanDeployer could look at some XML and be the bridge between Aspects and MBeans, but lets keep Aspects a separate, lightweight framework.

We have totaly freedom as far as MBean XML config files go, right?

Here was my idea for an Aspect framework. I drew up the API while in Germany. The features were:

- Interceptors could be services/singletons OR instantiated per chain.
- You could prepend or append an interceptor to the chain globally at runtime
- You could prepend or append an interceptor to an individual chain.
- DynamicProxies would have a generic Aspect interface



interface AspectManager
{
void createChain(String name);
void registerInterceptorSingleton(String name, Interceptor interceptor);

// These methods globally modify the chain of any Aspect in system with the given name
void prependAspect(String chainname, String interceptorName, Class clazz, Element metadata);
void appendAspect(String chainname, String interceptorName, Class clazz, Element metadata);

void prependAspect(String chainname, String singletonName);
void appendAspect(String chainname, String singletonName);

void removeAspect(String chainname, String interceptorName);


/**
* Given any old object, make it Aspect Oriented.
* metadata could hold InvocationContext-like information
*/
Aspect metamorphisis(String chainName, Class[] interfaces, Element metadata, Object targetObject);

/**
* No target object, useful for remote invocations.
* metadata could hold InvocationContext-like information like MBean name to invoke on
* and stuff like that.
*/
Aspect createAspect(String chainName, Class[] interfaces, Element metadata); }

/**
* Every DynamicProxy would implement this interface
*/
interface Aspect
{
String getAspectName();

/**
* Allows you to detach this particular aspect
*/
void setAspectName(String newName);

Object[] getInterceptors();
Interceptor findInterceptor(String name);

Object getTargetObject();

}


So, XML would look something like this. An AspectChain MBean would create chains within the AspectManager. Add a new keyword to XML <aspect-chain>. This would give the deployer a reference to the name of the interceptor chain to use. The Deployer would create a Proxy via the AspectManager with this chain name and register this Proxy with the MBeanServer.


<!-- add new keyword -->
<aspect-chain>jboss.AspectChains:name=SomeOldChain</aspect-chain>


<mbean code="org.jboss.aspect.AspectChain"
name="jboss.AspectChains:name=ClientProxyChain>

<aspect-chain>

<!--

</aspect-chain>





<aspect-chain>


<!-- etc... -->
</aspect-chain>

[marc.fleury]

> Ok I imagine a client invocation chain will look like:
>
> clientproxy -> client-interceptor-stack ->
> serverproxy -> server-interceptor-stack -> targetMbean

not quite there is no typed serverproxy in the middle just a straight
invoke() stack.

The server/client nature just appear do to a invoker in the JBoss sense.


so...

> Would doing some think like this satisfy you client-server
> requirments? :
>
> serverproxy =
> factory.createAspect("server-interceptor-stack",
> targetMbean); clientproxy =
> factory.createAspect("client-interceptor-stack", serverproxy
> );
>

so... no that would be overkill as you introduce an additional Dynamic
Proxy in the middle. Right now there are straight invoke().

The point of the separation is that you may want travelling proxies and
you may want inVM proxies all the time. While our client/server
separation works today as inVM proxies (we have the EJB proxies working
this way).

It needs to be a construct in the factory whether you want distributable
proxies or standalone. Note that the full client/server merged with no
distribution would cover both cases however.

> files. If we
> provide a JMX interface to the factory so that you can
> view/update stack
> configurations, would that satisfy your requirement "to have
> these puppies
> manageable."

It is a bit more deep than that. I am really looking for a central
repository of that name-> configuration mapping and a way to interact
with it, clearly JMX is the way to go and it needs to be centralized.
Don't worry about it for now. Bill and I are thinking about that
centralization. There also needs to be a callback in the interceptors
for configuration changes. This dynamicity of configuration is
completely missing from the current codebase and the EJB spec in
general. This would take care of that.

[marc.fleury]

I'm a little confused about one part of this...

I thought the plan was to turn our current ejb interceptors into mbean interceptors and the Containers into fancy MBeanInvokers (If I remember correctly, anyway the top thing on the mbean interceptor stack). If this is correct, the ServerInterceptors would be behind the target MBean and not part of this new factory.

This would look more like
clientproxy -> client-interceptor-stack ->
serverproxy -> targetMbean -> mbean-interceptor-stack


In any case, I think all the stack factories should be mbeans as Hiram mentions.

david jencks


On 2002.09.12 14:25:25 -0400 Hiram Chirino wrote:
>
> Ok I imagine a client invocation chain will look like:
>
> clientproxy -> client-interceptor-stack ->
> serverproxy -> server-interceptor-stack -> targetMbean
>
> Would doing some think like this satisfy you client-server
> requirments? :
>
> serverproxy = factory.createAspect("server-interceptor-stack",
> targetMbean);
> clientproxy = factory.createAspect("client-interceptor-stack",
> serverproxy
> );
>
> Please note: that "server-interceptor-stack" in essence will resolve
> to a set of { server-interfaces[], server-interceptors[],
> server-configurations[] }
>
> On another note, right now the factory that generates the proxys for
> say the "server-interceptor-stack", is configured through static xml
> files. If we
> provide a JMX interface to the factory so that you can view/update stack
> configurations, would that satisfy your requirement "to have these
> puppies
> manageable."
>
> Regards,
> Hiram
>

[hchirino]

Hi.

I've updated JBossAOP to FINAL version and have problem with my XML entities which I access from XML my-aop-file.xml file.

Here's the code:

$cd /home/nthx/private/YYY/Project/
$ls
 configurations/
 src/
 build.xml


$cat /home/nthx/private/YYY/Project/configurations/myAOP-A.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE aop [
 ENTITY include1.ent SYSTEM "configurations/META-INF/include1.ent"
 ...
]>
<aop>
 &include1.ent;
 ...
</aop>



$ant
...
internal:parametrisied-aopc:
 [aopc] [info] Total length of filenames to be compiled is greater than 1000, listing files
 in --SOURCEPATH: /tmp/src5805.tmp
 [aopc] [debug] jboss.aop.class.path is NULL
 [aopc] [debug] jboss.aop.search.classpath: 'null' true
 [aopc] [debug] jboss.aop.path: /home/nthx/private/YYY/Project/configurations/myAOP-A.xml
 [aopc] jboss.aop.path[0]: /home/nthx/private/YYY/Project/configurations/myAOP-A.xml
 [aopc] [deploying] file:/home/nthx/private/YYY/Project/configurations/myAOP-A.xml
 [aopc] java.io.FileNotFoundException: JAR entry configurations/META-INF/include1.ent not found
in /home/nthx/private/YYY/Project/lib/jboss-aop.jar
 [aopc] at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:97)
 [aopc] at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:107)
 [aopc] at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
 [aopc] at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
 [aopc] at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
 [aopc] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEntityReference(Unknown Source)
 [aopc] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.
dispatch(Unknown Source)
 [aopc] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
 [aopc] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 [aopc] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 [aopc] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 [aopc] at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
 [aopc] at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
 [aopc] at org.jboss.aop.AspectXmlLoader.loadURL(AspectXmlLoader.java:948)
 [aopc] at org.jboss.aop.AspectXmlLoader.deployXML(AspectXmlLoader.java:885)
 [aopc] at org.jboss.aop.Deployment.deployXmlFile(Deployment.java:164)
 [aopc] at org.jboss.aop.Deployment.preconfigThroughSystemProperty(Deployment.java:146)
 [aopc] at org.jboss.aop.Deployment.deploy(Deployment.java:36)
 [aopc] at org.jboss.aop.AspectManager.instance(AspectManager.java:122)
 [aopc] at org.jboss.aop.standalone.Compiler.compile(Compiler.java:160)
 [aopc] at org.jboss.aop.standalone.Compiler.main(Compiler.java:67)
 [aopc] java.lang.RuntimeException: [error] failed to load
aop path: /home/nthx/private/YYY/Project/configurations/myAOP-A.xml
 [aopc] at org.jboss.aop.Deployment.preconfigThroughSystemProperty(Deployment.java:155)
 [aopc] at org.jboss.aop.Deployment.deploy(Deployment.java:36)
 [aopc] at org.jboss.aop.AspectManager.instance(AspectManager.java:122)
 [aopc] at org.jboss.aop.standalone.Compiler.compile(Compiler.java:160)
 [aopc] at org.jboss.aop.standalone.Compiler.main(Compiler.java:67)
 [aopc] Caused by: java.io.FileNotFoundException: JAR entry configurations/META-INF/include1.ent
not found in /home/nthx/private/YYY/Project/lib/jboss-aop.jar
 [aopc] at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:97)
 [aopc] at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:107)
 [aopc] at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
 [aopc] at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
 [aopc] at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
 [aopc] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEntityReference(Unknown Source)
 [aopc] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.
dispatch(Unknown Source)
 [aopc] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
 [aopc] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 [aopc] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 [aopc] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 [aopc] at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
 [aopc] at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
 [aopc] at org.jboss.aop.AspectXmlLoader.loadURL(AspectXmlLoader.java:948)
 [aopc] at org.jboss.aop.AspectXmlLoader.deployXML(AspectXmlLoader.java:885)
 [aopc] at org.jboss.aop.Deployment.deployXmlFile(Deployment.java:164)
 [aopc] at org.jboss.aop.Deployment.preconfigThroughSystemProperty(Deployment.java:146)
 [aopc] ... 4 more

I run it through ant task, and all the files which you see here exist in apropriate directories with apropriate names.

This code has worked until RC1 (don't know about RC2).


Thanks for help,
Tomasz