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: <ben...@jb...> - 2005-05-20 17:09:51
|
I will encourage you to post your design doc (can be brief) to the Clustering Design forum. People may have valuable feedback, actually. :-) Like Scott mentioned, the correct patch process is create a Jira and attach your documentation, patch, and possibly junit testing there. Please post the jira issue here as well once you have that. Thanks, -Ben View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878579#3878579 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878579 |
|
From: <sco...@jb...> - 2005-05-20 17:09:07
|
So there needs to be a clear mapping of the names used in the references such as extends, component to both the binary and source repositories. There also needs to be a definition of the structure for a component source and binary tree. In terms of a project wanting to import the docs/licenses/* or another component, this is just an alternate artifact reference to the binary repository as I see it. The docs would also seem to be more of a release level reference. The licenses I would expect to be a general feature of a common thirdparty target that pulled the binaries from the repository. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878578#3878578 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878578 |
|
From: ScottMarlowNovell <nu...@jb...> - 2005-05-20 16:32:56
|
That is pretty creative thinking on your part, finding a use for the timestamp checking code :-) The FarmMemberSingletonService that you are working on sounds really interesting. If you want to post the implementation, just create a Jira task with the code attached when your done. The org.jboss.ha.framework.server.FarmMemberService.deploy() fix for JBCLUSTER-42 is checked into the JBoss 4.0.3 repository. -Scott View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878570#3878570 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878570 |
|
From: wobbet <nu...@jb...> - 2005-05-20 16:21:29
|
Since you're in England you probably don't see the same television commercials that we see. There's a collection of Guiness commercials with two animated Brits talking about what's new with the beer... "Look what I've invented - a six pack!" "A six pack?!?! Brilliant!" "But don't drink all six at once." "Not drinking six beers at once?!?! Brilliant!" Your opening line triggered a commercial flashback for me... rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878568#3878568 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878568 |
|
From: patrickdalla <nu...@jb...> - 2005-05-20 15:19:25
|
Caused by: javax.portlet.PortletException: Cannot start the forums theme at org.jboss.portlet.forums.ForumsPortlet.init(ForumsPortlet.java:198) at org.jboss.portlet.JBossPortlet.init(JBossPortlet.java:337) at org.jboss.portal.portlet.PortletContainer.start(PortletContainer.java:129) ... 129 more View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878555#3878555 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878555 |
|
From: <sco...@jb...> - 2005-05-20 14:42:41
|
Give some specific examples of more complicated authorization rules. Your choices are: 1. If the rules can be decomposed into a user having a set of roles, the existing JAAS mechanism can be used. 2. If the rules require more logic, but can be expressed using custom java.security.Permission objects, you can use the java.security.Policy mechanism to assign permissions to users and test the permissions using the Policy.implies check similar to how JACC works. 3. If the permission rules just don't fit Permissions, we need a new security service that layers on top of the others and employs a rules engine to help with the permissions evaluations. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878552#3878552 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878552 |
|
From: umeshs79 <nu...@jb...> - 2005-05-20 10:43:08
|
Hi, I am new in JBoss/JMX development. I have created a simple MBean and it works fine for me. Now my requirement is that I need to register this MBean in JBoss JNDI Context and need to access it from JNDI Context. So please help me how and where I register my MBean in JNDI context..? Is there a way to specify the Jndi Name in jboss-service.xml, so JBoss read from there and register automatically in JNDI context. or do i need to write code to register my mbean in JNDI Conext..? I seen JNDIMap example in Chapter 2 of JBoss4.0 Guide where JNDIMapMean itself is registering in JNDI InitialContext. Is that the way todo that..? Please reply thanks. Umesh View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878535#3878535 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878535 |
|
From: <tom...@jb...> - 2005-05-20 10:41:42
|
could i do something usefull with security in jBPM ? this is a philisophical jBPM question rather then a jboss question, but i would appreciate the opinion of the jboss experts on this. authentication: this is outside the scope of jBPM to do the authentication. the environment needs to do the authentication and pass the authenticated user information to jBPM. passing that information can be done via the jBPM API. authorization: there are definitely process related authorization constraints. E.g. the 'payraise process' can only be started by 'managers'. But jBPM can never include a generic mechanism for authorization constraints because 1) the organisation model is different in every organisation (it's pluggable in jBPM) 2) the authorization rules are expressed in terms of the organisation model 3) the authorization rules themselves are also different from organisation to organisation. So we cannot include authorization into jBPM unless we freeze the organisation model and the format for authorization rules. that does not seem like a good idea to me. any advice or twist of mind is welcome. regards, tom. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878534#3878534 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878534 |
|
From: <kab...@jb...> - 2005-05-20 09:18:43
|
Hi, I've added this to JIRA http://jira.jboss.org/jira/browse/JASSIST-10 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878525#3878525 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878525 |
|
From: <kab...@jb...> - 2005-05-20 09:10:02
|
Great, These are the kind of "border-line use cases" that are only found in real world scenarios. Thanks a lot for your help:-) Bill is on holiday this week, but I'll have a word with him about adding your fixes next week since he knows the javassist internals better than me. http://jira.jboss.org/jira/browse/JBAOP-140 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878522#3878522 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878522 |
|
From: hengels <nu...@jb...> - 2005-05-20 08:09:38
|
Hi, I found another bug in javaassist. The workaround is to comment out the call to doCompaction in CtClassType->getClassFile2 The problem is, that the method doCompaction calls CtClassType->isModified in order to check, if a class can be removed from the cache. isModified returns the field "wasChanged" and this isn't updated on changes (see method checkModify). So, what actually happens is that modified classes are pruned from the cache and thus, the modifications get lost. This is the reason, why the compiler can't find renamed original methods when compiling wrapper methods during instrumentation with jboss aop. could you please have a look at this issue and furthermore, could you please apply my patch for the tokenizer (see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=64091). Thanks, Holger View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878519#3878519 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878519 |
|
From: hengels <nu...@jb...> - 2005-05-20 07:58:56
|
Hi Kabir, thanks for your help. finally I managed to localize the bug in javaassist. The workaround is to comment out the call to doCompaction in CtClassType->getClassFile2 The reson is, that the method doCompaction calls CtClassType->isModified in order to check, if a class can be removed from the cache. isModified returns the field "wasChanged". The latter isn't updated on changes (see method checkModify). So, what actually happens is that modified classes are pruned from the cache and thus, the modifications get lost. this is the reason, why the compiler couldn't find the renamed method. Regards, Holger View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878518#3878518 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878518 |
|
From: garu <nu...@jb...> - 2005-05-20 07:36:00
|
Sorry to bother you again but i think i found another problem that may become an issue in a large environment. Suppose you have a cluster of N nodes and each node has A applications in the farm directory. Now you join node (N+1) to cluster, it receives N farmDeployments responses and pullNewDeployments() is called for each response. This means that each of the A applications is pulled from each of the N nodes. Now i see two problems, i have N*A transfers and for large values of N and A this may become a problem and if the size of A files is large there may be a huge latency in startup. Second, given that by definition the farming service keeps in sync all the member of the cluster, once i pulled the A files from the first member in list then i have (N-1)*A useless transfers. In my opinion the service startup actions should be: 1- ask for farmDeployments from cluster 2- pull the A applications form the first farmDeployments response 3- call scannerThread.doScan(), the status is still STARTING so no deploy will take place but parentDUMap is filled with each pulled file name 4- now pull the applications from the remaining N-1 nodes, but this time parentDUMap is filled and lastModified time can be checked avoiding useless transfers (in theory this should be useless, but i don't know the clustering stuff so deeply to understand if this step can be safely skipped) 5- scannerThread.setEnabled(scanEnabled.get()) and return. Pls, tell me what do you think. Gabriele View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878512#3878512 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878512 |
|
From: mikezzz <nu...@jb...> - 2005-05-20 07:09:32
|
Brilliant, I will attempt to merge this weekend. Mike. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878505#3878505 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878505 |
|
From: jiwils <nu...@jb...> - 2005-05-20 04:07:08
|
"be...@jb..." wrote : Don't you have CVS write access. Go ahead and commit those changes once the FileCacheLoaderTest passes... I have committer access for JGroups, but not for the JBoss stuff, so I just created a JIRA issue...access would be good... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878492#3878492 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878492 |
|
From: qdotlu <nu...@jb...> - 2005-05-20 00:24:23
|
Per J2EE specification,
"All web, enterprise bean, and application client containers are required to provide an ORB instance in the JNDI namespace under the name java:comp/ORB"
I am using the following code to try get ahold of the default ORB instance in the EJB code:
InitialContext context = new InitialContext();
ORB orb = (ORB)context.lookup("java:comp/ORB");
but failed with the following exception. Should this be corrected?
17:19:19,376 INFO [STDOUT] javax.naming.NameNotFoundException: ORB not bound
17:19:19,376 INFO [STDOUT] at org.jnp.server.NamingServer.getBinding(Naming
Server.java:491)
17:19:19,376 INFO [STDOUT] at org.jnp.server.NamingServer.getBinding(Naming
Server.java:499)
17:19:19,376 INFO [STDOUT] at org.jnp.server.NamingServer.getObject(NamingS
erver.java:505)
17:19:19,376 INFO [STDOUT] at org.jnp.server.NamingServer.lookup(NamingServ
er.java:278)
17:19:19,376 INFO [STDOUT] at org.jnp.interfaces.NamingContext.lookup(Namin
gContext.java:610)
17:19:19,376 INFO [STDOUT] at org.jnp.interfaces.NamingContext.lookup(Namin
gContext.java:701)
17:19:19,376 INFO [STDOUT] at org.jnp.interfaces.NamingContext.lookup(Namin
gContext.java:572)
17:19:19,376 INFO [STDOUT] at javax.naming.InitialContext.lookup(InitialCon
text.java:347)
17:19:19,376 INFO [STDOUT] at tester.TesterEJB.ejbCreate(TesterEJB.java:42)
17:19:19,376 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke0(
Native Method)
17:19:19,376 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke(N
ativeMethodAccessorImpl.java:39)
17:19:19,376 INFO [STDOUT] at sun.reflect.DelegatingMethodAccessorImpl.invo
ke(DelegatingMethodAccessorImpl.java:25)
17:19:19,376 INFO [STDOUT] at java.lang.reflect.Method.invoke(Method.java:3
24)
17:19:19,376 INFO [STDOUT] at org.jboss.ejb.StatelessSessionEnterpriseConte
xt.(StatelessSessionEnterpriseContext.java:63)
17:19:19,386 INFO [STDOUT] at org.jboss.ejb.plugins.StatelessSessionInstanc
ePool.create(StatelessSessionInstancePool.java:35)
17:19:19,386 INFO [STDOUT] at org.jboss.ejb.plugins.AbstractInstancePool.ge
t(AbstractInstancePool.java:161)
17:19:19,386 INFO [STDOUT] at org.jboss.ejb.plugins.StatelessSessionInstanc
eInterceptor.invokeHome(StatelessSessionInstanceInterceptor.java:78)
17:19:19,386 INFO [STDOUT] at org.jboss.ejb.plugins.AbstractInterceptor.inv
okeHome(AbstractInterceptor.java:90)
17:19:19,386 INFO [STDOUT] at org.jboss.ejb.plugins.CallValidationIntercept
or.invokeHome(CallValidationInterceptor.java:41)
17:19:19,386 INFO [STDOUT] at org.jboss.ejb.plugins.AbstractTxInterceptor.i
nvokeNext(AbstractTxInterceptor.java:109)
17:19:19,386 INFO [STDOUT] at org.jboss.ejb.plugins.TxInterceptorCMT.runWit
hTransactions(TxInterceptorCMT.java:335)
17:19:19,386 INFO [STDOUT] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke
Home(TxInterceptorCMT.java:146)
17:19:19,386 INFO [STDOUT] at org.jboss.ejb.plugins.SecurityInterceptor.inv
okeHome(SecurityInterceptor.java:116)
17:19:19,386 INFO [STDOUT] at org.jboss.ejb.plugins.LogInterceptor.invokeHo
me(LogInterceptor.java:121)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878471#3878471
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878471
|
|
From: wobbet <nu...@jb...> - 2005-05-19 21:24:58
|
I posted a patch named "build.xml-patch.txt" into the wiki patch upload directory. The purpose of this patch is to create a collection of commone fileset elements used by the mail.sar and mail.har sub-tasks of the jar and mkunwrapped tasks so that maintaining file lists for the deploy and dev-deploy options only has to be performed in one location. The jASEN specific contributions to the build.xml are commented out in this patch and will not be included in any build. You can contact me by sending an email to my forum username at gmail.com. Many thanks! rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878450#3878450 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878450 |
|
From: wobbet <nu...@jb...> - 2005-05-19 21:15:30
|
Got it... Having the username/password be in Base64 was a small suprise... rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878447#3878447 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878447 |
|
From: <ad...@jb...> - 2005-05-19 18:08:50
|
"rya...@jb..." wrote : "ad...@jb..." wrote : | | Ideally, only primary components are in the top level build during normal development. | | e.g. JBossAS contains naming, jbossmq, etc. it does not define log4j because | | that is a secondary dependency introducted by common/logging. | | (I haven't created a usecase discussion for component builds yet...) | | | | Right, but during normal development, developers are still going to need to be able to build a release image for testing. Which means there will need to be one version of log4j selected somehow. So this target is not just for calling immediately before a release. I'll talk about release issues in a separate thread, but in general developers will want to build multiple release images (for testing different configurations) and we will probably be moving to an installer based release where the user will be creating the final release image themselves. unzip jboss-4.0.4 cd jboss-4.0.4 install -config=default or install -config=all or install -config=jms or install // use a gui to create a custom config View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878427#3878427 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878427 |
|
From: <ad...@jb...> - 2005-05-19 18:02:41
|
"rya...@jb..." wrote : | 3. Once conflicts are resolved, this file can then be copied to a source controlled file, versions.xml. This file effectively pegs components at specific versions. So usually, a developer will just check out this file and not worry about the above process. | | 4. We have an additional target "versions-report" which compares the materialized versions to the pegged versions. Cruisecontrol calls this at the end of each build and includes the results in the build email: | | Error: log4j is pegged at 1.2.8, but aop (1.0.2) is compatable with log4j 1.2.6, 1.2.7 or 1.2.9. | Warning: log4j is pegged at 1.2.8, but cache (1.2.30), remoting (1.1.3) are also compatible with 1.2.9. | | So this emailed report would trigger the discussion and would then be resolved by a developer starting with step #1. Yes, one of the original aims of the new build is to have a declartive build such that additional tools can do extra analysis or processing. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878426#3878426 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878426 |
|
From: <rya...@jb...> - 2005-05-19 18:00:34
|
"ad...@jb..." wrote : | Ideally, only primary components are in the top level build during normal development. | e.g. JBossAS contains naming, jbossmq, etc. it does not define log4j because | that is a secondary dependency introducted by common/logging. | (I haven't created a usecase discussion for component builds yet...) | Right, but during normal development, developers are still going to need to be able to build a release image for testing. Which means there will need to be one version of log4j selected somehow. So this target is not just for calling immediately before a release. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878425#3878425 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878425 |
|
From: <ad...@jb...> - 2005-05-19 17:59:54
|
"rya...@jb..." wrote : | 2. A developer can call the "materialize" target to traverse all the component-infos and generate a materialized-versions.xml. If there are conflicts, they will need to be resolved manually. This file is not source controlled, it is a product of the build. | No, it is very important that this is versioned in cvs. It defines the release. The "materialize" should be done as a part of the release process. I haven't discussed the release use cases yet either, but... e.g. 1) 4.0.3beta - developers happily continue developing, maybe there are conflicts which they discover through warnings from the build or through testing problems 2) pre-4.0.3final - the release manager or qa, materialize the dependencies in their own local workspace - this fixes the release versions and also helps to discover conflicts At this point, a discussion can start on conflict resolution 3) 4.0.3 final - the release manager branches cvs (allowing other developers to continue to use the lax build scripts for the next release - goto 5) 4) 4.0.3 final - the release manager commits the materialized build scripts and tags everything with the release id in cvs 5) 4.0.4 beta - see (1) It is fairly obvious to me that steps 2 through 4 can be done with the help of build targets. (3) and (4) can be pretty much automated, e.g. cd jbossas ant make-release -Dtag=4.0.3final -Dnext=4.0.4beta which is only done when the release manager is happy that (2) is complete It could even upload the final binaries to sourceforge. Of course, knowing cvs, and the fact that this is a human process (people make mistakes) it is never quite that simple :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878424#3878424 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878424 |
|
From: <ad...@jb...> - 2005-05-19 17:45:24
|
"rya...@jb..." wrote : | 1. Only direct dependencies are stored in the toplevel build (eg. jms1.1) | Ideally, only primary components are in the top level build during normal development. e.g. JBossAS contains naming, jbossmq, etc. it does not define log4j because that is a secondary dependency introducted by common/logging. (I haven't created a usecase discussion for component builds yet...) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878422#3878422 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878422 |
|
From: <ad...@jb...> - 2005-05-19 17:10:23
|
This also raises the general issue of people changing public api without discussing it first. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878414#3878414 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878414 |
|
From: <ad...@jb...> - 2005-05-19 17:09:06
|
I've removed the bodge/changed api that tries to "inject" the aspect manager into the PropertyKernelConfig. The KernelConfig is intended as a bootstrap object. i.e. it is self contained in the policy it provides on bootstraping the kernel. If you want to "inject" things into the kernel config, create your own kernel config by subclassing, don't mung the existing implementations. I already provided mechanisms where the policy can be overridden, See AspectTestKernelConfig.createDefaultClassAdapter() Additionally, for core JBoss use, we are not going to create an AspectManager before starting the kernel. The AspectManager should be under the control of the kernel for configuration/management purposes. This raises an interesting issue in how we provide aspects onto the core kernel objects (I assume the AspectManager will be the first object installed). This is a similar "chicken and egg" on how you apply a security advice to the security manager. I believe the Dynamic AOP of JBossAOP helps here? Finally, this AspectManager context used by the ClassAdapter (or whatever it is going to be replaced with) needs considering in the context of scoping/domains. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878413#3878413 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878413 |
1965 messages has been excluded from this view by a project administrator.
