October 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBossXB] - Marshalling Into java.util.properties

by anil.saldhana＠jboss.com

I tried using the jbxb marshalling into properties in conf/login-config.xml | <policy | xsi:schemaLocation="urn:jboss:security-config:5.0 resource:security-config_5_0 | .xsd" | xmlns="urn:jboss:security-config:5.0" | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> | | <application-policy name="TEST"> | <authentication> | <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" | flag="required"> | <module-option name="usersProperties">test-users.properties</module-option> | <module-option name="rolesProperties">test-roles.properties</module-option> | <module-option name="password-stacking">useFirstPass</module-option> | <module-option name="unauthenticatedIdentity">test-user</module-option> | </login-module> | </authentication> | <authorization> | <policy-module code="org.jboss.security.authorization.modules.JACCAuthorizationModule" flag="required"/> | </authorization> | <rolemapping> | <mapping-module code="org.jboss.security.mapping.providers.PolicyContextIdRoleMappingProvider"> | <module-option name="map" serialDataType="jbxb"> | <java:properties xmlns:java="urn:jboss:java-properties" | xsi:schemaLocation="urn:jboss:java-properties resource:java-properties_1_0.xsd"> | <java:property> | <java:key>jacc_principal2role_first_module_web.war</java:key> | <java:value>props/jacc_principal2role.ear.properties</java:value> | </java:property> | </java:properties> | </module-option> | </mapping-module> | </rolemapping> | </application-policy> | I see that on the setValue to ModuleOption, XB should have picked up the properties object, but it does not: | 2006-10-10 13:52:40,900 TRACE [org.jboss.security.authorization.config.SecurityConfigObjectModelFactory] newChild.RoleMappingInfo, mapping-module code: org.jbos | s.security.mapping.providers.PolicyContextIdRoleMappingProvider | 2006-10-10 13:52:40,900 TRACE [org.jboss.xb.binding.ObjectModelBuilder] accepted | urn:jboss:security-config:5.0:mapping-module | 2006-10-10 13:52:40,900 TRACE [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] | Exit startElement urn:jboss:security-config:5.0:mapping-module | 2006-10-10 13:52:40,900 TRACE [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] | Enter startElement urn:jboss:security-config:5.0:module-option | 2006-10-10 13:52:40,900 TRACE [org.jboss.security.authorization.config.SecurityConfigObjectModelFactory] newChild.MappingModuleEntry, localName: module-option | 2006-10-10 13:52:40,900 TRACE [org.jboss.security.authorization.config.SecurityConfigObjectModelFactory] newChild.MappingModuleEntry, module-option name: map | 2006-10-10 13:52:40,900 TRACE [org.jboss.xb.binding.ObjectModelBuilder] accepted | urn:jboss:security-config:5.0:module-option | 2006-10-10 13:52:40,900 TRACE [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] | Exit startElement urn:jboss:security-config:5.0:module-option | 2006-10-10 13:52:40,900 TRACE [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] | Enter startElement urn:jboss:java-properties:properties | 2006-10-10 13:52:40,900 TRACE [org.jboss.xb.binding.ObjectModelBuilder] ignored | urn:jboss:java-properties:java:properties | 2006-10-10 13:52:40,900 TRACE [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] | Exit startElement urn:jboss:java-properties:properties | It is ignoring the java:xxx elements. The JBossEntityResolver did resolve the java-properties_1_0.xsd schema succeefully. Anything obvious? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977351#3977351 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977351

19 years, 6 months

1
0
0 / 0

[Design of JBoss Admin Console] - Re: Moving admin-console out of jbossas/trunk

by charles.crouch＠jboss.com

Kabir recently posted to the dev list how he moved aop into its own project. I don't think we need to wait for any SVN migration, we can just do as he did: 1. svn mkdir https://svn.jboss.org/repos/jbossas/projects/admin-console 2. svn move https://svn.jboss.org/repos/jbossas/trunk/admin-console https://svn.jboss.org/repos/jbossas/projects/admin-console/trunk Then we need to get this building properly and running and tested as far as we can against HEAD of jbossas/trunk. Once we're happy we have something that runs (e.g. don't worry about test failures due to the read only nature of the JBossMQ configuration in the /all profile) we can tag it... svn copy https://svn.jboss.org/repos/jbossas/projects/admin-console/trunk https://svn.jboss.org/repos/jbossas/projects/admin-console/tags/JBossAdmi... -m "Tag of projects/admin-console for a 1.1 snapshot of the 'admin-console' project." After that we can take a look at adding support for JBoss Messaging. Cheers View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977350#3977350 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977350

19 years, 6 months

1
0
0 / 0

[Design of JBoss Admin Console] - Re: JBoss Admin console 1.1 snapshot

by charles.crouch＠jboss.com

Going back and finding a working revision of /trunk is a fruitless exercise due to the use of SNAPSHOT versions in thirdparty dependencies. For archival purposes only lets just tag the last revision which chhanged the Admin Console src: >From http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/admin-console/ it looks to be r57108, so lets do: svn copy -r 57108 https://svn.jboss.org/repos/jbossas/trunk https://svn.jboss.org/repos/jbossas/tags/JBossAdminConsole_1_1_SNAPSHOT -m "Tag of r57108 of jbossas/trunk for a 1.1 snapshot of the 'admin-console' project." Next step is to move the project out of /trunk, but lets discuss that here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=91371 Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977348#3977348 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977348

19 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: SIgnaficane of the ControllerMode ....

by vickyk

I have looked at all the links earlier. --http://docs.jboss.org/nightly/microkernel/docs/reference/en/html/ Are there any plans to have more details in the above link? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977347#3977347 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977347

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: To merge or not to merge?

by scott.stark＠jboss.org

This is what I was referring to previously about a unified api for traversing/merging the various scopes of data. This also intersects with the discussion on how overlapping annotation collections are merged. There is a tradeoff between having a framework that generally can build up something like a JndiBinding vs having to write the merge logic in terms of delgating accessors. Given n scopes of data of types T1...Tn, and a unfied type T (which usually would be amongst T1...Tn I would expect), the ideal thing would be to have the framework piece together the type instances so that T.x was a merge ot the T1...Tn sources of the property x. How to write this without significat restrictions on how the types relates seems non-trivial at this point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977345#3977345 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977345

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: MetaData hierarchy, a problem with annotations

by bill.burke＠jboss.com

This "deployment level" is a JBoss specific thing right? Shouldn't these types of annotations be driven by a metamodel rather than annotations? This way an annotation processor augments existing metamodel data. I ran into this problem as well, so what I did was process XML and annotations separately. What I should have done was combine them into one meta object model and work from there... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977331#3977331 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977331

19 years, 6 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Unable to directly manipulate the FROM address in a Mail obj

by sappenin

Hey All -- Looking for some simply feedback. Is there any good reason that the org.jboss.mail.message.Mail object does not expose the "from" field more publicly (or other fields for that matter)? As it stands now, the "from" field is private, so I can't manipulate it directly. Adding a header to the Mail object merely "appends" another From: header to the list of existing headers, which means there would be two FROM addresses (which I don't want). Does anyone have any input on exposing the FROM field on the Mail object via a public setter? My use case is below. USE CASE ------------ I Create a user-account called "admin" in JBCS. Login to webmail, select the "admin" alias, and send a message from "admin" to a local user. In my Mail listener, the "FROM" address is "admin@localhost" because the MailAddress.parseSMTPStyle() function uses "localhost" as the default domain if no domain is detected. I want to be able to catch this in my mail-listener, and if necessary, "adjust" the FROM address to be "admin(a)example.com", or some other domain in my domain group. Using the public FROM setter, I merely update the FROM address, and process the Mail per usual --> the Mail object will be used to create a MessageData object, thus delivering the message to the intended recipient, with a proper TO address. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977329#3977329 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977329

19 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: SIgnaficane of the ControllerMode ....

by alesj

- http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMicrocontainer View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977324#3977324 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977324

19 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: SIgnaficane of the ControllerMode ....

by alesj

- http://labs.jboss.com/portal/jbossmc/?prjlist=false - http://docs.jboss.org/nightly/microkernel/docs/reference/en/html/ - http://docs.jboss.org/nightly/microkernel/docs/gettingstarted/en/html/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977321#3977321 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977321

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Dashboard & Personalization proposal

by julien＠jboss.com

It is possible although we will not implement the use case as dashboard are really private (doing def.getCustomization("userA.page").getCustomization("userB.anotherpage"); ) We will certainly consider it when we will have a richer model with a collaboration engine. "andy.miller(a)jboss.com" wrote : Julien, | | Have you thought about the use case where a user would want to share his customizations with another user? Let's say user A, customizes a specific portlet, shows it to another user, user B, and that user says they really like that and it fits my needs as well, so user A is able to share it with user B. | | I supposed this concept could happen with an entire private page as well. Especially, in a small team setting where the same customizations are applicable to a handful of users working colaboratively. | | Andy View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977320#3977320 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977320

19 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2006