September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMETA-220) Support JAXB style programming for RAR module

by Jesper Pedersen (JIRA)

Support JAXB style programming for RAR module --------------------------------------------- Key: JBMETA-220 URL: https://jira.jboss.org/jira/browse/JBMETA-220 Project: JBoss Metadata Issue Type: Task Security Level: Public (Everyone can see) Reporter: Jesper Pedersen Assignee: Jeff Zhang Fix For: 2.0.0.CR1 Currently we have standard get- and set- methods, like @XmlElement(name="outbound-resourceadapter") public void setOutboundRa(OutboundRaMetaData outboundRa) { this.outboundRa = outboundRa; } public OutboundRaMetaData getOutboundRa() { return outboundRa; } We should support a JAXB style programming in the RAR module, and thereby creating any objects or lists that doesn't exists in the get-method, like @XmlElement(name="outbound-resourceadapter") public void setOutboundRa(OutboundRaMetaData outboundRa) { this.outboundRa = outboundRa; } public OutboundRaMetaData getOutboundRa() { if (outboundRa == null) outboundRa = new OutboundRa(); return outboundRa; } This will allow an easier merging between the annotation model and the XML model. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBJCA-160) Clean up checkstyle for the JCA API

by Jesper Pedersen (JIRA)

Clean up checkstyle for the JCA API ----------------------------------- Key: JBJCA-160 URL: https://jira.jboss.org/jira/browse/JBJCA-160 Project: JBoss JCA Issue Type: Task Components: Core Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.Alpha4 Clean up as many of the JCA API checkstyle as possible - the rest needs bug-fixes from checkstyle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
1
0 / 0

[JBoss JIRA] Assigned: (JBAS-1436) Improved management

by Dimitris Andreadis (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-1436?page=com.atlassian.jira.plug... ] Dimitris Andreadis reassigned JBAS-1436: ---------------------------------------- Assignee: Jesper Pedersen (was: Vicky Kak) Give back to JCA lead for review. > Improved management > ------------------- > > Key: JBAS-1436 > URL: https://jira.jboss.org/jira/browse/JBAS-1436 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-5.1.0.GA > Reporter: Adrian Brock > Assignee: Jesper Pedersen > Fix For: JBossAS-6.0.0.Alpha1 > > > Forum Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48682 > **This is a holder issue. Each section should be raised as a new issue as it is > developed with a link from this issue.** > There are a number of areas in JCA that need better management capabilities. > Some of these stats may also reveal the need for new configuration/tuning parameters. > In core JCA: > 1) Better visibility on the ManagedConnectionFactory. > This is currently a DynamicMBean that provides basic config parameters, but we could also > provide a proxy/wrapper to provide statistics of operations on the factory and its > ManagedConnections. > a) createManagedConnections > b) matchManagedConnections > c) events on from the listeners > 2) Better visibility of the Pool(s) > Only top level statistics are provided (you cannot see the subpools). > The statistics are also not synchronized with the pool (for performance reasons > and also the fact that each stat is retrieved on individual MBean getAttribute requests) > Additional statistics could include wait times when requests are waiting on an empty pool, > idle time of unused connections, etc. > 3) Better visibility of the ConnectionManager > Currently this has no visibility for management. > Its main responsibilties are transactions enlistment and security. > e.g. This could show how long is wasted because <track-connection-by-tx/> does not > return the connection the pool until transaction completion. > 4) JDBC resource adapter > PreparedStatementCache stats > Query time stats > etc. > 5) JMS resource adapter > Message send/receive stats > 6) Inbound messaging > Stats for message delivery > 7) Transaction inflow > Stats for transaction inflow and also display a list of current inbound transactions > 8) Work management > Stats for the work management pools and timers -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3524) Support Kerberos authentication in CSIv2

by David Robison (JIRA)

Support Kerberos authentication in CSIv2 ---------------------------------------- Key: JBAS-3524 URL: http://jira.jboss.com/jira/browse/JBAS-3524 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: IIOP service Affects Versions: JBossAS-4.0.4.GA Environment: JBoss 4.0.4.GA Reporter: David Robison Assigned To: Francisco Reverbel JacORB supports Kerberos Authentication as part of its SAS implementation. I would be useful for JBoss to support it as part of his JBoss CSIv2 implementation. -- 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

3
3
0 / 0

[JBoss JIRA] Updated: (JBAS-2190) New ClientUserTransaction does not honour the jndi environment

by Dimitris Andreadis (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-2190?page=com.atlassian.jira.plug... ] Dimitris Andreadis updated JBAS-2190: ------------------------------------- Assignee: Stefan Guilhen (was: Francisco Reverbel) Re-assign older iiop tasks to Stefan, to review. > New ClientUserTransaction does not honour the jndi environment > -------------------------------------------------------------- > > Key: JBAS-2190 > URL: https://jira.jboss.org/jira/browse/JBAS-2190 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Transaction Manager (JBossTM) > Affects Versions: JBossAS-5.0.0.Beta1 > Reporter: Adrian Brock > Assignee: Stefan Guilhen > > JBoss5 code: > Context ctx = new InitialContext(); > txFactory = (TransactionFactory) ctx.lookup( > DistributedTransactionManager.JNDI_NAME); > JBoss4 code: > Hashtable env = (Hashtable) NamingContextFactory.lastInitialContextEnv.get(); > InitialContext ctx = new InitialContext(env); > factory = (UserTransactionSessionFactory) ctx.lookup("UserTransactionSessionFactory"); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1180) bi-pass JacORB interceptors for purely local invocations

by Dimitris Andreadis (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-1180?page=com.atlassian.jira.plug... ] Dimitris Andreadis updated JBAS-1180: ------------------------------------- Assignee: Stefan Guilhen (was: Francisco Reverbel) Re-assign older iiop tasks to Stefan, to review. > bi-pass JacORB interceptors for purely local invocations > -------------------------------------------------------- > > Key: JBAS-1180 > URL: https://jira.jboss.org/jira/browse/JBAS-1180 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: IIOP service > Affects Versions: JBossAS-3.2.6 Final > Reporter: SourceForge User > Assignee: Stefan Guilhen > > SourceForge Submitter: marklittle . > I registered the following issue > (http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi? > id=526) with JacORB bugzilla a couple of weeks ago, but > no response so far. I think it's sufficiently important to > register here too in case you are able to do something > for JBoss. > In the current implementation of JacORB (2.2), if I > register an interceptor with the ORB, then > it appears that all invocations to all objects go through > that interceptor, > even if they are co-located with the invoker. I > understand that rational given > the PI specification and the original intention behind > that work: to make > local invocations and remote invocations similar. > However, most ORBs provide a way of doing a local, no- > interceptor > optimization. The JDK 1.4 ORB is one example (though > that takes the other > extreme and won't invoke interceptors on any local > object). > Orbix 2000, for example, supports multiple ORBs and > POAs within the same VM, > and interceptors are registered on a per-ORB basis, not > a per VM basis as > appears to be the case with JacORB. You can also turn > on local optimizations > for the individual ORBs. > The reason for asking for this optimization is > performance. With a very simple > test, where the interceptor does nothing, we see a 66% > degredation in > performance for local calls. For example, with no > interceptors we can get > 3000 invocations, whereas > with a "null" interceptor this is around 1000. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1182) Thread creation during deactivate_object

by Dimitris Andreadis (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-1182?page=com.atlassian.jira.plug... ] Dimitris Andreadis updated JBAS-1182: ------------------------------------- Assignee: Stefan Guilhen (was: Francisco Reverbel) Re-assign older iiop tasks to Stefan, to review. > Thread creation during deactivate_object > ---------------------------------------- > > Key: JBAS-1182 > URL: https://jira.jboss.org/jira/browse/JBAS-1182 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: IIOP service > Reporter: SourceForge User > Assignee: Stefan Guilhen > > SourceForge Submitter: kevinconner . > This is a duplicate of bug 527 in the JacORB database. > It is being submitted here so that a patch may be > applied to the JBoss patched version of JacORB. > http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=527 > The deactiviation of an object causes Thread creation > in AOM.remove. Would it > be possible to use a thread pool instead of creating > new threads? > A possible solution could be to have the > RequestController provide a > notification mechanism (instead of a thread waiting on > object completion) and > have the notification request work from the thread pool. > The attached patch uses a threadpool to prevent the > thread creation but I don't > believe it is the best solution. > Index: AOM.java > =================================================================== > RCS file: > /cvsroot/jacorb/JacORB/src/org/jacorb/poa/AOM.java,v > retrieving revision 1.29 > diff -u -r1.29 AOM.java > --- AOM.java 6 May 2004 12:40:00 -0000 1.29 > +++ AOM.java 21 Oct 2004 14:38:11 -0000 > @@ -27,6 +27,9 @@ > import org.jacorb.poa.util.ByteArrayKey; > import org.jacorb.poa.util.POAUtil; > import org.jacorb.poa.util.StringPair; > +import org.jacorb.util.threadpool.Consumer; > +import org.jacorb.util.threadpool.ConsumerFactory; > +import org.jacorb.util.threadpool.ThreadPool; > > import > org.omg.PortableServer.POAPackage.ObjectAlreadyActive; > import org.omg.PortableServer.POAPackage.ObjectNotActive; > @@ -69,6 +72,23 @@ > /** a lock to protect two consecutive operations > on the list, used > in remove() */ > private Object deactivationListLock = > new Object(); > + > + private Consumer deactivationConsumer = new > Consumer() { > + public void doWork(final Object job) { > + try { > + ((Runnable)job).run() ; > + } catch (final Throwable th) { > + logger.info("Unhandled exception > during deactivation", th); > + } > + } > + } ; > + private ConsumerFactory > deactivationConsumerFactory = new ConsumerFactory() { > + public Consumer create() { > + return deactivationConsumer ; > + } > + } ; > + > + private ThreadPool deactivationPool = new > ThreadPool(deactivationConsumerFactory) ; > > private AOM() > { > @@ -348,8 +368,7 @@ > final POA poa_ = poa; > final boolean cleanupInProgress_ = > cleanupInProgress; > > - Thread thread = new Thread("AOM_RemovalThread") > - { > + final Runnable job = new Runnable() { > public void run() > { > _remove( > @@ -361,8 +380,8 @@ > ); > } > }; > - > - thread.start(); > + > + deactivationPool.putJob(job) ; > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[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

3
5
0 / 0

[JBoss JIRA] Created: (JBJCA-159) JBoss Common 2.2.15.GA

by Jesper Pedersen (JIRA)

JBoss Common 2.2.15.GA ---------------------- Key: JBJCA-159 URL: https://jira.jboss.org/jira/browse/JBJCA-159 Project: JBoss JCA Issue Type: Component Upgrade Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.Alpha4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCOMMON-89) Release version 2.2.15 of JBoss Common Core

by Paul Ferraro (JIRA)

Release version 2.2.15 of JBoss Common Core ------------------------------------------- Key: JBCOMMON-89 URL: https://jira.jboss.org/jira/browse/JBCOMMON-89 Project: JBoss Common Issue Type: Task Security Level: Public (Everyone can see) Components: common-core (2.x) Reporter: Paul Ferraro Fix For: 2.2.15.GA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2009