[angryYarn]

I seem to have broken something in my ejbdoclet task (both when run in Blue->MyEclipse->Run XDoclet and when run from ANT outside of Blue). Now, when it generates interfaces, it also creates a manager folder next to my ejb folder, and puts *Manager classes in it. Our EJB bean classes are weird in that some of them extend *Manager classes in a “Manager” java project. The bean inherits from that Manager class in the different project; that works OK. But now ejbdeploy creates a duplicate class, same package and class, so there is an error:
[ejbdoclet] The class “com.my.package.BandingAreaToLotTaskManager” occurs in more than one fileset. That’s illegal.

Any ideas?

Thanks,
Phil.

[Robert Varga]

@angryYarn wrote:

I seem to have broken something in my ejbdoclet task (both when run in Blue->MyEclipse->Run XDoclet and when run from ANT outside of Blue). Now, when it generates interfaces, it also creates a manager folder next to my ejb folder, and puts *Manager classes in it. Our EJB bean classes are weird in that some of them extend *Manager classes in a “Manager” java project. The bean inherits from that Manager class in the different project; that works OK. But now ejbdeploy creates a duplicate class, same package and class, so there is an error:
[ejbdoclet] The class “com.my.package.BandingAreaToLotTaskManager” occurs in more than one fileset. That’s illegal.

Any ideas?

Thanks,
Phil.

Hi Phil,

The following applies to XDoclet1 not XDoclet2:

you can look around using the havingClassTag attribute of the session Xdoclet subtask in the ejbdoclet task.

Alternatively you can look at this XDoclet bug I submitted with a patch (and on which the XDoclet guys haven’t acted for years, I think) for an in some cases somewhat more convenient approach for the super-class not to be generated instead of being generated (in case some sources need generation of the session but you are not able to alter the sources of that class therefore not being able to use havingClassTag attribute):

http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1675

I think this might help…

Best regards,

Robert

[Robert Varga]

@angryYarn wrote:

I seem to have broken something in my ejbdoclet task (both when run in Blue->MyEclipse->Run XDoclet and when run from ANT outside of Blue). Now, when it generates interfaces, it also creates a manager folder next to my ejb folder, and puts *Manager classes in it. Our EJB bean classes are weird in that some of them extend *Manager classes in a “Manager” java project. The bean inherits from that Manager class in the different project; that works OK. But now ejbdeploy creates a duplicate class, same package and class, so there is an error:
[ejbdoclet] The class “com.my.package.BandingAreaToLotTaskManager” occurs in more than one fileset. That’s illegal.

Any ideas?

Thanks,
Phil.

Hi Phil,

The following applies to XDoclet1 not XDoclet2:

you can look around using the havingClassTag attribute of the session Xdoclet subtask in the ejbdoclet task.

Alternatively you can look at this XDoclet bug I submitted with a patch (and on which the XDoclet guys haven’t acted for years, I think) for an in some cases somewhat more convenient approach for the super-class not to be generated instead of being generated (in case some sources need generation of the session but you are not able to alter the sources of that class therefore not being able to use havingClassTag attribute):

http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1675

I think this might help…

Best regards,

Robert

[Robert Varga]

Ehh… no hourglass in IE7 upon posting…

[angryYarn]

Robert, thanks for your response. The problem was indeed due to a change I made. I had modified the bean’s parent classes to implement SessionBean, but I don’t remember why. Removing the “implements SessionBean” clause from the ejb’s parent class solved the problem.

Thanks,
Phil.

[angryYarn]

Ah now I remember. Running the WsEjbDeploy ANT task has this error:

[*Error] ImportedClasses/com/blah/manager/TaskEngine.class(Class: com.blah.manager.TaskEngine): CHKJ2017E: This class must implement javax.ejb.SessionBean (EJB 2.0: 7.5.1, 7.10.2).

That’s why I changed the TaskEngine class (the parent of the bean) to implement SessionBean.

The WsEjbDeploy task I am using also does not generate CORBA Tie classes, so perhaps there is something wrong with the version of WsEjbDeploy that I am using:
classpath=”${WebSphere 6 installation}/plugins/com.ibm.ws.runtime_6.1.0.jar” />
classname=”com.ibm.websphere.ant.tasks.WsEjbDeploy”

Anyone know a better one, or what Blue uses to do the RMIC stub generation?

[angryYarn]

Here is what I did to get around this problem:
My session bean no longer inherits from POJO superclass.
For every public method in session bean, added a pass-through method to POJO superclass.
The pass-through methods call the corresponding method in the POJO superclass.

I can now build an EAR using ANT. It has no Tie classes in it; that problem is documented in this thread:
https://www.genuitec.com/forums/topic/wsejbdeploy-is-not-genereating-quot-tie-quot-classes/&highlight=

[Author]

Posts