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: <aco...@jb...> - 2005-07-27 23:31:03
|
Very helpful good points. keep it coming! For NOOP/Check, I'd like to use NIO and make hte connection go on a NOOP/Check pool. The tomcat guys did this with native stuff for keep alive with nice results! The latter point I'm less sure of. Its a matter of transacitonal integrity. I'm not sure I like the volatile integrity this implies... My thought is that the Hibernate implemenation will be the default. We'll use versioning and optimistic locking...something goes awry the latter user gets an exception "no sucka you can't" or the IMAP equiv and his DB session is essentially reloaded or something. I'm not sure a notification scheme is safe or necessary or even permissible by IMAP (though I could be wrong). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886947#3886947 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886947 |
From: <ani...@jb...> - 2005-07-27 21:20:57
|
When tools generates Java Types with annotations, we will use JDK5 enums to solve this issue. When using JDK1.4, I will retain the current implementation of generating xsd -> Java as shown in my previous post. But the user will not be able to reuse the Java Type (that contains JDK1.4 style enumerations) to be converted into a xsd simple type with enumeration. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886926#3886926 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886926 |
From: SunFire <nu...@jb...> - 2005-07-27 20:19:23
|
While you are working on the Mailbox design maybe you want to keep an eye down the road on features need by imap (and mybe other protocols). In addition to the more JBM internally used attributes you need to be able to attach a set of flexible (and client definded custom) flags to a folder (e.g. \Draft, \Seen, $Spam, etc.). Simplest way todo it would be to introduce a private hashmap to the mailbox and let every protocol have their own key to access their flag object in it and expose it like this: | Object getFlags(String key); | void setFlags(String key, Object flags); | NOTE: String may be prefered over Object and would certainly satisfy the needs for imap but since I have no idea if other protocols my need their own complex objects for flags... It would also be a nice feature to add an event observer type of mechanism to mailboxes. Reason for that: an IMAP connections instance has opened a mailbox and is idleing in it with NOOPs/CHECKs. A second connections instance is accessing the same mailbox and expunges a few mails (could also a user in a webfrontend, a pop3 instance, other imap client, etc). The first connection now needs to be updated that mail # 3, 5 and 8 have been deleted. So to allow a protocol instance to subscribe in some way to certain mailbox events like DELETE or ADD would make things much easier. Else you need to either do a lot of dirty overhead in the protocol implementations and/or place locks on the mailboxes much longer then actually needed (or needed at all). Cheers, Thorsten View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886917#3886917 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886917 |
From: <sco...@jb...> - 2005-07-27 19:34:06
|
That has to be provably incorrect since I wrote them. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886909#3886909 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886909 |
From: <aco...@jb...> - 2005-07-27 19:28:38
|
Ummm yes... I like the folder addressing scheme. I need to start thinking virtual hosts... I think I like the above aspect but idea... I mostly like it...I think... I dunno it seems like it is missing something but I can't put my finger on it. So do we have to go to JDK 5 yet? I scheduled this for M5 in the jira stuff I'm trying to outline a formal plan... My mind says wait just a little longer....but my heart says "yumm...upgrades!" I'm also salavating over something we should not do (the NIO threading thing....)...at least prototyping it....but I must ....resist....think...release schedule....important stuff first... -Andy View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886908#3886908 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886908 |
From: <aco...@jb...> - 2005-07-27 19:24:39
|
I figured. The instructions in readme.html are misleading. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886907#3886907 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886907 |
From: bdaw <nu...@jb...> - 2005-07-27 19:19:21
|
ok. So I finally deployed it. For code from nukes cvs head: 1) Use JavaCC.zip from JBoss Portla 2.0 thirdparty dir - it is different then https://javacc.dev.java.net/files/documents/17/686/javacc-3.2.zip 2) Use JBoss AS 3.2.3 - in greater there are some class differences in /lib/jboss-jmx.jar Instructions from: http://wiki.jboss.org/wiki/Wiki.jsp?page=InstallUninstallUpgrade are quite ok, but not 100% ok. Strange thing but I had problems with hsqldb but work fine with mysql ( I think some configuration is covered within for it...) And I need to call ant tasks it in such order: 1) #nukes/build/build 2) (all DS placement and configuration work) 3) #nukes/distrib/build clean 4) #nukes/distrib/build installer 5) #nukes/distrib/build deploy-installer 6) (installer from http) 7) #nukes/build/build deploy-all I hope somebody will save some time with above... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886906#3886906 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886906 |
From: mholzner <nu...@jb...> - 2005-07-27 18:27:38
|
here is the short of it: 1) requirements and goals: * JACC implementations need to be pluggable similar to JAAS modules * JACC modules need to be configurable per application * the current JACC implementation needs to be extended to allow other then J2EE resources to check access control through the same mechanism (portal resources for instance) * the JACC module should allow for more dynamic features , such as access check for portal pages that were created after the portal was deployed * all JEMS components need to use a unified way to check access control (through JACC; to allow easy configuration of a single PDP) * static role assignment (in the login module) imposes too many restrictions (think: user is in role 'bookkeeper' from 9 to 5 only). As a result, for more advanced security scenarios, the JACC provider needs to be the one that handles role memberships (dynamically) 2) implementation details: * JACC modules can be written against a defined API (SPI) that would need to be created * JACC modules can be configured per application (login?config.xml ?) * JACC modules could potentially be stackable ((static)J2EE module, Portal module, jBPM module, custom module...) similar to (but far more flexible then) DelegatingPolicy * container code (interceptors) checks access via an abstracted API very simplified: | Security.implies(permission type, subject, resource, action) | where permission type is one of J2EE, Portal, .... * deployers can discover the configured JACC module and add the correct permissions * all permission types extend java.security.Permission * the abstracted API news up the correct Permission class (based on the permission type) and calls into a deeper layer * this deeper layer reads the configured JACC module(s), loads them, and performs the access check with them * the JAAS and JACC modules need to share some state to allow the JACC provider to get to SAML assertions etc. This would potentially be done via special principals in the subject * if no JACC provider is configured for an app, the JBoss default one is used 3) questions and food for thought: * during our discussion around this topic we realized that most applications up the stack (Portal, BPM, WSRP, ...) all need to handle "identity as data" as well. Meaning: they all need to access user attributes in one form or another. We believe that this topic needs to be considered as well when we try to solve JAAS, JACC , RBAC , SAML,... in this layer. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886900#3886900 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886900 |
From: dwatling <nu...@jb...> - 2005-07-27 18:15:43
|
Where can I access the CVS repository? I couldn't find any reference to it in the forums, documentation, or anywhere else. -Dan View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886897#3886897 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886897 |
From: <ad...@jb...> - 2005-07-27 18:14:55
|
Actually, I posted the wrong link: http://docs.jboss.org/jbossas/javadoc/4.0.2/org/jboss/mx/loading/RepositoryClassLoader.html#getClasspath() You would want to use code like: | URL[] urls = null; | ClassLoader cl = Thread.currentThread().getContextClassLoader(); | if (cl instanceof RepositoryClassLoader) | urls = ((RepositoryClassLoader) cl).getClassPath(); | else if (cl instanceof URLClassLoader) | urls = ((URLClassLoader) cl).getURLs(); | else | throw new DeploymentException("Unable to determine urls for classloader " + cl); | // Use the urls here | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886896#3886896 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886896 |
From: <ste...@jb...> - 2005-07-27 18:04:30
|
Yes, we are saying the same thing in terms of the capaibilities. I am just uncertain how the MBean would "ad...@jb..." wrote : ask the classloader | for the urls in the TCL and get all four jar urls (the main jar and the embedded jars) | as possibilities to search. I'll take a look at that link and see if that helps me see the light. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886893#3886893 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886893 |
From: <ad...@jb...> - 2005-07-27 17:59:14
|
Yes, and what I'm saying is you could have | myejbs.jar/ | META-INF/ | ejb-jar.xml | mydomainclassesandmappings.jar | ehcache.jar | myotherjars.jar | hibernate-service.xml | When the MBean in hibernate-service.xml is deployed, it will ask the classloader for the urls in the TCL and get all four jar urls (the main jar and the embedded jars) as possibilities to search. See: http://docs.jboss.org/jbossas/javadoc/4.0.2/org/jboss/mx/loading/RepositoryClassLoader.html#getAllURLs() View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886891#3886891 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886891 |
From: mikezzz <nu...@jb...> - 2005-07-27 17:57:30
|
Perhaps annotated aspect to that contains a description the type of access to a folder (read, write). And an interface 'Securable' which has the methods for getting a list of roles for this object. public class Folder implement Securable { | | @Secured (access="read") | public void getMessage {...} | } | | public class SecurityAspect { | | public void isAllowed() { | Securable sc = (Securable) getCurrentObject(); | String access = metaData.get("access"); | if (sc.getRoleSet(access).retainAll(currentUser.getRoleSet()).size() > 0) { | // Ok. | } | else { | throw new SecurityException("Bad person doing bad things"); | } | } | } We would define a join point for Security Aspects to be bound to methods annotated with @Secured. One of the things that I was thinking about related to folders is that it would be nice to be able to address any entity in JBMail using a path e.g. my inbox could be addressed as '/{domain}/mail/folders/mike/INBOX'. Mostly this would help REST and CalDAV should we decide to implement these and provide a uniform interface to any object in the system. Perhaps we could have the concept of "mounting" a module. It would require a common contract for all modules that contain entities. Just an idea, probably overkill. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886888#3886888 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886888 |
From: <ste...@jb...> - 2005-07-27 17:55:40
|
"ad...@jb..." wrote : Rather you just need the urls of the mbean's context classloader | (the TCL during startService or whatever it invokes), | i.e. the sar, ejb, ear, etc. urls from the deployment it is a part of. Well, that's an important distinction ;) Yes, I am only interested in the URL pertaining to the deployment (as well as anything "under" it). What I am uncertain of is exactly how to get that information from inside the mbean. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886886#3886886 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886886 |
From: <ste...@jb...> - 2005-07-27 17:48:33
|
*** OK actually formatted :) *** what i mean is this; currently the .har format is: | .har/ | meta-inf/ | hibernate-service.xml | MyMapping.hbm.xml | org/ | myproject/ | MyMapping.class | ehcache.jar | myotherjars.jar | So, the .har itself is added to the deployment classloader. The HARDeployer, then marks any nested jars as deployable (mimicing the behavior of SARDeployer). However, what would be nice, and people have asked for, is to instead be able to do this: | .har/ | meta-inf/ | hibernate-service.xml | mydomainclassesandmappings.jar | ehcache.jar | myotherjars.jar | such that mydomainclassesandmappings.jar contains the domain classes as well as their mappings. Then later, say I (assuming .har is exploded) drop in "myextendeddomainclassesandmappings.jar" which contains further domain classes and mappings. I understand JBoss will not handle this automatically in terms of forcing a redploy of the mbean/deployment. I am talking about the information available to me when the user does the above mentioned "drop" and then performs the "rebuildSessionFactory()" managed operation. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886885#3886885 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886885 |
From: <sco...@jb...> - 2005-07-27 17:47:36
|
Yes, we need the izpack in the repository as it contains jboss patches for group behavior that has not been merged back as yet. It also includes custom installer actions for things like applying the velocity macro templates based on the user input panel settings. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886884#3886884 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886884 |
From: <ste...@jb...> - 2005-07-27 17:46:43
|
what i mean is this; currently the .har format is: .har/ meta-inf/ hibernate-service.xml MyMapping.hbm.xml org/ myproject/ MyMapping.class ehcache.jar myotherjars.jar So, the .har itself is added to the deployment classloader. The HARDeployer, then marks any nested jars as deployable (mimicing the behavior of SARDeployer). However, what would be nice, and people have asked for, is to instead be able to do this: .har/ meta-inf/ hibernate-service.xml mydomainclassesandmappings.jar ehcache.jar myotherjars.jar such that mydomainclassesandmappings.jar contains the domain classes as well as their mappings. Then later, say I (assuming .har is exploded) drop in "myextendeddomainclassesandmappings.jar" which contains further domain classes and mappings. I understand JBoss will not handle this automatically in terms of forcing a redploy of the mbean/deployment. I am talking about the information available to me when the user does the above mentioned "drop" and then performs the "rebuildSessionFactory()" managed operation. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886883#3886883 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886883 |
From: <aco...@jb...> - 2005-07-27 17:38:05
|
So I thought I was following the instructions in readme.html I built JBoss... BUILD SUCCESSFUL Total time: 5 minutes 46 seconds Andrew-Olivers-Computer:~/projects/jboss/jboss-mail/head/jboss-4.0 acoliver$ cd - /Users/acoliver/projects/jboss/jboss-mail/head/jboss-4.0/build/install Andrew-Olivers-Computer:~/projects/jboss/jboss-mail/head/jboss-4.0/build/install acoliver$ ant -Dizpack.home=/Users/acoliver/projects/jboss/jboss-mail/head/izpack Buildfile: build.xml installer: [echo] Building JBossAS jboss-4.0.3RC2-installer.jar ... BUILD FAILED /Users/acoliver/projects/jboss/jboss-mail/head/jboss-4.0/build/install/build.xml:55: com.izforge.izpack.compiler.CompilerException: install.xml:93: CustomAction jar file not found: /Users/acoliver/projects/jboss/jboss-mail/head/jboss-4.0/build/install/output/jboss-listeners.jar it seems that it actually kind of wants the one in the repository (I grabbed my izPack from the head). Once I did the install-izpack despite a really annoying bug with the file picker (it won't pick directories only files)...the build then works. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886879#3886879 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886879 |
From: <ad...@jb...> - 2005-07-27 17:28:03
|
I don't understand the added/removed domain classes stuff. JBoss does not currently support classloader dependencies or hot deployment of single classes inside a deployment (other than what the jvm provides for hotswap when debugging) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886873#3886873 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886873 |
From: <ad...@jb...> - 2005-07-27 17:26:38
|
My understanding is that you only need the deployer to get the urls to search from the DeploymentInfo. If you use code like the AbstractWebContainer.getClassLoaderURLs() you don't need the deployment info. I'm not saying use the above method as is, which will give you ALL urls of all classloaders in the loader repository. Rather you just need the urls of the mbean's context classloader (the TCL during startService or whatever it invokes), i.e. the sar, ejb, ear, etc. urls from the deployment it is a part of. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886870#3886870 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886870 |
From: <sco...@jb...> - 2005-07-27 17:21:48
|
We are never back to the current situation because: 1. Its not an unversioned CVSROOT/modules admin file that defines the makeup of the thirdparty tree. 2. The master build is defining the versions explicitly so this is what controls what goes into a release. This is a versioned file that can easily be monitored and manged for project specific changes. 3. Developers are not updating thirdparty libraries with who knows what version, license, etc. and checking them in. This is done by populating the repository, and strict adherence to population of a valid component info will be required for any content checked in there. All Adrian is saying is that propagation of the version info to local workspace paths just makes life difficult. The local version info is superflous. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886868#3886868 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886868 |
From: <ste...@jb...> - 2005-07-27 17:13:51
|
So as requested in http://jira.jboss.com/jira/browse/JBAS-2000, lets discuss this. So basically what you are saying regarding the extraction of URLs to use is that I would simply internalize that into the org.jboss.hibernate.jmx.Hibernate.startService() method rather than a deployer being needed to inject that value. I actually really like that since it will also give the added benefit of the HAR archive not necessarily needing the hbm.xml files nor the domain classes to be included at the root of the HAR archive itself; users could actually jar it seperately and just include the jar into the har since those bundled jars should then be available on the classloader you are talking about. Can I use that AbstractWebContainer.getClassLoaderURLs() method here? Or do I need to duplicate that logic over to my MBean? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886829#3886829 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886829 |
From: milesif <nu...@jb...> - 2005-07-27 17:13:18
|
Hi everybody, (hope this is the right place to post) I am using jdk1.5.0_03, Jboss4.0.2 in the ALL configuration where I installed ejb3 beta 1 and jboss portal . Ejb3 work perfect so I decided to make experiments to add my interceptors to my ejb and servlets. To start, I deployed the annotated-injboss example and I got the following results. 1. when I run "ant deploy-ear-aop" it is all fine, but I get the following message anonymous wrote : | Classes have not been aop'ed - run JBoss with enable transformations = true | [echo] Deploying ear containing a lib.aop file containing the jboss-aop.xml file | | 2. I thought it would be ok after restarting the server, but on restart I got the following output: anonymous wrote : | INFO [EARDeployer] Init J2EE application: file:/home/francescom/development/jboss-4.0.2/server/all/deploy/aopexample.ear | INFO [STDOUT] [debug] Looking for aspects in: org.jboss.injbossaop.lib.ExampleValue | INFO [STDOUT] [debug] Looking for aspects in: org.jboss.injbossaop.lib.SimpleInterceptor | INFO [STDOUT] [debug] Found @InterceptorDef in: org.jboss.injbossaop.lib.SimpleInterceptor | INFO [STDOUT] [debug] Looking for aspects in: org.jboss.injbossaop.web.BasicExampleServlet | INFO [STDOUT] [debug] Looking for aspects in: org.jboss.injbossaop.web.EarExampleServlet | INFO [AspectDeployer] Deployed AOP: file:/home/francescom/development/jboss-4.0.2/server/all/tmp/deploy/tmp23248aopexample.ear-contents/aopexamplelib.aop | INFO [EjbModule] Deploying ExampleSession | INFO [EJBDeployer] Deployed: file:/home/francescom/development/jboss-4.0.2/server/all/tmp/deploy/tmp23248aopexample.ear-contents/aopexampleejb.jar | INFO [TomcatDeployer] deploy, ctxPath=/aopexample, warUrl=file:/home/francescom/development/jboss-4.0.2/server/all/tmp/deploy/tmp23248aopexample.ear-contents/aopexample.war/ | INFO [EARDeployer] Started J2EE application: file:/home/francescom/development/jboss-4.0.2/server/all/deploy/aopexample.ear | and when I connected to http://localhost:8080/aopexample/index.jsp I had the following results: anonymous wrote : | 15:20:10,036 INFO [STDOUT] **** ExampleValue empty Constructor | 15:20:10,043 INFO [STDOUT] **** ExampleValue.getMessage() | 15:20:15,121 INFO [STDOUT] **** EarExampleServlet.service() | 15:20:15,316 INFO [STDOUT] *** ExampleSessionBean.getValue() | 15:20:15,317 INFO [STDOUT] **** ExampleValue String Constructor | 15:20:15,318 INFO [STDOUT] **** ExampleValue String Constructor | 15:20:15,377 INFO [STDOUT] **** ExampleValue.getMessage() | Neither ejbs nor servlets have been aop'ed. How is this possible if my ejbs3 work correctly (that should mean that transaction and security aspects has been succesfully installed). What is it transformations = true ? Where can I set it ? Thanks in advance for help milesif View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886810#3886810 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886810 |
From: <kab...@jb...> - 2005-07-27 16:59:36
|
http://docs.jboss.com/aop/1.3/aspect-framework/reference/en/html/running.html#jboss EJB3 does not do bytecode weaving, it just uses AOP for configuration View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886826#3886826 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886826 |
From: <ad...@jb...> - 2005-07-27 16:51:08
|
"rl...@jb..." wrote : ...this will give us a very similiar thirdparty folder as to what was being checked out from cvs. In this case, even if no eclipse classpath is generated, aren't we basically at the same point we are with the standard buildmagic build as far as classpath information is concerned? Yes, except that now we have more control over the versions, (and we will get even more control as the new build move forwards), something that was a nightmare when it was in a non-versionable module definition in CVSROOT/modules. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886857#3886857 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886857 |