[EJB/JBoss] - Re: persist entity ignores the
by sfisque
posting this so that anyone else searching on this will find what i found:
if you have an object with a composite key object, e.g:
| @Entity
| @IdClass( ThingPK.class )
| @Table( name="Thing" )
| public class Thing
| implements Serializable
| {
| @Id
| private String keyOne;
|
| @Id
| private String keyTwo;
|
| @Column( name="value_one" )
| private String valueOne;
|
| // getter/setters omitted for brevity
| }
|
| public class ThingPK
| implements Serializable
| {
| @Column( name="key_one" )
| private String keyOne;
|
| @Column( name="key_two" )
| private String keyTwo;
|
| // getter/setters omitted for brevity
| }
|
what ended up causing the above problem is that i had annotated the @Columns in the entity object (Thing), instead of instrumenting the PK class (ThingPK), once i corrected it (to appear like the above), the column name was properly injected and it worked fine. all of the example code i've seen never indicates that the @Column instrumentation is supposed to go into the PK class and not the entity class.
caveat emptor.
== stanton
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163724#4163724
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163724
17 years, 10 months
[JBoss jBPM] - Re: does this design make sense?
by twiceknightly
Hi dOoMi,
I'm not at work so I can't remember the exact details of the calls etc however it would go something like that presented below. DISLAIMER: I'm not sure if this is enough to simulate a lock an prevent concurrency issues or not.
A task is meant to be a unit of work that the user performs via the UI. Generally tasks are assigned to a pool/group. So if an individual is a member of that pool/group then they can see that task. Tasks are then pulled or pushed from the pool to an individuals personal task list to prevent multiple people picking up the task. Once on the personal task list the user then completes the task. A fairly straight forward usage would be to have a task inside a task node and, by default I believe, when you signal the token into the task node it creates the task instance. When the token leaves the task node it closes the task. There are a lot of scenarios when using tasks but I believe that is probably the most common usage.
Ok so to use a task as a lock I would propose
1. In an action handler at the start of the process a call to
TaskMgmtInstance.createTaskInstance() to create a task solely to be used as a lock. (see section 11.2.2 of the user guide)
2. Create a new group in the database
3. Assign the task to the group via TaskInstance.setPooledActors()
4. Before executing an update of the process instance, e.g. a signal, you need to make a call to acquire the lock (i.e. you need to get the task assigned to you i.e. you pull it from the group list onto your task list). This is done by TaskInstance.setActorId().
5. Determine if you have the lock. Stated another way determine if the special task is on your personal work list with a call to TaskMgmtInstance.findTaskInstancesByActorId()
6. If you have the lock then you are free to carryout your actions on the process instance.
7. Free up the lock by doing TaskInstance.setActorId(null). This effectively takes the task out of your list and puts it back on the pooled/group list.
A timer may be needed to automatically free up the lock/task if not user(Section 13.1 of user manual).
It's very crude and I'm not even sure if it would work but I would love your thought on the idea.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163723#4163723
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163723
17 years, 10 months
[Remoting] - Re: java.net.SocketException: Can not obtain client socket c
by ron.sigal＠jboss.com
You're right about maxPoolSize restricting the number of connections from a client to the server. Maybe you've haven't configured it in the right place - there are several jboss-service.xml files in the Application Server directory. You want ${JBOSS_HOME}/server/${CONFIG}/deploy/ejb3.deployer/META-INF/jboss-service.xml, where you want to change the EJB3 Connector MBean:
| <mbean code="org.jboss.remoting.transport.Connector"
| name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
| <depends>jboss.aop:service=AspectDeployer</depends>
| <attribute name="InvokerLocator">socket://${jboss.bind.address}:3873/?maxPoolSize=100</attribute>
| <attribute name="Configuration">
| <handlers>
| <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
| </handlers>
| </attribute>
| </mbean>
|
where I set maxPoolSize=100 just for illustration.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163721#4163721
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163721
17 years, 10 months
[Security & JAAS/JBoss] - Re: How is JBoss SSO SAML token been validated?
by sohil.shah＠jboss.com
anonymous wrote :
| And this trust callback happens directly between the federate server in the backend on the server side, no browser redirection involved?
|
Yes this is a backend server side communication. There is no browser involvement here. Browser is only used to store/propagate the token. At some point I would also like a complete cookie-less approach for token storage/propagation, but its something I have only thought about for now.
anonymous wrote :
| Where does the site2 gets the URL of the issuing site? The SAML token doesn't seem to have that information.
|
Correct. For security reasons, the SAML token does not need to carry this information.
This information is contained as part of the federation server configuration where information about the partners it needs to support/trust within the federation is provided.
Here is a sample configuration file for a federation server. Note: this is new functinality added on the trunk, so it different than the CR1 release. This will be included in the next release
Here is the conf/server.cfg.xml file
| <?xml version='1.0' encoding='ISO-8859-1'?>
|
|
|
| <jboss-sso>
|
|
|
| <!--
|
| partners configuration of the federation server...
|
| partners are the collection of sites which are part of the Single Sign On Federation
|
| it lists the web domains and their corresponding federation servers in this domain
|
| -->
|
| <federation-server>
|
| <partners>
|
| <partner domain="jboss.com" server="https://node1.jboss.com:8443/federate">
|
| <host>
|
| <id>node1.jboss.com</id>
|
| <secret>node1.jboss.com/somesecret</secret>
|
| </host>
|
| <host>
|
| <id>node2.jboss.com</id>
|
| <secret>node2.jboss.com/somesecret</secret>
|
| </host>
|
| <!--
|
| Used to configure the TrustPlugin which is responsible for validation of an incoming assertion/token
|
| Basically this verifies the token against the partner sending the assertion and makes sure with
|
| the partner that this assertion/token is valid so the user can be granted access without
|
| challenging them for credentials
|
| -->
|
| <trust>
|
| <url>https://node1.jboss.com:8443/federate/trust/validateSecret</url>
|
| <plugin class="org.jboss.security.federation.trust.JBossSSOTrustPlugin">
|
| <property name="allowSelfSignedSSLCert">true</property>
|
| </plugin>
|
| </trust>
|
| </partner>
|
| <partner domain="jboss.org" server="https://node1.jboss.org:8443/federate">
|
| <host>
|
| <id>node1.jboss.org</id>
|
| <secret>node1.jboss.org/somesecret</secret>
|
| </host>
|
| <trust>
|
| <url>https://node1.jboss.org:8443/federate/trust/validateSecret</url>
|
| <plugin class="org.jboss.security.federation.trust.JBossSSOTrustPlugin">
|
| <property name="allowSelfSignedSSLCert">true</property>
|
| </plugin>
|
| </trust>
|
| </partner>
|
| </partners>
|
| </federation-server>
|
|
|
| </jboss-sso>
|
The trust server url is what is used based on the partner in question
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163720#4163720
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163720
17 years, 10 months