FileGeneration/Wlappc not including local ejb interfaces in client jar

Question

With the following setting in the EJB source:
@FileGeneration(
          remoteClass = Constants.Bool.TRUE,
          remoteHome = Constants.Bool.TRUE,
          remoteClassName = "ReportService",
          remoteHomeName = "ReportServiceHome",
          localClass = Constants.Bool.TRUE,
          localHome = Constants.Bool.TRUE,
          localClassName = "ReportSvc",
          localHomeName = "ReportSvcHome")
          @JarSettings(ejbClientJar = "dist/ReportFacadeClient.jar")
          @JndiName(remote="service-ReportFacade", local="local-ReportFacade")
          @Session(maxBeansInFreePool = "100",
                    initialBeansInFreePool = "10",
                    transTimeoutSeconds = "0",
                    type = Session.SessionType.STATELESS,
                    defaultTransaction = Constants.TransactionAttribute.SUPPORTS,
                    ejbName = "statelessSession",
                    enableCallByReference = Constants.Bool.TRUE)
Along with the "<ejb-client-jar>ReportServiceClient.jar</ejb-client-jar>" entry in the ejb-jar.xml
the ant build script invocation of wlappc successfully creates the "dist/ReportFacadeClient.jar" file as specified which includes the Remote Home and Remote interface, however the local definitions are absent.
It is confirmed that the wlcompile does create the local implementation and interface files, they are just missing from the client jar.
Do I need to manually append them to the jar or is there a configuration setting that I am missing to have this done automatically as is is done
for the remote interface?
Thanks.

Answer 1

Hi,
the local interface and local home is for local client which is within the same application (.ear). So local client needn't any client jar. it can always load the classes (local interface, local home, etc. ) it needs.
so there isn't needs to put local interface and local home to a client jar.
the client jar is for client out of the application, and it will be a remote invocation certainly.