You can specify the packages attribute on the root Configuration element.
http://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax


On 22 August 2014 18:31, Henrik Østerlund Gram <henrik.g...@gmail.com>
wrote:

> The Log4j2Plugins.dat is in the jar with the plugins I created, but while
> the various wars/jars have a dependency on that jar file, the plugin jar
> file itself needs to be present only in the ear's lib folder (along with
> log4j and other classes that may be passed between webapps to ejbs as each
> module gets its own classloader but shares the parent classloader.)   I'll
> just note that I'm using JBoss/Wildfly, but I believe it's in the spec that
> each module gets its own classloader, so the problem should be the same
> elsewhere I think.
>
> I do like the annotation-processor way of generating the dat file - it
> simplifies things - it's just that the automatic detection at runtime is
> real difficult to debug to find out why something isn't being picked up and
> I think it may be more natural simply being able to specify the class for
> your custom converters in the config file with the expectation of getting
> an error if the framework can't find the classes you specify rather than
> "failing silenty".
>
> Regards,
> Henrik
>
> On Sat, Aug 23, 2014 at 12:58 AM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
>
> > Using the annotation processor seemed like a more natural and automatic
> > way to invoke the plugin processor.  If there are ways we can configure
> > things to make it easier just let us know.  The processor doesn’t look in
> > just one jar though so I don’t know why it didn’t find your file.
> Logically
> > the Log4j2Plugins.dat file should be in the same jar as the plugins you
> > have created. Are you not including them in the ejb jar?
> >
> > Ralph
> >
> > On Aug 22, 2014, at 1:30 PM, Henrik Østerlund Gram <
> henrik.g...@gmail.com>
> > wrote:
> >
> > > Thanks a lot for that tip!  It turns out I had to copy the
> > > Log4j2Plugins.dat file (which *was* actually being generated from the
> > > annotations processor) from the jar that contained my logging classes
> and
> > > other utils, into the jar that contained my ejbs and as that
> initialized
> > > before any of the actual webapps, that was enough to make it work for
> all
> > > webapps (probably since I use a single logger.)
> > >
> > > I don't really understand why this was changed; it's extremely
> > inconvenient
> > > having to do this and surely it's much better that the framework looks
> > for
> > > it in the entire classpath rather than in just one jar.
> > >
> > > Thanks again,
> > > Henrik
> > >
> > > On Fri, Aug 22, 2014 at 9:59 PM, Clément Guillaume <
> > cguilla...@hotpads.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> I'm also using some custom plugins and several project and wars. I
> just
> > >> succeeded to setup a maven build that generate the Log4j2Plugins.dat.
> > >>
> > >> First I enable the annotation processor on the project that content my
> > >> plugins:
> > >>
> > >> <plugin>
> > >> <groupId>org.bsc.maven</groupId>
> > >> <artifactId>maven-processor-plugin</artifactId>
> > >> <version>2.2.1</version>
> > >> <executions>
> > >> <execution>
> > >> <id>process</id>
> > >> <goals>
> > >> <goal>process</goal>
> > >> </goals>
> > >> <phase>process-sources</phase>
> > >> </execution>
> > >> </executions>
> > >> <dependencies>
> > >> <dependency>
> > >> <groupId>org.apache.logging.log4j</groupId>
> > >> <artifactId>log4j-core</artifactId>
> > >> <version>2.0.1</version>
> > >> </dependency>
> > >> </dependencies>
> > >> </plugin>
> > >>
> > >> And after I copy the Log4j2Plugins.dat from the generated archive (a
> > jar in
> > >> my case) to the finals wars:
> > >>
> > >>   - I use unpack of the maven-dependency-plugin
> > >>   - I include the file in my wars.
> > >>
> > >>
> > >> Clément
> > >>
> > >>
> > >> On Fri, Aug 22, 2014 at 12:09 PM, Henrik Østerlund Gram <
> > >> henrik.g...@gmail.com> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I had been using the betas for a couple of years and everything was
> > fine.
> > >>> But unfortunately I cannot seem to make 2.0.x work.
> > >>>
> > >>> I have couple of plugins (converters) that are annotated properly,
> but
> > >> the
> > >>> automatic detection of these never did work and I had to use the
> follow
> > >>> maven step to create the necessary Log4j2Plugins.dat for it to work.
> > >>>
> > >>> <plugin> <groupId>org.codehaus.mojo</groupId>
> > >>> <artifactId>exec-maven-plugin</artifactId> <version>1.2.1</version>
> > >>> <executions> <execution> <phase>process-classes</phase> <goals>
> > >>> <goal>java</goal> </goals> </execution> </executions> <configuration>
> > >>>
> > >>>
> > >>
> >
> <mainClass>org.apache.logging.log4j.core.config.plugins.PluginManager</mainClass>
> > >>> <arguments>
> > >>> <argument>${project.build.directory}/../src/main/resources</argument>
> > >>> <argument>my.package</argument> </arguments> </configuration>
> </plugin>
> > >>> But since rc2 the PluginManager was disabled, and it's now seemingly
> > >>> impossible to get the plugins registered. The source for
> PluginManager
> > >>> suggests looking at the configuration page supposedly using the
> > packages
> > >>> attr to tell the framework where to scan for plugins, but again, that
> > >> just
> > >>> doesn't work.  I used that as well in the betas where it also did not
> > >> work.
> > >>>
> > >>> Perhaps in trivial project setups it works fine, I don't know, but I
> > have
> > >>> an ear with multiple .wars and a common single log4j2 (present in the
> > >> ear's
> > >>> lib where the jar for my converters is also present) and I don't know
> > why
> > >>> it cannot pick it up.
> > >>>
> > >>> Any workarounds?  I can't understand why it should be this difficult
> to
> > >>> register a converter.
> > >>>
> > >>> Regards,
> > >>>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >
> >
>



-- 
Matt Sicker <boa...@gmail.com>

Reply via email to