[JBoss JIRA] Created: (JBAS-3773) Empty baseCtxDN and rolesCtxDN adds a comma to the userDn and user roles
by Eric van Lydegraf (JIRA)
Empty baseCtxDN and rolesCtxDN adds a comma to the userDn and user roles
------------------------------------------------------------------------
Key: JBAS-3773
URL: http://jira.jboss.com/jira/browse/JBAS-3773
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-4.0.5.CR1
Reporter: Eric van Lydegraf
Assigned To: Scott M Stark
The LDAP server (Lotus Domino) has users organized along different CtxDN contexts, so for JNDI empty contexts are used and the filter sorts out the users and groups.
When Using LoginExtLoginModule, a sucessful retrieval of a User, has a full userDN but the code will append a comma expecting BaseCtxDN used in the search.
The same is true for group membership.
The solution I came up with is if the context is empty, no Ctx is appended and only the search result is preserved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 7 months
[JBoss JIRA] Created: (JBAS-3841) Occasional NPE in org.apache.commons.modeler.Registry during startup
by Rolf Arne Corneliussen (JIRA)
Occasional NPE in org.apache.commons.modeler.Registry during startup
--------------------------------------------------------------------
Key: JBAS-3841
URL: http://jira.jboss.com/jira/browse/JBAS-3841
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-4.0.3 SP1
Reporter: Rolf Arne Corneliussen
Assigned To: Remy Maucherat
Sometimes (but less than half the times), I get the following in the log when JBoss is started:
2006-11-09 17:38:14,453 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
2006-11-09 17:38:14,468 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8443
2006-11-09 17:38:14,468 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-9443
2006-11-09 17:38:14,484 INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel) [4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)] Started in 19s:531ms
2006-11-09 17:38:14,500 WARN [org.apache.commons.modeler.Registry] No metadata found for org.apache.coyote.RequestInfo
2006-11-09 17:38:14,500 ERROR [org.apache.commons.modeler.Registry] Error registering jboss.web:type=RequestProcessor,worker=http-0.0.0.0-8443,name=HttpRequest2
java.lang.NullPointerException
at org.apache.commons.modeler.Registry.registerComponent(Registry.java:862)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.init(Http11Protocol.java:709)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.getInitData(LeaderFollowerWorkerThread.java:48)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:673)
at java.lang.Thread.run(Thread.java:595)
2006-11-09 17:38:14,500 WARN [org.apache.coyote.http11.Http11Protocol] Error registering request
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months
[JBoss JIRA] Created: (JBCLUSTER-157) Server Shutdown Latency and Session replication and Forwarding
by Shankar Pattabiraman (JIRA)
Server Shutdown Latency and Session replication and Forwarding
--------------------------------------------------------------
Key: JBCLUSTER-157
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-157
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Java 1.5.0_05, Win XP,Red Hat 3 JBoss 4.0.5 Apache
Reporter: Shankar Pattabiraman
Assigned To: Brian Stansberry
Priority: Minor
Setup a cluster with 2 nodes. Be in a session where a server is servicing.
Try to give a Control Z to kill the server while servicing. The latency involved in shutting down the server never gives a chance for the server to switch to the other.
The session in the latency period of shutdown never gets successfully switched to the other node in the cluster.
Apache-2 Node Jboss Cluster and a Trivial JEE Application.
Check this out whether it is a configuration issue or a real issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months
[JBoss JIRA] Created: (EJBTHREE-686) Bidirectional @OneToOne with CascadeType.ALL and optional=false on the non-owning side:
by Jeremy Norris (JIRA)
Bidirectional @OneToOne with CascadeType.ALL and optional=false on the non-owning side:
---------------------------------------------------------------------------------------
Key: EJBTHREE-686
URL: http://jira.jboss.com/jira/browse/EJBTHREE-686
Project: EJB 3.0
Issue Type: Bug
Components: EJB3 Extensions
Affects Versions: EJB 3.0 RC8 - FD, EJB 3.0 RC7 - FD, EJB 3.0 RC6 - PFD
Reporter: Jeremy Norris
Consider the following two classes:
----- class X:
@Entity
@Table(name="x")
public class X
{
private Integer id;
private Y y;
public X()
{
this.y = new Y(this);
}
@Id
@GeneratedValue
@Column(name = "id", nullable=false, updatable=false)
public Integer getId()
{
return id;
}
protected void setId(Integer id)
{
this.id = id;
}
@OneToOne(cascade={CascadeType.ALL}, mappedBy="x")
public Y getY()
{
return y;
}
protected void setY(Y y)
{
this.y = y;
}
}
----- class Y:
@Entity
@Table(name="y")
public class Y
{
private Integer id;
private X x;
protected Y()
{
}
public Y(X x)
{
this.x = x;
x.setY(this);
}
@Id
@GeneratedValue
@Column(name = "id", nullable=false, updatable=false)
public Integer getId()
{
return id;
}
protected void setId(Integer id)
{
this.id = id;
}
@OneToOne
@JoinColumn(name="x_id", nullable=false)
public X getX()
{
return x;
}
protected void setX(X x)
{
this.x = x;
}
}
----- X is persisted as follows:
// Note: The constructor creates a new dependent Y instance, and hooks it up appropriately:
X x = new X();
em.persist(x);
-----
This works fine and persists as expected. However, if I add "optional=false" to the X.@OneToOne declaration, it fails with the following exception:
javax.ejb.EJBTransactionRolledbackException: javax.persistence.PersistenceException: org.hibernate.PropertyValueException: not-null property references a null or transient value: ... Y.x
Y.x definitely set. Also, "x == x.getY().getX()" is true. (Interestingly, this only happens if I put the "optional=false" on the X side. "optional=false" on the Y side is fine). This seems like a bug unless there is something I don't understand about "optional", but it seems pretty simply - The spec says the following about this attribute:
(Optional) Whether the association is optional.
If set to false then a non-null relationship must
always exist.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months
[JBoss JIRA] Created: (GPD-9) save deployment options
by Brice Ruth (JIRA)
save deployment options
-----------------------
Key: GPD-9
URL: http://jira.jboss.com/jira/browse/GPD-9
Project: JBoss jBPM GPD
Issue Type: Feature Request
Affects Versions: 3.0.11
Reporter: Brice Ruth
Assigned To: Koen Aers
The current jBPM Process Designer plugin for Eclipse does not save deployment settings for a process definition. It would be useful to set remote deploy settings as a workspace preference (host/port/path). Then, what files are to be deployed (gpd.xml, processdefinition.xml, processimage.xml, src files, etc.) should be saved per process, and stored as part of the project/process files (whichever, just not in .metadata, so it can be committed to CVS and shared by a team).
JBoss Support Case: 00012512
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months
[JBoss JIRA] Created: (JBAS-3521) OptimisticLockUnitTestCase Intermittently Fails
by Matt Wringe (JIRA)
OptimisticLockUnitTestCase Intermittently Fails
-----------------------------------------------
Key: JBAS-3521
URL: http://jira.jboss.com/jira/browse/JBAS-3521
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-4.0.4.GA
Environment: Sun 1.4.2_12 JVM
RHEL 4, Linux Kernel 2.6.9
Reporter: Matt Wringe
The OptimisticLockUnitTestCase testBug1006723 test seems to fail randomly. This is a known issue, and is described here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=TestsuiteTroubleShooting
But there does not appear to be a bug filed about this issue, nor can I find bug 1006723
"Problem OptimisticLockUnitTestCase fails
Suite: org.jboss.test.cmp2.optimisticlock.test.OptimisticLockUnitTestCase Test: testBug1006723 Type: error Exception: javax.ejb.CreateException Message: Error checking if entity exists:java.sql.SQLException: Column not found: \ OIDCMP in statement SELECT COUNT(*) FROM ENTITYA WHERE OIDCMP=?
This test passes intermintently. Run it a few times"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 9 months
[JBoss JIRA] Created: (JBAS-3405) Unable to secure JMX Invoker
by amdonov (JIRA)
Unable to secure JMX Invoker
----------------------------
Key: JBAS-3405
URL: http://jira.jboss.com/jira/browse/JBAS-3405
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.0.3 SP1
Environment: Windows Sun JDK 1.5
Reporter: amdonov
I am having the same problem securing the JMX invoker as the user in the referenced forum thread. However, I'm running 4.0.4.GA instead of 4.0.3 SP1. When, performing a clean installation using the installer. I selected the default configuration and elected to secure the invokers. The install completes without error. JBoss has the following error which is unfortunatly only written at the DEBUG level.
2006-07-20 10:40:47,541 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
at java.lang.Class.getConstructor0(Class.java:2647)
at java.lang.Class.getConstructor(Class.java:1629)
at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
at org.jboss.system.ServiceController.install(ServiceController.java:226)
at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.install(Unknown Source)
at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy6.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:464)
at java.lang.Thread.run(Thread.java:595)
2006-07-20 10:40:47,551 DEBUG [org.jboss.system.ServiceCreator] Created bean:
Access to the adaptors is not restricted.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (JBAS-3644) ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
by anajavi (JIRA)
ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
----------------------------------------------------------------------------
Key: JBAS-3644
URL: http://jira.jboss.com/jira/browse/JBAS-3644
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: CMP service
Affects Versions: JBossAS-4.0.3 SP1
Environment: JBoss 4.0.3SP1, Sybase 12.5 (and Sybase 15.0)
Reporter: anajavi
Assigned To: Alexey Loubyansky
Ejbqltosql92compiler creates LEFT OUTER JOIN's when INNER JOIN could be used. This leads to bad performance, because database server does table scan instead of using index.
Running INNER JOIN instead of LEFT OUTER JOIN gives 10x better performance (0,6s/query vs. 0,06s/query).
I submitted this as a feature request because it is about performance, not bug. However, this bad performance prevents us from using cmp2.x jdbc2 pm, which we would seriously need.
I tried to go through ejbqltosql92compiler's source, but could not figure out a clean way to make it use INNER JOIN when joining is caused by a path in WHERE-clause (not containing OR).
I also tried tweaking RDBMS optimizer and upgrading to newer version, but it did not help.
Example:
Original EJBQL:
SELECT OBJECT(o) FROM Rooli AS o WHERE o.toimipaikka.yritys.id=?1 AND o.rooli.nimi=?2
Generated SQL:
SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
FROM rooli t0_o
LEFT OUTER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id
LEFT OUTER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id
LEFT OUTER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id
WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'
10x faster SQL:
SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
FROM rooli t0_o
INNER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id
INNER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id
INNER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id
WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'
Thank you.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months