[JBoss JIRA] (JBRULES-3470) publish org.drools.updatesite-*-assembly.zip contents to download.jboss.org so it can be used by end-users and linked from JBoss Central
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3470?page=com.atlassian.jira.plug... ]
Geoffrey De Smet resolved JBRULES-3470.
---------------------------------------
Resolution: Done
For the last open part of this ticket:
After discussion with nbolt, it is for now no longer required to create that syslink.
Because our release procedure now does create syslinks already, it's easy to uncomment that specific syslink too in the bottom of this file:
https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/scri...
So if the link is needed anyway, create a pull request uncommenting that part of create_filemgmt_links.sh
> publish org.drools.updatesite-*-assembly.zip contents to download.jboss.org so it can be used by end-users and linked from JBoss Central
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBRULES-3470
> URL: https://issues.jboss.org/browse/JBRULES-3470
> Project: JBRULES
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: drools-eclipse
> Affects Versions: 5.3.1.Final, 5.4.0.CR1
> Reporter: Nick Boldt
> Assignee: Geoffrey De Smet
> Fix For: 5.4.0.Final
>
>
> Currently the only ways to get drools/jbpm 5 plugins installed into Eclipse are to:
> a) download the org.drools.updatesite-*-assembly.zip zip from Nexus, or
> b) unpack the droolsjbpm-tools-distribution-*.zip linked from http://www.jboss.org/drools/downloads, or
> c) use the nightly staging site for JBT SOA Tooling http://download.jboss.org/jbosstools/updates/nightly/soa-tooling/trunk/
> d) use the nightly staging site for JBDS SOA Tooling http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-5.0_trunk....
> Since the JBT site (c) is going away, and (a) and (b) are a relative pain in the butt, we need a new unpacked site, eg., under here:
> http://download.jboss.org/drools/updates/
> or
> http://download.jboss.org/drools/releases/
> ----
> For JBoss Tools, the convention we use is:
> http://download.jboss.org/jbosstools/updates/stable/ (releases)
> http://download.jboss.org/jbosstools/updates/development/ (milestones and candidate releases)
> http://download.jboss.org/jbosstools/updates/nightly/ (bleeding edge CI builds)
> http://download.jboss.org/jbosstools/updates/ (see this page for further discussion of the build types)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6583) Performance regression comparing to previous release
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-6583?page=com.atlassian.jira.plugin.s... ]
jaikiran pai edited comment on AS7-6583 at 2/22/13 8:36 AM:
------------------------------------------------------------
The https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja... can indeed turn out to be expensive since it scans the stacktrace elements to check for the calling classes to see if any of those classloaders have a LogContext associated with it. I'm not too sure why we need to find a LogContext in such a fashion instead of relying on TCCL (which is what ContextClassLoaderLogContextSelector did). Maybe James knows.
Edit: Didn't see James' reply before posting mine.
was (Author: jaikiran):
The https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja... can indeed turn out to be expensive since it scans the stacktrace elements to check for the calling classes to see if any of those classloaders have a LogContext associated with it. I'm not too sure why we need to find a LogContext in such a fashion instead of relying on TCCL (which is what ContextClassLoaderLogContextSelector did). Maybe James knows.
> Performance regression comparing to previous release
> ----------------------------------------------------
>
> Key: AS7-6583
> URL: https://issues.jboss.org/browse/AS7-6583
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld, Logging
> Affects Versions: 7.2.0.Alpha1
> Environment: 7.2.0.Final (prerelease-1 tag)
> Reporter: Tomas Remes
> Assignee: James Perkins
> Priority: Critical
> Labels: performance
> Attachments: AS7-snapshot-good.jps, AS7-snapshot-wrong.jps
>
>
> There is significant performance regression in 7.2.0 prerelease. I discovered it in my Weld performance load tests (testing simple Weld numberguess example application), but I am quite sure that's not Weld issue at all. I did some investigations and it seems that problem occurred in org/jboss/as/logging module.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6583) Performance regression comparing to previous release
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-6583?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on AS7-6583:
-----------------------------------
The https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja... can indeed turn out to be expensive since it scans the stacktrace elements to check for the calling classes to see if any of those classloaders have a LogContext associated with it. I'm not too sure why we need to find a LogContext in such a fashion instead of relying on TCCL (which is what ContextClassLoaderLogContextSelector did). Maybe James knows.
> Performance regression comparing to previous release
> ----------------------------------------------------
>
> Key: AS7-6583
> URL: https://issues.jboss.org/browse/AS7-6583
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld, Logging
> Affects Versions: 7.2.0.Alpha1
> Environment: 7.2.0.Final (prerelease-1 tag)
> Reporter: Tomas Remes
> Assignee: James Perkins
> Priority: Critical
> Labels: performance
> Attachments: AS7-snapshot-good.jps, AS7-snapshot-wrong.jps
>
>
> There is significant performance regression in 7.2.0 prerelease. I discovered it in my Weld performance load tests (testing simple Weld numberguess example application), but I am quite sure that's not Weld issue at all. I did some investigations and it seems that problem occurred in org/jboss/as/logging module.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6583) Performance regression comparing to previous release
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/AS7-6583?page=com.atlassian.jira.plugin.s... ]
James Perkins commented on AS7-6583:
------------------------------------
There is no doubt that the {{ContextClassLoaderLogContextSelector}} is faster than the {{ClassLoaderLogContextSelector}}. We can't change that. We need to ensure that certain modules use the system {{LogContext}.
Regardless the speed of the {{LogContextSelector}} is not the issue. Something is invoking it too often to see a performance issue. It's either Weld or another library. They key is to find where a new logger is being "created" and fix that. There is no fix for the logging subsystem. It needs to the use the {{LogContextSelector}} it is using and that won't change.
> Performance regression comparing to previous release
> ----------------------------------------------------
>
> Key: AS7-6583
> URL: https://issues.jboss.org/browse/AS7-6583
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld, Logging
> Affects Versions: 7.2.0.Alpha1
> Environment: 7.2.0.Final (prerelease-1 tag)
> Reporter: Tomas Remes
> Assignee: James Perkins
> Priority: Critical
> Labels: performance
> Attachments: AS7-snapshot-good.jps, AS7-snapshot-wrong.jps
>
>
> There is significant performance regression in 7.2.0 prerelease. I discovered it in my Weld performance load tests (testing simple Weld numberguess example application), but I am quite sure that's not Weld issue at all. I did some investigations and it seems that problem occurred in org/jboss/as/logging module.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JBJCA-951) The pool statistics "Available" shows wrong value after fill pool
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-951?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBJCA-951:
-----------------------------------------------
vrastsel(a)redhat.com made a comment on [bug 901220|https://bugzilla.redhat.com/show_bug.cgi?id=901220]
Verified on EAP 6.1 DR4
> The pool statistics "Available" shows wrong value after fill pool
> -----------------------------------------------------------------
>
> Key: JBJCA-951
> URL: https://issues.jboss.org/browse/JBJCA-951
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.14.Final, 1.1.0.Beta3
> Reporter: Masafumi Miura
> Assignee: Jesper Pedersen
> Fix For: 1.0.15.Final, 1.1.0.Beta4
>
>
> The pool statistics' "Available" shows wrong value (one less than "max-pool-size") after fill pool.
> For example, min-pool-size=5, max-pool-size=10 and prefill=true are set to datasource configuration:
> {code:xml}
> <pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>10</max-pool-size>
> <prefill>true</prefill>
> </pool>
> {code}
> Then, when checking pool stats via CLI after JBoss start-up, the results shows the following:
> {code}
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS/statistics=pool/:read-resource(recursive=false,proxies=false,include-runtime=true,include-defaults=true)
> {
> "outcome" => "success",
> "result" => {
> "ActiveCount" => "5",
> "AvailableCount" => "9",
> "AverageBlockingTime" => "0",
> "AverageCreationTime" => "3",
> "CreatedCount" => "5",
> "DestroyedCount" => "0",
> "MaxCreationTime" => "4",
> "MaxUsedCount" => "1",
> "MaxWaitTime" => "0",
> "TimedOut" => "0",
> "TotalBlockingTime" => "0",
> "TotalCreationTime" => "17"
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JBJCA-951) The pool statistics "Available" shows wrong value after fill pool
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-951?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBJCA-951:
-----------------------------------------------
vrastsel(a)redhat.com changed the Status of [bug 901220|https://bugzilla.redhat.com/show_bug.cgi?id=901220] from NEW to VERIFIED
> The pool statistics "Available" shows wrong value after fill pool
> -----------------------------------------------------------------
>
> Key: JBJCA-951
> URL: https://issues.jboss.org/browse/JBJCA-951
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.14.Final, 1.1.0.Beta3
> Reporter: Masafumi Miura
> Assignee: Jesper Pedersen
> Fix For: 1.0.15.Final, 1.1.0.Beta4
>
>
> The pool statistics' "Available" shows wrong value (one less than "max-pool-size") after fill pool.
> For example, min-pool-size=5, max-pool-size=10 and prefill=true are set to datasource configuration:
> {code:xml}
> <pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>10</max-pool-size>
> <prefill>true</prefill>
> </pool>
> {code}
> Then, when checking pool stats via CLI after JBoss start-up, the results shows the following:
> {code}
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS/statistics=pool/:read-resource(recursive=false,proxies=false,include-runtime=true,include-defaults=true)
> {
> "outcome" => "success",
> "result" => {
> "ActiveCount" => "5",
> "AvailableCount" => "9",
> "AverageBlockingTime" => "0",
> "AverageCreationTime" => "3",
> "CreatedCount" => "5",
> "DestroyedCount" => "0",
> "MaxCreationTime" => "4",
> "MaxUsedCount" => "1",
> "MaxWaitTime" => "0",
> "TimedOut" => "0",
> "TotalBlockingTime" => "0",
> "TotalCreationTime" => "17"
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JBVFS-185) Switch to 'mkdirs'
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/JBVFS-185?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski updated JBVFS-185:
-------------------------------------
Summary: Switch to 'mkdirs' (was: Remove static initializers from TempFileProvider)
> Switch to 'mkdirs'
> -------------------
>
> Key: JBVFS-185
> URL: https://issues.jboss.org/browse/JBVFS-185
> Project: JBoss VFS
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
>
> TempFileProvider has:
> {code}
> static {
> String configTmpDir = System.getProperty(JBOSS_TMP_DIR_PROPERTY);
> if (configTmpDir == null)
> configTmpDir = System.getProperty(JVM_TMP_DIR_PROPERTY);
> try {
> TMP_ROOT = new File(configTmpDir, "vfs");
> TMP_ROOT.mkdirs();
> }
> catch (Exception e) {
> throw new RuntimeException("Can't set up temp file provider", e);
> }
> }
> {code}
> This does its job fine when VM starts, but if something removes the directory, ie. as part of cleanup, provider stops, since createTempDir:
> {code}
> private static File createTempDir(String prefix, String suffix, File root) throws IOException {
> for (int i = 0; i < RETRIES; i++) {
> final File f = new File(root, createTempName(prefix, suffix));
> if (f.mkdir())
> return f;
> }
> throw new IOException(
> String.format("Could not create directory for root '%s' (prefix '%s', suffix '%s') after %d attempts",
> root,
> prefix,
> suffix,
> RETRIES));
> }
> {code}
> So either the static init is removed and performed for each provider( in constructor or better, in some kind of init() meethod ) or createTempDir calls File.mkdirs()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-3199) RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
by Ryan Connolly (JIRA)
[ https://issues.jboss.org/browse/AS7-3199?page=com.atlassian.jira.plugin.s... ]
Ryan Connolly edited comment on AS7-3199 at 2/22/13 7:13 AM:
-------------------------------------------------------------
I have run into this a couple of times now. Workaround for internal code means a single API base URI which probably makes sense for most web apps. The problem comes into play when using third party libs that supply classes that extend Application. I hit this recently while evaluating http://velopers.helloreverb.com/swagger/ for instance.
Re-reading this thread, I'm still amazed at how angry bill sounds in the first few comments. Read your book, bill. Thanks for the read. Hope you got some rest. (No pun intended).
was (Author: rynam0):
I have run into this a couple of times now. Workaround for internal code means a single API base URI which probably makes sense for most web apps. The problem comes into play when using thiribs that supply classes that extend Application. I hit this recently while evaluating http://velopers.helloreverb.com/swagger/ for instance.
Re-reading this thread, I'm still amazed at how angry bill sounds in the first few comments. Read your book, bill. Thanks for the read. Hope you got some rest. (No pun intended).
> RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
> ---------------------------------------------------------------------------------------------
>
> Key: AS7-3199
> URL: https://issues.jboss.org/browse/AS7-3199
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Attachments: ExampleJAXRS.war
>
>
> If I packed WAR WebApp with more that one subclass of javax.ws.rs.Application, deployment fails with "JBAS011232: Only one JAX-RS Application Class allowed."
> This is not correct because it is against JAX-RS 1.1. specs where invalid situation (in section 2.3.2) is only when "It is a n error for
> more than one application to be deployed +at the same effective servlet mapping+".
> If you have any objections, please compare to reference JEE6 and JAX-RS implementation represented by the GlassFish Prelude 3.1.1 application server with already +fully JEE6 platform support+.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-3199) RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
by Ryan Connolly (JIRA)
[ https://issues.jboss.org/browse/AS7-3199?page=com.atlassian.jira.plugin.s... ]
Ryan Connolly commented on AS7-3199:
------------------------------------
I have run into this a couple of times now. Workaround for internal code means a single API base URI which probably makes sense for most web apps. The problem comes into play when using thiribs that supply classes that extend Application. I hit this recently while evaluating http://velopers.helloreverb.com/swagger/ for instance.
Re-reading this thread, I'm still amazed at how angry bill sounds in the first few comments. Read your book, bill. Thanks for the read. Hope you got some rest. (No pun intended).
> RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
> ---------------------------------------------------------------------------------------------
>
> Key: AS7-3199
> URL: https://issues.jboss.org/browse/AS7-3199
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Attachments: ExampleJAXRS.war
>
>
> If I packed WAR WebApp with more that one subclass of javax.ws.rs.Application, deployment fails with "JBAS011232: Only one JAX-RS Application Class allowed."
> This is not correct because it is against JAX-RS 1.1. specs where invalid situation (in section 2.3.2) is only when "It is a n error for
> more than one application to be deployed +at the same effective servlet mapping+".
> If you have any objections, please compare to reference JEE6 and JAX-RS implementation represented by the GlassFish Prelude 3.1.1 application server with already +fully JEE6 platform support+.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (DROOLS-49) Improve Drools project to support deploymet on JBoss Fuse (Apache Karaf) platform
by Charles Moulliard (JIRA)
[ https://issues.jboss.org/browse/DROOLS-49?page=com.atlassian.jira.plugin.... ]
Charles Moulliard updated DROOLS-49:
------------------------------------
Description:
Existing Drools project has already been modified to support OSGI but the work done is incomplete, buggy and cannot be deployed like that on Apache Karaf (JBoss Fuse).
In order to allow Drools deployment on Karaf container, I suggest that first we prepare a uberjar bundle of Drools project (1) before to decide strategy to adopt to deploy Drools on OSGI platform and expose OSGI service (2)
Description of work already done
1) Add maven-felix bundle, packaging = bundle & define package to be imported/exported for drools-spring, drools-camel, drools-persistence-jpa, drools-decision-tables
2) Create a provisioning feature file to deploy Drools project on Apache Karaf 2.3.0
3) Create a itest project validating approach on Karaf with pax-exam & drools example
was:
Existing Drools project has already been modified to support OSGI but the work done is incomplete, buggy and cannot be deployed like that on Apache Karaf (JBoss Fuse).
In order to allow Drools deployment on Karaf container, I suggest that first we prepare a uberjar bundle of Drools project (1) before to decide strategy to adopt to deploy Drools on OSGI platform and expose OSGI service (2)
Description done
1) Add maven-felix bundle, packaging = bundle & define package to be imported/exported for drools-spring, drools-camel, drools-persistence-jpa, drools-decision-tables
2) Create a provisioning feature file to deploy Drools project on Apache Karaf 2.3.0
3) Create a itest project validating approach on Karaf with pax-exam & drools example
> Improve Drools project to support deploymet on JBoss Fuse (Apache Karaf) platform
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-49
> URL: https://issues.jboss.org/browse/DROOLS-49
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5
> Reporter: Charles Moulliard
> Assignee: Mark Proctor
>
> Existing Drools project has already been modified to support OSGI but the work done is incomplete, buggy and cannot be deployed like that on Apache Karaf (JBoss Fuse).
> In order to allow Drools deployment on Karaf container, I suggest that first we prepare a uberjar bundle of Drools project (1) before to decide strategy to adopt to deploy Drools on OSGI platform and expose OSGI service (2)
> Description of work already done
> 1) Add maven-felix bundle, packaging = bundle & define package to be imported/exported for drools-spring, drools-camel, drools-persistence-jpa, drools-decision-tables
> 2) Create a provisioning feature file to deploy Drools project on Apache Karaf 2.3.0
> 3) Create a itest project validating approach on Karaf with pax-exam & drools example
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months