jboss-dev-forums Mailing List for JBoss Community (Page 509)

Brought to you by: newtonm, nihility, patriot1burke, starksm

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

Flat | Threaded

<< < 1 .. 507 508 509 510 511 .. 584 > >> (Page 509 of 584)

[Jboss-dev-forums] [Design of JBoss Portal] - Question on UserInterceptor

From: yxyang <nu...@jb...> - 2005-07-25 13:39:36

Hi, 

I am reading the UserInterceptor class. It seems that for each HTTP request, user database is accessed to get the UserImpl object. Why is this needed even though the userImpl could be already stored in the userContext which is stored in the session?

regards
yang
anonymous wrote : 
  |       // Get the id
  |       String remoteUser = req.getRemoteUser();
  | 
  |       // Fetch user
  |       UserImpl user =  null;
  |       try
  |       {
  |          if (remoteUser != null)
  |          {
  |             Session session = getSession();
  |             Query query = session.createQuery("from UserImpl as u where u.userName=?");
  |             query.setString(0, remoteUser);
  |             user = (UserImpl)query.uniqueResult();
  |          }
  |       }
  |       catch (Exception e)
  |       {
  |          log.error("Cannot fetch user from hibernate", e);
  |       }
  | 
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886381#3886381

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886381

[Jboss-dev-forums] [Design of Security on JBoss] - Re: Generalizing the JACC service

From: tcherel <nu...@jb...> - 2005-07-25 13:07:29

There is a very good chance that you guys already thought about that, but just in case....

I think that the way you can dynamically (at login time) define the roles of a user by creating a custom JAAS login module is very useful.
An very often, this is all that is needed.
I understand that a custom JACC provider can do more, but I think it will be a pain if a full blown provider (or a full blown set of custom JACC policy) has to be defined if the only thing that is needed is to be able to specify what are the roles of a given user.

May be the future default JBoss JACC provider should have multiple extension points (JBoss specific) where a user can simply overwrite the way roles are retrieved for a user, the way roles are associated to resources and the way permissions are checked (or something like that).
Users will then be able to easily "pick and choose" which part of the default JACC provider they want to customize for their needs.

Thomas


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886377#3886377

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886377

[Jboss-dev-forums] [Design of Mail Services] - Re: deploy problems?

From: mikezzz <nu...@jb...> - 2005-07-25 12:07:48

Run 'build create-key'.  This will create a simple default key-store.  Or you can disable TLS in the jboss-service.xml file.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886366#3886366

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886366

[Jboss-dev-forums] [Design of Management Features on JBoss] - servlet applet communication

From: eporcelli <nu...@jb...> - 2005-07-25 10:25:45

I can call a servlet from an applet on tomcat standalone using code like this (i want to call doPost method on servlet)

 URLConnection con = getServletConnection(); 
 OutputStream outstream = con.getOutputStream();
 ObjectOutputStream oos = new ObjectOutputStream(outstream);
 oos.writeObject(req);

but when i use jboss embedded tomcat this don't work (i debug the servlet using eclipse/lomboz enviroment and the breakpoint on doPost is never reached)

Someone can help me?


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886354#3886354

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886354

[Jboss-dev-forums] [Other JBoss Development Design] - Extracting JBossMQ

From: Node <nu...@jb...> - 2005-07-25 10:19:48

I am in the process of extracting JBossMQ so that we can use it without having to install the whole application server - I ran the application server after running the standalone JBossMQ script, and got a list of all classes loaded, I have found which jar files all of these classes are in except for one:

org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory

I havent found this one, does anybody know which jar file it is in?

Also do you know which of the xml, .propreties etc, files I would need for it to work?

Thanks.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886353#3886353

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886353

[Jboss-dev-forums] [Design of Security on JBoss] - Re: Generalizing the JACC service

From: abelapurkar <nu...@jb...> - 2005-07-25 09:47:35

I essentially started with the "in-memory" JACC provider that comes out-of-the-box with JBoss 4.0.2 and enhanced it to include the mapping between the JACC Permission classes and the corresponding XACML constructs. (So, for example, the commit method was enhanced to include code for generating the XACML policy sets etc.)

In my version of the provider, I've used the open source XACML implementation from Sun (http://sunxacml.sourceforge.net) as the underlying framework for the XACML constructs. This framework
provides, out-of-the-box, a very simple file-based policy finder module (intended for use only as a sample). I?m using this finder in my JACC provider. So, the XACML policy set(s) for applications are written out into flat files during app deployment; these files are then searched at policy enforcement time. A file-based approach is clearly not the most performant/scalable of options, and needs to be reworked.

An aside: while testing my provider, I noticed that unchecked WebUserDataPermission instances were not being generated for a deployed application as expected. Briefly, the problem seems to be as follows. Line # 180 of the file "WebPermissionMapping.java" reads while (roles.hasNext()). However, this loop is always skipped, since the roles Iterator is never re-initialized after the previous loop (line # 157) has completed its run.

At first glance, it would seem that the way to fix this is to change line #179 to read roles = info.getTransportMethods(). However, after having made that change, I found that unchecked WebUserDataPermission instances were certainly getting generated, but not all of them seemed to be quite the right ones I was expecting. I've not had a chance to follow up on this point since. This needs to be revisited, to confirm whether there is indeed a problem.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886350#3886350

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886350

[Jboss-dev-forums] [Design of Mail Services] - deploy problems?

From: jeff87 <nu...@jb...> - 2005-07-25 03:29:50

Hi guys. I got the latest code today and I'm getting some errors. They happen when I use either dev-deploy or deploy. I don't recall changing anything configuration wise with my JBoss 4.0.2 installation. Any ideas?

23:18:45,478 INFO  [EARDeployer] Init J2EE application: file:/C:/java/jboss-4.0.2/server/default/deploy/mail.ear
  | 23:18:46,881 INFO  [ServiceConfigurator] Problem configuring service jboss.security:domain=Mail+SSL,service=JaasSecurityDomain
  | org.jboss.deployment.DeploymentException: Exception setting attribute javax.management.Attribute: name=KeyStoreURL value=mailkey.store on mbean jboss.security:domain=Mail+SSL,service=JaasSecurityDomain; - nested throwable: (java.net.MalformedURLException: Failed to find url=mailkey.store as a URL, file or resource)
  | 	at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:573)
  | 	at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:275)
  | 	at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:164)
  | 	at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:118)
  | 	at org.jboss.system.ServiceController.install(ServiceController.java:202)
  | 	at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:324)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
  | 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
  | 	at $Proxy4.install(Unknown Source)
  | 	at org.jboss.deployment.SARDeployer.create(SARDeployer.java:220)
  | 	at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918)
  | 	at org.jboss.deployment.MainDeployer.create(MainDeployer.java:910)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
  | 	at sun.reflect.GeneratedMethodAccessor51.invoke(Unknown Source)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:324)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
  | 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:121)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
  | 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
  | 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
  | 	at $Proxy8.deploy(Unknown Source)
  | 	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:325)
  | 	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:501)
  | 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:204)
  | 	at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:277)
  | 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:272)
  | 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:222)
  | 	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:324)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
  | 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:897)
  | 	at $Proxy0.start(Unknown Source)
  | 	at org.jboss.system.ServiceController.start(ServiceController.java:418)
  | 	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:324)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
  | 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
  | 	at $Proxy4.start(Unknown Source)
  | 	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:273)
  | 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:964)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:775)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
  | 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:722)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:324)
  | 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
  | 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:121)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
  | 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
  | 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
  | 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
  | 	at $Proxy5.deploy(Unknown Source)
  | 	at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:434)
  | 	at org.jboss.system.server.ServerImpl.start(ServerImpl.java:315)
  | 	at org.jboss.Main.boot(Main.java:195)
  | 	at org.jboss.Main$1.run(Main.java:463)
  | 	at java.lang.Thread.run(Thread.java:534)
  | Caused by: java.net.MalformedURLException: Failed to find url=mailkey.store as a URL, file or resource
  | 	at org.jboss.security.plugins.JaasSecurityDomain.validateStoreURL(JaasSecurityDomain.java:551)
  | 	at org.jboss.security.plugins.JaasSecurityDomain.setKeyStoreURL(JaasSecurityDomain.java:221)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:324)
  | 	at org.jboss.mx.interceptor.AttributeDispatcher.invoke(AttributeDispatcher.java:121)
  | 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
  | 	at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:88)
  | 	at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:61)
  | 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
  | 	at org.jboss.mx.server.AbstractMBeanInvoker.setAttribute(AbstractMBeanInvoker.java:446)
  | 	at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:593)
  | 	at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:569)
  | 	... 83 more

Thanks,
Jeff

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886289#3886289

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886289

[Jboss-dev-forums] [Design of Mail Services] - virtual domains

From: SunFire <nu...@jb...> - 2005-07-25 02:57:45

Hi there,

I just started to play around with the JBMAIL system a few days ago and I think it has a hugh potential. :)

But I have a question I could't find answer to it in the wiki:

Are you going to seperate local domains from virtual domains or how are you going to hande multidomains in general? In other un*x based MTAs (e.g. qmail) the reason for having local and virtual domains is so that the locals can be delivered to system users mailboxes (may it be ~/.maildir or some spools) and virtuals are going into a different storage system (e.g. vpopmail) where they can be retrieved via pop/imap. Since JBMAIL is not a MTA bound to un*x or windoze you don't have "real" system users by default. Would't it seem more native to the approch to create a unified multirealm system where a realm may have n-domains associated with it as well as n-users in it. In a realm a username has to be unique as well as a domain name. Two realms can have the same accountnames but domains need to be unique in the entire system.

Since its a little abstract here is a little sample structure:

  | <realms>
  |     <realm
  |         mailbox_impl="com.jboss.mail.x.mailbox.HBImpl" //user Hibernate implemantation to store mailboxes
  |         userrepos_impl="com.jboss.mail.x.userrepository.XMLFileImpl">  //get useraccounts from this file
  |         <domains>
  |             <domain>test.com</domain>
  |             <domain>testtest.com</domain>
  |         </domains>
  |         <users>
  |             <user>
  |                 <login>john.doe</login>
  |                 <password>verysecret</password>
  |             </user>
  |             <user>
  |                 <login>zoe.jane</login>
  |                 <password>evenmoresecret</password>
  |             </user>
  |         </users>
  |     </realm>
  |     <realm
  |         mailbox_impl="com.jboss.mail.x.mailbox.SystemMaildirImpl"  //use a .maildir implementation to store the mailbox
  |         userrepos_impl="com.jboss.mail.x.userrepository.ShadowPasswordImpl">  //use the system account implementaion to get accountnames for this realm
  |         <domains>
  |             <domain>localhost</domain>
  |             <domain>hostname.domain</domain>
  |         </domains>
  |         <users/>
  |     </realm>
  | </realms>
Just a very basic idea. Mail routing, header rewriteing and other fancy stuff could be configured on a per realm, per domain or per user base. User accounts/credentials could also be stored different per realm since it has only a well defined interfaces and implementations could ba a simple xml file, ldap, unix systemaccounts, etc... same is true for the mailboxes but this is allready in the makeing as far as I can see.
For user authentication or to receive a mail a protocol (e.g. SMTP) could parse the domain part of a username like zoe...@lo... and ask a realm manager if there is a realm for the domain like this:
RealmIF realm = realmManager.getRealmByDomain(localhost.com)
and if realm != null try to get an user interface 
UserIF user = realm.getUserByName(zoe.jane);
if user != null we know the user is ok and maybe get his mailbox, password or other attributes our protocol may need
MailboxIF mailbox = user.getMailbox()

It would also eliminate "alias domains" since all domains that are associated with a realm are "real" and are able to receive, send, authenticate the users in the realm (depending in the way the interfaces/configurationattributes are designed this could change and all but 1 domain in a realm would be "aliases" with different treatment...).

A mailservice hosting provider would be able to use any userrepository implementation to hook one of his customers hosted realms with domain ldapuser.com up to his customers existing LDAP server and use a local storage engine to store all the users mail on his ueberstoragearray. Tadaaa, his customer would be able to have a nice and neat hosted mailsolution available and the only thing the customer needs to maintain is his good 'ol ldap server to create/modify users.

Don't know if this makes sense or not but the separation of local and virtual domains is something that bothered me so many times in the past and could be done so nicley if you just use different storage/repository implementations for users and mailboxes. :)

Cheers, Thorsten

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886287#3886287

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886287

[Jboss-dev-forums] [Design of JBossXB] - Unmarshalling without specifying the top schema

From: <sco...@jb...> - 2005-07-24 22:30:54

One last issue with integrating the jbxb framework into the legacy SARDeployer is having to know the schema of the document root passed to the jbxb Unmarshaller. Since the SARDeployer does not use the jbxb Unmarshaller for the jboss-service.xml document (in the future it will), it ends up having to parse the content of an attribute of serialDataType="jbxb" without any knowledge of the associated schema. For example, the Bindings attribute in this example jboss-service.xml:

  | <server>
  |    <!-- A self-contained dynamic login configuration deployment
  |    -->
  |    <mbean code="org.jboss.naming.JNDIBindingService"
  |          name="jboss.tests:service=JNDIBindingService">
  |       <attribute name="Bindings" serialDataType="jbxb">
  |          <jndi:bindings
  |             xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
  |             xmlns:jndi="urn:jboss:jndi-binding-service"
  |             xs:schemaLocation="urn:jboss:jndi-binding-service jndi-binding-service_1_0.xsd"
  |             >
  |             <jndi:binding name="ctx1/key1">
  |                <jndi:value>value1</jndi:value>
  |             </jndi:binding>
  |             <jndi:binding name="ctx1/user.home">
  |                <jndi:value replace="false" >${user.home}</jndi:value>
  |             </jndi:binding>
  |             <jndi:binding name="ctx1/key2">
  |                <jndi:value type="java.net.URL">http://www.jboss.org</jndi:value>
  |             </jndi:binding>
  |             <jndi:binding name="ctx2/key1">
  |                <custom:properties xmlns:custom="urn:jboss:custom-object-binding"
  |                   xs:schemaLocation="urn:jboss:custom-object-binding custom-object-binding.xsd">
  |                   <custom:property>
  |                      <custom:key>key1</custom:key>
  |                      <custom:value>value1</custom:value>
  |                   </custom:property>
  |                   <custom:property>
  |                      <custom:key>key2</custom:key>
  |                      <custom:value>value2</custom:value>
  |                   </custom:property>
  |                </custom:properties>
  |             </jndi:binding>
  | 
  |             <jndi:binding name="hosts/localhost">
  |                <jndi:value editor="org.jboss.util.propertyeditor.InetAddressEditor">
  |                   127.0.0.1
  |                </jndi:value>
  |             </jndi:binding>
  | 
  |          </jndi:bindings>
  |       </attribute>
  |    </mbean>
  | 
  | </server>
  | 

I added support for this by doing a query to the schema resolver following a failure to find a root element current binding to the SundayContentHandler.startElement:


  |    public void startElement(String namespaceURI,
  |                             String localName,
  |                             String qName,
  |                             Attributes atts,
  |                             XSTypeDefinition type)
  |    {
  |       QName startName = localName.length() == 0 ? new QName(qName) : new QName(namespaceURI, localName);
  |       ElementBinding binding = null;
  | 
  |       ElementBinding parentBinding = null;
  |       if(elementStack.isEmpty())
  |       {
  |          binding = schema.getElement(startName);
  |          if( binding == null )
  |          {
  |             /* This can happen when an empty SchemaBinding was used to kick
  |             start the unmarshalling. The actual document schema needs to be
  |             obtained based on the first element's namespace.
  |             */
  |             String schemaLocation = atts.getValue(
  |                XMLConstants.W3C_XML_SCHEMA_INSTANCE_NS_URI,
  |                "schemaLocation");
  |             SchemaBinding nextSchema = schema.resolve(namespaceURI, localName,
  |                schema.getBaseURI(), schemaLocation);
  |             if( nextSchema != null )
  |                binding = nextSchema.getElement(startName);
  |          }
  |       }
  | 

Using this I can start with an empty SchemaBinding with a SchemaResolver to parse the jndi:bindings content:

  |       InputStream is2 = xml content of jndi-bindings element;
  | 
  |       SchemaBinding schemaBinding = new SchemaBinding();
  |       DefaultSchemaResolver resolver = new DefaultSchemaResolver(new JBossEntityResolver());
  |       schemaBinding.setSchemaResolver(resolver);
  |       URL url = Thread.currentThread().getContextClassLoader().getResource("xml/naming/");
  |       schemaBinding.setBaseURI(url.toString());
  |       Unmarshaller unmarshaller = UnmarshallerFactory.newInstance().newUnmarshaller();
  |       JNDIBindings bindings = (JNDIBindings) unmarshaller.unmarshal(is2, schemaBinding);
  | 
  | 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886276#3886276

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886276

[Jboss-dev-forums] [Design of JBossXB] - Adding support for system property reference replacement

From: <sco...@jb...> - 2005-07-24 06:35:45

We have so many places that depend on being able to replace system property references, this is going to be a roadblock to migrating configuration files over to parsing using the jbxb framework unless it also supports this.

It seems the best place to to this is the org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler (Alexey is still killing me with the naming).

We would need configuration to suppress the replacement. This could be done globally as well as on each attribute/element/text. Its not clear where to do this for the individual elements because other than text, we don't have a binding element.

I'm going to add the global configuration control to the schemaBindings and add this replacement support so I can finish integration of jbxb into the sar deployer.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886251#3886251

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886251

[Jboss-dev-forums] [Design of JBossXB] - ObjectModelFactory, schemas and type conversion

From: <sco...@jb...> - 2005-07-24 05:13:37

So I was looking at adding the ignoreUnresolvedFieldOrClass setting to the jbxb:schemaBindings as an element, the addition to the jndi-binding-service_1_0.xsd being:


  | <xs:schema version="1.0beta"
  |    attributeFormDefault="unqualified"
  |    elementFormDefault="qualified"
  |    xmlns:jbxb="http://www.jboss.org/xml/ns/jbxb"
  |    xmlns:xs="http://www.w3.org/2001/XMLSchema">
  |     <xs:annotation>
  |         <xs:documentation>The JBossXB schema customization
  |         elements</xs:documentation>
  |     </xs:annotation>
  |     <xs:element name="schemaBindings">
  |         <xs:annotation>
  |             <xs:documentation>This element defines default bindings for the
  |                 schema</xs:documentation>
  |         </xs:annotation>
  |         <xs:complexType>
  |             <!-- The child elements can be selected in any order. -->
  |             <xs:choice maxOccurs="unbounded" minOccurs="1">
  |                 <xs:element maxOccurs="1" minOccurs="0" ref="jbxb:package"/>
  | 
  |                <xs:element name="ignoreUnresolvedFieldOrClass" type="xs:boolean" default="true"
  |                   maxOccurs="1" minOccurs="0">
  |                   <xs:annotation>
  |                      <xs:documentation>The ignoreUnresolvedFieldOrClass specifies the behavior the parser chooses
  |                         when a field is not found in the parent class for a child value, or when an element does not have
  |                         any class assignement. If false, an exception will be thrown when either situation is encountered.
  |                         If true, the missing mapping is ignored and the parse continues.
  |                         </xs:documentation>
  |                   </xs:annotation>
  |                </xs:element>
  | 
  |             </xs:choice>
  |         </xs:complexType>
  |     </xs:element>
  | 

My first hack were the following changes to the XsdAnnotation$JbxbObjectModelFactory which was using a BooleanEditor as the older for the immutable boolean:

  |       public Object newChild(Object parent,
  |                              UnmarshallingContext ctx,
  |                              String namespaceURI,
  |                              String localName,
  |                              Attributes attrs)
  |       {
  |          Object child = null;
  |          // schemaBindings/ignoreUnresolvedFieldOrClass
  |          if( "ignoreUnresolvedFieldOrClass".equals(localName) )
  |          {
  |             // Just a place holder to get to the element text value
  |             child = new BooleanEditor();
  |          }
  | ...
  | 
  |       public void addChild(Object parent,
  |                            Object child,
  |                            UnmarshallingContext ctx,
  |                            String namespaceURI,
  |                            String localName)
  |       {
  |          
  |          // schemaBindings/ignoreUnresolvedFieldOrClass
  |          if( "ignoreUnresolvedFieldOrClass".equals(localName) )
  |          {
  |             BooleanEditor editor = (BooleanEditor) child;
  |             Boolean flag = (Boolean) editor.getValue();
  |             SchemaMetaData schema = (SchemaMetaData) parent;
  |             schema.setIgnoreUnresolvedFieldOrClass(flag.booleanValue());
  |          }
  | 
  | ...
  | 
  |       public void setValue(Object o, UnmarshallingContext ctx, String namespaceURI, String localName, String value)
  |       {
  |          if( o instanceof PropertyEditor )
  |          {
  |             PropertyEditor pe = (PropertyEditor) o;
  |             pe.setAsText(value);
  |          }
  |          else
  |          {
  |             log.warn("setValue: " + localName + "=" + value);
  |          }
  |       }
  | 

This can be handled much easier by just ignoring the ignoreUnresolvedFieldOrClass element and just converting its text content:


  |       public void setValue(Object o, UnmarshallingContext ctx, String namespaceURI, String localName, String value)
  |       {
  |          // schemaBindings/ignoreUnresolvedFieldOrClass
  |          if( "ignoreUnresolvedFieldOrClass".equals(localName) )
  |          {
  |             SchemaMetaData schema = (SchemaMetaData) o;
  |             Boolean flag = Boolean.valueOf(value);
  |             schema.setIgnoreUnresolvedFieldOrClass(flag.booleanValue());
  |          }
  |          else
  |          {
  |             log.warn("setValue: " + localName + "=" + value);
  |          }
  |       }
  | 

So it seems that there is something of a chicken and egg problem here. We are writing a sax based content handler to provide schema based xml/java mapping, but the jbxb elements themselves have a schema that a parser could use to perform basic conversions.

The base problem is that schemas still aren't well integrated into the javax.xml.* apis. Browsering through the jdk api, I see this javax.xml.validation package that at least knows about schemas, but appears to only really support validation of a document against the schema as shown by this fragment from the package docs:


  |     // parse an XML document into a DOM tree
  |     DocumentBuilder parser = DocumentBuilderFactory.newInstance().newDocumentBuilder();
  |     Document document = parser.parse(new File("instance.xml"));
  | 
  |     // create a SchemaFactory capable of understanding WXS schemas
  |     SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
  | 
  |     // load a WXS schema, represented by a Schema instance
  |     Source schemaFile = new StreamSource(new File("mySchema.xsd"));
  |     Schema schema = factory.newSchema(schemaFile);
  | 
  |     // create a Validator instance, which can be used to validate an instance document
  |     Validator validator = schema.newValidator();
  | 
  |     // validate the DOM tree
  |     try {
  |         validator.validate(new DOMSource(document));
  |     } catch (SAXException e) {
  |         // instance document is invalid!
  |     }
  | 

What is missing is an expansion of the sax parser apis to provide basic type conversion. There are some hooks in the javax.xml.validation like javax.xml.validation.TypeInfoProvider which provides org.w3c.dom.TypeInfo objects for the current attributes and elements.

So two questions:

1. Have we looked as using the javax.xml.validation to simplify/standardize the jbossxb impl?

2. Is it possible/worth it to have a GenericObjectModelFactory base that accepts a schema that automates or simplifies the amount of type conversion needed in an implementation like JaxbObjectModelFactory.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886246#3886246

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886246

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: Any projects for thin Client

From: <sco...@jb...> - 2005-07-24 04:05:09

What do you classify as a thin client? 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886245#3886245

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886245

[Jboss-dev-forums] [Design of Security on JBoss] - Generalizing the JACC service

From: <sco...@jb...> - 2005-07-24 02:48:05

So with the introduction of a pluggable authorization service for the j2ee 1.4 JACC requirement, we have opened up the possibility of having a very general authorization decision service. One main problem with the existing service is that it has no extensibility in terms of what permissions have been assigned to roles with a given context.

I talked to Abhijit Belapurkar at JavaOne about an implementation he did based on the XACML implementation from Sun and will work with him on at least getting this into the codebase as a testcase of alternate implementation to avoid the implementation details assumptions from leaking into the security aspects on top of JACC. I do want to look at moving to a default JACC provider that is built on XACML as the current overloading of the JAAS authentication phase to provide the declarative roles is too limiting.

This topic is the start of discussion on what needs to be done to move to the next generation of JACC implementation, and more generally the next generation of authorization service.

I don't expect to get too much done for a month as I'm focused on finalizing 4.0.3 and there is vacation time on the horizon.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886241#3886241

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886241

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: using CallLoggingInterceptor on existing web app

From: mlybarger <nu...@jb...> - 2005-07-23 12:02:54

i think the include was what was tripping me up on the examples.  i finally got it working!!

then i tried my servlet again to use the CallLoggingInterceptor.  Still no luck. Then I added a SimpleInterceptor right into my war.  Again, the war isn't aspectized, I'm using the load type weaving w/ jdk 1.5.  i started to get logging exceptions that seemd to be recursive aop calls to botht eh CallLoggingInterceptor and the SimpleInterceptor.  Then I completely shut off the CallLoggingInterceptor in the base-aop.xml.  Finally, i've got a simple interceptor working with my war!  

I'm still not sure why the CallLoggingInterceptor wasn't working.  I have debug log4j logging in my servlet configured explicitly as:

  | 	Logger LOG = Logger.getLogger( SnoopServlet.class );
  | 	{
  | 		BasicConfigurator.configure();
  | 		LOG.setLevel( Level.DEBUG );
  | 	}
  | 

i could see the debug logs from my servlet in the console, but nothing from the CallLoggingInterceptor.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886213#3886213

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886213

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

From: <sco...@jb...> - 2005-07-22 21:30:49

I have gone through the build and it looks good so far. I'm still running the unit tests.

The wiki page needs to be more strict about how the thirdparty contents are maintained. Generally, one should never update existing binaries. The only time this should be done is for snapshots on pre-release binaries.

The respository is also independent of any existing build, so the discussion about looking to the build/build-thirdparty.xml for the correct version is off target. Someone has version x.y.z of a binary and they simply need to know how to add this to the repository.

Its a independent choice to update the jboss-x.y/build/build-thirdparty.xml version to refer to the newer version. It may very well never happen, and there needs to be a jira issue that documents every change in thirdparty dependencies.

As for merging this, announce it on the dev list and give it 24 hours to sink in. If I find a major problem in running the testsuite I'll followup to the dev list announcement.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886171#3886171

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886171

[Jboss-dev-forums] [Design of JBoss Portal] - layouts and themes are working again in HEAD

From: mholzner <nu...@jb...> - 2005-07-22 19:07:03

I've done limited testing but a simple test case works . I'll do more testing and bug fixes next week 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886143#3886143

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886143

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

From: <rl...@jb...> - 2005-07-22 17:56:12

I have fully integrated all changes for the jboss thirdparty build on the branch Repo_Branch_4_0.  The output directories match up and testsuite results are consistent with a regular 4.0 build both with 1.4 and 1.5 compilers.

You can test this in the following fashion:

mkdir test
cd test
cvs co -r Repo_Branch_4_0 jboss-4.0.x
cd jboss-4.0
cd build
./build.sh

The first time build.sh is executed the dependencies will be downloaded from the repository.   Later attempts at building will not download the thirdparty dependencies unless the build-thirdparty.xml file has been updated.

In anticipation of migration to the thirdparty build I have set up a JBossBuild wiki page:  
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossBuild

The final step for deployment will be to merge this branch into the Branch_4_0.   

What is the best process for doing this (e.g. notifying people, lead time, day to do it...)?



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886122#3886122

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886122

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: Remote EJB and Mixins

From: rmcdonough <nu...@jb...> - 2005-07-22 11:34:55

anonymous wrote : So, is it possible to make an interface extend another one using introduction? 

I'm sure you can, but that won't fix your problem. Tthe real issue you have is that your underlying implemetation of that interface must be able to perform the behavior you need to execute. By themselves, interfaces don't do much. I think You'd need to find a way to do something to the proxy. 

One question though, do you have the aspects working on both side of the equation? Meaning both client and server are using AOP? 

Ryan-

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886071#3886071

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886071

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: annotationc on jdk 1.4.2

From: natebowler <nu...@jb...> - 2005-07-22 03:43:18

Ok, I got it working. 

The way I used the [annotationc] with a [fileset] did not work. My files were not being examined. When I changed it to use an [include] tag with the [src] tag, it started to examine the files.

Once this worked, I discovered I had several methods marked that had comments AFTER the markup @@biz.OptimisticLockRetry. I guess you CAN'T have anything after this or you get a parse error. :)  

This is fairly obvious, I suppose, but it was easy to fix once I started getting messages.

At any rate, thanks for the help. It's working great.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886028#3886028

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886028