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: <ani...@jb...> - 2006-07-06 16:42:56
|
"j2ee_junkie" wrote : I understand what you are saying and I am not necessarily disagreeing, but consider the following settings in jboss.xml | | | | <assembly-descriptor> | | <security-role> | | <role-name> | | <principal-name> | | </security-role> | | </assembly-descriptor> | | | | This maps a principal to a role in the deployment. Isn't this very similar to mapping a role to a role? | | cgriffith Agreed. This is how WL/WebSphere do it. I still think it may be wise to put it at the security domain level via an external configuration. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955937#3955937 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955937 |
|
From: <sco...@jb...> - 2006-07-06 16:38:11
|
Any significant refactoring should be a 2.0 release of jbossxb so just restoring the unmarshal(java.lang.String, org.jboss.xb.binding.ObjectModelFactory, org.jboss.xb.binding.metadata.unmarshalling.DocumentBinding) could be restored to simplify the current problem. The login-config.xml parsing problem is the same NSME error so restoring this to avoid having to patch two jbossas jar files is a better solution. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955934#3955934 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955934 |
|
From: <soh...@jb...> - 2006-07-06 16:33:57
|
Since it makes sense to associate this mapping at the security-domain level to be utilized at different layers of the app (not just ejb and web)(I am thinking Portal,SEAM, JBPM etc)
wouldn't it make sense to extend the configuration options in the login-config.xml so that you can specify the role/identity mappings kind of like this:
<application-policy name="security-domain-name">
<login-module>blahblah</login-module>
<role-mapping>
<application-role>whatever role from login module</application-role>
<deployment-role>whatever deployment role it should map to</deployment-role>
</role-mapping>
</application-policy>
Ofcourse this is just an example, and definitely needs better element names
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955932#3955932
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955932
|
|
From: <go...@ic...> - 2006-07-06 16:08:06
|
are you authenticating, did you set it to require auth? Did you set it to require TLS or ?WTLS?? When you connect to it on POP using telnet, can you issue the commands to list a users mail? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955923#3955923 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955923 |
|
From: wolfc <do-...@jb...> - 2006-07-06 16:00:58
|
Okay thanks. For the moment I'll just implement it with the 4 basic methods being optional. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955920#3955920 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955920 |
|
From: <hei...@jb...> - 2006-07-06 15:52:31
|
anonymous wrote : | but the best solution would seem to be a patch to the jboss-system.jar that made the call to the unmarshal(java.lang.String, org.jboss.xb.binding.ObjectModelFactory, java.lang.Object) variation explicit. | I agree, it probably makes most sense to replace these calls. But if we chose this way i'd say we reinstate the DocumentBinding for the next XB release and stick to it until the next AS will be released. The problem on the WS side is, that we can't communicate differrent XB versions for different environments. And since we offer drop in replacements for the most current AS (different release cycles), we need XB to align to this strategy. I understand that the refactoring needs to be done. But what difference does it make to postpone it until the next AS release? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955919#3955919 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955919 |
|
From: <sco...@jb...> - 2006-07-06 15:51:55
|
An FYI on the glassfish management api: https://glassfish.dev.java.net/nonav/javaee5/amx/amx.html View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955917#3955917 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955917 |
|
From: j2ee_junkie <do-...@jb...> - 2006-07-06 15:50:50
|
I understand what you are saying and I am not necessarily disagreeing, but consider the following settings in jboss.xml | <assembly-descriptor> | <security-role> | <role-name> | <principal-name> | </security-role> | </assembly-descriptor> | This maps a principal to a role in the deployment. Isn't this very similar to mapping a role to a role? cgriffith View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955916#3955916 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955916 |
|
From: <ani...@jb...> - 2006-07-06 15:41:33
|
"j2ee_junkie" wrote : | If it can be seen that this is a deployment issue, and if web.xml or ejb-jar.xml do not cover these issues, then I would think that the jboss.xml file would need to contain this mapping. | Cannot include the mapping in the jboss DD because it will be like tying the mapping to a layer(web/ejb) when it should be at the security domain level for multple layers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955912#3955912 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955912 |
|
From: j2ee_junkie <do-...@jb...> - 2006-07-06 15:33:27
|
Anil, Although this does not answer your question... Consider the current case where a developer of a j2ee component references some other component. This is done by name, correct? Then the deployer is resonsible for mapping between the application used name and the deployment environment name. So my point is that I would see this as a deployment issue with a need to modify to the ejb-jar.xml and web.xml descriptors. Of course that may not be possible. If it can be seen that this is a deployment issue, and if web.xml or ejb-jar.xml do not cover these issues, then I would think that the jboss.xml file would need to contain this mapping. Am I way off base? cgriffith View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955909#3955909 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955909 |
|
From: tomy82 <do-...@jb...> - 2006-07-06 15:29:49
|
"dajevtic" wrote :
| Since I am using jboss-seam I hope I haven't forgotten anything.
| If I did, sorry, I'll post the remaining things if needed.
Could you please tell me how you've implemented this Schedule with Seam...
I keep having this error coming back:
com.sun.facelets.FaceletViewHandler handleRenderException
| SEVERE: Error Rendering View[/home.xhtml]
| javax.faces.el.PropertyNotFoundException: /home.xhtml @36,123 value="#{scheduleHandler.model}": Bean: $Proxy281, property: model
| at com.sun.facelets.el.LegacyValueBinding.getValue(LegacyValueBinding.java:58)
| at org.apache.myfaces.custom.schedule.util.ScheduleUtil.getObjectProperty(ScheduleUtil.java:268)
| at org.apache.myfaces.custom.schedule.UISchedule.getValue(UISchedule.java:263)
| at org.apache.myfaces.custom.schedule.UISchedule.getModel(UISchedule.java:228)
| at org.apache.myfaces.custom.schedule.renderer.ScheduleDelegatingRenderer.getDelegateRenderer(ScheduleDelegatingRenderer.java:94)
| at org.apache.myfaces.custom.schedule.renderer.ScheduleDelegatingRenderer.encodeBegin(ScheduleDelegatingRenderer.java:67)
| at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:512)
| at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:232)
| at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:239)
| at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:239)
| at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:554)
| at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
| at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.seam.servlet.SeamRedirectFilter.doFilter(SeamRedirectFilter.java:30)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| at java.lang.Thread.run(Thread.java:613)
|
Could you show me what your Bean looks like!
Thank you very much!
Thomas
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955908#3955908
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955908
|
|
From: <sco...@jb...> - 2006-07-06 14:57:38
|
All of the lifecycle calls are optional in the legacy jmx service contract as an mbean is wrapped in a proxy that only delegates the lifecycle calls if there is a mapping. The underlying bean may not have a corresponding lifecycle method, or it may map the method to another name (start mapped to go for example). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955889#3955889 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955889 |
|
From: wolfc <do-...@jb...> - 2006-07-06 14:51:27
|
Got lifecycle working. Are any of the lifecycle methods (create, start, stop, destroy) optional? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955885#3955885 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955885 |
|
From: <ani...@jb...> - 2006-07-06 14:50:38
|
Many users would like to map the application roles that are derived out of the Jaas authentication process to declarative roles (defined in various deployment descriptors like web.xml). There is a feature request that has been implemented with an optional login module called as the RoleMappingLoginModule. http://jira.jboss.com/jira/browse/JBAS-3323 This works perfectly fine for majority of the cases except for one, when there are login modules with the control flag of "Sufficient" and no "required/requisite" modules. The problem is that the optional RoleMapping LM will never be reached, if authentication succeeds. Given this, there are alternatives: 1) The user can override the getRoleSets method of any JBoss standard LM. 2) The Abstract Server LM base class can be retroffited with role mapping logic. Both the options hold merit in various usecases. Option 2 can solve majority of the user needs, but the issue is that we cannot tie the logic to a single store for role map, like the properties file as done by the RoleMappingLoginModule. This can require a override in all LM if users need to do it. The right solution is logic should be added after the Jaas authentication process is completed. This will decouple the process from the login module life cycle. The above discussion holds true mainly for JBoss 4.0.x As I see, I think we will need to add the logic into the JaasSecurityManager. The question is should we get the rolemapping setup for a particular security domain, by peeking into the jaas configuration. I welcome your thoughts on this topic. For JBoss 5.x, the Security SPI as discussed in the following forum thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=81097 will handle the Role Mapping logic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955884#3955884 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955884 |
|
From: <sco...@jb...> - 2006-07-06 14:41:39
|
The location of the ObjectModelFactorySimpleSubDeployerSupport call that is failing is:
| Caused by: java.lang.NoSuchMethodError: org.jboss.xb.binding.Unmarshaller.unmars
| hal(Ljava/lang/String;Lorg/jboss/xb/binding/ObjectModelFactory;Lorg/jboss/xb/bin
| ding/metadata/unmarshalling/DocumentBinding;)Ljava/lang/Object;
| at org.jboss.deployment.ObjectModelFactorySimpleSubDeployerSupport.parse
| MetaData(ObjectModelFactorySimpleSubDeployerSupport.java:52)
| ... 68 more
|
The parse of the conf/login-config.xml is also failing. The previous 1.0.0.CR4 version had the following methods:
| public abstract java.lang.Object unmarshal(java.lang.String, org.jboss.xb.binding.ObjectModelFactory, org.jboss.xb.binding.metadata.unmarshalling.DocumentBinding) throws org.jboss.xb.binding.JBossXBException;
|
| public abstract java.lang.Object unmarshal(java.lang.String, org.jboss.xb.binding.ObjectModelFactory, java.lang.Object) throws org.jboss.xb.binding.JBossXBException;
|
|
It would seem that call like unmarshaller.unmarshal(url.toString(), factory, null) should not even be compiling as its ambiguous. Obviously its binding to the DocumentBinding variation as can be seen via javap -c:
| [starksm@banshee9100 lib]$ javap -classpath 'jboss-jmx.jar;jboss-system.jar' -c
| org.jboss.deployment.ObjectModelFactorySimpleSubDeployerSupport
| Compiled from "ObjectModelFactorySimpleSubDeployerSupport.java"
| public abstract class org.jboss.deployment.ObjectModelFactorySimpleSubDeployerSupport extends org.jboss.deployment.SimpleSubDeployerSupport{
| ...
|
| protected void parseMetaData(org.jboss.deployment.DeploymentInfo, java.net.URL)
| throws org.jboss.deployment.DeploymentException;
| Code:
| 0: invokestatic #2; //Method org/jboss/xb/binding/UnmarshallerFactory.newInstance:()Lorg/jboss/xb/binding/UnmarshallerFactory;
| 3: invokevirtual #3; //Method org/jboss/xb/binding/UnmarshallerFactory.newUnmarshaller:()Lorg/jboss/xb/binding/Unmarshaller;
| 6: astore_3
| 7: aload_0
| 8: invokevirtual #4; //Method getObjectModelFactory:()Lorg/jboss/xb/binding/ObjectModelFactory;
| 11: astore 4
| 13: aload_1
| 14: aload_3
| 15: aload_2
| 16: invokevirtual #5; //Method java/net/URL.toString:()Ljava/lang/String;
| 19: aload 4
| 21: aconst_null
| 22: invokeinterface #6, 4; //InterfaceMethod org/jboss/xb/binding/Unmarshal
| ler.unmarshal:(Ljava/lang/String;Lorg/jboss/xb/binding/ObjectModelFactory;Lorg/jboss/xb/binding/metadata/unmarshalling/DocumentBinding;)Ljava/lang/Object;
| 27: putfield #7; //Field org/jboss/deployment/DeploymentInfo.metaData:Ljava/lang/Object;
| 30: goto 57
| 33: astore_3
| 34: new #9; //class java/lang/StringBuffer
| 37: dup
| 38: invokespecial #10; //Method java/lang/StringBuffer."<init>":()V
| 41: ldc #11; //String Error parsing meta data
| 43: invokevirtual #12; //Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
| 46: aload_2
| 47: invokevirtual #13; //Method java/lang/StringBuffer.append:(Ljava/lang/Object;)Ljava/lang/StringBuffer;
| 50: invokevirtual #14; //Method java/lang/StringBuffer.toString:()Ljava/lang/String;
| 53: aload_3
| 54: invokestatic #15; //Method org/jboss/deployment/DeploymentException.rethrowAsDeploymentException:(Ljava/lang/String;Ljava/lang/Throwable;)V
| 57: return
| Exception table:
| from to target type
| 0 30 33 Class java/lang/Throwable
|
|
| }
|
Without going through the language spec I can't say why this should have failed to compile, but the best solution would seem to be a patch to the jboss-system.jar that made the call to the unmarshal(java.lang.String, org.jboss.xb.binding.ObjectModelFactory, java.lang.Object) variation explicit. This way either jbossxb version could be used. Until I see why the conf/login-config.xml is failing to parse I don't know if that is a sufficient path. Most likely a patch to the jbossx.jar will also be required.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955875#3955875
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955875
|
|
From: vickyk <do-...@jb...> - 2006-07-06 14:11:46
|
anonymous wrote : | Consider two deployment units: A and B, where B depends on A. B holds references to classes from A. Now A gets redeployed -> A2. You'll notice, that B is invalid, cause it still references instances of old A's classloader. You're getting ClassCastExceptions. B has to be redeployed -> B2. B2 will create new instances of A2's new classes. | This looks an interesting case, you have the classes in B holding the reference from A . I am not sure if this needs to be considered for fix, as you have a workaround for this. Regards Vicky View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955858#3955858 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955858 |
|
From: hengels <do-...@jb...> - 2006-07-06 13:10:29
|
Hm, are we solving the class compatibility problems with dependent deployment units, then? Consider two deployment units: A and B, where B depends on A. B holds references to classes from A. Now A gets redeployed -> A2. You'll notice, that B is invalid, cause it still references instances of old A's classloader. You're getting ClassCastExceptions. B has to be redeployed -> B2. B2 will create new instances of A2's new classes. Holger View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955839#3955839 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955839 |
|
From: <kab...@jb...> - 2006-07-06 13:10:29
|
Actually the above ties in with the JBAOP-236 subtask of JBAOP-88 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955838#3955838 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955838 |
|
From: <rob...@jb...> - 2006-07-06 13:09:55
|
AbelMJ: I've looked at your .jar files in your project and found that they don't contain the typical ejb xml descriptors. As of right now, my plugin works as follows: If META-INF/ejb-jar.xml is found, it's an ejb jar. If WEB-INF/web.xml is found, it's a web archive If META-INF/application.xml is found, it is an ear archive. If none are found, a "launchable artifact" is never created. If multiple are found, It's undetermined which factory will be used but it doesn't matter for most situations of simple deploy because htey all deploy the same way (through simple system copy). They only differ in their 'verify' functionality. I'm very open to suggestions on how to better discover what type of module is being deployed. One suggestion I've heard is to just have a backup "launchable artifact" creater that will create some generic deployable / launchable artifact even if no descriptor is located. I'm quite open to other suggestions. In fact, I beseech the user community for them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955837#3955837 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955837 |
|
From: <kab...@jb...> - 2006-07-06 13:08:49
|
A comment here about splitting out the "lazy" stuff http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955835#3955835 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955836#3955836 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955836 |
|
From: <kab...@jb...> - 2006-07-06 13:05:29
|
I've made some changes to AspectBeanMetaDataFactory.
| <aop:aspect xmlns:aop="urn:jboss:aop-beans:1.0"
| name="InterceptedAdvice"
| class="org.jboss.test.microcontainer.support.CalledInterceptor"
| pointcut="execution(* $instanceof{org.jboss.test.microcontainer.support.SimpleBean}->*(..))">
| </aop:aspect>
|
has no dependencies and now becomes:
| <beanfactory name="InterceptedAdvice" class="org.jboss.test.microcontainer.support.CalledInterceptor"/>
|
| <bean name="InterceptedAdvice$Aspect" class="org.jboss.aop.microcontainer.beans.Aspect">
| <property name="advice"><inject bean="InterceptedAdvice"/></property>
| <property name="manager"><inject bean="AspectManager"/></property>
| </bean>
|
| <bean name="InterceptedBinding" class="org.jboss.aop.microcontainer.beans.AspectBinding">
| <property name="pointcut">execution(* $instanceof{org.jboss.test.microcontainer.support.SimpleBean}->*(..))</property>
| <property name="aspect"><inject bean="InterceptedAdvice$Aspect" property="definition"/></property>
| <property name="manager"><inject bean="AspectManager"/></property>
| </bean>
|
And the following
| <aop:aspect xmlns:aop="urn:jboss:aop-beans:1.0"
| name="InterceptedAdvice"
| class="org.jboss.test.microcontainer.support.InterceptorWithDependency"
| pointcut="execution(* $instanceof{org.jboss.test.microcontainer.support.SimpleBean}->*(..))">
| <property name="simpleBean"><inject bean="Dependency"/></property>
| </aop:aspect>
|
which has dependencies still becomes
| <beanfactory name="InterceptedAdvice" class="org.jboss.test.microcontainer.support.InterceptorWithDependency">
| <property name="simpleBean"><inject bean="Dependency"/></property>
|
| <!-- Enables the deployed AspectDefinition and injects into the AspectFactory -->
| <install bean="InterceptedAdvice$Aspect" method="install">
| <parameter><this/></parameter>
| </install>
|
| <!-- undeploys the AspectDefinition, so it is not available when updating the interceptors -->
| <uninstall bean="InterceptedAdvice$Aspect" method="uninstall"/>
|
| <!-- Same as before: removes and reinstalls the AdviceBinding/AdviceFactory with the new
| AspectDefinition/AspectFactory -->
| <install bean="InterceptedAdvice$AspectBinding" method="rebind">
| <parameter><inject bean="InterceptedAdvice$Aspect" property="definition"/></parameter>
| </install>
| </beanfactory>
|
| <bean name="InterceptedAdvice$Aspect" class="org.jboss.aop.microcontainer.prototype.Aspect">
| <property name="adviceBean">InterceptedAdvice</property>
| <property name="manager"><inject bean="AspectManager"/></property>
| </bean>
|
| <bean name="InterceptedAdvice$AspectBinding" class="org.jboss.aop.microcontainer.prototype.AspectBinding">
| <property name="pointcut">execution(* @org.jboss.test.microcontainer.support.Test->*(..))</property>
| <property name="aspect"><inject bean="InterceptedAdvice$Aspect" property="definition"/></property>
| <property name="manager"><inject bean="AspectManager"/></property>
| </bean>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955835#3955835
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955835
|
|
From: wolfc <do-...@jb...> - 2006-07-06 12:47:30
|
I'm looking at the following issues: http://jira.jboss.com/jira/browse/EJBTHREE-323 http://jira.jboss.com/jira/browse/EJBTHREE-606 http://jira.jboss.com/jira/browse/EJBTHREE-631 I have created some unit tests and to my surprise the @Service and @Management are working except for lifecycle calls (606). It appears that these are normally called by the the ServiceController, but this is a MBean. Currently I'm lost in the forest around MCKernelAbstraction & JMXKernelAbstraction, but @Management is dependant on JMX, right? If so 631 is unsolvable. Shall I resolve 323 as done? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955831#3955831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955831 |
|
From: <kab...@jb...> - 2006-07-06 10:35:10
|
Ignore my previous post, I'm able to discover the dependencies View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955800#3955800 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955800 |
|
From: <rac...@jb...> - 2006-07-06 09:36:25
|
Dear Messaging I was asked by Ryan to incorporate targets into the JBAS testsuite for running Messaging against the existing JBossMQ integration tests. I'm running into some problems with this task, and need your advice. So far, I have added a target (not yet committed) to testsuite/build.xml to: (i) create a 'messaging' configuration (ii) start up JBAS with that configuration (iii) run the JBossMQ tests against JBAS (iv) shut down JBAS (v) delete the 'messaging' configuration Setting up the 'messaging' configuration was based largely on mimicking the target release-admin.xml in the Messaging1.0.1 distribution, as well as replacing jboss-remoting.jar, jboss-serialization.jar, jboss-aop.jar and jboss-aspect-library.jar with the modified versions in the deploy directory. Some of the JBossMQ tests are passing without change, so I suspect that the test case execution classpath and configuration I have set up are close to being what they should be. The problem i'm having is that a number of the JBossMQ test cases test implementation-dependent aspects of JBossMQ, which may or may not have a counterpart in Messaging. For example, the test case CleanTopicRemovalTestCase: - creates a topic - publishes a message to the topic - checks the state of the JBossMQ service MessageCache - deletes the topic - checks the state of the JBossMQ service MessageCache - the expected result is that message cache count (after) = message cache count(before) -1 In order to produce a similar test case for Messaging, I would really need to know if a counterpart to MessageCache exists in Messaging, and whether that counterpart should exhibit the same behaviour. That question isn't easily answered, without looking in detail at the Messaging implementation and all the classes. So, i'm really uncertain as to what I should do here. A number of the JBossMQ test cases pass without change. Some fail for fairly simple reasons (e.g. user not defined), and these are easily fixed. Others fail because of implementation dependencies, as in the example I described, and are not so easily fixed. I'd like to ask your advice on this matter - for the short term goal of getting a subset of the integration tests up and running, what is the best approach to deciding which tests should be modified and retained and which discarded? On an unrelated point, the test cases will need to be modified (e.g. instances of object names changed from jboss.mq:service=DestinationManager to jboss.messaging:service=ServicePeer, for example). Should I create a new directory under testsuite/src/main/org/jboss/test, say messaging, to contain the new copies of the tests? Richard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955780#3955780 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955780 |
|
From: tueur_a_gage <do-...@jb...> - 2006-07-06 09:11:31
|
Hello I'm interresting to know which languages are supported by JBoss Portal. With the live demo I tried French, English and Spanish, Italian does'nt work.... I'm particulary interrested by UTF-16 language such as arabic and cyrilic. Is-it possible to use them ? thanks for your answer View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955767#3955767 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955767 |
1965 messages has been excluded from this view by a project administrator.
