[JBoss Seam] - Re: release connection after lazy init in view
by imario
I think we could be able to find a solution for it. Using eager loading is one of them, though, I see three drawbacks:
1) you have to know what the view requests from your entities - in our theoretical case where the view and the backing bean author are different persons you might not be able to know this ...
2) you have to pollute your backing bean with database system code.
We access the database through DAO classes, now, the same method to retrieve a list of entities has to be duplicated just to have once lazy loading or in the other case eager loading
3) the ORM mapper looses some of its transparency
I don't know whats "silly" on my post or my proposed solution which is just a start of a discussion.
At least my solution keeps the ORM transparency and you have to do NOTHING in your backing bean, DAO or somewhere else in your code.
I am sure tons of developers out there do not even know what it means having an open Connection laying around, in the worst case until the conversation times out.
With multiple conversations (say 2 per user) and say 50 user you might end with 100 active Connections (in the worst case for sure).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4047675#4047675
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4047675
18 years, 11 months
[Remoting] - Remoting from unsigned applet - ClassLoader security excepti
by fatbatman
Hi,
I need to try and get JBoss remoting (the latest version from cvs) working in an unsigned applet, as quickly as possible :)
I first got a security exception from the code in org.jboss.remoting.Version that checks the system property for the remoting version e.g. System.getProperty(PRE_2_0_COMPATIBLE). I've hard coded(hacked) this to the values I require, that's ok for now.
I've now come across something else though that looks a bit more involved;
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:424)
at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324)
at org.jboss.remoting.Client.connect(Client.java:413)
at com.xxx.client.net.jbossremoting.JadeRemotingClient.createRemotingClient(JadeRemotingClient.java:74)
at com.xxx.client.lobby2.LobbyApplet$1.run(LobbyApplet.java:261)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkCreateClassLoader(Unknown Source)
at java.lang.ClassLoader.(Unknown Source)
at org.jboss.remoting.loading.ClassByteClassLoader.(ClassByteClassLoader.java:62)
at org.jboss.remoting.AbstractInvoker.(AbstractInvoker.java:76)
at org.jboss.remoting.MicroRemoteClientInvoker.(MicroRemoteClientInvoker.java:52)
at org.jboss.remoting.RemoteClientInvoker.(RemoteClientInvoker.java:45)
at org.jboss.remoting.transport.http.HTTPClientInvoker.(HTTPClientInvoker.java:78)
at org.jboss.remoting.transport.http.TransportClientFactory.createClientInvoker(TransportClientFactory.java:38)
... 14 more
Does anyone have any suggestions for how I might quickly get around this, or is not possible without significant work?
Thanks in advance
James
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4047668#4047668
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4047668
18 years, 11 months
[JBoss Portal] - LDAP Authentication & Authorization to eDirectory
by arnieAustin
I am working with the jboss-portal-2.6-CR2 bundle. After getting it configured for MySQL and logging in as 'admin', I reconfigured it for LDAP using the LDAPExtUser/RoleModuleImpl classes. We are using Novell eDirectory setup in an Identity Vault configuration (nearly flat directory with different ou's for users and groups). Anyway, so far so good. I can log in. Well, actually Admin can login. I cannot. Keep getting "Your account is disabled." message on the login screen. Which is WRONG since my account is neither disabled nor locked in LDAP. My guess is this misleading message has something to do with Authorization.
Our LDAP structure:
| o=idv
| ou=groups,o=idv
| ou=apps,ou=groups,o=idv
| ou=jbossportal,ou=apps,ou=groups,o=idv
| cn=Administrators,ou=jbossportal,ou=apps,ou=groups,o=idv
| cn=Users,ou=jbossportal,ou=apps,ou=groups,o=idv
|
| ou=people,o=idv
| ou=apps,ou=people,o=idv
| cn=admin,ou=apps,ou=people,o=idv
| ou=employees,ou=people,o=idv
| ou=al,ou=employees,ou=people,o=idv
| cn=acm3,ou=al,ou=employees,ou=people,o=idv
|
Note that the admin I am using to authenticate is in a different container in the tree. My account (acm3) is where most employees would be.
The two groups mentioned have various users in them. In the Administrators case, Admin and ACM3 are both members. Yet when Admin logs in, the "Admin" link doesn't appear in the portal window. And ACM3 cannot log in at all.
What could I be missing here? There were no messages on the console log or in server.log that something was wrong.
I've included the ldap_identity-config.xml below:
| <identity-configuration>
| <datasources>
| <datasource>
| <name>LDAP</name>
| <config>
| <option>
| <name>host</name>
| <value>idv1-lab.oag.state.tx.us</value>
| </option>
| <option>
| <name>port</name>
| <value>389</value>
| </option>
| <option>
| <name>adminDN</name>
| <value>cn=portalsystem,ou=apps,ou=people,o=idv</value>
| </option>
| <option>
| <name>adminPassword</name>
| <value>password</value>
| </option>
| <!--<option>
| <name>protocol</name>
| <value>ssl</value>
| </option>-->
| </config>
| </datasource>
| </datasources>
| <modules>
| <module>
| <!--type used to correctly map in IdentityContext registry-->
| <type>User</type>
| <implementation>LDAP</implementation>
| <class>org.jboss.portal.identity.ldap.LDAPExtUserModuleImpl</class>
| <config/>
| </module>
| <module>
| <type>Role</type>
| <implementation>LDAP</implementation>
| <class>org.jboss.portal.identity.ldap.LDAPExtRoleModuleImpl</class>
| <config/>
| </module>
| <module>
| <type>Membership</type>
| <implementation>LDAP</implementation>
| <config/>
| </module>
| <module>
| <type>UserProfile</type>
| <implementation>DELEGATING</implementation>
| <config>
| <option>
| <name>ldapModuleJNDIName</name>
| <value>java:/portal/LDAPUserProfileModule</value>
| </option>
| </config>
| </module>
| <module>
| <type>DBDelegateUserProfile</type>
| <implementation>DB</implementation>
| <config>
| <option>
| <name>randomSynchronizePassword</name>
| <value>true</value>
| </option>
| </config>
| </module>
| <module>
| <type>LDAPDelegateUserProfile</type>
| <implementation>LDAP</implementation>
| <config/>
| </module>
| </modules>
|
| <options>
| <option-group>
| <group-name>common</group-name>
| <option>
| <name>userCtxDN</name>
| <value>ou=PEOPLE,o=IDV</value>
| </option>
| <option>
| <name>roleCtxDN</name>
| <value>ou=GROUPS,o=IDV</value>
| </option>
| <option>
| <name>userSearchFilter</name>
| <value>(cn={0})</value>
| </option>
| <option>
| <name>roleSearchFilter</name>
| <value>(cn={0})</value>
| </option>
| <option>
| <name>uidAttributeID</name>
| <value>cn</value>
| </option>
| <option>
| <name>passwordAttributeID</name>
| <value>password</value>
| </option>
| <option>
| <name>membershipAttributeId</name>
| <value>member</value>
| </option>
| <option>
| <name>membershipAttributeIsDN</name>
| <value>true</value>
| </option>
| </option-group>
| <option-group>
| <group-name>userCreateAttibutes</group-name>
| <option>
| <name>objectClass</name>
| <!--This objectclasses should work with Red Hat Directory-->
| <value>top</value>
| <value>person</value>
| <value>inetOrgPerson</value>
| </option>
| <!--Schema requires those to have initial value-->
| <option>
| <name>cn</name>
| <value>none</value>
| </option>
| <option>
| <name>sn</name>
| <value>none</value>
| </option>
| </option-group>
| <option-group>
| <group-name>roleCreateAttibutes</group-name>
| <!--Schema requires those to have initial value-->
| <option>
| <name>cn</name>
| <value>none</value>
| </option>
| <!--Some directory servers require this attribute to be valid DN-->
| <!--For safety reasons point to the admin user here-->
| <option>
| <name>member</name>
| <value>cn=portalsytem,ou=apps,ou=people,o=idv</value>
| </option>
| </option-group>
| </options>
| </identity-configuration>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4047666#4047666
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4047666
18 years, 11 months