Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ad...@jb...> - 2005-06-02 17:22:29
|
Can you repeat the question in English :-) Let me explain the recent changes in one place... I have changed the controller along the lines mentioned in this thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=64229 This allows different context models to be plugged into the same controller and take part in the same lifecycle, i.e. dependencies Currently, there are two models envisioned 1) The new BeanMetaData from the pojo microcontainer 2) The "ServiceContext" from the jmx microcontainer It is left to each model to interpret what happens during the different state transfers, though they have similar meanings across the models: NOT_INSTALLED - the controller knows about the context DESCRIBED - the model has examined the metadata INSTANTIATED - the target is constructed CONFIGURED - the target is configured (setters invoked) CREATE - the create method is invoked START - the start method is invoked INSTALLED - the target is enabled for "external" use There is a corresponding reverse set of states. The states are also pluggable, i.e. you can insert new states in the Controller, though existing models will NOOP the state transfer if they don't understand it. I have only envisioned linear state models (with install/uninstall callbacks) at the moment, though a graph might also be possible, if more complicated, should a usecase demand it. On top of this, we have the MODE which is the discussion in this thread. The current JMX model has no such notion (everything is MANUAL with the AUTOMATIC behaviour an illusion provided by the deployers). I plan to retrofit the MODE into the JMX model for deployment/management i.e. at least the ServiceController, ServiceMBean and -service.xml. Doing the other deployers will take more work since their xml is not always simply related to the MBeans they control. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879981#3879981 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879981 |
|
From: <cle...@jb...> - 2005-06-02 17:11:11
|
The DLL I commited in CVS doesn't open new thread files when the profiler is not started. The profiler opens one file for each available thread. The old version was doing that even if the profiler was not running. This new version does it properly. If you can't connect to CVS and download the file, please send me a private e-mail, then I can attach you in a private message Just one note: Make sure you are using the right CVS repository: http://wiki.jboss.org/wiki/Wiki.jsp?page=CVSRepository Clebert Suconic View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879980#3879980 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879980 |
|
From: <ad...@jb...> - 2005-06-02 16:51:45
|
So we are actually talking about two different issues. The first is to record in the repository that jgroups-2.2.8 has been tested with log4j-1.2.8 and log4-1.2.9 The second that to reproduce the jboss-4.0.3 package release you need jgroups-2.2.8 and log4j-1.2.8 I think "materializing" the versions in the top level build was the solution I proposed for the second requirement? My only issue was whether those versions remain fixed until somebody updates the top level build, or whether interim/development checkouts use "LATEST". I preferred the second option, but either will work. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879976#3879976 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879976 |
|
From: <bil...@jb...> - 2005-06-02 16:50:55
|
No, there is no standard at this time. The concepts are shared between implementations, but the APIs ware different. Both AspectJ and JBoss AOP are open source though, but it seems that doesn't make you feel any better. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879975#3879975 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879975 |
|
From: mtedone1 <nu...@jb...> - 2005-06-02 16:38:59
|
Hi, I looked for AOP to see if I get into it in a near future (I am a J2EE developer). I found two main sources of information: AspectJ (Eclipse project) and Jboss AOP. Few questions: is there an official reference document for AOP? Is Sun owner of such requirements? Is there an official product? What I'd like to avoid is to get into a technology, to discover that it was just the (bright) thought of a company rather than a shared new concept, to apply a 'vendor-oriented' AOP to discover that my solutions didn't work with another vendor. Is this scenario possible, or is AOP just a generic concept that anyone can implement as they like? Thanks for any response. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879972#3879972 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879972 |
|
From: <sco...@jb...> - 2005-06-02 16:30:32
|
Sure, but this is another layer of the as yet undefined patch release process that is adding information on top of the cast in stone jbossas 4.0.1 release build. I'm saying that right now I don't see a reason to not express the version dependencies in the master build. Certainly this should be overridable via local properties, and the LATEST notion can be useful for development builds, but there really is no other place for this version information. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879971#3879971 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879971 |
|
From: mxc <nu...@jb...> - 2005-06-02 16:27:40
|
Hi, When running the profiler in a production environmnet with over 50 concurrent users we get multiple error messages like the following. After about 10 minutes the application ab-ended. We restarted the server and did not invoke the activate method on the profiler bean but we still get the error messages in the console. Luckily the app has not crashed again. ******************************************************************************** ****************************************************************ERROR: Cannot open file c:/profilertemp\serverspy_4096_thread_1117728206235_0_702.log.gz View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879968#3879968 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879968 |
|
From: <dim...@jb...> - 2005-06-02 15:11:00
|
Ok, thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879963#3879963 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879963 |
|
From: <ad...@jb...> - 2005-06-02 15:04:44
|
Ok. But can I suggest a different approach. Rather than getting us to validate every change you make to the software by forcing us to read your patches, use the following alogorithm: 1) I think I've found a problem 2) Write a test that reproduces the problem 3) Write some stress tests to measure the performance (both contended and uncontended) 4) Fix the problem 5) Rerun the unit test to make sure it is fixed 6) Rerun the stress test to make sure you haven't introduced a bottleneck in the uncontended case or a deadlock in the contended case NOTE: The contended case in (3) will likely fail as well if there is a real MT problem. NOTE 2: We do read your patches on the cvs commit mailing list anyway View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879961#3879961 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879961 |
|
From: <ad...@jb...> - 2005-06-02 14:57:32
|
"sco...@jb..." wrote : | I don't view this future compatibility issue as a useful requirement. So the 4.0.1 of jbossas was tested with log4j-1.2.8 and a user wants to upgrade to log4j-1.2.9. Say we test this as part of a support case and validate log4j-1.2.9 works. We certainly are not going to re-release 4.0.1 with an updated compatibility version stamp on the log4j component. | No we are not going to release the base package it is fixed for all time. But users of the JBoss Network can get access to this information. i.e. "log4j-1.2.9 is now available it contains the following fixes/enhancements, it has been tested/validated against 4.0.1, 4.0.2, etc. click here to install" Although, this usecase is probably more relevent for our packages. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879959#3879959 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879959 |
|
From: <ad...@jb...> - 2005-06-02 14:52:05
|
"dim...@jb..." wrote : Thanks a lot for the hints! | | Actually we make the same mistake in TransactionImpl :) | Then fix it :-) Or at least report it on JIRA if you don't have time to analyse/test the consequences. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879956#3879956 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879956 |
|
From: <ad...@jb...> - 2005-06-02 14:50:42
|
"dim...@jb..." wrote : | My implementation is a bit naive for the time being, due to the notifyAll(). | notify leaves it to the underlying lock implementation to decide which thread gets woken (e.g. this might implement fair queuing) notifyAll wakes up all the threads and leaves it to a race in the OS scheduler as to who aquires the lock. Semantically they should be same in this circumstance, with notify being more efficient. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879955#3879955 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879955 |
|
From: <dim...@jb...> - 2005-06-02 14:41:46
|
Thanks a lot for the hints!
Actually we make the same mistake in TransactionImpl :)
| ...
| try
| {
| // Wakeup happens when:
| // - notify() is called from unlock()
| // - notifyAll is called from instanceDone()
| wait();
| }
| catch (InterruptedException ex)
| {
| // ignore
| }
| ...
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879953#3879953
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879953
|
|
From: <ad...@jb...> - 2005-06-02 14:35:39
|
"dim...@jb..." wrote : Another thing, txLockSet shouldn't be static, since we protect the state of each particular TreadLocal per tx. Correct. NO GLOBAL LOCKS. It is transaction + object (threadlocal). You might also consider adding a timeout to the lock such that we don't wait forever. e.g. if you are waiting 5 minutes to get access to the thread local it is almost certainly a deadlock. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879952#3879952 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879952 |
|
From: <ad...@jb...> - 2005-06-02 14:32:26
|
Also, the current TransactionLocal.get() allows a null transaction (returning null). So should interpret the lock()/unlock() as noops when there is no transaction. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879951#3879951 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879951 |
|
From: <ad...@jb...> - 2005-06-02 14:30:54
|
ReentrantLock.
You don't want to ignore/eat InterruptedException.
It is thrown for a reason.
I hate the early java examples where people didn't know what to do with InterruptedException and just ignored it.
If you want to continue through the InterruptedException you should restore
the state of the thread to interrupted.
| boolean interrupted = false;
| synchronized (txLockSet)
| {
| while (!txLockSet.add(transaction))
| {
| try
| {
| txLockSet.wait();
| }
| catch (InterruptedException ex)
| {
| interrupted = true;
| }
| }
| if (interrupted)
| Thread.interrupt();
| // got the lock
| }
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879949#3879949
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879949
|
|
From: <cle...@jb...> - 2005-06-02 14:20:15
|
You should use: java -XrunjbossInpsector:/tmp,include=org.jboss,include=com.mysql ..... BTW: I think you should use the DLL from CVS and not from the dowload package. I have fixed some bugs and I don't have a new release yet. (expected by the end of July). Clebert View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879943#3879943 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879943 |
|
From: <dim...@jb...> - 2005-06-02 14:16:07
|
Possible races condition in enlist(), when trackByTx is true, are probably caused one step back while a ConnectionListener is checkout from the ManagedConnectionPool.
I understand that 2 threads in the same Tx could both get a different managed connection, so I'm considering re-writing BasePool.getConnection(..) to temporarily lock on the ThreadLocal when trackByTx is active.
Code now
| public ConnectionListener getConnection(Transaction transaction, Subject subject, ConnectionRequestInfo cri)
| throws ResourceException
| {
| // Determine the pool key for this request
| boolean separateNoTx = false;
| if (noTxSeparatePools)
| separateNoTx = clf.isTransactional();
| Object key = getKey(subject, cri, separateNoTx);
| InternalManagedConnectionPool mcp = getPool(key, subject, cri);
|
| // Are we doing track by connection?
| TransactionLocal trackByTx = null;
| if (transaction != null)
| trackByTx = (TransactionLocal) trackByTxPools.get(key);
|
| // Do we have a previous connection in this transaction?
| if (trackByTx != null)
| {
| ConnectionListener cl = (ConnectionListener) trackByTx.get(transaction);
| if (cl != null)
| {
| if (traceEnabled)
| dump("Getting connection tracked by transaction " + cl);
| return cl;
| }
| }
|
| // Get a connection from the correct pool
| ConnectionListener cl = mcp.getConnection(subject, cri);
|
| // Are we tracking by connection?
| if (transaction != null && trackByTx != null)
| {
| cl.setTrackByTx(true);
| trackByTx.set(cl);
| }
|
| if (traceEnabled)
| dump("Getting connection from pool " + cl);
| return cl;
| }
|
Changed to
| /**
| * Return a connection from the pool, optionally tracked by a transaction
| */
| public ConnectionListener getConnection(Transaction transaction, Subject subject, ConnectionRequestInfo cri)
| throws ResourceException
| {
| // The connection listener to return
| ConnectionListener cl;
|
| // Use separate pools, if noTxSeparatePools configured in the
| // BasePool and the ConnectionListenerFactory is transactional
| boolean separateNoTx = false;
| if (noTxSeparatePools)
| {
| separateNoTx = clf.isTransactional();
| }
| // The overriding subclass determines the pool key for this request
| Object key = getKey(subject, cri, separateNoTx);
|
| // Get the pool for this particular key, create it first if needed
| InternalManagedConnectionPool mcp = getPool(key, subject, cri);
|
| // Are we tracking connection by transaction?
| //
| // TxConnectionManager will pass a non-null transaction if there
| // is a transaction associated with the thread and the connection
| // manager is configured to trackConnectionByTx
|
| if (transaction != null)
| {
| TransactionLocal trackByTx = (TransactionLocal) trackByTxPools.get(key);
|
| if (trackByTx != null)
| {
| // If trackByTx we need to synchronize competing threads
| // on the TransactionLocal, so they end up using the same
| // ConnectionListener/ManagedConnection
|
| trackByTx.lock();
| try
| {
| // Do we have a previous connection in this transaction?
| cl = (ConnectionListener) trackByTx.get(transaction);
|
| // If yes use it, if no get a one from the pool
| if (cl != null)
| {
| if (traceEnabled)
| log.trace("Getting existing connection tracked by transaction");
| }
| else
| {
| // Get a new connection (listener) from the pool
| cl = mcp.getConnection(subject, cri);
| // Mark that is tracked by transaction
| cl.setTrackByTx(true);
| // Store the connection listener to the TransactionLocal
| trackByTx.set(cl);
|
| if (traceEnabled)
| log.trace("Getting a connection from the pool to track the transaction");
| }
| }
| finally
| {
| trackByTx.unlock();
| }
| }
| else
| {
| // Weird, can happen only if BasePool.getTransationManager()
| // returns null, while constructing the TransactionLocal in
| // getPool(). Treat as if trackByTx is disabled
| if (traceEnabled)
| log.trace("TrackByTx true, but no TransactionManager associated with the pool;" +
| " getting a connection from the pool");
|
| // Get a new connection (listener) from the pool
| cl = mcp.getConnection(subject, cri);
| }
| }
| else
| {
| // Not tracking connection by transaction
| if (traceEnabled)
| log.trace("Getting a connection from the pool");
|
| // Get a connection from the correct pool
| cl = mcp.getConnection(subject, cri);
| }
|
| if (traceEnabled)
| dump("Returning connection " + cl);
|
| return cl;
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879942#3879942
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879942
|
|
From: <sco...@jb...> - 2005-06-02 14:11:27
|
On the point of where the version of an included component is defined, I don't see anywhere but the master build to define this. Another possible requirement for the repository is a notion of the LATEST version of a component, but this is just an optimisitic view that the next version, even if restricted to the latest point release of a series, will work. This is actually the mode we run in now as whatever has been checked into thirdparty on a given branch is what is going into the release. anonymous wrote : | 4) You can later change the release to record that although it was originally tested with log4j-1.2.8, it also works just as well with 1.2.9 | | This was my argument against holding versions in the build files | and instead recording which artificats have been tested twith which versions of a dependency. Who is going to (or even knows when) a version should be unpegged. | I don't view this future compatibility issue as a useful requirement. So the 4.0.1 of jbossas was tested with log4j-1.2.8 and a user wants to upgrade to log4j-1.2.9. Say we test this as part of a support case and validate log4j-1.2.9 works. We certainly are not going to re-release 4.0.1 with an updated compatibility version stamp on the log4j component. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879940#3879940 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879940 |
|
From: mxc <nu...@jb...> - 2005-06-02 14:10:00
|
Hi How do you include multiple name spaces in the -XrunjbossInspector java option. ex. java -XRunInspector: /tmp, include=org.jboss,com.mysql,exclude=.... ie we want to log multiple namespaces. thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879939#3879939 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879939 |
|
From: <dim...@jb...> - 2005-06-02 13:30:39
|
Another thing, txLockSet shouldn't be static, since we protect the state of each particular TreadLocal per tx. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879928#3879928 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879928 |
|
From: <sco...@jb...> - 2005-06-02 13:28:34
|
What is the correlation with these states and any management exposure, or is that an arbitrary aspect that depends on the service configuration? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879927#3879927 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879927 |
|
From: <dim...@jb...> - 2005-06-02 13:19:31
|
Actually the locking needs to be smarter than the one in TransactionImp because we want to "lock" the ThreadLocal based on the active transaction, i.e. synchronize the threads inside the same tx only.
My implementation is a bit naive for the time being, due to the notifyAll().
I guess I need to look for an EDU.oswego equivalent.
| ...
| /**
| * Set to monitor which transactions are "locked"
| * with lock() and unlock().
| */
| private static final Set txLockSet = new HashSet();
| ...
| /**
| * Lock using the current transaction
| */
| public void lock()
| {
| lock(getTransaction());
| }
|
| /**
| * Lock using the provided transaction
| *
| * @param transaction
| */
| public void lock(Transaction transaction)
| {
| if (transaction == null)
| {
| throw new IllegalStateException("there is no transaction");
| }
|
| synchronized (txLockSet)
| {
| while (!txLockSet.add(transaction))
| {
| try
| {
| txLockSet.wait();
| }
| catch (InterruptedException ex)
| {
| // ignore
| }
| }
| // got the lock
| }
| }
|
| /**
| * Unlock using the current transaction
| */
| public void unlock()
| {
| unlock(getTransaction());
| }
|
| public void unlock(Transaction transaction)
| {
| if (transaction == null)
| {
| throw new IllegalStateException("there is no transaction");
| }
|
| synchronized (txLockSet)
| {
| if (!txLockSet.remove(transaction))
| {
| throw new IllegalStateException("Unlocking, but not locked");
| }
| // REVISE
| txLockSet.notifyAll();
| }
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879924#3879924
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879924
|
|
From: ignsdui <nu...@jb...> - 2005-06-02 12:34:19
|
We found what the problem is: It's a bug in the ADF runtime libraries of Jdeveloper 10.12. Earlier versions of Jdeveloper didn't have this problem View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879918#3879918 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879918 |
|
From: neil_g_avery <nu...@jb...> - 2005-06-02 11:07:32
|
Hi All, Im in the process of hooking up an AspectFactory to our application container. I would like to delegate Aspect creation to our container, given the way AspectFactory hangs together it assumes you will only use a single factory per aspect; in that . Whereas I would like to use the same generic aspectfactory, then determine the aspect context (class) and ask the container for the appropriate aspect. One way around this is to write my generic AspectFactory(Class aspectType) and then create a subclass factroy for every aspect type. However this is cumbersome in terms of adding aspects and maintaining the configuration. It would be much easier if I were to write my aop.xml as follows, <aspect name="Aspect1" class "my.aspect1l" factory="MyJBossAOPFactory" scope="PER_CLASS"/> | <aspect name="Aspect2" class "my.aspect2" factory="MyJBossAOPFactory" scope="PER_CLASS"/> | | <bind pointcut="execution(* my.POJOx->*(..))"/> | <advice name="execute" aspect="Aspect1"/> | <advice name="execute" aspect="Aspect2"/> | <bind/> | Is there a means of using a single AspectFactory across multiple Aspects? (meta data?) Regards Neil View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879911#3879911 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879911 |
1965 messages has been excluded from this view by a project administrator.
