Bug 195385

(In reply to comment #0)
> Netbeans 7 beta [...] never package libraries into EJB jar.

This was intentionally removed as it does not make any sense - no version of EE specification requests that EJB jar should package its dependencies this way.

Package checkbox works as expected. In case of 'EJB module in EAR' scenario the checkbox decides which JARs will be packaged into the EAR. In case of 'standalone EJB module' scenario these jars are deployed in server specific way, eg. --libraries option in GlassFish.

(In reply to comment #1)

Well, but "Package" checkbox still present, so why not make it working? Why delete useful feature?

Packaging jar with remote interfaces into ejb jar is very important!

(In reply to comment #2)
> (In reply to comment #1)
> 
> Well, but "Package" checkbox still present, so why not make it working? Why
> delete useful feature?
> 
> Packaging jar with remote interfaces into ejb jar is very important!

I do not understand what you mean by this. Could you elaborate how are you using this? Why is packaging jar with remote interfaces important? It is not required by EE servers.

The checkbox is there to express what should be deployed to server and that's working as expected as far as I know.

(In reply to comment #3)
> I do not understand what you mean by this. Could you elaborate how are you
> using this? Why is packaging jar with remote interfaces important?

Imagine we deploy single ejb jar to server. Where to place jar with remote interfaces? It should be inseparable from ejb jar. So, packaging jar with remote interfaces into the ejb jar is only option.

Well, if ejb jar deployed as part of EAR, then jar with remote interfaces can be placed into lib folder, as EAR deployed as single unit. But in case of standalone ejb jar all that we need should be packaged into this standalone jar.

> It is not required by EE servers.

But it works in any Netbeans versions prior to 7! Why broke compatibility with earlier versions? Where to place remote interfaces in case of standalone ejb? Please note, Netbeans 7 forces placing remote interfaces into separate library project.

> The checkbox is there to express what should be deployed to server and that's
> working as expected as far as I know.

Please check how it works in Netbeans 6.9.1 (or any other version prior to 7) - libraries which marked as "Package" checkbox packaged into ejb jar.

Thanks for explanation. Unfortunately this "feature" was result of misunderstanding of EE specification or just a mistake which did happen long time ago and was present in several NB releases. I understand the convenience of distributing remote EJB interfaces alongside of EJB implementation but that's exactly what EAR is for - in simplest for all what EAR does is it packages bunch of EE module jars and library jars they depend on.

You are likely aware of this but once your EJB implementation starts depending on other jars then all these jars used to be packaged inside EJB jar as well. Again, this is done without any reason or use.

Existing code (and Ant scripts) dealing with packaging J2EE modules is quite complex and supporting a feature which is actually a mistake or side effect or does not have any justification from EE spec point of view makes maintenance and new features development very hard. That's why I removed it.

Remote EJB interfaces are enforced to be stored in separate JAR and again it was mistake that this has not happened much earlier. Keeping remote interface classes along classes which implement that interface in single jar does not make any sense. Remote interfaces are for other (remote) clients to communicate with EJBs and compile against these interfaces. That's why remote interfaces should be defined in separate jar and be available separately for remote clients. If remote access is not needed then local interfaces should be used instead.

Last thing I would say is that it should not be hard to customize Ant script of EJB module to include jar with remote interfaces in it if that's still what you would prefer. I'm happy to help with that if needed. I'm also happy to reconsider this issue if there would be strong support from community in favor of this "feature".

*** Bug 196043 has been marked as a duplicate of this bug. ***

WORKAROUND

To workaround this new netbeans behavior, add <target> into build.xml:

<target depends="compile" name="library-inclusion-in-archive">
    <copyfiles files="${reference.NameOfDependent.jar}" todir="${build.classes.dir}"/>
</target>

Where NameOfDependent.jar is the name of dependency jar, which should be packaged into main project jar.

*** Bug 198167 has been marked as a duplicate of this bug. ***

We also used that feature extensively at work with Jboss EJBs.
The problem of the workarround is that is not GUI based.

*** Bug 198504 has been marked as a duplicate of this bug. ***

lujop, rpelting, could you please explain how were you using this feature - why storing required JARs in the root of EJB JAR is useful? As I explained earlier I removed this 'feature' because it is not mandated in any EE spec. Thanks!

We use it in Jboss EJBs because it works and it's very simple.
We also use it to make JBoss SARs, we only have to rename .jar to .sar

(In reply to comment #11)
> lujop, rpelting, could you please explain how were you using this feature - why
> storing required JARs in the root of EJB JAR is useful? As I explained earlier
> I removed this 'feature' because it is not mandated in any EE spec. Thanks!

Hello David, I simply upgraded from Netbeans 6.9.1 to 7.0 and because this
target doesn't work as before, I considered that this must be an error.

I read your comment #5 and figured out that I abused this feature to produce
something like a "poor man's EAR", which in fact was just a simple JAR file.

I generated now an new empty Java EE Enterprise Application project and
added the existing EJB Module to this project.
Now I have the 'EJB module in EAR' scenario as you described in comment #1
and everything works fine.

Thanks for your help.

(In reply to comment #12)
> We use it in Jboss EJBs because it works and it's very simple.

lujop, does deployment of standalone EJB JAR (which depends on a few JARs) from NetBeans to JBoss works? If not could you please file an issue for serverpluging/jboss component. For example Glassfish has "--libraries" option on deployment command which is used to deploy required JARs and apart from packing of EJB jar you should not notice any different from previous versions of NB. If there would be enormous support in favor of keeping required jars inside EJB jar then I'm happy to reconsider putting the feature back. The solution I would use in such case would be probably a dedicated checkbox somewhere in EJB project properties saying "[ ] Package required JARs in EJB jar". Thanks.

Hi David Konecny,

We use it this feautre too and it is strange projects which worked before now don't run on production neither on development. If we try to deploy the project with netbeans in local JBoss, it fails as it don't found the jars dependencies.

The workaround is a little scary, because we have to check all projects and add targets which aren't easy discovereable (we have to open nbproperties to find reference.NameOfDependent.jar).

Uff! What a messy! 

(In reply to comment #14)
> (In reply to comment #12)
> > We use it in Jboss EJBs because it works and it's very simple.
> 
> lujop, does deployment of standalone EJB JAR (which depends on a few JARs) from
> NetBeans to JBoss works? If not could you please file an issue for
> serverpluging/jboss component. For example Glassfish has "--libraries" option
> on deployment command which is used to deploy required JARs and apart from
> packing of EJB jar you should not notice any different from previous versions
> of NB. If there would be enormous support in favor of keeping required jars
> inside EJB jar then I'm happy to reconsider putting the feature back. The
> solution I would use in such case would be probably a dedicated checkbox
> somewhere in EJB project properties saying "[ ] Package required JARs in EJB
> jar". Thanks.

I'm sorry for the inconvenience. I would like to repeat what I said in comment #14 - could you please file a new defect for component serverpluging/jboss describing what JBoss versions you run and how reproduce the problem. A simple test project demonstrating the problem would be appreciated. I'm not familiar with JBoss so I would prefer somebody else to file the issue and describe it. Despite internal changes how EJB projects are packaged the deployment should just work. Thanks.

But I really think that this is the correct DEFECT report.
Because if we open another bug report for deploy from Netbeans we only solve the half of the problem.
Becuase when we want to deploy to production server we will have to make the workarround manually, and that makes no sense.

Hi all,

I have the same problem whit EJB distribution. Not happens before Netbeans 7.0 so i assume it will be solved as it's probably a bug of this version. Hope will be soon. Thanks.

Ok, i'm working on large Project. 200+ subprojects and libraries, over 200 000 classes. Because reconfigure programming model is to expensive. I'm stuck in 6.9.1.

Everything is based on jboss single ejb archives, and swing clients.

Now I have a question, that bug/feature will be added back or not ?

Thanks

*** Bug 199864 has been marked as a duplicate of this bug. ***

Based on the feedback this change needs to be revisited.

a simple EJB project which makes use of some class files from a jar file
that does not contain any javaee components should be able to be
deployed as a simple EJB module -- it should not be required to
be made into a EAR module.

This current bug disallows any jar files being part of the EJB jar,
even when they are not Java EE component classes.

emiddio, in your scenario I think the problem is in integration of GlassFish v211 into NetBeans. GlassFish 3.0 does not manifest this problem and deployment of single EJB module works fine.

I would like to keep distinction between two problems:

#1) deployment of standalone EJB module from the IDE - that should always work. If it does not then integration module of such server must to be fixed. Just file an issue for such server plugin.

#2) inclusion of required jars in standalone EJB module jar - this is not Java EE specification requirement but based on feedback so far IDE should support this feature

to try and clarify some more issues i see -- mostly at this time regarding
j2ee1.4 ejb2.1 type ejb modules... and inability to make use of a jar file
to be included in the ejb module distribution ...

imagine a number of re-usable EJB components -- i have been working with
ejb2.1 entity beans from the j2ee 1.4 petstore 1.4 blueprints sample recently,

There is a standalone Address EJB module with one ejb --  Address.

then i have a ContactInfo standalone entity ejb module that has
2 EJB's -- the Address, and a ContactInfo ejb.

and a purchaseOrder ejb with 5 entity ejb's in the module,
Address, ContactInfo, CreditCard, LineItem, and PurchaseOrder.

By the way, CreditCard, LineItem, are also like Address -- reusable standalone
ejb classes, and EBJ project modules.

The class files for these ejb's (invidivdual ejbs, not ejb modules) are just
class files that could be all stored into a single jar archive.

Nothing magic about them -- they only become j2ee components when put inside
an ejb.jar file with a ejb-jar.xml -- which defines how the ejb-module appears
as a j2ee component -- multiple entity beans --different tables -- related
to each other --like a bunch of JPA entity classes within a persistence.xml
file --that ties them all together.

when generic EJB classes can be reused -- all one needs is a new ejb-jar.xml file in each ejb module project -- and a jar file that can provide the classes
referenced by the ejb-jar.xml file.

in principle one can obtain all these various EJB modules with various combinations EJB components -- without any java files -- just ejb-jar.xml, and
perhaps other ejb configuration xml files within each EJB module project -- and
only the ability to reference the jar file that contains all the referenced
EJB classes.

i do not see how this is a netbeans integration issue with glasfish -- the
EJB module must contain all it needs for deployment -- I can log into glassfish and deploy via the admin console the ejb jar file - and netbeans has nothing
to do with deployment.

i have only been required to use directory deployment with gfv3+ and netbeans.
but i can still build a j2ee project --ear, ejb, war -- and deploy without
making use of netbeans via admin console.

As a separate note -- it seems that something "perhaps" not done "right" in
numerous previous releases should not be "fixed" if its going to break things for users -- netbeans is a tool -- why should it police/prohibit doing something that might violate a spec -- the user should ultimately decide what they want to do -- and netbeans should help them do it -- not refuse to let them do what they want. Encouraging doing things "right" should be enough.

We can always unzip are jar files into the project and then build our ejb and get the results we want or like previously posted we can hand modify the
build-impl.xml --but please dont make us do that.

I appreciate all your feedback guys! And based on that I reopened this issue and will try to resolve this in next release.

A few more comments inlined:

(In reply to comment #24)
> i do not see how this is a netbeans integration issue with glasfish -- the
> EJB module must contain all it needs for deployment -- I can log into glassfish
> and deploy via the admin console the ejb jar file - and netbeans has nothing
> to do with deployment.

GlassFish admin console (some 3.x version if I remember well) also has "Libraries" field which you are supposed to use and fill in all required jars on which standalone EJB jar you are deploying depends. It does not expect jars to be in the root of EJB jar. Or maybe it does accept them in the root because that's how GF 2.x used to do it and for backward compatibility the option was left there. But as far as I remember (year or two ago!)(likely result of discussion with GF team) the recommended way was to follow spec and do not package jars in EJB jar.

> As a separate note -- it seems that something "perhaps" not done "right" in
> numerous previous releases should not be "fixed" if its going to break things
> for users -- netbeans is a tool -- why should it police/prohibit doing
> something that might violate a spec -- the user should ultimately decide what
> they want to do -- and netbeans should help them do it -- not refuse to let
> them do what they want. Encouraging doing things "right" should be enough.

This has a simple explanation: NetBeans source code is huge and when you are doing major upgrade (ie. support new EE 6) and have less rather than more resources then you have to decide how to go about it. And this particular "feature" was under-documented, not required by EE spec and GF recommendation was to use admin's "--libraries" parameter. So it was dropped rather than upgraded. It is impossible to keep dead looking branch of code and still move forward. Thanks to your feedback the purpose of the feature is more obvious now and has a justification which it did not have before.

> We can always unzip are jar files into the project and then build our ejb and
> get the results we want or like previously posted we can hand modify the
> build-impl.xml --but please dont make us do that.

Well, I do think that this problem has several workarounds (eg.: use EAR to package your dependencies; override default project's build script; use older NetBeans version; upgrade to EE6 and package your EJBs in WAR).

please point us to the relevant part of the spec you are referring to.

i have been trying to look up info on the net regarding this issue and have
been only able to find "some" info -- it seem that some of this issue was
not "fully" covered by the spec .

and finally -- has the spec changed between j2ee1.4 and EE6 regarding this issue?

Oh -- also -- i thought --deployable units --EAR, EJB, WAR were expected to be
fully self contained -- you suggest that additional meta data needs to be
specified outside of the containing package unit  -- if so this type of info
should be contained in something like sun-ejb-jar.xml  or sun-application.xml -- vs ejb-jar.xml or application.xml, -- ie -- vendor specific info outside of the spec which would still be part of the deployable unit.

BTW --there is no option with the admin console to specify libraries - all it
asks for is EAR, EJB, or WAR  -- no libraries.


thanks

gary

(In reply to comment #26)
> please point us to the relevant part of the spec you are referring to.
> 
> i have been trying to look up info on the net regarding this issue and have
> been only able to find "some" info -- it seem that some of this issue was
> not "fully" covered by the spec .

This was my main point - it is not specified and so each server implements it differently.

> and finally -- has the spec changed between j2ee1.4 and EE6 regarding this
> issue?

I do not think so. What changed though is reference implementation of EE spec - GlassFish.

> Oh -- also -- i thought --deployable units --EAR, EJB, WAR were expected to be
> fully self contained -- you suggest that 

I do not suggest anything. :-) I'm just trying to deal with reality - they are deployable units but interpretation of deployable unit is on server implementation. That's why in my comment #23 I look at this problem from two angles: from IDE it can always work because each NetBeans server plugin can use NetBeans project metadata and deploy EJB to server in sever specific manner; but when it comes to packaging EJB jar I did not want to enforce GlassFish v2 approach of packaging required jars in the root of EJB jar. However, it looks like JBoss is following the same path. I have not found yet how Weblogic deals with this.

> additional meta data needs to be
> specified outside of the containing package unit  -- if so this type of info
> should be contained in something like sun-ejb-jar.xml  or sun-application.xml
> -- vs ejb-jar.xml or application.xml, -- ie -- vendor specific info outside of
> the spec which would still be part of the deployable unit.

You should raise this issue with EE spec leads. Earlier this year somebody told me that packaging of jars in EJB case should be clarified in next spec (EE7?) but I have no idea whether it was a wishful thinking or a real commitment.
 
> BTW --there is no option with the admin console to specify libraries - all it
> asks for is EAR, EJB, or WAR  -- no libraries.

In admin console when you choose "Deploy Applications or Modules" and select "EJB Jar" type then bunch of fields appear and one of them at the bottom is "Libraries". I tested this once (could have been some daily builds of GF v3.0 about two years ago) and it worked - painfully complicated as all jars has to be enumerated but it worked.

re comment#27 -- specifically,

> additional meta data needs to be
> specified outside of the containing package unit  -- if so this type of info
> should be contained in something like sun-ejb-jar.xml  or sun-application.xml
> -- vs ejb-jar.xml or application.xml, -- ie -- vendor specific info outside of
> the spec which would still be part of the deployable unit.

You should raise this issue with EE spec leads. Earlier this year somebody told
me that packaging of jars in EJB case should be clarified in next spec (EE7?)
but I have no idea whether it was a wishful thinking or a real commitment.
-----


sun-ejb-jar.xml and sun-application.xml -- were part of j2ee 1.4 and netbeans
support of j2ee 1.4; it has always been the case that these extra meta-info
files were part of the EJB/WAR/EAR deployable units -- and were customized
for each particular server implementation -- sun's App Server 8.1 and 8.2
both taught us via the j2ee 1.4 tutorial to make use of these files. Netbeans
automatically updates, creates these files.

glassfish V2 made use of sun-application.xml and sun-ejb-jar.xml and so
did netbeans support of glassfish V2.

with glassfish V3 they seem to be migrating towards glassfish-application.xml,
and glassfish-ejb-jar.xml files names.

netbeans "should" know how to generate these files and would --if support for
non-directory based deploying had not been removed from netbeans for glassfish
V3 releases.

These files are the proper place for this information to be kept. Support for
non directory based deploying should be brought back in to netbeans.

The folks at dev@glassfish.java.net should know how this should be done -- have you consulted with them ?

Please do.

What I wanted to say is that my preferred solution is to sort out the EE spec. What you suggest about server specific deployment descriptors make perfect sense as well.

(In reply to comment #28)
> The folks at dev@glassfish.java.net should know how this should be done -- have
> you consulted with them ?

No, I have not. Independent user voice like your one has much more power so I would suggest you discuss it with them or file an issue in their BugZilla.

(In reply to comment #23)
> I would like to keep distinction between two problems:
> 
> #1) deployment of standalone EJB module from the IDE - that should always work.
> If it does not then integration module of such server must to be fixed. Just
> file an issue for such server plugin.
> 
> #2) inclusion of required jars in standalone EJB module jar - this is not Java
> EE specification requirement but based on feedback so far IDE should support
> this feature

Here is how I'm fixing #2. The fix has two parts:

1. To avoid confusion I renamed "Package" label in EJB Project Properties in Libraries panel as it is not about packaging but whether a library should be used only for compilation or also in runtime. New name is "Required in runtime" - I welcome any suggestions with better name. This option tells IDE which libraries it needs to use when EJB jar is being packaged into EAR or in case when EJB jar is being deployed to a server in standalone EE module mode.

2. If user desires to store all required jars in root of EJB jar there is a new option in EJB Project Properties in Packaging panel labeled "Package required JARs in EJB jar". Ticking this box will result in all jars marked as "Required in runtime" being also included in EJB jar root.

I would appreciate your feedback whether this addresses the problem and whether it works for servers you are using (ie. JBoss, GF2.x, etc.). You may have to download NB Dev nightly build containing this bug fix in day or two. If you would like to update your existing projects in batch then just add "jars.in.ejbjar=true" to nbproject/project.properties of your EJB projects.

Fixed in: 47f8feda4e3f

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/47f8feda4e3f
User: David Konecny <dkonecny@netbeans.org>
Log: #195385 - Netbeans 7 beta/dev ignores "Package" checkbox for "compile time libraries"

I see this is marked as fixed, nonetheless I am using NetBeans IDE 7.0.1 (Build 201107282000) and I can't see the new option Comment #30 is referring to.
Do I have to download another version ?

Thanks

(In reply to comment #32)
> I see this is marked as fixed, nonetheless I am using NetBeans IDE 7.0.1 (Build
> 201107282000) 

It was fixed for NB 7.1, that is in the trunk development line. See target milestone.