[JBoss JIRA] (AS7-6643) Consider JSF/Groovy support
by Stan Silvert (JIRA)
Stan Silvert created AS7-6643:
---------------------------------
Summary: Consider JSF/Groovy support
Key: AS7-6643
URL: https://issues.jboss.org/browse/AS7-6643
Project: Application Server 7
Issue Type: Feature Request
Components: JSF
Reporter: Stan Silvert
Assignee: Stan Silvert
Mojarra JSF includes the ability to use Groovy as an alternative to Java. Since the work is already done for JSF integration, we might want to include it. Presumably, this would only require shipping a Groovy runtime.
Currently, there is a bug in Mojarra 2.2 that, when running a CDI app, produces a stack trace saying that Mojarra/Weld can't find the Groovy classloader. This error does not cause any real problems with the app, but it needs to be addressed upstream in Mojarra.
{noformat}
10:22:11,468 INFO [org.jboss.weld.ClassLoading] (MSC service thread 1-8) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.faces.scripting.groovy.GroovyHelperImpl$MojarraGroovyClassLoader
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:167) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.bootstrap.BeanDeployer.loadWeldClass(BeanDeployer.java:116) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:135) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:63) [jboss-as-weld-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1972)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1905)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
Caused by: java.lang.NoClassDefFoundError: groovy/lang/GroovyClassLoader
at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.7.0_15]
at java.lang.Class.privateGetDeclaredFields(Class.java:2317) [rt.jar:1.7.0_15]
at java.lang.Class.getDeclaredFields(Class.java:1762) [rt.jar:1.7.0_15]
at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:105) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:102) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:102) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:155) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:121) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:59) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:358)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:396)
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:163) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
... 11 more
Caused by: java.lang.ClassNotFoundException: groovy.lang.GroovyClassLoader from [Module "com.sun.jsf-impl:main" from local module loader @40334c25 (finder: local module f
inder @67cc3210 (roots: C:\as7trunk\jboss-as\build\target\jboss-as-8.0.0.Alpha1-SNAPSHOT\modules,C:\as7trunk\jboss-as\build\target\jboss-as-8.0.0.Alpha1-SNAPSHOT\modules\
system\layers\base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.2.0.CR2]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.CR2]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.CR2]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.CR2]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.CR2]
... 29 more
{noformat}
--
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, 2 months
[JBoss JIRA] (AS7-6397) Cluster Environment Web Session Locks
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-6397?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-6397:
------------------------------------------
Manuel
An update. In trying to reproduce the error you are seeing, I set up an Apache load balancer + two node cluster with non-sticky sessions, firing thousands of requests at the load balancer. This setup caused each request to be processed at a node different from the one before it, and so forced the global locking mechanism to transfer lock ownership from one node to the other. I did not see any problems in this configuration in all my test scenarios.
Where I did manage to recreate the problem was by setting a reply_timeout on the workers, so that if the processing of a request took longer than the reply timeout, the load balancer would not wait for completion of the request and would retry the same request on an alternate host. This would create a situation where the original request (now considered failed by the load balancer) and the failed over request were simultaneously needing access to the same lock, and the exception would result.
I am still investigating what happens with the locking mechanism after the condition occurs.
However, in the mean time, please check to see if you have retry_timeout values set for your workers. If they are set, increasing these values may allow a long-running request time to complete before it is failed over and restarted on another node. This is one possible explanationfor what you are seeing.
In fact, if you could let me know which load balancer you are using and its configuration, that would be helpful.
Richard
> Cluster Environment Web Session Locks
> -------------------------------------
>
> Key: AS7-6397
> URL: https://issues.jboss.org/browse/AS7-6397
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.1.Final
> Environment: Windows 7 64bits, 8 GB RAM
> Reporter: Manuel Pinto
> Assignee: Paul Ferraro
> Attachments: AS7-4260.patch
>
>
> Hi,
> I found a problem with web session locks in a cluster environment. We have two Liferay 6.1.1 nodes (over JBoss 7.1.1 Final) in standalone-ha.xml configuration with infinispan "web" cache-container, replicated-cache and file store. The load balancer is configured in non sticky session mode.
> Problem: when a node processes requests in some cases locks the session and never unlock it, preventing other node from processing requests for that session. The affected node never regain the locked session and keep throwing the following exception for all subsequent requests and only recover a session when other node shutdown:
> Note: we also tried invalidation-cache and distributed-cache and all locking modes but without success.
> 17:39:00,174 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http--172.16.250.105-8080-4) An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Cvn-K+r-cBGesIBoDrakJhrO
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:496) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.connector.Request.doGetSession(Request.java:2625) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:81) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//Cvn-K+r-cBGesIBoDrakJhrO from cluster
> at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
> at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372)
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> ... 12 more
> The standalone-ha.xml "web" cache-container config is the following:
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="SYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="sso" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> Thanks,
> Manuel Pinto
--
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, 2 months
[JBoss JIRA] (JGRP-1604) SEQUENCER problems and slowness
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1604?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1604:
--------------------------------
Also check performance of UnicastTestRpc, which doesn't use multicasts, as it's also slow with SEQUENCER on the stack !
> SEQUENCER problems and slowness
> -------------------------------
>
> Key: JGRP-1604
> URL: https://issues.jboss.org/browse/JGRP-1604
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> On high volumes of messages (e.g. MPerf), SEQUENCER runs out of memory.
> The culprit is the forward-table, which is unbounded, and if messages are added as a faster rate than the time it takes to forward the message to the coordinator (sequencer) and for it to be received as a multicast and subsequently be removed from the forward-table, memory increases.
> This also makes SEQUENCER slow.
> SOLUTION:
> * Look into bounding the forward-table, e.g. define the max number of bytes to be in the table at any given time
> * When a message is to be added, its length is checked (Message.getLength())
> ** If the length is 0 or length + accumulated bytes is less than max: add, else block
> * A received message (sent by self) causes the entry to be removed from the forward-table and its length to be subtracted from accumulated bytes (unblocking potentially blocked threads)
> We should also look at delivery table and see if we can make it simpler, e.g. by running a gathering round when a new sequencer is chosen, determining the highest seqnos of all members
--
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, 2 months
[JBoss JIRA] (AS7-6376) Separate attribute for custom transaction isolation
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6376?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri resolved AS7-6376.
----------------------------------
Resolution: Rejected
Rejecting due to last Jesper's comment
> Separate attribute for custom transaction isolation
> ---------------------------------------------------
>
> Key: AS7-6376
> URL: https://issues.jboss.org/browse/AS7-6376
> Project: Application Server 7
> Issue Type: Enhancement
> Components: Domain Management, JCA
> Reporter: Brian Stansberry
> Assignee: Stefano Maestri
> Fix For: 7.3.0.Alpha1
>
>
> Request is to create a list of allowed values for "transaction-isolation" and use a separate alternative attribute for the edge cases where a custom value is desired.
> hbraun: take a look at https://gist.github.com/4594850
> [08:01am] hbraun: the description contains a list of allowed values
> [08:01am] hbraun: do we have a formalised way to describe this within the model?
> [08:02am] hbraun: https://community.jboss.org/wiki/DetypedDescriptionOfTheAS7ManagementModel doesn't contain it
> [08:03am] bstansberry: hbraun: use https://docs.jboss.org/author/display/AS71/Description+of+the+Management+... now
> [08:03am] hbraun: tnx
> [08:03am] bstansberry: which is the same thing, but in the more maintained stream
> [08:03am] bstansberry: hbraun: but yes, it should be formally described
> [08:04am] bstansberry: hbraun: under "Arbitrary Descriptors" see "allowed"
> [08:05am] hbraun: bstansberry: great, exactly what I was looking for
> [08:05am] hbraun: I knew we had something like this
> [08:05am] bstansberry: hbraun: so if that's missing it's a bug
> [08:06am] bstansberry: there's a standard way of adding that for attributes backed by an enum
> [08:08am] bstansberry: hbraun: where is that attribute? datasource subsystem?
> [08:08am] hbraun: yeah
> [08:10am] bstansberry: hbraun: ok, the reason "allowed" isn't set is because custom levels are supported
> [08:11am] hbraun: hm
> [08:11am] hbraun: i would prefer an extra attribute for customisation
> [08:11am] hbraun: and let them be mutual exclusive
> [08:11am] hbraun: cases like this prevent a successful move to a dynamic GUI
> [08:13am] hbraun: the less ambiguity the better
> [08:13am] hbraun: especially in the DMR model
--
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, 2 months
[JBoss JIRA] (AS7-6376) Separate attribute for custom transaction isolation
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/AS7-6376?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen commented on AS7-6376:
--------------------------------------
[~brian.stansberry] there shouldn't be two attributes for this, as it should match the XSD and how it is handled by all app servers.
It should be modelled by the type of the field - a field which has a number of constants, but still allows custom overrides. Which is done in AS7-5666.
> Separate attribute for custom transaction isolation
> ---------------------------------------------------
>
> Key: AS7-6376
> URL: https://issues.jboss.org/browse/AS7-6376
> Project: Application Server 7
> Issue Type: Enhancement
> Components: Domain Management, JCA
> Reporter: Brian Stansberry
> Assignee: Stefano Maestri
> Fix For: 7.3.0.Alpha1
>
>
> Request is to create a list of allowed values for "transaction-isolation" and use a separate alternative attribute for the edge cases where a custom value is desired.
> hbraun: take a look at https://gist.github.com/4594850
> [08:01am] hbraun: the description contains a list of allowed values
> [08:01am] hbraun: do we have a formalised way to describe this within the model?
> [08:02am] hbraun: https://community.jboss.org/wiki/DetypedDescriptionOfTheAS7ManagementModel doesn't contain it
> [08:03am] bstansberry: hbraun: use https://docs.jboss.org/author/display/AS71/Description+of+the+Management+... now
> [08:03am] hbraun: tnx
> [08:03am] bstansberry: which is the same thing, but in the more maintained stream
> [08:03am] bstansberry: hbraun: but yes, it should be formally described
> [08:04am] bstansberry: hbraun: under "Arbitrary Descriptors" see "allowed"
> [08:05am] hbraun: bstansberry: great, exactly what I was looking for
> [08:05am] hbraun: I knew we had something like this
> [08:05am] bstansberry: hbraun: so if that's missing it's a bug
> [08:06am] bstansberry: there's a standard way of adding that for attributes backed by an enum
> [08:08am] bstansberry: hbraun: where is that attribute? datasource subsystem?
> [08:08am] hbraun: yeah
> [08:10am] bstansberry: hbraun: ok, the reason "allowed" isn't set is because custom levels are supported
> [08:11am] hbraun: hm
> [08:11am] hbraun: i would prefer an extra attribute for customisation
> [08:11am] hbraun: and let them be mutual exclusive
> [08:11am] hbraun: cases like this prevent a successful move to a dynamic GUI
> [08:13am] hbraun: the less ambiguity the better
> [08:13am] hbraun: especially in the DMR model
--
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, 2 months
[JBoss JIRA] (JGRP-1604) SEQUENCER problems and slowness
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1604?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1604:
--------------------------------
The same problem is present in FORWARD_TO_COORD's forward-table.
> SEQUENCER problems and slowness
> -------------------------------
>
> Key: JGRP-1604
> URL: https://issues.jboss.org/browse/JGRP-1604
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> On high volumes of messages (e.g. MPerf), SEQUENCER runs out of memory.
> The culprit is the forward-table, which is unbounded, and if messages are added as a faster rate than the time it takes to forward the message to the coordinator (sequencer) and for it to be received as a multicast and subsequently be removed from the forward-table, memory increases.
> This also makes SEQUENCER slow.
> SOLUTION:
> * Look into bounding the forward-table, e.g. define the max number of bytes to be in the table at any given time
> * When a message is to be added, its length is checked (Message.getLength())
> ** If the length is 0 or length + accumulated bytes is less than max: add, else block
> * A received message (sent by self) causes the entry to be removed from the forward-table and its length to be subtracted from accumulated bytes (unblocking potentially blocked threads)
> We should also look at delivery table and see if we can make it simpler, e.g. by running a gathering round when a new sequencer is chosen, determining the highest seqnos of all members
--
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, 2 months
[JBoss JIRA] (JGRP-1604) SEQUENCER problems and slowness
by Bela Ban (JIRA)
Bela Ban created JGRP-1604:
------------------------------
Summary: SEQUENCER problems and slowness
Key: JGRP-1604
URL: https://issues.jboss.org/browse/JGRP-1604
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
On high volumes of messages (e.g. MPerf), SEQUENCER runs out of memory.
The culprit is the forward-table, which is unbounded, and if messages are added as a faster rate than the time it takes to forward the message to the coordinator (sequencer) and for it to be received as a multicast and subsequently be removed from the forward-table, memory increases.
This also makes SEQUENCER slow.
SOLUTION:
* Look into bounding the forward-table, e.g. define the max number of bytes to be in the table at any given time
* When a message is to be added, its length is checked (Message.getLength())
** If the length is 0 or length + accumulated bytes is less than max: add, else block
* A received message (sent by self) causes the entry to be removed from the forward-table and its length to be subtracted from accumulated bytes (unblocking potentially blocked threads)
We should also look at delivery table and see if we can make it simpler, e.g. by running a gathering round when a new sequencer is chosen, determining the highest seqnos of all members
--
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, 2 months
[JBoss JIRA] (DROOLS-57) Split packages: OSGi packaging issue/conflict with Kie API & Kie Internal
by Charles Moulliard (JIRA)
[ https://issues.jboss.org/browse/DROOLS-57?page=com.atlassian.jira.plugin.... ]
Charles Moulliard commented on DROOLS-57:
-----------------------------------------
The problem is more general as drools-core (or drools-compiler I think so) should use packages exported by kie-api & kie-internal-api but as the package is the same, that clash (see here for more info : http://wiki.osgi.org/wiki/Split_Packages).
Remark : I have also used split but problem is still there
{code}
<Bundle-SymbolicName>org.kie.internalapi</Bundle-SymbolicName>
<!--<Require-Bundle>org.kie.api;visibility:=reexport;bundle-version="${drools.osgi.version}"</Require-Bundle>-->
<Import-Package>
!org.kie*,
com.sun.tools.xjc;resolution:=optional,
*
</Import-Package>
<Export-Package>
org.kie.*;org.kie.internalapi=split;mandatory:=org.kie.internalapi
</Export-Package>
{code}
{code}
<Bundle-SymbolicName>org.kie.api</Bundle-SymbolicName>
<Import-Package>
!org.kie*,
com.sun.tools.xjc;resolution:=optional,
*
</Import-Package>
<Export-Package>
org.kie.*;org.kie.api=split;mandatory:=org.kie.api
</Export-Package>
{code}
{code}
<Bundle-SymbolicName>org.drools.core</Bundle-SymbolicName>
<!-- Should be removed after refactoring of org.kie api -->
<Require-Bundle>
org.kie.internalapi,
org.kie.api
</Require-Bundle>
<Import-Package>
!org.drools*,
com.sun.tools.xjc*;resolution:=optional,
org.drools.io.impl,
org.osgi.util.tracker,
*
</Import-Package>
<Export-Package>
org.drools.*
</Export-Package>
{code}
karaf@root> start 72
Error executing command: Error starting bundles:
Unable to start bundle 72: Unresolved constraint in bundle org.drools.core [72]: Unable to resolve 72.5: missing requirement [72.5] osgi.wiring.package; (osgi.wiring.package=org.kie)
> Split packages: OSGi packaging issue/conflict with Kie API & Kie Internal
> -------------------------------------------------------------------------
>
> Key: DROOLS-57
> URL: https://issues.jboss.org/browse/DROOLS-57
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Charles Moulliard
> Assignee: Mark Proctor
>
> Due to overlap of packages between module kie-api & kie-internal, some classes of kie-internal are not found by kie-api
> example :
> Caused by: java.lang.ClassNotFoundException: org.kie.KieBaseConfiguration not found by org.kie.api [88] = KIE API
> The class org.kie.KieBaseConfiguration should be exported by the bundle kie-internal and imported by kie-api on OSGI platform and this is not the case as both bundles import/export same package org.kie
> {code}
> Bundle 88 = kie api & bundle 89 = kie internal
> karaf@root> packages:exports 88
> ID Packages
> 88 org.kie.event.rule; version=6.0.0.SNAPSHOT
> 88 org.kie.command; version=6.0.0.SNAPSHOT
> 88 org.kie.event.kiebase; version=6.0.0.SNAPSHOT
> 88 org.kie.definition; version=6.0.0.SNAPSHOT
> 88 org.kie.definition.process; version=6.0.0.SNAPSHOT
> 88 org.kie.runtime.rule; version=6.0.0.SNAPSHOT
> 88 org.kie.event.process; version=6.0.0.SNAPSHOT
> 88 org.kie.conf; version=6.0.0.SNAPSHOT
> 88 org.kie.runtime.help; version=6.0.0.SNAPSHOT
> 88 org.kie.runtime.conf; version=6.0.0.SNAPSHOT
> 88 org.kie.management; version=6.0.0.SNAPSHOT
> 88 org.kie.definition.type; version=6.0.0.SNAPSHOT
> 88 org.kie.definition.rule; version=6.0.0.SNAPSHOT
> 88 org.kie.io; version=6.0.0.SNAPSHOT
> 88 org.kie.marshalling; version=6.0.0.SNAPSHOT
> 88 org.kie.builder.model; version=6.0.0.SNAPSHOT
> 88 org.kie.time; version=6.0.0.SNAPSHOT
> 88 org.kie; version=6.0.0.SNAPSHOT
> 88 org.kie.runtime; version=6.0.0.SNAPSHOT
> 88 org.kie.runtime.process; version=6.0.0.SNAPSHOT
> 88 org.kie.logger; version=6.0.0.SNAPSHOT
> 88 org.kie.builder; version=6.0.0.SNAPSHOT
> 88 org.kie.concurrent; version=6.0.0.SNAPSHOT
> 88 org.kie.cdi; version=6.0.0.SNAPSHOT
> 88 org.kie.persistence.jpa; version=6.0.0.SNAPSHOT
> 88 org.kie.osgi.api; version=6.0.0.SNAPSHOT
> 88 org.kie.event; version=6.0.0.SNAPSHOT
> karaf@root> packages:exports 89
> ID Packages
> 89 org.kie.event.rule; version=6.0.0.SNAPSHOT
> 89 org.kie.command; version=6.0.0.SNAPSHOT
> 89 org.kie.internal.utils; version=6.0.0.SNAPSHOT
> 89 org.kie.runtime.helper; version=6.0.0.SNAPSHOT
> 89 org.kie.builder.conf; version=6.0.0.SNAPSHOT
> 89 org.kie.fluent; version=6.0.0.SNAPSHOT
> 89 org.kie.definition; version=6.0.0.SNAPSHOT
> 89 org.kie.conf; version=6.0.0.SNAPSHOT
> 89 org.kie.builder.help; version=6.0.0.SNAPSHOT
> 89 org.kie.io; version=6.0.0.SNAPSHOT
> 89 org.kie.event.io; version=6.0.0.SNAPSHOT
> 89 org.kie.marshalling; version=6.0.0.SNAPSHOT
> 89 org.kie.fluent.test; version=6.0.0.SNAPSHOT
> 89 org.kie.agent.conf; version=6.0.0.SNAPSHOT
> 89 org.kie; version=6.0.0.SNAPSHOT
> 89 org.kie.runtime; version=6.0.0.SNAPSHOT
> 89 org.kie.simulation; version=6.0.0.SNAPSHOT
> 89 org.kie.event.knowledgeagent; version=6.0.0.SNAPSHOT
> 89 org.kie.logger; version=6.0.0.SNAPSHOT
> 89 org.kie.builder; version=6.0.0.SNAPSHOT
> 89 org.kie.concurrent; version=6.0.0.SNAPSHOT
> 89 org.kie.persistence.jpa; version=6.0.0.SNAPSHOT
> 89 org.kie.agent; version=6.0.0.SNAPSHOT
> 89 org.kie.event; version=6.0.0.SNAPSHOT
> 89 org.kie.task.service; version=6.0.0.SNAPSHOT
> karaf@root> packages:imports 89
> System Bundle (0): javax.xml.bind; version=2.2.1
> OPS4J Pax Logging - API (4): org.slf4j; version=1.7.1
> OPS4J Pax Logging - API (4): org.slf4j; version=1.6.6
> OPS4J Pax Logging - API (4): org.slf4j; version=1.5.11
> OPS4J Pax Logging - API (4): org.slf4j; version=1.4.3
> Apache ServiceMix :: Bundles :: xstream (57): com.thoughtworks.xstream; version=1.4.3
> KIE API (88): org.kie.event.rule; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.command; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.event.kiebase; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.definition; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.definition.process; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.runtime.rule; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.event.process; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.conf; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.runtime.help; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.runtime.conf; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.management; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.definition.type; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.definition.rule; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.io; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.marshalling; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.builder.model; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.time; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.runtime; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.runtime.process; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.logger; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.builder; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.concurrent; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.cdi; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.persistence.jpa; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.osgi.api; version=6.0.0.SNAPSHOT
> KIE API (88): org.kie.event; version=6.0.0.SNAPSHOT
> camel-core (229): org.apache.camel.spi; version=2.10.3
> camel-core (229): org.apache.camel; version=2.10.3
> {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, 2 months
[JBoss JIRA] (JBWEB-266) Cookie Processing of JSON Cookie destroys Cookie Header
by Remy Maucherat (JIRA)
[ https://issues.jboss.org/browse/JBWEB-266?page=com.atlassian.jira.plugin.... ]
Remy Maucherat commented on JBWEB-266:
--------------------------------------
Yes, it can be improved, but it is a bit more complex. The original value is almost never useful since the unescape processing is rather expensive and the cookie API is rather nice.
> Cookie Processing of JSON Cookie destroys Cookie Header
> -------------------------------------------------------
>
> Key: JBWEB-266
> URL: https://issues.jboss.org/browse/JBWEB-266
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-7.0.1.GA
> Environment: Windows 7 x64 and RHEL/CentOS 5.x, Java 1.7.0_11, JBoss AS 7.0.2 Final
> Reporter: Manuel Coenen
> Assignee: Remy Maucherat
>
> When sending a cookie with JSON content to JBoss the automatic cookie processing (triggered by looking for a session cookie) modifies the {{byte[]}} buffer which is also used for the HTTP headers.
> This is due to multiple objects depending on the same {{byte[]}} buffer instance. The following hierarchy should demonstrate this dependency:
> {noformat}
> Http11Processor.request (Request)
> └> cookies (Cookies)
> | └> scookies[] (ServerCookie)
> | └> scookies[x] (where x is the index referencing the JSON cookie)
> | └> value (MessageByte)
> | └>byteC (ByteChunk)
> | \
> | |-> buff (byte[])
> | /
> | ┌> byteC (ByteChunk)
> | ┌> valueB (MessageByte)
> | ┌> headers[y] (where y is the index referencing the JSON cookie header)
> | ┌> headers[] (MimeHeaderField)
> └> headers (MimeHeader)
> {noformat}
> The method {{Cookies.unescapeDoubleQuotes(ByteChunk)}} modifies this buffer by overwriting its contents when removing the escaped double-quotes. This in return destroys the reference for the header as it will still maintain the {{start}} and {{end}} reference inside this buffer. If the value for this header is read later it will be the unescaped content trailed by the surplus escaped region (see reproduction instructions for a more detailed example).
> In my opinion the method {{Cookies.unescapeDoubleQuotes(ByteChunk)}} should copy the {{byte[]}} first to avoid side effects to other parts referencing this {{byte[]}} as it could be (and is in our case) that the headers (including cookie) need to be forwarded unmodified to another server.
--
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, 2 months