By maintaining the shaded lib's under application server there is a
drawback as these libraries get released each time we are doing an AS
release. So better to came up with a common location where we can maintain
and release separately as our orbit mode.
On possible approach we can use is
On Tue, May 10, 2016 at 5:15 PM, Chiranga Alwis wrote:
> +1
>
> But shouldn't the naming of the module be more generic? Using "shaded"
> refers more towards the implementation where we have used the plugin
> Maven-Shade-Plugin. We have effectively relocated the classes.
>
>
+1
But shouldn't the naming of the module be more generic? Using "shaded"
refers more towards the implementation where we have used the plugin
Maven-Shade-Plugin. We have effectively relocated the classes.
/modules/*relocated-libs*
|- slf4j
+1
*Manoj Kumara*
WSO2 Inc. *| **lean. enterprise. middleware.*
*Mobile:* +94 713 448188
On Tue, May 10, 2016 at 3:58 PM, KasunG Gajasinghe wrote:
>
> Yes, we need to avoid having common logging frameworks such as SLF4J in
> the classpath since it has a good possibility to
Yes, we need to avoid having common logging frameworks such as SLF4J in the
classpath since it has a good possibility to lead to classloading issues
for webapp developers .
Since slf4j could be used by multiple jars, it should be a separate shaded
jar. I believe the *artifactId* should reflect
+1, let's use the AS repo and at build time, which can get installed during
build time and this will also become part of release which will be deployed
onto nexus.
Is the naming is correct? Shouldn't it be "shaded"?
On Tue, May 10, 2016 at 3:00 PM, Manoj Kumara wrote:
> Hi
Hi Dev's,
During testing WSO2AS 6.0.0 we encounters $Subject error when SLF4j library
available on the webapp libs directory as /lib also contain the
same library to be used by libthrift library used during stat publishing.
After analyzing the issue with the team realized that this occurred as