[Design of JBoss Portal] - Portal User Creation
by JavaWings
I am new to JBoss and the portal. A search of related keywords didn't show any postings about this so I'd like to ask a question about the 2.4.2 version of the portal.
I need a portlet that deals with user accounts.
I find the user register/subscription model to be inappropriate for corporate use. I am planning to turn off anonymous user subscriptions. Meanwhile, I'd like to have the admin user log in and create new users and their profiles. It isn't clear to me how to program this.
Here's some thoughts....
In UserModuleImpl.java there is a createUser method that calls session.save(user). If called from a new user (not the admin) trying to create a new account for himself it makes sense to have the current session save this. But does it make sense, or is it safe, for the admin's current session to save the UserModuleImpl object of a user other than himself? I haven't yet found any programming guides around how to program user management using sessions. I don't understand sessions and what objects can be placed in them. Hints would be appreciated.
Thanks ahead,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036115#4036115
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036115
18 years, 9 months
[Design of JBoss ESB] - Re: Advanced MessageStore implementation
by derek.adams
I checked the JCR message store code into the trunk. The required configuration files and libraries are now bundled in the jbossesb.sar during the build. There are two basic configurations: load the JCR repository from JNDI or initialize it from the repository.xml in the root directory of the sar.
To enable the JCR message store, add the following line to the "core" section of the jbossesb-properties.xml:
| <property name="org.jboss.soa.esb.persistence.base.plugin.jcr" value="org.jboss.internal.soa.esb.persistence.format.jcr.JCRMessageStorePlugin"/>
|
To configure the message store, add the following properties to the "dbstore" section of the jbossesb-properties.xml:
| <property name="org.jboss.soa.esb.persistence.jcr.jndi.path" value="jcr"/>
| <property name="org.jboss.soa.esb.persistence.jcr.username" value="username"/>
| <property name="org.jboss.soa.esb.persistence.jcr.password" value="password"/>
| <property name="org.jboss.soa.esb.persistence.jcr.root.node.path" value="JBossESB/MessageStore"/>
|
If the "jcr.jndi.path" property is not specified, the repository will be configured locally using the repository.xml in the root of the sar.
The "jcr.username" and "jcr.password" are passed to the repository to get a session.
The "root.node.path" property determines the relative path in the repository under which message nodes will be stored.
An easy test for whether the JCR message store is configured properly is to add the org.jboss.soa.esb.actions.persistence.StoreJCRMessage action onto an existing service. The action will attempt to store the current message to the JCR store.
Let me know if you run into any problems.
Thanks,
Derek
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036072#4036072
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036072
18 years, 9 months
[Design of JBossCache] - Re: PojoInstance: ref count & notification
by jason.greene＠jboss.com
Ah I assumed you were using the pojo notification framework. Yeah this is by design. Any mutable object that is serializable will have visible changes since the object isn't serialized until the transaction commits. So a cache listener will only see identity changes, and not a true state change.
Assuming that remote pojo notifications worked, what information are you missing? I plan to fix all notification issues (including remote delivery) by GA, so if the design is missing something you need I would like to know. If you can't wait, and need to implement your own solution I understand, but do keep in mind that the internal structure isn't considered public, so it may change in the future.
Why do you need to know if an object is multiply referenced?
Regarding your change, a safer solution would be to add whatever information you need as independent internal properties.
Also, everyone has access to our anonymous cvs server:
| cvs -d :pserver:anonymous@anoncvs.forge.jboss.com:/cvsroot/jboss login
| (hit enter for password)
| cvs -d :pserver:anonymous@anoncvs.forge.jboss.com:/cvsroot/jboss co JBossCache
|
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036066#4036066
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036066
18 years, 9 months
[Design of JBoss ESB] - Re: Finding the EPR for a provider from a notifier
by derek.adams
Kurt,
That sounds like exactly what I was looking for. Thanks for the clarification!
For the registration of non-ESB-aware endpoints, it seems like the EPR instances (created from the -esb.xml) could have provider category and provider name properties added in the schema. The EPR instances that have those properties would be added to the registry on startup and would be discoverable by other components.
Deployment of the actual providers that implement functionality for the EPRs is something I have been wondering about too. Right now, the providers for file, FTP, JMS, etc are tightly coupled to the framework itself. It seems like the providers should be deployed separately in their own SARs, and hot-deployed by the ESB. The SAR would include all of the implementation code and some kind of descriptor that contains a list of the EPRs available from the provider. Each EPR listed would have a unique identifier so that it could be referenced from the -esb.xml to create an EPR instance (would require using the generic schema elements rather than the provider-specific ones).
It sounds like a lot of work, but I think it would make contributing new providers to the ESB much easier.
Thanks,
Derek
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036041#4036041
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036041
18 years, 9 months
[Design of JBossCache] - Re: PojoInstance: ref count & notification
by supi
Unfortunately, I don't have CVS access right now, and not much time either.
But to clarify (I don't think it's the serialization issue):
1) I'm not talking about attach/detach notifications provided by PojoCacheListener because they don't currently work for remote changes and also don't provide all the information I need. Right now, I'm building my own POJO notification adapter. This is simply a stateful CacheListener (not a PojoCacheListener) that converts pre and post node modified notifications into attach/modify/detach (I like the concept), and whether this is an initial attach or the last detach.
2) For this to work, PRE must really be PRE, especially in the case of reference counts. If you do:
| int count = pojoInstance.incrementRefCount(referencingFqn);
| // need to update it.
| put(originalFqn, PojoInstance.KEY, pojoInstance);
|
the local pojoInstance object is already changed before you issue the put (incrementRefCount not intercepted).
To check this, you can simply add a cache listener to a pojo cache's base cache and print data of local node modified events. By cloning the object, node modified (PRE) actually contains the ref count before changing it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036000#4036000
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036000
18 years, 9 months